Been checking in on this since the initial hubbub a few months ago... It would be great if it started to swing into high gear.
I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.
There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines.
We've still got a long ways to go, but it's much nearer than 10+ years!
I'd guess 3-5 if you look at most penetration once an initial implementation takes hold in browsers... now, you may have upwards of 30-40% of people not covered by a feature, but that doesn't mean you can't target it... it comes down to your audience... If MS actually keeps its' promise of rolling releases, or closer to it this time, it could be much sooner than later.
With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.
It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1].
Seth, the wasm "Text Format" doc at [1] says one of its purposes is "Presentation in browser development tools when source maps aren't present (which is necessarily the case with the Minimum Viable Product (MVP))" and that "Debuggers and profilers will present binary code using this textual format."
However, bugs like [2] suggest to me that the Chrome and Firefox teams do not place an especially high priority on readability and debuggability with source maps in plain old JavaScript. Basically, it's impossible to use Chrome Devtools to see original variable names from the source file (e.g. 'jquery.js') instead of the minified file (e.g. 'jquery.min.js') mapped by the source-map file. This essentially makes source maps useless for debugging complex code and has been a known issue for almost two years.
The most recent comment in that ticket notes work is blocked until a new version of the sourcemap spec is shipped, but the linked resources indicate there hasn't been any public activity on them in three weeks with the Sterland proposal [3] and three months with the Fitzgerald proposal [4].
If keeping the web open source is indeed a priority of Google and Mozilla, then why haven't more resources been allocated to develop those specifications?
In brief, the lack of urgency for bugs like [2] suggests to me that Google and Mozilla don't take "The JavaScript Trip" described by Stallman [5] seriously. I fear that wasm could make it much worse.
The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case).
WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).
WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is.
If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed.
And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.
Maybe they were referring to embedding the advertisers code into the code base itself without network calls? But I still don't see how this is any different than current sites that serve ad content through their own servers.
pdkl95 has brought this up before[1] and again, it looks like everyone is confused by his (mis)understanding of: WebAssembly, The Halting Problem, and the economics+friction of practical advertising delivery (now and in the future.)
I couldn't convince him/her that any future trends towards pre-built ads rendered on server proxies, or seamless "native advertising", is orthogonal to WebAssembly.
Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods.
That said, a new type of adblocker based on pattern-matching against a JS syntax tree would be pretty useful.
> Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts.
This is true, but it's not problem unique to WASM. In fact, your proposed pattern matching AdBlocker seems like it would be much easier to produce targeting WASM.
It's also worth nothing what an edge case this is. Some sites might do this, but large enough sites to be worth doing this will likely be large enough to inspire site-specific workarounds. Smaller sites will be unlikely to couple their ads to their rendering so tightly.
WebAssembly is just a new storage format for asm.js, which is just a javascript subset. It doesn't replace the DOM. That still exists just as it does with Javascript! Any openness problems that exist with WebAssembly already exist with minified Javascript.
That's not really the use case for it, the use case for Web Assembly is to take web audio and turn it from being a kind of toy into a platform where an ableton live could be empowered to run in the browser, as well as being able to load native plugins for audio processing and generation. Also say you want to transcode a video file from webm to hls, with web assembly that becomes possible, even with asm.js its really brutally slow to try to do that.
> and I fear it will introduce the Halting Problem in to a lot more areas.
This is the part of your post where I concluded that you were deeply confused and stopped reading. The didactic part of me wants to teach you what the halting problem is, but I'm not even sure what it is you don't know at this point.
You'll be able to reverse engineer. Interpreting JS is a massive waste of CPU/battery for the majority of users. The savings is worth a slight increase in complexity for developers.
The solution to high CPU/battery usage is to send a static page. Invoking a new type of VM may help slightly, but it probably just moves the problem around.
As someone who works in the web space, albeit on the back-end, can anyone explain why a project like this is desired over a better language / run-time?
wasm and asm.js are perfect examples of incremental improvements rather than building something from scratch. The benefit of this is that incremental improvements can be built slowly on top of existing deployed JavaScript engines, whereas writing something from scratch has a serious bootstrapping problem.
The wasm/asm.js story goes like this so far:
1. emscripten, a JavaScript backend for LLVM, demonstrates that you can "compile" C/C++ code into JavaScript.
2. Some vendors start writing specific optimisations for emscripten-style JavaScript code.
3. This is formalised into a subset of JavaScript called asm.js.
4. More browser vendors get onboard with asm.js optimisations.
5. wasm is proposed. Initially it is a compact binary format that is equivalent to asm.js and that can be trivially translated into asm.js at runtime using a polyfill.
The future might look like this:
6. Browsers adopt wasm natively, so the asm.js shim can be dropped, giving more performance benefits.
7. Further enhancements to wasm follow and wasm perhaps begins to diverge from its underlying JavaScript runtime.
Hardware support only makes sense if the optimisations are already included in the compiler output. The JVM does all the optimisations which makes Java Bytecode not suitable for that purpose.
I guess the argument boils down to "path dependence". We're highly unlikely to get any language environment other than Javascript, so mutate Javascript to try and strong-arm it into something better.
Some people say Javascript is the best language , you see the problem ? nobody will ever agree on what "a better language" means.
JavaScript is constrained by forward compatibility. The goal here is to let people choose the language they want to develop with. The APIs will stay the same, and that's what matters. Front end development shouldn't be about knowing Javascript ninja tricks, but web and DOM apis.
The idea of a good language evolves over time, and varies among people. Look at how many languages transpile to JavaScript today. If you ask the users of those languages, they'll tell that their language is the "better language" you're looking for.
I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms.
Almost feels like a throwback to the days of entirely flash-based websites......
This would be terrible for the web from crawl-ability, accessibility, extension and OS integration points of view.
The web is awesome because it's document based, and largely because of links embedded in a open document format. Get rid of the document and you get rid of readable links, web crawlers, find-in-page, screen readers, and on and on...
This assumes what you want is documents. The web is already great for documents. Meanwhile, a lot of people also want apps. You can bemoan document viewers being stretched beyond reason into app platforms, but it already happened over a decade ago and shows no sign of slowing. It's time to just deal with it. With wasm and webgl, these document viewers can at least be slightly less crappy app platforms.
We're working hard to make sure that WebAssembly is a first-class citizen in the open web platform in ways that other native execution environments didn't accomplish.
For example, it's a goal to have WebAssembly modules interopt with the ES6 module system, and as soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly [0]. Both of these are huge steps towards ensuring that wasm plays well with everything that's great about the web today.
> As soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly.
Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.
We'll start tackling GC as soon as we finish the MVP [0]. No timeline yet, but we consider it essential to the high level goal of integrating well into the existing platform.
Check out the last paragraph of "Is WebAssembly only for C/C++ Programmers?" in the FAQ [0]. The tl;dr is that you'll be able to port a Python interpreter (that is itself written in C) to WebAssembly from day 1, but a more robust solution that relies on WebAssembly GC will have to wait until after the MVP.
The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it.
Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s not without reason that Photoshop, ProTools, Maya, Excel, Final Cut, SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of other serious tools don’t have credible web alternatives.)
They’re slower. They aren’t persistent. They change all the time with no ability for the user to prevent it, sometimes spontaneously breaking when the developer stops supporting the user’s browser or goes out of business. They make it hard for users to load/save local data, and instead they store personal data on a faraway server. Accidentally pressing the back button can destroy hours of user work. They usually have terrible accessibility. They don’t interoperate with other applications on the system. They flagrantly violate UI design conventions on every platform. They can’t access most local hardware devices. They have an extremely limited user input device model. Their UI layout tools are limited, inflexible, and incredibly hard to work with. They throw out decades of implementation effort on various standard solutions to problems and force complete reimplementation from scratch. They are difficult or impossible to build proper cryptographic primitives on top of.
In short, web applications are inherently second-class citizens on every platform.
BUT! Web applications are also amazing. Dropping the barrier to entry – URLs and HTTP and fairly reliable code sandboxing – makes all the difference, and makes the web an extremely attractive platform despite its many flaws.
> web applications are inherently second-class citizens on every platform.
Yes. By design. If a webpage can impersonate a local app, you have a serious security problem.
> They make it hard for users to load/save local data
There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc.
> They don’t interoperate with other applications on the system.
That's a feature.
> They flagrantly violate UI design conventions on every platform.
The user agent can render the page however it wants. This is a feature.
> They can’t access most local hardware devices.
Are you trying to introduce even more security problems?
> They are difficult or impossible to build proper cryptographic primitives on top of.
That's not the place you should be implementing crypo.
> Accidentally pressing the back button can destroy hours of user work.
Ok, that one would be nicer to fix, but that's a problem for the browser, and shouldn't impact the page at all.
--
If you want to develop software that uses more than the web can provide, you should choose a platform that actually provides those features. There is a trade-off, of course, but making that kind of decision is a an important part of software engineering.
While many people have been ignoring some or all of the security aspects of programming, it is important to remember that anything connected (even indirectly) to a network is under attack, so security must be considered first.
I think what your parent comment was saying was that : 'even though web is a great solution to many problems that can be solved with software, it has its limitations'. Clearly the problems s/he mentioned are a source of pain for some users, and many of them do not exist in the native application platform. Even if those trade-offs look unreasonable to you, it may not look so to many others. If we have more data to support the statement that somehow the web is always superior to native, then this discussion can move forward. Without it we are more likely going around in circles.
Flash should definitely export to WebAssembly and retire its player once and for all. Whether Adobe is ready to do that is another issue.
Flash is still an excellent IDE for artists. And I enjoy some "creativity" on the web. The "everything's flat and like the next site because Bootstrap" web is getting old.
It's possible to eschew the DOM even today with just JavaScript & <canvas> [0]! While this would be possible with wasm & WebGL as well, we're working to build something that integrates well into the open web platform. Check out #3 from our high-level goals [1].
Flash and Java applets were (and are) kind of terrible, but the basic premise of compiled binary applications accessible as embeds in a browser is, I think, potentially more revolutionary than even that of the web as linked documents. It just may be that the first iteration of this was too primitive to realize its true potential, and the traditional javascript run "web app" is just an awkward interstitial phase we have to get past.
Although... I also think that at some point the line between the web, browser and operating system might have to blur or disappear entirely.
As someone who works in VR this is something I've been thinking about a lot. We need an open platform for creating and sharing VR content which is 3D rendered. WebAssembly + WebVR + WebGL might be the beginning of that platform.
The reason for that is very simple. asm.js has no access to the DOM. You have no choice other than to use WebGL. Guess what problem web assembly is trying to solve?
1. factorial in S-expressions: https://github.com/WebAssembly/spec/blob/master/ml-proto/tes...
2. ray tracing in a C style: https://github.com/ncbray/wassembler/blob/master/demos/raytr...