4 ms·

WebAssembly is not a replacement for JavaScript, and (IMO) it most likely won't ever be. At the very least JavaScript will always be around as a "glue" languag

WebAssembly is not a replacement for JavaScript, and (IMO) it most likely won't ever be. At the very least JavaScript will always be around as a "glue" language to use wasm binaries. I think of the relationship between JavaScript and WebAssembly as the relationship between Python and C. JavaScript will call out to a wasm binary for some "heavy lifting" and JavaScript will be used to "glue" the data to the DOM. Also like the Python-C relationship, the wasm can be a compile target for non-javascript libraries. But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. It's possible (both now and in the future), but it's always going to be a leaky abstraction, or your language will end up being similar enough to javascript that targeting wasm is largely pointless (think TypeScript or Flow).

fizzbatter 10y ago
> But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. The performance of touching the DOM and browser APIs will be the factor that decides that, imo. I think you may be underestimating how many people are partially or heavily disgruntled at javascript, and would happily replace it if given the chance. If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years. Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM. Regardless, i'm quite excited, and hope to see something fruitful from it.
- bluejekyll 10y ago
  Yes. With this we can finally be less restricted in our language choice. I think the community of people who want tyoe safe languages is large, and this will the a target for them. I just hope for Dom bindings through the WASM ABI.
- douche 10y ago
  Javascript is awful. If WebAssembly is anywhere near consistent across browsers, and there are better languages that compile to WebAssembly, I would go that way in a New York minute.
- modarts 10y ago
  > how many people are partially or heavily disgruntled at javascript It's not actually the nightmare many make it out to be with ES6. I actually enjoy writing it quite a bit (I have mainly a functional background)
  - fizzbatter 10y ago
    Yea, fwiw these days it is much better. But i think the biggest issue is simply the lack of choice. On my OS, i can choose whatever language i want. Whether i choose for preference, or the right tool for the job, i have choices, many of them. On the web it's.. well, just JS. Some languages that transpile to JS.. but ultimately they're all pretty much just JS.
- yoklov 10y ago
  If your language of choice comes with a runtime that's not shipped in the browser, WASM doesn't seem like it will make speed into a non-issue, it will just frontload the slowness.
  - fizzbatter 10y ago
    ftr, when i mentioned speed i was mainly referring to WASM->DOM. So, if that ends up too slow for heavy DOM manipulation (eg, React style diffing/etc), then with any luck we can offload the DOM interactions to JS. Eg, WASM->JS->DOM
randyrand 10y ago
Screw that. Writing glue code sucks. Define an ABI for interacting with the DOM. And allow WASM compilers to target it.
- flohofwoe 10y ago
  I'm pretty sure there will be libs in various languages that allow to talk to the DOM directly (e.g. in C/C++ #include "dom.h"), under the hood they would still call out into JS but the library user wouldn't have to touch Javascript. This is how most of the C API wrappers in emscripten work (e.g. OpenGL wrapper which talks to WebGL). Calling out into JS sounds like a perf hit, but overall it works very well... as long as the JS code doesn't produce too much pressure on the garbage collector, I think this is the main problem with the current JS wrappers. But since DOM operations are slow anyway that shouldn't be a problem (it's fast enough for WebGL, so...).
  - wrmsr 10y ago
    I've heard that native DOM interaction (no JS middle man) is on their radar via WebIDL. They don't want people reinventing the DOM via custom canvas rendering and such so making DOM manipulation painless is a priority.

fizzbatter 10y ago

> But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. The performance of touching the DOM and browser APIs will be the factor that decides that, imo. I think you may be underestimating how many people are partially or heavily disgruntled at javascript, and would happily replace it if given the chance. If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years. Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM. Regardless, i'm quite excited, and hope to see something fruitful from it.

bluejekyll 10y ago
Yes. With this we can finally be less restricted in our language choice. I think the community of people who want tyoe safe languages is large, and this will the a target for them. I just hope for Dom bindings through the WASM ABI.
douche 10y ago
Javascript is awful. If WebAssembly is anywhere near consistent across browsers, and there are better languages that compile to WebAssembly, I would go that way in a New York minute.
modarts 10y ago
> how many people are partially or heavily disgruntled at javascript It's not actually the nightmare many make it out to be with ES6. I actually enjoy writing it quite a bit (I have mainly a functional background)
- fizzbatter 10y ago
  Yea, fwiw these days it is much better. But i think the biggest issue is simply the lack of choice. On my OS, i can choose whatever language i want. Whether i choose for preference, or the right tool for the job, i have choices, many of them. On the web it's.. well, just JS. Some languages that transpile to JS.. but ultimately they're all pretty much just JS.
yoklov 10y ago
If your language of choice comes with a runtime that's not shipped in the browser, WASM doesn't seem like it will make speed into a non-issue, it will just frontload the slowness.
- fizzbatter 10y ago
  ftr, when i mentioned speed i was mainly referring to WASM->DOM. So, if that ends up too slow for heavy DOM manipulation (eg, React style diffing/etc), then with any luck we can offload the DOM interactions to JS. Eg, WASM->JS->DOM

randyrand 10y ago

Screw that. Writing glue code sucks. Define an ABI for interacting with the DOM. And allow WASM compilers to target it.

flohofwoe 10y ago
I'm pretty sure there will be libs in various languages that allow to talk to the DOM directly (e.g. in C/C++ #include "dom.h"), under the hood they would still call out into JS but the library user wouldn't have to touch Javascript. This is how most of the C API wrappers in emscripten work (e.g. OpenGL wrapper which talks to WebGL). Calling out into JS sounds like a perf hit, but overall it works very well... as long as the JS code doesn't produce too much pressure on the garbage collector, I think this is the main problem with the current JS wrappers. But since DOM operations are slow anyway that shouldn't be a problem (it's fast enough for WebGL, so...).
- wrmsr 10y ago
  I've heard that native DOM interaction (no JS middle man) is on their radar via WebIDL. They don't want people reinventing the DOM via custom canvas rendering and such so making DOM manipulation painless is a priority.