Writing A CrossPlatform Internet Speed Testing CLI Tool, And Exporting A WebAssembly Version

Its 2020, WebAssembly is becoming a buzzword. It promises to make non JS, And Even JS developers more productive, by allowing developers build for the browser in almost any language.

So, how best do we take this bad boy for a spin and explore how feasible this technology would be in building the future of the web ?

The Challenge:

I and a friend have been discussing and explored building an internet speed testing app, for me this avenue provided a chance to dig into networking, and explore how the lower level pieces work when for example an http call is made. It also provided a chance to learn how networking is implemented on the browser via how it is done on a machine.

The Solution:

Speed testing applications are very simple under the hood. They basically monitor how much data can be uploaded or download per second. But is is not always that trivial, alot of factors can affect this measurement, for example

1. Latency due to distance - This made me understand, that computer networks are not magic. If The server is far away from the client, take for example in another country, or continent, this would greatly impact latency, that is why things like CDN are very important for performance in web frontend. Next time you use any tool to speed test, make sure to look at the location of the server.

2. Latency due to server - This might not really count, but if you must build an effective speed testing app, it would be best to ensure nothing slows down the request server end, like blocking the request, and or poor http implementation.

3. Poorly written client - Streaming and efficiently handling the transport layer is key to having better measurements. If you wait and buffer things too much before sending over the transport. It might affect the measurement.

4. Network Protocol - While TCP/IP is mostly used as the transport for http, the protocol might impact measurement. Like the round trip that happens at the beginning of transport. Packet size also imposed by the TCP protocol is another thing to consider.

Since speed test is mostly based on rough estimation, factors above can easily be handled.

Porting To WebAssembly :

Writing the CLI version was fairly straight forward due to the rich OS/Kernel APIs available. WASM version was a little diffrent

1. WebAssembly Still Relies on JS - Sad news all non-JS fans, while WASM is good and all, access to the DOM and other browser apis are still tightly coupled to JS, and in most cases you would need to call into JS for basic things.

2. Networking Stack Still Uses the fetch Api - Using WASM i sort of expected some magic around http calls. Soon realised nothing is really different from standard js . The fetch api also brought the cors issue again 😅.

3. WASM Size in Go - Writing the WASM part with GO meant that i had to bring along the Go WASM runtime, GC and other packages. At the end i hit a size of 8MB, there might be ways to optimise for size, but for performance sake when choosing to write solution for webassembly, this is defiantly something to consider.

In conclusion, this project offered a chance to dig into some networking primitives, also allowed me to explore WebAssembly and the future it promises. I still think WebAssembly still has a long way to go, especially decoupling the browser away from JS, Other languages still have to evolve to be more WASM friendly.

Project Is Available Here .. Alpha Release And Binaries Are available Here