The argument I'm making is one for increased choice in the technologies we have available to us as web developers, particularly when it comes to writing applica

The argument I'm making is one for increased choice in the technologies we have available to us as web developers, particularly when it comes to writing applications that aim to accommodate users with slower/more affordable devices. In a lot of cases, shipping a wasm blob is not that bad. Depending on the language; compressed and optimized blobs are only a few kilobytes and can be "code-split" such that they are lazy loaded. Wasm binaries also evaluate faster than JavaScript which could lead to better "web vital" metrics (like "time to first paint/interactive", though anyone can write a slow application in any language so that's not a given). Syntactically, there is nothing missing from other programming languages that make them unsuited to working with DOM APIs. The real blocker is waiting for wasm to gain access to DOM APIs thereby dropping the need for JavaScript glue code - once that constraint is lifted, I see no reason why it wouldn't be practical to use an alternative to JavaScript for web development. JavaScript is practical and useful in _most_ web development cases because the runtime is built in, the ecosystem around it is quite mature and the use cases aren't that complex - however there are many cases that would benefit from more performant languages (think YouTube, Jira, VSCode, banking apps, etc). When thinking about the "next billion" internet users (related to the topic of the article), we are going to see more users with affordable devices that feature many cores with lower clock speeds. In such contexts it is vital to efficiently leverage the available client device hardware resources - something that JavaScript isn't well suited to and something most of us don't experience (the privilege of having fast computing hardware). Take multi-threading as an example. JavaScript's single threaded non-blocking nature is safe/ergonomic from a programming perspective and fantastic on devices that feature fast individual cores - however it falls over when clients have slower devices with more cores. Ideally, we need _the choice_ to follow a more conventional multi-threaded model in cases where we care about performance (a UI thread + worker threads, like we see in native apps/desktop applications). The only initiative that has the potential to get us there is wasm.