Client-side Processing and WebAssembly Explained ​

Honeycomb works a bit differently than traditional location data and mapping tools. Rather than relying on a server to process data and send it to your web browser, Honeycomb utilizes a technology called WebAssembly to handle the computation within the web browser itself.

This approach results in a highly responsive experience, as updates to the map can occur with no perceptible lag in most cases. However, this approach comes with a few drawbacks - including slower initial loading times and a limit to the amount of data that can be loaded into the tool.

In this article we'll dive into why Honeycomb uses WebAssembly and what it means for you as you use the tool.

Clients and servers ​

The internet is made up of billions of networked devices. At a high level, these can be divided into clients and servers. Clients are devices that are in front of users - like your laptop or phone. Servers are a different type of computer that typically sits further away from the user, perhaps at a company office ('on premise') or in a managed server farm ('in the cloud').

Part of computer system architecture is deciding which tasks should be done by the server and which should be done by the client. Historically, clients have had relatively less computing power compared to servers, so many applications were built as 'thin-client' systems where the server would handle much of the computation and send the results to the client for display.

MapQuest, ESRI, and Google Maps are all built following this 'thin-client' approach. As users are interacting with a map on their device, the device is requesting new data from a server. For example, if the user zooms in on a heatmap, their device will send a request to the server for new map data for the zoomed-in view. The server then computes results and returns them to the user.

Latency and responsiveness ​

However, one of the drawbacks of relying on a remote server to compute results is the amount of latency between the client's device and the server. This latency can cause map tools to feel slow and be frustrating to use. A typical rule-of-thumb is that an interface must respond within 80ms in order for the user to feel 'in control'.

Because information can only travel at the speed of light, the distance between a client's device and the server handling their requests determines a minimum amount of latency a user will experience. The round-trip latency between Amsterdam and San Francisco is 144ms. This means that even if the most advanced fiber connections are used, and a large amount of compute power is dedicated to the task, data will still take 144ms to make the trip, resulting in a subpar user experience.

Honeycomb moves computation to the client side ​

In contrast to most other geospatial tools on the market today, Honeycomb handles data processing on the client side and does not rely on a backend server for computations. Because data is processed directly on the user's computer, there's no need to wait for a response from a remote server, and the user experiences a highly responsive map.

In addition to creating a more responsive user experience, processing data on the client side is also more secure, as it does not need to be sent to a third-party server for processing. As it is purely a visualization tool and not a data processor, Honeycomb is ideal for sensitive location data like home addresses which may be considered PII and subject to regulation under GDPR and CCPA schemes.

Client-side data processing also enables better scalability, as additional users do not lead to large increases in backend compute resources. This means that companies using Honeycomb can scale from a small number of initial users to a company-wide deployment without worrying about slower performance or higher costs from additional users.

Utilizing WebAssembly for efficient client-side data processing ​

Honeycomb runs completely in a web browser (all major browsers are supported) and does not need to be installed on users' computers. Traditional web applications were limited by the web browser execution environment, which only supported HTML, CSS, and JavaScript.

In 2018, all major browsers began supporting WebAssembly (or 'Wasm'). WebAssembly lets browsers run advanced programs that are compiled from other languages. Although WebAssembly isn't very well-known (yet!), it's likely that the tools you already use rely on it. For example, Figma's smooth graphics editing experience is powered by Wasm, and so is ESRI's on-the-fly map reprojection capability.

Honeycomb uses WebAssembly to run a custom version of DuckDB, a state-of-the-art column-oriented OLAP data processing engine. By calculating results on the client and using additional GPU optimizations, Honeycomb can deliver most map and chart updates in under 80ms, resulting in an extremely smooth user experience. This performance is maintained even with hundreds of thousands of points displayed on the map. Parts of this proprietary technology are patent pending.

Drawbacks of client-side data processing ​

While client-side data processing provides fast updates and a smooth user experience, it isn't without drawbacks. Here are the two main drawbacks:

• Data and code must be loaded to the client, resulting in slower startup times.
• Client devices have resource limitations.

The first time you use Honeycomb, it may take a bit longer to load. This is because the WebAssembly bundle and the data to be analyzed must be loaded to the client. This can be made more efficient by utilizing a CDN as well as caching the bundle between loads (Honeycomb does both). In addition, Honeycomb supports using range requests to selectively load only the parts of large data files that are needed.

Laptops today are tremendously more powerful than they were 10 years ago. However, laptops are still portable consumer devices and have less processing power than dedicated servers. More tangibly, the current 32-bit memory layout of WebAssembly means that it can only use 4GB of memory. This means that any datasets loaded into Honeycomb must be less than 4GB (which varies based on data but is about 10M rows). See the related article, "Analyzing massive amounts of data with Honeycomb" for ideas on how to effectively work within this limitation.

What it means for you: Honeycomb's client-side processing unlocks powerful location data analysis ​

By leveraging client-side data processing, Honeycomb Maps are highly responsive with less latency, leading to higher user satisfaction and usage. Moving processing to the client side also means that private data does not need to be sent to a third-party server and simplifies scaling as the number of users rises.