Hacker News Reader

Comment by duxup | Hacker News Reader

I wonder if people think work involving web assembly will coalesce around a few languages over time?

LLVM kinda proved having a common target back-end doesn't kill language diversity, it actually achieves the opposite.

One could still ask the question, though.

The way that coding language and deployment/executable language have been tied together (JS for both) has served as a force that pushed everyone toward that single language.

Now that WebAssembly promises to remove that force, will it be a free-for-all, or will other forces push toward standardization on a few languages? And if so, what will those forces be?

Likely the ones that are on the bandwagon early.

To be even more specific, in the early days now, the main allure of wasm is performance. So the focus will be on languages and toolchains capable of generating optimized native code. Out of those, look at which ones are easy for the developer to set up (both in general, and for wasm) on all popular developer OSes.

So, I'd say that Rust will probably be the biggest beneficiary.

C#/.NET will be in that bandwagon. They have been pushing WebAssembly usage with their Blazor framework.

The performance angle is interesting. Right now JS has lots of mindshare and momentum for obvious reasons, so maybe the things that will take off at first are the ones that help web developers in specific areas where JS performance is not good enough, perhaps graphics for example.

I wonder if web development were to shift dramatically... would it go to largely one or a few languages?

There are always few languages that dominate a niche.

I imagine binary size would be a concern for web development, what is a negative for complex runtimes... But then, if I carefully set the compiler to trim dead code, my Haskell email server is smaller than any modern JS framework (still larger than a new version Jquery), so the runtime may not actually make much of a difference.

I think "native" web-tech like JavaScript & HTML will still have a lot of momentum in it. WASM is about other languages getting access to browser as a delivery platform. I wonder if language JavaScript that was originally designed to run on the web should have a competitive edge here?

The drawback of JavaScript has so far been its low execution speed, maybe WASM will make it run faster.

In other words maybe WASM will not be the downfall of JavaScript but its uplift.

Absolutely, have a look at that:

https://assemblyscript.org

Cool. And Types too!

It seems to me that, given the incredible number of person-years put into making Javascript fast, it's probably approaching its max speed of execution already without modifying the language itself. I'd expect the C/C++ interpreters are already using so many tricks to speed it up that remaining gains would be difficult without adding more information to the language itself (e.g. stricter typing) or modifying the way it works (fewer things represented as objects, more types of collections).

In short, I suspect the actual instructions executed when JS runs on a modern interpreter are already pretty damn close to what a fairly well-optimized JS-to-WASM compiler would provide. If you want more major gains I think you'd have to start looking at locking down (or at least providing the option to lock down, in performance-critical code) the ability of Javascript to do all kinds of wacky stuff at runtime.

Isn't it mostly aimed at C/C++/Rust right now?

Reply on news.ycombinator.com