tl;dr I’m burying the lede with context and catch-up material first, so impatient or already-clued-in readers should skip to below the videos for today’s big news. Or just read Luke Wagner‘s blog post right now.
My Fluent 2015 “ECMAScript Harmony: Rise of the Compilers” talk given on April 21st:
Jeremy Ashkenas picked up this ball and ran into the next field’s end zone two days later in Brooklyn:
My slides for the talk I gave at ModernWeb.tw on May 15th:
Perhaps you detect a theme, beyond “JS turned 20”. Something about compilers rising, Java bytecode and asm.js, shared memory threads and SIMD. The usual retort, recurrent on Hacker News, looks like this:
In an HN sub-thread sparked by my ModernWeb.tw slides, I concurred with Patrick Walton on analogies between browsers and the Unix kernel, JS and C. One does not get to write kernel code in any language, at least not yet. Elsewhere in that sub-thread the analogue of JS was identified as architecture-specific assembly code, where the CPU architecture is fixed by physical reality, while software is written in virtual languages compiled to machine code, or run through interpreters.
In any event, whether analogous to C or assembly, JS has had a lock on the “kernel” of the client side. Web “userland code”, in contrast, can be written in a great many languages. Adding a second (bytecode) syntax has looked like a “now you have two problems” loss, against the alternative of one syntax. Until now.
Today’s Big News
It’s by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let’s say. Today I’m pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
What: WebAssembly, “wasm” for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS’s semantics, in order to best serve as common object-level format for multiple source-level programming languages.
It’s crucial that wasm and asm stay equivalent for a decent interval, to support polyfilling of wasm support via JS. This remains crucial even as JS and asm.js evolve to sprout shared memory threads and SIMD support. Examples of possible longer-term divergence: zero-cost exceptions, dynamic linking, call/cc. Yes, we are aiming to develop the Web’s polyglot-programming-language object-file format.
Why: asm.js is great, but once engines optimize for it, the parser becomes the hot spot — very hot on mobile devices. Transport compression is required and saves bandwidth, but decompression before parsing hurts. A secondary consideration: JS has a few awkward corners even in its asm.js subset. Finally, once browsers support the WebAssembly syntax natively, JS and wasm can diverge, without introducing unsafe or inappropriate features into JS just for use by compilers sourcing a few radically different programming languages.
See the FAQ for more nuance and detail. No, JS isn’t going away in any foreseeable future. Yes, wasm should relieve JS from having to serve two masters. This is a win-win plan.
How: If you use Emscripten, then wasm support via a command-line flag will at first include and target the prototype polyfill. But as native wasm decoders appear in top engines (see the V8 native prototype decoder), Emscripten will auto-configure for best results. Another prototype: a JS AST compressor (encoder).
These prototypes will evolve and track draft specification changes as WebAssembly matures and receives progressively more developer testing. Other compilers than Emscripten, and other compiler frameworks than LLVM, will join the mix. I expect all engines will support fast native decoders. All these parts are means to the end of a common WebAssembly standard.
Who: A W3C Community Group, the WebAssembly CG, open to all. As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I’m sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off.
Here you can see JF Bastien of Google’s PNaCl team barely able to keep a lid on the secret. Good thing I replied with a comic book reference as plausible cover. Close one! 😀
Having both the PNaCl team and the V8 team from Google, along with key people from Microsoft and the asm.js and Emscripten gurus from Mozilla, collaborating closely once everyone saw the light, has been inspiring. I’d like to single out for highest praise JF Bastien, K. Gadd, and Ben Titzer of Google; Dan Gohman of Mozilla; Abhijith Chatra and Michael Holman of Microsoft; Alon Zakai of asm.js & Emscripten fame; Filip Pizlo for JavaScriptCore/WebKit; and especially asm.js/OdinMonkey mastermind Luke Wagner.
The Big Picture
In the history of computing, the dream of a universal, language-neutral intermediate form goes back to well before Melvin Conway‘s UNCOL (1958, the same year LISP was born). I remember ANDF from the ’80s, and U-something from the ’70s. No one wants the “N x M” language sources vs. machine targets problem.
Sometimes we must take a trip or two around Fortuna’s Wheel before falling into success. Neurons appear to have evolved more than once. Believe me, I find it ha-ha funny that lowly JS (which I did not plan out this far in advance!) has paved the evo-path to WebAssembly. Yet here we are.
Although it won’t be the only compiler framework used to generate wasm, LLVM has been a boon to this project, as to wasm’s Emscripten and PNaCl progenitors. Kudos to Chris Lattner and team.
The PNaCl folks I know are good natured, but I think some are sore at me for playing Cassandra to their Troy over the years on HN. So I want to give them major credit for wringing much undefined behavior (UB) out of LLVM — really out of all levels of abstraction, from C/C++ specs down to hardware. That kind of thankless work is a big help for WebAssembly, which must be mostly-determinstic and well-defined, for interoperation and security.
(Astute readers will have by this point recalled The Birth & Death of JavaScript by Gary Bernhardt. I live to troll Gary. 😉
Bottom line: with co-evolution of JS and wasm, in a few years I believe all the top browsers will sport JS engines that have become truly polyglot virtual machines. I predict that JS over the same timespan will endure and evolve to absorb more APIs and hardware-based affordances — but not all, where wasm carries the weight.
Again we see how the Web favors a succession of “little bangs”:
- to hold community consensus along the evolutionary path, by
- testing each hop for fitness with developers and implementors, and
- supporting usable polyfills for older deployed browsers.
I usually finish with a joke: “Always bet on JS”. I look forward to working “and wasm” into that line — no joke.
/be
Is this the death of view-source? Even if it’s unintelligible uglified goobletygook, JS has maintained it’s relevance it’s commonality and usefulness as a target for other languages by it’s human expressibility: the enhancements here sound like they go well beyond the bounds of JS. Does that mean that we’ll have to use all new tools to debug webassembly?
@Rektide: no, see the FAQ:
https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web
Lots of good info there ;-).
/be
Great news!
Three years ago you said you couldn’t see this ever happening:
https://news.ycombinator.com/item?id=1905291
What happened to make you think it was feasible, and worth the push?
Subtle difference. If you read closely, you’ll see I wrote in that comment
“A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good compression; see Ben Livshits’ JSZap from MSR, and earlier work by Michael Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not on TC39’s radar.”
And that (binary AST encoding) is exactly what WebAssembly is, currently. The “bytecode” in that old HN thread was over-lowered stack machine or virtual register code with gotos, a possibly irreducible control flow graph.
But as I just wrote to you on HN (https://news.ycombinator.com/item?id=9733762) it’s ok with me if you call wasm “bytecode” ;-).
/be
I dont understand the JIT part: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#platform-independent-just-in-time-compilation. Is the goal to provide hooks in the runtime so you can specify how to JIT code?
@Foo: Yes, think of LuaJIT2 ported to wasm. This is more than a cross-compile, and must support wasm via an LJ2 back end for all the JIT optimizations. PNaCl folks did some work on how to support JITs, I believe. Same goal: support downloadable language engines that use classic JIT tricks (PICs, other self-modifying code structures).
/be
> What happened to make you think it was feasible, and worth the push?
The web changed a lot in 3 years, the web is constantly changing. The way transpilers picked up, the need to run “native” apps in browsers and other things have changed and we need to adapt.
It’s perfectly fine to change your mind given new evidence after 3 years 🙂
But as noted, what I doubted could be standardized on HN three+ years ago was “bytecode” in the Java sense. I explicitly, back then, allowed for the AST-encoding gleam in my eye to spread, and it did. I helped, but the research work is cited in my old comment; I was just a publicist.
/be
As a ‘reverse’ of the view-source question above:
If one were seeking to write compiled-binary browser-runnable code – that is NOT view-source friendly, in order to protect proprietary IP – would using WebAssemply make this possible?
(And if yes, would the result be comparable to a regular C++ binary executable, or more along the lines of a compiled virtual-machine file – like a java .class file?)
A sample use case as I see it: let’s say you have a commercial product that provides complex business intelligence that runs on the client side. The portion of the product that is it’s UI/UX could then be written in a traditional way with CSS/JS frameworks… whereas the ‘integral core’ (whose logic the company wanted to keep proprietary) could be done via wasm.
Does that fit within the intended scope of WebAssemply?
@Gary B: Real obfuscation is a commercial product, e.g. from Arxan (https://www.arxan.com/).
Anything else, including binary code, is not going to stop people from stealing your inventions. Consider how black/green/white-hat tools decompile binaries nicely, every day.
It’s not clear how good Arxan is, but let’s say it’s better. Then the question becomes could Arxan’s proprietary techniques be used on wasm? I don’t know.
/be
Since support for call/cc is on the table, is there any possibility for consideration of composable continuations as a WebAssembly language feature, e.g. shift/reset in Racket?
See: Adding Delimited and Composable Control to a Production Programming Environment
https://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf
@MBinSTL: Dave Herman championed shift/reset-based delimited continuations for ES6 a while ago, before concluding that generators were better. See
https://wiki.ecmascript.org/doku.php?id=strawman:shallow_continuations
Anything like this for wasm is possible and on the farther-out roadmap, but no one’s working on it yet. Contribute to the W3C CG and github if you can. Thanks.
/be
Great News!
Can someone write a blog post/article for the millions of Web app developers who might not be able to make the most of this blog ?
I’m sure A Wired article of what transpired (including the private github repo) over the last few months will be in the works.
I’m absolutely thrilled!
I love JS, but couldn’t help thinking that there’s too much strain on it. Until yesterday it played the role of the web’s bytecode. What it certainly wasn’t designed for.
Glad you’re back, Brendan!
I don’t quite understand, why can’t Java bytecode be extended for dynamic languages and used instead. It seems silly that there were already many more advanced IR formats and JIT engines and now everyone believes in JS instead. Think about Julia language, LuaJIT, Sun JVM, CLR, Mono. Why JS?
@Matt D: Java flopped on the client for several reasons, but so have all plugin-like approaches including Flash and PNaCl. WebAssembly starts as a second syntax for JS, targeting the one and only JS VM.
This avoids the fatal flaw of trying to wedge two VMs into the browser and then connect them (inevitably) via the DOM and other browser APIs, with attendant memory cycle collection overhead (this killed Dart in WebKit, see https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html).
Java bytecode also suffers in comparison to an AST (parse tree) encoding, which is what wasm uses. Follow the links at https://github.com/WebAssembly/design/blob/master/AstSemantics.md under “Why not a stack-, register- or SSA-based bytecode?”
So, mainly: browsers have no JVM and must have a JS VM, and that means no “lift” from using Java anything. If that weren’t enough, we know better now how to do a portable and safe IR for the Web, and Java bytecode ain’t it.
/be
Awesome!
It may be something on the network here at work, but I’ve been unable to see the slides (except the first) using IE,Chrome or FF (all latest available versions on Win7).
@Rob G: try https://brendaneich.github.io/ModernWeb.tw-2015/. I’ll see if I can help the iframed version work better. It kills iOS Safari dead!
/be
So they are just redoing parrot but for the web.. Parrot is a bytecode VM, that already can be a target for javascript, as well as many other languages. It has been in development since around 2000.
Initially parrot’s development stated with it being the target for Perl 6, but can have the following languages output to it, Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. (taken from the parrot website, https://www.parrot.org/
@Fran: I recall Parrot well. Sorry, not competitive with JS VMs in browsers, ever. Also, “bytecode” as “compressed AST encoding” is quite different from a more concrete IR for use by a concrete VM. The latter won’t make a great cross-browser standard (has not, anyway). There are good reasons for these differences between what came before, and what browsers actually could agree on due to demonstration-by-evolution (asm.js mainly, plus shared ArrayBuffers, SIMD, other JS API uplift).
/be
So begins the Object Pascal renaissance. Believe it.
U-something from the ’70s was UCSD-p System.
p-Code was generated by Pascal And Modula compilers.
All in 64Kb of memory.
Sheesh!
I could see this being a good option for “custom” video codecs and DRM schemes. For something like Daala, which will have zero browser support at the start, having a fast loading and fast running decoder in WebAssembly would mean you could switch to Daala on the server side for streaming video without having to worry about built in browser support. And of course it could be made faster once things like SIMD support and maybe WebGL2 make it into browsers.
@RobertoM: I remember p-code, should have mentioned it (the Pick OS was built on it), but the U-something was more a universal object file format. Still can’t quite remember the name, believe I read of it in a Springer-Verlag compiler book.
/be
You can’t keep a good man down! Can’t wait to dig into Web-Assembly!!
I wrote the below comment on Luke Wagner’s blog, but it disappeared for some reason (presumably a technical glitch). Not especially insightful, but I just wanted the opportunity to express it in a relevant place, and maybe get some response to it.
—
I think this is a bad idea, but I’ll wait and see how it pans out. (I’m saying this more often than I’d like lately.)
I’m not sure when the idea ‘standardized binary = as open as standardized text’ became fashionable, but it’s dangerously misleading.
My particular worry is that I find these developments conceptually interesting and even exciting, but some of the possible ethical implications genuinely distressing. Maybe I’m chicken-littling, but it doesn’t feel like any of the people with the power to make these decisions are paying enough attention to the bad possible outcomes. Sometimes, society simply doesn’t put up with the bad outcomes (like XML/XHTML/RDF/Java blobs and many more), but that’s not guaranteed — particularly when people are given short-term sweeteners like performance and novelty features.
But because I don’t have a choice, I’ll wait and see how it pans out.
@Voracity: I think WebAssembly is a really good idea. I don’t think it’s about fashionability as much as it is about capabilty. The downloads will be smaller, the load times will be faster, and I think WebAssembly will really come into its own as they add support for other languages.
Where I work we do a lot of internal application development. If we could do WebAssembly builds of our applications (i.e. the fat client use case from WebAssembly’s github page) it would give us a zero install option as well as the scope for the application to run on anything with a good enough browser. This would be a really good fit for us and a much nicer approach than reimplementing everything from scratch.
It doesn’t matter that it’s a binary blob in our fat client use case. Our applications are already binary blobs and aren’t used outside the company anyway.
@Ray Stantz++ (and for Ghostbusters 😉
@Gary B:
>> If one were seeking to write compiled-binary browser-runnable code
>> – that is NOT view-source friendly, in order to protect proprietary IP
>> – would using WebAssemply make this possible?
>> (And if yes, would the result be comparable to a regular C++ binary executable
>> , or more along the lines of a compiled virtual-machine file
>> – like a java .class file?)
obfuscation of proprietary code while maintaining the openness of the
whole architecture is a serious concern and your question
is the first one I asked myself the very second an article on .wasm came out.
I’m quite positive on it, since asm.js is very close to bare compiled native C/C++ output.
That gives a good level of protection of the source code.
I’m currently using emscripten to compile big financial libraries where IP is relevant.
The results are encouraging since optimized C++ cannot be reverted to original source.
(problem with emscripten is SIZE of the produced js. NaCl could be a good solution if it wasn’t DOA, while Dart is only a typo).
So, no, we won’t suffer the “decompile with a right-click” issue you will have for sure targeting
Java/.Net/Dart JVMs where sometimes decompiled sources are even better organized and formatted than original source.
OO Virtual Machines retain too much useless info,that’s the problem.
And even if obfuscators tried to tackle the problem they produced suboptimal crippled code and were easily to circumvent.
This stems from the 1995 original sin of Sun JVM when Sun bet on a new type of processors, where
objects and methods were to replace LDAs and JSRs (Java Processor anyone?)
Thanking some god or chance this did NOT happen, and with GPUs asm code is going even more dirtier & low-level.
For the older ones like me .wasm is more a CALL -151 mini-assembler.
IP protection is and will be possible in asm.js/.wasm (even more with yet-to-release obfuscation tools)
while hacking a game by changing an LDA #05 with an LDA #FF to get more lives ALWAYS will.
Life’s good.
Roberto
@ExedraOS
A sample use case as I see it: let’s say you have a commercial product that provides complex business intelligence that runs on the client side. The portion of the product that is it’s UI/UX could then be written in a traditional way with CSS/JS frameworks… whereas the ‘integral core’ (whose logic the company wanted to keep proprietary) could be done via wasm.
Does that fit within the intended scope of WebAssemply?
>> I usually finish with a joke: “Always bet on JS”. I look forward to
>> working “and wasm” into that line — no joke.
No joke, really. If properly executed wasm in a few years will be on all the servers
architectures as well, supplanting current JVM and .Net enterprise solutions.
I’m really damn happy that after years Google (p)Nacl and emscripten/asm.js teams join their efforts and big mama Microsoft hops in.
My computers will be happier than me since they won’t have to suffer anymore long the
cumbersome GCC/Clang/emscripten/pNacl/Cordova/whatever build chain.
Paraphrasing Marshall McLuhan, from today we can say that “The web is the platform”.
Really from today.
Roberto
Is there already an indicative time frame?
I could not find that …
WebAssembly is fantastic – not necessarily the binary format but the simple fact that all the big players in this space! Well done!
But threads and shared memory semantics in JS?! There’s gotta be a better incentive than playing zombie games… It’s gonna be tons fun mixing async and blocking code.
@Chubi: no fear, I see no blocking APIs ever coming to foreground threads, but wait-on-promise to block a worker (and only a worker — again not main/fg threads) is being debated and it’s needed for C/C++ compilation (due to all those legacy blocking Unix syscalls).
I predict the streams won’t cross in practice: jQuery on main thread will never see a data race among workers running compiled Unreal Engine 4 game code on background threads.
/be
@Ray Stantz: There’s lots of positive use cases for wasm. And, as I said, I find this kind of technology interesting and exciting in and of itself. No quarrels on my part there.
However, the openness of the web is an extraordinary and extremely *lucky* thing. The web was built by scientists who had openness in their blood. I get very defensive and anxious whenever I see anything that might be a threat to that openness. I can’t properly describe the threat I see in wasm in the space available here, but I’ll try to bullet an outline.
– wasm binary (for machines) will be monomorphic with wasm text (for humans). (Shouldn’t that be isomorphic, since they’re not literally the same form?) However, source text will *not* be monomorphic with either wasm binary or text.
– Source maps will be supported, but are ‘opt-in’. Until wasm, the web has *always* provided source, unless you ‘opt-out’. (Media is an exception, but it’s debatable as to whether the difference between product and source there is significant.)
– wasm (whether binary or text) is a target language nobody is meant to use directly, and very few people will understand — but it’s the only way to debug code in a ‘view source’ way without a source map.
– wasm is a target platform *and* a language. It’s a second web-universal language alongside JavaScript, but designed for machines, not humans.
– wasm has several advantages over JavaScript for developers — performance (parsing, downloading and executing), support of existing code bases and support for any source language. But:
– Performance is a temporary advantage. For example, the JavaScript code I wrote yesterday runs faster than the C code I wrote 3 years ago — because I’m running it on a faster machine. The set of all that’s practically achievable in JavaScript is growing at the same rate as the set of all that’s practically achievable in C, it’s just a few years in delay. Would you seriously be fussed if all the world’s innovations came 3 years later than they otherwise would, if it meant preserving something as precious as openness?
– Support for existing code bases and libraries is a genuine positive, with few downsides. (Except for over-complex libraries that continue to float around because no-one’s brave enough to tackle a rewrite.) Indeed, we should be trying to preserve electronic history as much as possible. However, this is already possible with transpilation to JS (I already enjoy playing the games of yore on archive.org — incidentally, running blindingly faster than they ever did on their original systems), so there isn’t any unique advantage to wasm here. This just boils down to performance again — and again, that’s a temporary advantage.
– Support for any source language is a wolf in sheep’s clothing, for several reasons. Tool chains that live outside the web platform become a requirement. (Tool chains are also bad, for roughly the same reasons as wasm.) Debugging tools will have to be specialised to each language to work well. They will migrate outside the web platform and, with enough JS -> wasm transition, browser-based developer tools will rot away due to lack of relevance (perhaps becoming front-end shells to external debugging tools). With first-class universal web support, the number of languages will grow in a way that’s worse than the growth of human languages pre-modern era. Developer communities will largely be incapable of talking to each other — this already happens in the non-web developer world, and is increasingly happening with frameworks in the web world. The common touchstone will remain HTML/CSS, but how long will that last? (With things like, for example, React Native.)
So, actually, the advantages of wasm are spectacularly feeble.
– It’s likely people will perceive wasm to be the ‘best-practice’ approach over JavaScript. There will be misinformation about the initial performance differences. There already is — I mean, how often is parsing performance (whether 20x slower or otherwise) a problem? (You haven’t heard of caching or staggered parsing?) Or as another example of misinformation, the FAQ describes the difference in size between gzipped asm.js and wasm — about 30%. How much of a difference does that really make, when compared to the benefits of openness? All this will result in many more people using wasm than should really be the case, which will result in browser developers focusing on improving wasm rather than JavaScript, which in turn will signal more web devs to focus on wasm, and so forth. (This already started with asm.js, so I can’t see why it wouldn’t get worse with wasm.)
– The most prominent first uses of wasm will be games. Games have always been at the forefront of advances in computing, and have a habit of shaping our ideas about how software should be written. The problem is, games have always been obsessed with performance beyond all rationality, and are a terrible guide for deciding how almost any other kind of software should be written. Genericity, legibility and endurance are all far more important than performance. This is true for almost every use case described here: https://github.com/WebAssembly/design/blob/master/UseCases.md
– Very few people are going to opt-in to source maps. They are annoying to create and maintain, and are of absolutely no advantage to most web developers outside of debugging. Big companies aren’t going to provide source maps. Governments aren’t going to provide source maps. Not even individuals who are pragmatic (rather than idealistic) will bother providing source maps. Opt in for source maps will pan out worse than opt in for organ donations — 95%+ of the web will eventually go dark. Source maps = debugging (in the early stages of wasm’s life) and that’s it.
– Regardless of the source map issue, people will jump at the chance to use their pet language on the web. There was a lot of VB on the web when MS supported it, and a) nobody took VB seriously and b) it was only supported by MS. What do you think is going to happen when serious languages get ported, and are supported extremely well by every browser? This is not a good thing. We don’t need a plurality of dialects that all encode the same procedural ideas (read/write, if, loop) or functional ideas (transform) over and over again, in a way that people can’t inter-communicate because the names and structure for all the *identical* ideas have to be learned afresh with each new language/framework/environment.
Sorry, a proper criticism of wasm would be many times longer than the above (and require me to go into the philsophy of openness), but I’m hoping I’ve made the point that, at the very least, wasm isn’t obviously a fantastic thing. If you can accept that wasm *might* turn out very bad, then I’ll be satisfied.
– This simply is following OpenGL’s new compiled shader push announced last year.
– The standard’s organization moved slower than the vendors moved, so instead of fighting for a higher level language standard, they went with a much lower level compiled format to let the vendors do their own languages, extensions and special features.
– Flash transcompiled to webassembly and hosted natively in the browser
– Silverlight transcompiled to webassembly and hosted natively in the browser
@Voracity: I’m not quite sure what you mean by “openness”. If you’re talking about open source licensing, I’d say that’s a separate issue. If you’re talking about always having access to the source code that runs a website, I’d say that for the most part you don’t have that access so I don’t see that WebAssembly changes anything there.
Voracity: “Until wasm, the web has *always* provided source, unless you ‘opt-out’.”
I wouldn’t say that’s the case. You don’t have access to a lot of the web’s source because it’s on the server side. A lot of web software is closed source. Even when open source servers or frameworks are used people often build their own layer of software on top of that.
The other day I built a little web based status display. The Python based backend does most of the work and is invisible to the end user. I could reimplement it in another language and from the end user’s perspective nothing will have changed. They never had access to the backend source to begin with.
Voracity: “wasm (whether binary or text) is a target language nobody is meant to use directly, and very few people will understand … wasm is a target platform *and* a language. It’s a second web-universal language alongside JavaScript, but designed for machines, not humans.”
I’d say few people understand HTTP or HTML or CSS or JavaScript. They exist to tell web software how to transport or mark up or style or execute a web page. WebAssembly’s not doing anything different in this regard. And again, most of the interesting stuff is on the server side anyway. If anything, WebAssembly can bring stuff that’s more usually on the server side to the client side.
Voracity: “Would you seriously be fussed if all the world’s innovations came 3 years later”
Yes. Now matters. I don’t want to buy new hardware in three years when I can make the hardware I’ve got do the job today. There are always underpowered systems that need to be supported so every performance gain you can get helps. And trust me, it never matters how fast your software is because users always want it to be faster.
Voracity: “Tool chains that live outside the web platform become a requirement. (Tool chains are also bad, for roughly the same reasons as wasm.) ”
Tool chains that live outside the web are already a requirement and realistically always will be, even just on the basic level of a text editor. You need some compiler to compile some language your web server is written in. Similarly for web browsers. Similarly for whatever web framework you use on the server side. If you want to use Java or PHP or C# or whatever language to implement your web service then you need the tools to work with those languages. And let’s not forget that all web software relies on the tools, libraries and services provided by the underlying operating system.
If you never want to use anything hosted outside the web platform, then I’d say that’s what WebAssembly offers. One of its goals is for WebAssembly development to be self hosting, including compiling compilers to WebAssembly so you can code in your language of choice and then compile it to WebAssembly using the WebAssembly build of the compiler. (see the tooling section on WebAssembly’s github repository)
Voracity: “Regardless of the source map issue, people will jump at the chance to use their pet language on the web.”
I’d say people already use their pet language on the web for the reasons above. I don’t see any problem at all with the capability to use whatever language you want to use. If I can write programs for my operating system in whatever language I like, then why not my web page too? If I can program my web server or browser or framework in whatever language I like, then why not my web page as well? To me this makes the web platform less restrictive and opens up more possibilities.
So to my way of thinking WebAssembly increases the openness of the platform, but it’s possible our ideas of openness are different. 😉
I was hoping these apps would leverage js-ctypes. Any chance js-ctypes comes to the other browsers so we have more open source work in it to look at for examples?
Bendan, I believe that if this project is done right, it will be the single most important development in the history of the computer industry – not just the web, but the whole industry. But I have a much broader vision than I’ve seen from the design documents and the public statements on Wasm.
Currently Wasm is focused on supporting C/C++, and that’s fine as a first iteration, just to get the ball rolling. But I’ve been pushing my bigger vision for over a year (a summary of which I sent you on 2014/3/26). In the long run I hope the goals are extended to something truly visionary and disruptive.
First there’s the obvious: Wasm will not replace Javascript as a programming language, only as a VM. But eventually the relationship will flip: rather than running Wasm on top of Javascript, we’ll run Javascript on top of Wasm.
But my vision starts by observing that just as non-web programmers have been pulled toward using Javascript for various reasons, Wasm will make that pull even stronger. In the end, Wasm will be a universal language of the entire computer industry. Not only that, but the possibility of using Wasm as a universal platform can have tremendous benefits to the industry *if it is done right*. Therefore, it’s crucial that we do a good job and not limit our vision.
So let me propose four core design principles for Wasm beyond the MVP:
1. Performance is important. Wasm code should, at the limit, run as fast as C.
2. It should contain a variety of flexible primitives so that the core features of all known languages can be supported somewhat efficiently. In addition to opcodes, I’m talking about design issues like garbage collection, how pointers interact with GC (e.g. the .NET rules are too limiting), “sub-sandboxing”, and metaprogramming features at the JIT level, whether it be replacing code at run-time or injecting profiling instructions.
3. Interoperability between programming languages should be a core focus, and a multi-language standard library should be defined so that different languages can exchange complex data structures with ease.
4. Traditionally, client code on the web has been open-source. Let’s not threaten this tradition. Wasm binaries should be rich in metadata by default, so that it can be decompiled to existing programming languages, complete with documentation. Obfuscation should be opt-in, not opt-out. Incidentally, third parties will use this as a means of converting code between languages.
There are are at least three multi-language VMs that run on the web already: PNaCl, Silverlight, and JVM. Of these three, Silverlight’s .NET Core is now open source, and it adheres to the four principles above more than the other two VMs. .NET Core already supports C/C++ and garbage-collected languages – so why make a new VM? It would be a terrible shame if Wasm ended up being less capable than .NET Core. Instead, Wasm should be a moonshot – let’s make Wasm better than the CLR in every possible way, in a system that is no more complex than the JVM or CLR.
@Voracity: you have some good points. I, too, am concerned that Wasm as currently defined makes it impossible to reconstruct readable source code. .NET has proven (e.g. Reflector, ILSpy) that using a binary bytecode format doesn’t imply that users can’t see the source code (albeit without comments). That’s why my vision would include metadata to allow easy decompilation, and this should be the default, the developer should not get obfuscation unless specifically requested.
– I disagree with the idea that Javascript’s performance disadvantage is “temporary”. First of all, Moore’s law stopped making processors faster all the way back in 2009 or so, and all further speed gains have been incremental (by optimizing architecture). Secondly, even if that weren’t so, C/C++/D/Rust are always faster than Javascript within a particular year. And there are always benefits to higher performance to some developers, whether it’s because they’re making video games, or they are in IoT, or because they want to run their code on a 400MHz processor that costs $1 and will be sent to developing countries. Performance will always be important on the smallest, cheapest devices, in games (which are popular) and on the biggest computational problems.
– In the long run you need not worry that toolchains “live outside the web platform”. In my vision, the web platform will be THE universal platform, and all core tools will surely run on it. Even without my vision, Wasm runs C/C++ so it’ll run a variety of compiler tools.
– Your concern about “developer communities will largely be incapable of talking to each other” is a serious problem with Wasm as currently designed, but my vision includes interoperability as one of the most fundamental problems that we need to very smart about tackling.
– Good point about source maps. If Wasm is easily decompilable, as I propose, you’ll be able to debug and ‘view source’ without source maps, but of course devs will prefer to use source maps and I hope it ends up easy to deploy original source code with the Wasm.
– I must disagree in the strongest terms against the idea that being allowed to use the programming language of your choice is a bad thing. I’m an American, dammit, freedom is the cornerstone of our way of life! More importantly, being able to use features that JavaScript doesn’t have is important for the progress of the software industry as a whole. Non-web programmers are always being pulled toward using Javascript, and I’m concerned this leads to fossilization of the whole concept of programming. Notwithstanding improvements in ES6, there are many programming languages with features you don’t get from JS. Developers have to be allowed to program in other languages in order to learn about different ways of doing things, different ways of seeing things. The ultimate programming language is not yet invented. The industry needs freedom so that innovation in language design will continue.
Just FTR, I’ve corresponded privately with David and others, and I’ve strongly suggested that any long-form comments are better off on your own blogs. You can leave links here, for sure.
Also, remember the key to the wasm breakthrough: 1VM, like 1JS: no second or third VM and consequent cycle collector and other costs that killed DartVM-in-Chrome. This means no CLR or JVM, sorry. The JS VMs (all top four, and more) stand ready to evolve with wasm.
/be
@Brendan: Absolutely, I’ll respect your wishes to avoid long form comments here. (Although it has the unfortunate unintended side-effect of ending the conversation.) There were 2 major points that emerge from Ryan and David’s comments that I was hoping to address quickly.
Performance: I’ll reassert that performance is a temporary advantage. I could write lots, but I think the most impressive point is that parallel code completely obliterates serial code (C, JS, [blob], whatever) for almost all real-world problems. 128+ core CPUs (which Servo+ will create demand for), coupled with parallel algorithm thinking (already happening), will make the small differences in performance across languages entirely ridiculous.
One Language: I think I’ve misled. Multiple languages are great, as are multiple frameworks/libraries. But once an idea becomes obviously universally useful, it should be standardised at the source level. Multiple source languages that all do the same thing *is* silly, in the same way that multiple dialects of HTML would be silly (that’s why standards exist — to prevent the very problems that arise from all of that duplication!) Wasm will encourage developer communities to stop talking to each other.
Also, @Ray: Yes, I think our ideas about openness are a bit different. I believe your describing what I’d be more inclined to call freedom. Freedom is a much more complex concept than people realise — e.g. the GPL restricts some freedoms to protect what it believes are more important ones.
(242 words. Not too bad. 🙂 )
Thank you, Brendan! Great news!
Really curious about WebAssembly developments!