This is why I'm excited for Web Assembly. Writing an efficient high performance, mutli-threaded GUI in Rust or Go would be awesome.
Just waiting on it to be practically usable
Just waiting on it to be practically usable
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.
The problem isn't the technologies available to us. Majority of devs just have no desire to write efficient code.
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.