20 ms·

> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be

> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly for their language of choice. It's not just C/C++. Go, Rust, Ruby, Python, Crystal, Nim, D, and many more. Now you might get the reaction that "meh, why would anyone write web apps with Rust?", but that's an irrelevant question. Companies are going to see this as an opportunity to save resources and become more efficient, especially since wasm has so much better perf than JITed JS and the possibility of going isomorphic is a reality (back-end & front-end written in Ruby for example, deriving from the exact same codebase and shares code). Now I'm not saying "WebAssembly will take over JS!", what I'm saying is that it perhaps, possibly, maybe will. It will depend on these languages and how they add support for it, what abstractions and integrations they provide with their current ecosystems. And of course, how WebAssembly will improve over the coming years.

AgentME 10y ago
You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if many do it soon for anything more than a small high-performance core or for a large application that has a small DOM surface area (a game that just renders to a canvas).
- Svenskunganka 10y ago
  Yes of course, but only during the early stages. The post-MVP roadmap for WebAssembly specifies DOM & Web API integration (http://webassembly.org/docs/gc/ http://webassembly.org/docs/gc/), so that specific case will too disappear with time. If you read point 3 on this page (http://webassembly.org/docs/high-level-goals/ http://webassembly.org/docs/high-level-goals/) you should realize that the need for JavaScript won't be required at that point. edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.
- the_duke 10y ago
  Direct DOM access including manipulation is planned for WebAssembly. They wanted to progress on the spec and push it out without that, but it's on the roadmap. (Along with GC integration).
- bluejekyll 10y ago
  Can someone explain what the option is for accessing the dom initially? Is there some wrapper JS that will be needed to call into the wasm?
  - mikepurvis 10y ago
    Yes: https://github.com/WebAssembly/design/issues/119 https://github.com/WebAssembly/design/issues/119
  - steveklabnik 10y ago
    Yup, see stuff like https://crates.io/crates/webplatform https://crates.io/crates/webplatform
    - bluejekyll 10y ago
      Omg, hello. How did I miss that!
ncantelmo 10y ago
I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.
- shadowmint 10y ago
  > something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop? Microsoft? Come on. Apple? Google? Google tried with dart and failed. Who else, seriously, is going to step up? We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work. Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices. You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse. Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/
  - ncantelmo 10y ago
    I don't quite agree with the all-or-nothing assessment, but your passion is exactly why this will happen. Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.
  - wybiral 10y ago
    > This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
skybrian 10y ago
JavaScript is strong competition both on the front end (source ecosystem) and the back end (compiler target). For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language. For C++ and Rust I'd expect WebAssembly will perform well, since it fits these languages' runtime model better. But for garbage-collected languages, compiling to JavaScript may result in smaller and faster code, since you can reuse JavaScript's runtime instead of downloading it. There may not be any reason for Elm or Dart (for example) to replace a compiler that works well with one that targets WebAssembly. Or if you like Go, I'd at least try out GopherJS before thinking you need a whole new toolchain. It's not just performance, either. Generating somewhat-readable JavaScript that you can debug using Chrome Devtools when something goes wrong is a pretty nice advantage.
- ktRolster 10y ago
  Garbage collection is coming to WebAssembly.
  - skybrian 10y ago
    Sure, eventually, and I assume some day there will be decent debuggers. But if your toolchain outputs JavaScript, you already have these things today.
- nanolith 10y ago
  To be fair, a generational mark-sweep GC algorithm doesn't take much more space over the compile-time modifications to the code itself. A reasonably performant GC algorithm suitable for most front-end work would probably only add about 10 kilobytes to 20 kilobytes of code to an executable. That can be downloaded and cached in the blink of an eye.
  - imtringued 10y ago
    The problem is that you need to get all the GC root nodes on the stack. This is platform specific and must be implemented by the browser. The only crossplatform way is to create an additional shadow stack that contains only the root nodes but this means you pay an additional cost for the GC on every function invocation.
K0SM0S 10y ago
Honestly I don't see how a low-level paradigm takes over a field when every other trend is towards ever more abstraction. Sure, wasm has its rightful place, like DX12/Vulkan, but it's a tiny fraction of apps/projects. Most likely we'll see js-to-wasm preprocessors of sorts to invoke optimized calls when it matters, but most devs won't touch low level (much like most game devs don't touch engines/middleware). There's the 1% edgy companies built on node+rust/D and what-have-you, and then there's the 80% wordpress crowd who longs for a human-readable programming language a la Star Trek. I think the latter is a future that will come unimpededly over this century, as far as the majority of the industry is concerned. More pressingly, people are waiting for async and other cool multi-threaded features in JS, and ES6 really is a second coming of sorts in that regard. Long gone are the days of horrendous paradigms once we adopt the 2016 spec, really. Economically, because that's the true judge ultimately, we have to consider the existing JS ecosystem: actual prods, skillsets, experience, actual needs of businesses who fund the construction of the web currently solved by JS, and so on and so forth. It's a giant thing, that JS. If we had a better alternative today, we'd still be writing JS in many projects in 2020 and maintaining some of it late into that decade. Let's face it, JS is here to stay, there's no turning back now --see how polarizing Java has always been for another historical case, and see how it's still top 3: can't suddenly undo all that cash poured into production, can't instantly retrain hordes of programmers. I'll say one thing about wasm though: it's a formidable effort that paves the way towards a truly 'next-gen' web paradigm, most notably suited to be actuated (viewed) within a VR/AR environment; it's also a prime candidate to run on the smallest devices at the heart of an "ambient"/IoT ecosystem. I'm considering a superset of low-level networking protocols that go beyond the web, obviously. And I haven't researched anything about it yet but I suspect the low-level hooks of wasm could be hacked to do some fancy ML stuff on-the-spot (thinking low-cost online algos and reinforcement learning here, if we are to make our 'ambient' IoT ecosystem able to 'learn' about us as users and map the physical world semantically). Ha, fascinating times, really. Let's just not lose sight of how the real world operates, though, if only to improve on that. In due time when ideas become feasible under the right circumstances. Low-level programming is very much not how we've trained the bulk of tech people since the smartphone era / mobile paradigm essentially. It'll take time to shift, if we ever did. I don't think we will, in the grander scheme of things.

AgentME 10y ago

You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if many do it soon for anything more than a small high-performance core or for a large application that has a small DOM surface area (a game that just renders to a canvas).

Svenskunganka 10y ago
Yes of course, but only during the early stages. The post-MVP roadmap for WebAssembly specifies DOM & Web API integration (http://webassembly.org/docs/gc/ http://webassembly.org/docs/gc/), so that specific case will too disappear with time. If you read point 3 on this page (http://webassembly.org/docs/high-level-goals/ http://webassembly.org/docs/high-level-goals/) you should realize that the need for JavaScript won't be required at that point. edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.
the_duke 10y ago
Direct DOM access including manipulation is planned for WebAssembly. They wanted to progress on the spec and push it out without that, but it's on the roadmap. (Along with GC integration).
bluejekyll 10y ago
Can someone explain what the option is for accessing the dom initially? Is there some wrapper JS that will be needed to call into the wasm?
- mikepurvis 10y ago
  Yes: https://github.com/WebAssembly/design/issues/119 https://github.com/WebAssembly/design/issues/119
- steveklabnik 10y ago
  Yup, see stuff like https://crates.io/crates/webplatform https://crates.io/crates/webplatform
  - bluejekyll 10y ago
    Omg, hello. How did I miss that!

ncantelmo 10y ago

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.

shadowmint 10y ago
> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop? Microsoft? Come on. Apple? Google? Google tried with dart and failed. Who else, seriously, is going to step up? We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work. Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices. You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse. Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/
- ncantelmo 10y ago
  I don't quite agree with the all-or-nothing assessment, but your passion is exactly why this will happen. Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.
- wybiral 10y ago
  > This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.

skybrian 10y ago

JavaScript is strong competition both on the front end (source ecosystem) and the back end (compiler target). For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language. For C++ and Rust I'd expect WebAssembly will perform well, since it fits these languages' runtime model better. But for garbage-collected languages, compiling to JavaScript may result in smaller and faster code, since you can reuse JavaScript's runtime instead of downloading it. There may not be any reason for Elm or Dart (for example) to replace a compiler that works well with one that targets WebAssembly. Or if you like Go, I'd at least try out GopherJS before thinking you need a whole new toolchain. It's not just performance, either. Generating somewhat-readable JavaScript that you can debug using Chrome Devtools when something goes wrong is a pretty nice advantage.

ktRolster 10y ago
Garbage collection is coming to WebAssembly.
- skybrian 10y ago
  Sure, eventually, and I assume some day there will be decent debuggers. But if your toolchain outputs JavaScript, you already have these things today.
nanolith 10y ago
To be fair, a generational mark-sweep GC algorithm doesn't take much more space over the compile-time modifications to the code itself. A reasonably performant GC algorithm suitable for most front-end work would probably only add about 10 kilobytes to 20 kilobytes of code to an executable. That can be downloaded and cached in the blink of an eye.
- imtringued 10y ago
  The problem is that you need to get all the GC root nodes on the stack. This is platform specific and must be implemented by the browser. The only crossplatform way is to create an additional shadow stack that contains only the root nodes but this means you pay an additional cost for the GC on every function invocation.

K0SM0S 10y ago

Honestly I don't see how a low-level paradigm takes over a field when every other trend is towards ever more abstraction. Sure, wasm has its rightful place, like DX12/Vulkan, but it's a tiny fraction of apps/projects. Most likely we'll see js-to-wasm preprocessors of sorts to invoke optimized calls when it matters, but most devs won't touch low level (much like most game devs don't touch engines/middleware). There's the 1% edgy companies built on node+rust/D and what-have-you, and then there's the 80% wordpress crowd who longs for a human-readable programming language a la Star Trek. I think the latter is a future that will come unimpededly over this century, as far as the majority of the industry is concerned. More pressingly, people are waiting for async and other cool multi-threaded features in JS, and ES6 really is a second coming of sorts in that regard. Long gone are the days of horrendous paradigms once we adopt the 2016 spec, really. Economically, because that's the true judge ultimately, we have to consider the existing JS ecosystem: actual prods, skillsets, experience, actual needs of businesses who fund the construction of the web currently solved by JS, and so on and so forth. It's a giant thing, that JS. If we had a better alternative today, we'd still be writing JS in many projects in 2020 and maintaining some of it late into that decade. Let's face it, JS is here to stay, there's no turning back now --see how polarizing Java has always been for another historical case, and see how it's still top 3: can't suddenly undo all that cash poured into production, can't instantly retrain hordes of programmers. I'll say one thing about wasm though: it's a formidable effort that paves the way towards a truly 'next-gen' web paradigm, most notably suited to be actuated (viewed) within a VR/AR environment; it's also a prime candidate to run on the smallest devices at the heart of an "ambient"/IoT ecosystem. I'm considering a superset of low-level networking protocols that go beyond the web, obviously. And I haven't researched anything about it yet but I suspect the low-level hooks of wasm could be hacked to do some fancy ML stuff on-the-spot (thinking low-cost online algos and reinforcement learning here, if we are to make our 'ambient' IoT ecosystem able to 'learn' about us as users and map the physical world semantically). Ha, fascinating times, really. Let's just not lose sight of how the real world operates, though, if only to improve on that. In due time when ideas become feasible under the right circumstances. Low-level programming is very much not how we've trained the bulk of tech people since the smartphone era / mobile paradigm essentially. It'll take time to shift, if we ever did. I don't think we will, in the grander scheme of things.