My excitement for WASM has nothing to do with speed or efficiency of the runtime. It's all about finally having a universal compile target for the web. We're finally going to be able to develop web apps in a proper language of our own choosing, without needing hacks like TypeScript.
Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iOS and Android native development.
> 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.
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.
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).
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.
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.
On one hand, I'm excited about performance improvements. On the other, I lament the fact that this will kill one of the best parts of the web: the fact that the source is sent to the end user instead of a binary. It now makes the code and how it works opaque, thus killing the spirit of innovation and learning.
The edge over asm.js is a subset of this. Obviously, asm.js neither has JIT reoptimisation overhead, nor garbage collection to worry about.
However, a weird, highly-annotated strict subset of JS is not the ideal representation of what is basically portable assembly language. WebAssembly's big strength over asm.js is it has smaller executables and they can be rapidly decoded and verified in binary IR form, rather than having to shove megabytes of ungzipped bracket-fest through a JS parser.
> WebAssembly's big strength over asm.js is it has smaller executables
It's not about the "smallness" as measured in the number of bytes, the minimized (that is, short variable names, no comments and whitespaces) asm.js code with the "bracket-fest" can actually be quite compact.
It is about the form which does save some lexing, parsing, searching and allocation steps in the run-time. Which matters when the code is measured in megabytes and the goal is to run it as soon as possible and save as much battery as possible on the mobile devices. From the FAQ:
"The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding" "is critical to providing a good cold-load user experience."
A big part of the advantage is more consistent adoption by browsers. All the major browsers have experimental WebAssembly support already, and Firefox and Chrome are already shipping it (although it's off by default). Firefox/SpiderMonkey and Edge/Chakra have AOT compilation for asm.js, but notably Chrome/V8 doesn't (although they did optimize its performance significantly). Asm.js also still hasn't become a formal spec, while WebAssembly is already very close.
> Obviously, asm.js neither has JIT reoptimisation overhead
Why does it never need to re-optimise the JITed code? I know WebAssembly and asm.js are more static than JS, but even very static languages like C benefit from speculative optimisations which may need to be reversed. For example asm.js and WebAssembly have branches don't they? Does the JIT always compile both branches even if one has never been taken in practice?
And what is the reoptimisation overhead anyway? If deoptimisation is caused by a bad speculation on the same thread, it's zero overhead on the fast path until it's used isn't it?
I really hope web assembly takes off and becomes a thing wide implemented in all the major browsers. The web is such a fantastic application platform (despite its frequent misuse...), and removing the javascript performance tax will be huge.
JavaScript is not just a performance tax, it's also a language that is poorly suited to a great number of tasks which we would like to apply web browsers to today.
Not that it is all around terrible, but definitely much preferred if we can choose the best language for the job instead of being strictly stuck with JavaScript.
While Javascript has its flaws, it's been refined over many years and finally there are pretty decent ways of building UI's, using React, Vue etc. Wouldn't we have to start all over again if people begin to write UI code in languages not built or configured for interacting with the DOM?
Is WebAssembly's binary format finalized? I wasn't able to find anything about it, but about two weeks ago binaryen pushed a new release[1] whose notes said "update wasm version to 0x01, in prep for release, and since browsers are ready to accept it".
From what I had heard the plan was not to do that until the final standard was settled on, but I wasn't able to find any corresponding announcement.
What's the point if you can't interact with the DOM?
Almost all examples of webassembly just render to a canvas.
Does this mean instead of a normal "native app" I'm going to start getting C applications compiled with wasm and distributed in electron? What does this possibly gain the end user?
You're unnecessarily constraining your thinking to the present-day Web. WASM fundamentally expands what's feasible in that domain.
For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal, or for lower level libraries like OpenCV, libsass, or libarchive which you might want to use in your web application.
No one is arguing that WebAssembly will completely replace JavaScript, especially not right out of the gate, but it will be used to optimize hot code paths within JS apps, as well as allowing robust, efficient, native libraries to be used directly on the Web. This is more about the pie getting larger than it is about WebAssembly hypothetically crowding out JavaScript.
>At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent.
I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement reference counting (and maybe automatic reference counting) similar to Objective-C, and if so, would that simply be a matter of the particular language and WebAssembly transpiler you're using supporting it? And are there disadvantages to reference counting that make it a bad idea? I enjoyed using it doing earlier iPhone programming.
I recall seeing a test compile of some C++ code to WebAssembly instead of JS and on Chrome it was an order of magnitude slower than the JS version. Has the performance increased lately?
Javascript is an awfully designed language (it's getting better, but the basics are awful, no ints, crazy comparsions...) I hope that it will die soon and enable everybody to write web apps in a language of their choosing.
This may even end the craze around JS frontend tooling.
Yay! Nothing improved for me as a consumer, but total control of the app by Microsoft (it runs on their website and I don't even own my own copy) and slower speed (because of the extra VM and sandbox).
WebAssembly won't give you unlimited power. You will still have the browser sandboxing and security / privacy policies in place. Accessing to the local file system is for instance constrained in the browser for good reasons. WebAssembly apps will be able to do what Web APIs let any page do.
It's both amusing and absurd that what was practically intended as Java's little helper, JavaScript, has grown up to be this thing that might actually replace Java entirely.
How long until there's a really good JVM written in JavaScript of some form and embedded Java apps end up running in JavaScript for performance and security reasons?
It'll be even more ridiculous and hilarious if the "j" in "jruby" ends up meaning "JavaScript".
> It's both amusing and absurd that what was practically intended as Java's little helper, JavaScript, has grown up to be this thing that might actually replace Java entirely.
I though JS was named to piggyback on Java's popularity, not because it was actually intended to complement Java.
> How long until there's a really good JVM written in JavaScript of some form and embedded Java apps end up running in JavaScript for performance and security reasons?
That's an amusing idea. But it's extremely unlikely for the same reason that you are unlikely to see C++ rewritten in JavaScript.
It's possible, however, that over time, more and more languages might target JavaScript, rather than the JVM or the native hardware.
For instance, I program in Scala for a living. The main platform for Scala is the JVM, but there's also Scala.js, which targets JavaScript. And in fact, we now write most of our "JavaScript" in Scala, rather than in JavaScript.
I suppose that someday there might be a version of Java that targets JavaScript, and then your dream might come true. Oh wait... it already happened! It's called GWT and it's been around for a decade.
Java and Javascript are related like Car and Carpet are similar.
There was no historical connection between Java and JavaScript beyond renting the brand "Java" from Sun to make the language more credible.
It would be interesting to recompile the old applet plugin as WebAssembly - it should be both secure (well, as secure as WebAssembly ever will be) and fast.
>How long until there's a really good JVM written in JavaScript of some form and embedded Java apps end up running in JavaScript for performance and security reasons?
Much of the JVM is written in C++ (From the docs: "There are nearly 1500 C/C++ header and source files, comprising almost 250,000 lines of code.")
>has grown up to be this thing that might actually replace Java entirely.
Java is just a language that runs on JVM, there have been many many attempts to replace it with languages brand new ( scala), existing languages ( jruby) including javascript( nashorn/ringojs ect), but no language has even come close to dethroning it. Its unlikely that javascript will replace it just because jvm is rewritten in java script.
> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent.
Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many people writing SPAs in C++ for the extra speed (let's say, the JS layer acting like an X Server for the DOM, driven by a C++/WebAssembly application). Games, yes.
Furthermore JS has view source. WebAssembly has a text format [1] but it's really assembly. Hopefully there will be source maps [2].
You don't have to go back to the 80's to develop closer to the metal. Neither Rust nor Swift have garbage collection, but both are thoroughly modern, productive languages. I've also been told that C++14 is reasonably pleasant, but I have no personal experience with which to judge.
The lack of GC is a benefit here. Remember, WASM as an MVP is meant to bring C/C++ codebases on the web.
There is plenty to be excited about here. This will enable faster [media apps, games, etc](http://webassembly.org/docs/use-cases/) on the web. Wasm is knocking at the door and I can't wait to see what it's bringing with it.
Edit: HN really should support a few more formatting options.
There are a lot of developers -- a huge amount, actually -- who believe memory management is too important to leave to an automated GC algorithm. That, and the memory requirements of a particular application might require something different than a GC provides.
Many developers have no practical exposure to compiled languages, and are prone to believe that Node.js is generally "faster" than Java and comparable to C++. We all had to learn this stuff somewhere. :)
I see what you mean, but it's actually possible for JITed code to be faster than compiled code, as JIT can make run-time optimisations that aren't visible at compile-time.
I realize this is about discussing technical merit, but I'd like to share a less naive view of what WebAss does to the web (eg. DRM, making ad-blockers impossible, etc.) over in the [other thread] (https://news.ycombinator.com/item?id=13755370).
Right now, the discussion evolves around finding fecalia-/coprophilia-inspired names for the WebAss ecosystem. Can't wait until America Awakens to contribute :)
[+] [-] aphextron|9 years ago|reply
Hopefully, this will lead to real dedicated IDE tooling and standardized libraries for the web along the lines of what's available in iOS and Android native development.
[+] [-] Svenskunganka|9 years ago|reply
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.
[+] [-] ncantelmo|9 years ago|reply
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.
[+] [-] AgentME|9 years ago|reply
[+] [-] skybrian|9 years ago|reply
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.
[+] [-] K0SM0S|9 years ago|reply
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.
[+] [-] rocky1138|9 years ago|reply
[+] [-] TazeTSchnitzel|9 years ago|reply
However, a weird, highly-annotated strict subset of JS is not the ideal representation of what is basically portable assembly language. WebAssembly's big strength over asm.js is it has smaller executables and they can be rapidly decoded and verified in binary IR form, rather than having to shove megabytes of ungzipped bracket-fest through a JS parser.
[+] [-] acqq|9 years ago|reply
It's not about the "smallness" as measured in the number of bytes, the minimized (that is, short variable names, no comments and whitespaces) asm.js code with the "bracket-fest" can actually be quite compact.
It is about the form which does save some lexing, parsing, searching and allocation steps in the run-time. Which matters when the code is measured in megabytes and the goal is to run it as soon as possible and save as much battery as possible on the mobile devices. From the FAQ:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
"The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding" "is critical to providing a good cold-load user experience."
[+] [-] johncolanduoni|9 years ago|reply
[+] [-] chrisseaton|9 years ago|reply
Why does it never need to re-optimise the JITed code? I know WebAssembly and asm.js are more static than JS, but even very static languages like C benefit from speculative optimisations which may need to be reversed. For example asm.js and WebAssembly have branches don't they? Does the JIT always compile both branches even if one has never been taken in practice?
And what is the reoptimisation overhead anyway? If deoptimisation is caused by a bad speculation on the same thread, it's zero overhead on the fast path until it's used isn't it?
[+] [-] lacampbell|9 years ago|reply
[+] [-] Taek|9 years ago|reply
Not that it is all around terrible, but definitely much preferred if we can choose the best language for the job instead of being strictly stuck with JavaScript.
[+] [-] hakanito|9 years ago|reply
[+] [-] axefrog|9 years ago|reply
[+] [-] 6nf|9 years ago|reply
[+] [-] johncolanduoni|9 years ago|reply
From what I had heard the plan was not to do that until the final standard was settled on, but I wasn't able to find any corresponding announcement.
[1]: https://github.com/WebAssembly/binaryen/releases/tag/version...
[+] [-] callahad|9 years ago|reply
[+] [-] daurnimator|9 years ago|reply
Does this mean instead of a normal "native app" I'm going to start getting C applications compiled with wasm and distributed in electron? What does this possibly gain the end user?
[+] [-] callahad|9 years ago|reply
For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal, or for lower level libraries like OpenCV, libsass, or libarchive which you might want to use in your web application.
No one is arguing that WebAssembly will completely replace JavaScript, especially not right out of the gate, but it will be used to optimize hot code paths within JS apps, as well as allowing robust, efficient, native libraries to be used directly on the Web. This is more about the pie getting larger than it is about WebAssembly hypothetically crowding out JavaScript.
[+] [-] jlebrech|9 years ago|reply
[+] [-] ClassyJacket|9 years ago|reply
I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement reference counting (and maybe automatic reference counting) similar to Objective-C, and if so, would that simply be a matter of the particular language and WebAssembly transpiler you're using supporting it? And are there disadvantages to reference counting that make it a bad idea? I enjoyed using it doing earlier iPhone programming.
[+] [-] etimberg|9 years ago|reply
[+] [-] hoschicz|9 years ago|reply
This may even end the craze around JS frontend tooling.
[+] [-] msoad|9 years ago|reply
[+] [-] coldtea|9 years ago|reply
Can't wait!
[+] [-] dmarcos|9 years ago|reply
[+] [-] austinjp|9 years ago|reply
Is anyone working on such a thing?
[+] [-] astrodust|9 years ago|reply
How long until there's a really good JVM written in JavaScript of some form and embedded Java apps end up running in JavaScript for performance and security reasons?
It'll be even more ridiculous and hilarious if the "j" in "jruby" ends up meaning "JavaScript".
[+] [-] dragonwriter|9 years ago|reply
I though JS was named to piggyback on Java's popularity, not because it was actually intended to complement Java.
[+] [-] nessus42|9 years ago|reply
That's an amusing idea. But it's extremely unlikely for the same reason that you are unlikely to see C++ rewritten in JavaScript.
It's possible, however, that over time, more and more languages might target JavaScript, rather than the JVM or the native hardware.
For instance, I program in Scala for a living. The main platform for Scala is the JVM, but there's also Scala.js, which targets JavaScript. And in fact, we now write most of our "JavaScript" in Scala, rather than in JavaScript.
I suppose that someday there might be a version of Java that targets JavaScript, and then your dream might come true. Oh wait... it already happened! It's called GWT and it's been around for a decade.
[+] [-] batmansmk|9 years ago|reply
[+] [-] greenhouse_gas|9 years ago|reply
[+] [-] andrewbinstock|9 years ago|reply
Much of the JVM is written in C++ (From the docs: "There are nearly 1500 C/C++ header and source files, comprising almost 250,000 lines of code.")
[+] [-] amorphid|9 years ago|reply
[+] [-] dominotw|9 years ago|reply
Java is just a language that runs on JVM, there have been many many attempts to replace it with languages brand new ( scala), existing languages ( jruby) including javascript( nashorn/ringojs ect), but no language has even come close to dethroning it. Its unlikely that javascript will replace it just because jvm is rewritten in java script.
[+] [-] kristianp|9 years ago|reply
[+] [-] pmontra|9 years ago|reply
Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many people writing SPAs in C++ for the extra speed (let's say, the JS layer acting like an X Server for the DOM, driven by a C++/WebAssembly application). Games, yes.
Furthermore JS has view source. WebAssembly has a text format [1] but it's really assembly. Hopefully there will be source maps [2].
[1] http://webassembly.org/docs/text-format/
[2] http://webassembly.org/docs/tooling/
[+] [-] callahad|9 years ago|reply
[+] [-] deburo|9 years ago|reply
There is plenty to be excited about here. This will enable faster [media apps, games, etc](http://webassembly.org/docs/use-cases/) on the web. Wasm is knocking at the door and I can't wait to see what it's bringing with it.
Edit: HN really should support a few more formatting options.
[+] [-] hellofunk|9 years ago|reply
[+] [-] verletx64|9 years ago|reply
[+] [-] hacknat|9 years ago|reply
[+] [-] kebolio|9 years ago|reply
[+] [-] calahad|9 years ago|reply
[+] [-] callahad|9 years ago|reply
[+] [-] Qwertious|9 years ago|reply
[+] [-] tannhaeuser|9 years ago|reply
Right now, the discussion evolves around finding fecalia-/coprophilia-inspired names for the WebAss ecosystem. Can't wait until America Awakens to contribute :)