Comment by jillesvangurp | Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

IMHO things like WASM, web vr, and LLVM are all converging this year after years of cool demos, prototypes and gradual progress. Having Rust out there as a first class citizen is awesome. This year we should see the beginning of a minor revolution in front end development, where essentially anything targeting LLVM will be able to compile to WASM, be bundled as an NPM, and be usable in the context of web application for essentially anything done in javascript until now whether it is performance critical algorithms, manipulating the dom, writing to canvas, driving IO via web sockets, dealing with web gl and web vr, audio, etc.

Breaking the monopoly Javascript has had on this space for close to 25 years is a good thing. Perhaps people will continue to use it but it will have to be on merits rather than just merely being the only game in town. In any case looking forward to having more choice in this space.

IMHO, modern JS based frontend development is a combination of tedious, error prone, and backwards. If this honestly is the state of the art, then WTF. happened in the past 20 years.

I agree with your two first paragraphs. I want to share some elements to complete your outlook.

Javascript, despite having monopoly on the client side since 2007, only saw its usage exploded with Node and NPM around 2013. Java applets and Flash were long dead by then. So it seems that JS success is only partially correlated to its hard-won monopoly on the client side. My intuition is that JS ecosystem cannot be that bad and win so many hearts. Using your words, it seems JS won based on some merits.

A few others clues: Hot reloading, fast build time, good debugging and profiling tools, lots of packages, plenty of already answered problems on stackoverflow/github, progressive complexity, multiple approaches possible from FP to OOP, particular attention to the developer experience (error messages, colors...), good set of linting tools with Typescript or Flow, easy to deploy/deliver, works to make desktop/mobile/web/VR apps, customizable build accessible to mortals, good enough package manager, evolving language that understood that it can always do better, welcoming and accessible dev community, mature networking APIs, good runtimes implemented by different companies...

I've been in this space pretty much throughout the whole period. Applets never took off as a serious option. They peaked briefly around 2000, then flash took over and by 2005 Ajax happened and JS took over.

As for build times, modern javascript is like having all of the disadvantages of a tedious build process without most of the advantages. You are spending the time, yet still don't have static type analysis and exclusion of whole categories of bugs. The reality is that, mostly for political reasons, javascript was the only thing that ran in a browser and after particularly MS (but certainly not them alone) ran into trouble with security issues, nobody really dared to do much else for a long time. Plugin APIs were deprecated, proprietary browser specifics were abandoned, etc.

So, what's happening now is a long over due correction where people compile to some heavily optimizable subset of js called wasm. As soon as that becomes commomplace the whole argument for javascript needs to be revisited, pretty much for the first time this century.

There is one huge change here (as compared to things like the golang wasm port) which makes this more likely to be adopted IMO:

Rust compiled to WebAssembly doesn’t have a runtime. This results in small .wasm binary sizes that are proportional to the amount of Rust code that is being compiled to WebAssembly. Binary size is of huge importance since the .wasm must be downloaded over the network. The proportionality means you only pay (in code size) for what you use. In turn, that means it is feasible for existing JavaScript code bases to incrementally and partially adopt Rust.

Great to hear they're taking this approach. I do think it'd be nice to have DOM access too though, as then you won't need JS at all - I do think long term the attraction of this is to replace JS as a front-end language, not just augment it, but it's nice they're taking an incremental approach.

It depends how you define "runtime", though.

If you use Rust strings, you may get a large amount of code included to handle them. Also, if you use malloc, that adds a significant amount of code.

It's true that languages like Rust have fewer runtime requirements than languages like Java but none of them are 100% proportional to the code you wrote.

wasm-bindgen is forward compatible with the host bindings proposal, so once that lands, the DOM stuff will Just Work.

Waiting for this !

"as compared to things like the golang wasm port" -- I have two questions here. First, can you elaborate the difference between the current Golang was port and proposed Rust wasm port? Secondly, can you elaborate why Golang port can't have small .wasm size?

Go has a mandatory runtime (think, the GC) that needs to be included, Rust does not. As such, it’s binaries will always be larger.

I remember I watch a talk on youtube saying browser vendors may start make their GC runtime support GC languages (such as Golang, Java), after which we don't need a large Runtime when we consume the WASM compiled from GC languages.

Probably it's far away down the road? But I was under the impression that it will soon get supported.

Wasm has “add a GC” to its roadmap, but a runtime is more than just a GC. That will certainly help, but it’s not a panacea.

What Steve said!

Also (and this does apply to Rust to some extent too), if you start pulling in the stdlib for your webapp then you can't avoid compiling in a lot of code (for example the fmt or net/http packages are pretty big - fmt adds around 1MB to binaries on my system here). If the stdlib for any of these popular languages could be cached or included somehow in browsers that'd be awesome, as part of the attraction of using them is having a great stdlib.

It'd be great if at some point they managed to slim it down significantly as I'd really love to replace JS with Go specifically.

I am not sure what WebAssembly has to do with "breaking the monopoly Javascript has had on this space". It always has been possible to target JavaScript from your compiler. Sure, WebAssembly is a better compiler target, but it does not enable anything.

For example, ClojureScript compiles to JavaScript. Clojure didn't need WebAssembly to do so.

I think it's cool that in a lot of ways JavaScript has "converged" as well. 5 years ago I was a hater like all the other cool kids, but JS today is a fantastic language in my opinion. There are still warts, for sure. But I enjoy writing ES6 almost as much as Python, and for a lot of things I enjoy it more.

Reply on news.ycombinator.com