Hacker News new | ask | show | jobs
by jjn2009 3280 days ago
the roadmap for WebAssembly does include interfaces into DOM manipulation, it's not the highest priority but allowing javascript replacement isn't completely out of the scope of web assembly. Just don't expect it to be a good idea for quite some time.
1 comments

Yeah, I think people are being conservative about where WebAssembly will lead us. Which I think is smart. Promise little, deliver big never hurt anyone, especially not open standards.

But I would love to have an Elm that compiles directly to wasm. I'd love to write a front-page app in Go or Python, or mix in some Rust code.

People talk about Javascript fatigue, and it's real and exhausting to keep up with the constant framework churn. But I think the biggest reason at the root of it all is Javascript. Nobody talks about Unix fatigue, and all the different languages and frameworks that you can use to build your backend services. When we have a truly open-ended platform to build on, we're not going to feel this fatigue, I don't think.

Well on one hand you will definitely increase the number of ways to do DOM manipulation, but on the other isolated communities could move at different paces. I think its hard to say if the dominate mode of ui web dev will slow down, I've definitely experienced this fatigue, its a huge issue. Some how the unix way of small composable parts which work well needs to find its way to the browser.
If the problem is really just JavaScript itself WASM won't be able to help -- WASM is basically just asm.js, which is just a restricted subset of JavaScript, but easier to parse and optimize.
>a restricted subset of JavaScript

This actually isn't the case. Browsers provide a virtual machine which can run assembly code with web assembly, its that simple, nothing about it necessitates javascript except that its the interface to the DOM, in the future it could very well be possible to have a new script tag type which is ASM and requires zero javascript or javascript runtime.

I didn't say WASM was a restricted subset of JavaScript. I understand that it is a lower-level virtual machine, and that in fact it provides some primitives that asm.js doesn't (e.g. 64 bit integers). My point was that if you're looking to WASM to be some kind of silver bullet, you've got the wrong expectations. The causes of people's JavaScript fatigue have little if anything to do with JavaScript the language.