It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it).
If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making.
And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that.
Also the JVM ran in the browser, etc.
You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
A couple years earlier, NetBSD device drivers were running in the browser, and JS-engine-as-hypervisor was an explicit, if distant, goal. https://news.ycombinator.com/item?id=4757581
I don't know that it's necessarily uncanny though either; ASM.js was already a thing back when that presentation was given, so the existence of WASM isn't really surprising. The real central "prediction" of that talk wasn't WASM, it was METAL, which hasn't quite taken off yet. (The idea is out there[0], but so far mostly just as a self-fulfilling prophecy).
The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it.
Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages compile to, but rather a bytecode perhaps inspired by JavaScript that will be the language of the future. Also, importantly this bytecode will win; that is most languages will the ability to directly compile to or have a VM in this bytecode.
Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance.
At least to me, neither of those were obvious insights even though I knew of these plugins and JSLinux.
First off, those plugins died. Silverlight, ActiveX, Java on the web, Flash, all of these died out and were replaced by JavaScript before wasm really took off. It might've looked like the end state would be a version of JavaScript "winning."
Second, things like PNacl, Emscripten, etc. still seemed like curiosities (as the talk refers to when showing Repl.it). It wasn't clear that they or the ideas they championed would get widespread adoption.
These days it is looking more and more likely that wasm is going to become a target for all sorts of different compilers. The fact that it's a major compilation target of Rust, a language that's about as far away from what I would've thought of as a language for the web as possible, is striking.
And though we're still a long ways away from running everything on WebAssembly, it no longer seems as exotic an idea as it once did to me.
And because of that, as well as the fantastic presentation, I still return to this talk every so often awed at how much closer we are to realizing Metal.
There's still a lot of room for the talk to go very wrong, but it's not as far-fetched as when I first watched it.
EDIT: Put another way; the talk is interesting to me because it emphasizes the birth and death of JavaScript. It talks about a world where the same forces that propelled JavaScript to towering heights of popularity ultimately cast it aside and create a world not possible without JavaScript, but in which JavaScript itself essentially no longer exists.
I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer.
Bytecode, by its nature, has to be translated into native code -- the way for it to be 'faster' than native code is to be native code. In software, you can do this with static or JIT compilation. The hardware people do this by changing their CPUs to make the things that people do in the bytecode faster. (Apple introduced new floating point CPU instructions in their iPhones just to make JavaScript faster.)
It's swapping out one abstract model for another, just that we are so used to the current abstract model that we don't perceive it as one.
With WASM you have the same kind of thing but the added wrinkle of the browser-based I/O being a different set of "basic abstractions" from what you get in libc, and every solution that bridges the gap being a bit of a hack. Being bytecode doesn't really change the fact that you still have to deal with the resulting dependencies at some level.
About speed, JIT optimized bytecode can be faster than what is possible to static binaries. The JIT has more information than the compiler to optimize your code. Currently I don't know of any that is that fast, but there is no inherent limitation here.
Originally my conception of the video was more like this commenter below: It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language.
I guess a lot of people are saying "he predicted this" without referring what specifically he is predicting.
FWIW it's not clear to me that WASM is going to do that. Everything I've heard from the team says that WASM and JS are complementary. Not that WASM will cause JavaScript to die.
I think there's some possibility of that happening in the distant future, but it's far from obvious. I think JS VMs will always be better at running JS than WASM VMs running JS engines, and all the JS out there will exist for a long time.
Also, JS is at a pretty good level of abstraction to manipulate the DOM, whereas C, C++ and Rust aren't. And it has some good syntactic shortcuts. Despite being a Python person, I would probably even argue that JS is better to manipulate the DOM, despite JS and Python being very similar otherwise. Function literals might be one reason.
So when people say "he predicted this", it would be nice to be specific about what the prediction was. WASM is a step in that direction but I would argue it's also fairly clear given that asm.js existed and he showed it. The real question is if WASM can handle all these use cases. Working on a language has made me appreciate many reasons that it's hard to make a polyglot VM. Tiny changes can bias your VM towards one compilation source vs. another.
In lieu of that, I'll offer my one-line take of the prediction of the video. JavaScript will fade from popularity, but its (original) popularity will inspire a low-level assembly-like language (looking more and more like WebAssembly these days) that will provide a new substrate for most application development, web-based or otherwise, replacing traditional binaries.
As you point out it's not at all clear, even five years on from this talk, that this prediction will be correct. WebAssembly is currently complementary to JS and cannot fully replace it. The vast majority of websites these days use JS but not WebAssembly. Use of WebAssembly for applications that traditionally have not been run inside a web browser (e.g. GIMP, LibreOffice, etc.) is still nascent and it's nowhere near a sure bet that it'll take off there.
But maybe, just maybe, it'll happen.
Everything else is "just engineering". E.g. as far as being complementary to JS, and not being able to replace it - they are already working on access to DOM.
I agree with your point in general, but surely the fact that there are 10 million js frameworks invented every week is proof that the native DOM APIs are not a good abstraction? As a mostly front end dev, most of my UI logic these days target _React_, not the dom APIs. To the extent that I write JavaScript, it’s pure data manipulation, which can be written in any language.
In other words, the particulars of the language matters. I wouldn't underestimate 20+ years of JS evolution toward expressing the problem better.
I'm working on my own language and all those details are hard. When they work, they're invisible to users. You only notice when it's not there or doesn't work! I would agree that Python is a better language than JS in most respects, but it's not clear to me that it's a better language for writing web front ends.
e.g. the async abstractions and promises are different and I believe that matters.
EDIT: some quick googling shows it's already being done
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
If you want to provide a plugin or extension interface, and want to give those plugins a limited interface rather than making them all-powerful, embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language.
Also see https://hacks.mozilla.org/2019/08/webassembly-interface-type... for an illustrated description of how that'll work smoothly across languages.
No, you would still have to provide an application programming interface for every target language you want to support.
If you export functions to WebAssembly, any language that can run in WebAssembly can call those functions.
And if you define WebAssembly Interface Types for your exported functions (note: still in development), any language that handles interface types can automatically handle things like "how does this language represent a string safely".
Either way, you don't need to define a new API for every language.
Interface Types are the mechanism for handling the different abstractions in different languages without having to write language-specific interfaces.
WebAssembly prior to Interface Types is more akin to an exported C function than to inline assembly. That already gives you enough for many kinds of interfaces, most notably the common pattern of obtaining an opaque handle and calling functions on that handle.
WebAssembly with Inteface Types gives you everything needed for high-level interfaces in any language. That lets you define strings, buffers, handles, arbitrary structured types, and pretty much anything you'd expect of a high-level interface.
Check out Wasmer! https://wasmer.io/ : along with other runtimes we are enabling the use case of WebAssembly programs as standalone applications that can run in any platform, or as libraries to be usable in any programming languages (disclaimer: I work at Wasmer!)
1. https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
2. https://www.fastly.com/blog/announcing-lucet-fastly-native-w...
EDIT: here it is: https://medium.com/wasmer/running-webassembly-on-the-kernel-...