I wouldn't be so sure. The browser ultimately need to render the UI from the DOM which is intrinsically linked with JavaScript. Wasm can help for some of the application logic maybe. But it also comes at a cost of some fixed overhead to bring up the wasm blob. JavaScript performance aren't that bad for UI.
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.
I hear you. I think it's important to lead by example here and demonstrate the value of performant software that is accessible to a wider range of users/devices.
Native apps do demonstrate that there are performance gains to be made with languages better suited for runtime performance (think threads, AOT compilation, etc)
Just because there is currently a culture in the web development world that de-emphasises the importance of performance, doesn't mean we shouldn't strive to offer better tools to developers.
Right now, wasm is the only feature on the web that has the potential to offer that capability to developers - so I'd say that it's worth wanting and asking for the choice to use better tools for web applications.
Just waiting on it to be practically usable