21 ms·

What makes WebAssembly fast?

338 points by nfriedly 10y ago

astrodust 10y ago
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".
- greenhouse_gas 10y ago
  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.
  - astrodust 10y ago
    I seriously can't wait for a Flash in JavaScript so that all those old Flash games don't get shuttled off to the dustbin of history, never to be enjoyed again. I do not want to ever have to update Flash again. Ever.
    - greenhouse_gas 10y ago
      That's a dead Mozilla project called Shumway
- batmansmk 10y ago
  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.
  - astrodust 10y ago
    Yes and no. In practice JavaScript was sometimes the thing that detected if Java was present and kicked off a Java applet. It also handled roll-overs before CSS was a thing, doing mundane stuff by comparison to what a full Java app could do. It was intended to be complementary.
  - zeveb 10y ago
    Well, it's possible that if it hadn't been for Java JavaScript might have had a decent, parens-based syntax. I still wonder what might have been if Eich had been allowed to write the Scheme system he had been hired to do. While I'm not a fan of Scheme by any means, it is approximately 281,757,423,024,353 better than JavaScript. And Scheme's a great little language for implementing other languages. Imagine, we could have had transpiling years ahead of time. We might be using S-expressions instead of JSON. Heck, we might even have moved to an S-expression syntax for HTML & CSS by now. Imagine, one syntax for everything (thanks to https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_inner_html https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_... & https://www.w3schools.com/css/css_howto.asp https://www.w3schools.com/css/css_howto.asp for the examples): (html (head (title "Example") (style (body (background-color linen)) (h1 (color maroon) (margin-left (px 40))))) (body (h1 "What can JavaScript do?") (p (@ (id "demo")) "JavaScript can " (em "change") " HTML content.") (button (@ (type "button") (onclick (set! (inner-html (get-element-by-id document "demo")) "Hello JavaScript!"))) "Click me!"))) The world could have been so much better.
    - nessus42 10y ago
      I'm a HUGE fan of Scheme. And of Lisp, in general. But having seen in the "real world" how so many people are so adverse to Lisp's beautiful syntax, I'm pretty confident that JavaScript would never have caught on if it looked like Lisp rather than like C.
      - zeveb 10y ago
- dragonwriter 10y ago
  > 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.
  - sandyarmstrong 10y ago
    "That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language." http://www.infoworld.com/article/2653798/application-development/javascript-creator-ponders-past--future.html http://www.infoworld.com/article/2653798/application-develop...
- amorphid 10y ago
  Until JavaScript offers a robust concurrency abstraction, I don't see it completely replacing anything that is used for that purpose.
  - voxic11 10y ago
    Async/await and promises are quite good concurrency abstractions.
  - brlewis 10y ago
    Based on the comment you're replying to I infer that you think Java offers a robust concurrency abstraction. I disagree. In moving to the single-threaded async style of JS concurrency, the hardest part for me has been to rid myself of the ugly habit I acquired from Java's threading model, i.e. asking myself at each line of code, what happens if my thread gets preempted here?
- dominotw 10y ago
  >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.
  - lanna 10y ago
    > Its unlikely that javascript will replace it just because jvm is rewritten in java script. that is not what oc meant. he is talking about runtime env, not source language
- andrewbinstock 10y ago
  >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.")
- nessus42 10y ago
  > 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.
msoad 10y ago
I can totally see Qt a and .NET apps running on top WebAssembly. Imagine MS Word is running in your browser without them having to rewrite it in JS!
- dmarcos 10y ago
  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.
  - mstade 10y ago
    Is this universally true – i.e. baked in to the wasm spec – or is it just true in a browser environment? Consider things like NW.js[1] or Electron[2] – might we see cross platform apps being developed where all or parts of it are written in <insert language here> and compiled to wasm, then packaged up with a runtime and delivered as a "native" application for desktop, mobile, or whatever? [1]: https://nwjs.io https://nwjs.io [2]: https://electron.atom.io https://electron.atom.io
    - johncolanduoni 10y ago
      No, the wasm spec doesnt mention web standards at all. It can be implemented without a JavaScript VM nearby, and at the moment isn't even capable of interacting with the DOM/JavaScript APIs directly when it is run in web browsers.
    - noam87 10y ago
      What would be the benefit of that? Might as well just compile to native and distribute that without all the overhead, no?
      - mstade 10y ago
        I probably should have specified but I was referring to GUI applications specifically. For things without a GUI, or that require deeper system integration than you get with these runtimes you're absolutely right – there's little point. But for a very large class of GUI applications it makes a lot of sense, working with technologies that not only have stood the test of time and are good enough for plenty of use cases, but also mean you can with very little effort package your application for multiple operating systems. Some of these applications will need stronger performance than can be provided by the JS engine, so hence the question re: wasm. Does that make more sense?
TazeTSchnitzel 10y ago
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.
- chrisseaton 10y ago
  > 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?
  - coldtea 10y ago
    >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. Because its marginal returns?
  - acqq 10y ago
    > 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? WebAssembly is treated just like other "real binaries" produced for the "real" OS. Whatever survived the static optimizations while producing the binaries is converted, at the end, to the pure machine code, you don't "trace" it in run-time by the user. > even very static languages like C benefit from speculative optimisations which may need to be reversed. I'm not aware of "speculative optimisations which may need to be reversed" in C, and I'd be very interested to read what you mean when you write that, possibly with some links and references. Do you mean run-time, by the user, or something else?
lacampbell 10y ago
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.
- Taek 10y ago
  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.
- 6nf 10y ago
  It looks very promising, most major players have experimental support for web assembly already.
- axefrog 10y ago
  The W3C spec is now finalised and locked in, and Chrome and Firefox will release Web Assembly completely in their next releases, respectively.
- hakanito 10y ago
  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?
etimberg 10y ago
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?
pmontra 10y ago
> 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]. [1] http://webassembly.org/docs/text-format/ http://webassembly.org/docs/text-format/ [2] http://webassembly.org/docs/tooling/ http://webassembly.org/docs/tooling/
- callahad 10y ago
  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.
  - matthewmacleod 10y ago
    Swift is garbage-collected – it might not have a tracing GC, but ARC is essentially compile-time GC – certainly, from the perspective of a developer, ARC is extrordinarily similar to a tracing GC (with some small caveats).
    - int_19h 10y ago
      Reference-counted GC is trivially implemented on top of WebAssembly memory model.
    - chatterbeak 10y ago
      Well, if you're going to say that, then C++ with smart-pointers is Garbage Collected, and nobody says that!
    - 10y ago
Svenskunganka 10y ago
> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly for their language of choice. It's not just C/C++. Go, Rust, Ruby, Python, Crystal, Nim, D, and many more. Now you might get the reaction that "meh, why would anyone write web apps with Rust?", but that's an irrelevant question. Companies are going to see this as an opportunity to save resources and become more efficient, especially since wasm has so much better perf than JITed JS and the possibility of going isomorphic is a reality (back-end & front-end written in Ruby for example, deriving from the exact same codebase and shares code). Now I'm not saying "WebAssembly will take over JS!", what I'm saying is that it perhaps, possibly, maybe will. It will depend on these languages and how they add support for it, what abstractions and integrations they provide with their current ecosystems. And of course, how WebAssembly will improve over the coming years.
- AgentME 10y ago
  You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if many do it soon for anything more than a small high-performance core or for a large application that has a small DOM surface area (a game that just renders to a canvas).
  - Svenskunganka 10y ago
    Yes of course, but only during the early stages. The post-MVP roadmap for WebAssembly specifies DOM & Web API integration (http://webassembly.org/docs/gc/ http://webassembly.org/docs/gc/), so that specific case will too disappear with time. If you read point 3 on this page (http://webassembly.org/docs/high-level-goals/ http://webassembly.org/docs/high-level-goals/) you should realize that the need for JavaScript won't be required at that point. edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.
daurnimator 10y ago
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?
- callahad 10y ago
  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.
  - daurnimator 10y ago
    > For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal My point was who wants these to be in the browser? I mean they're cool as demos, but I don't see the use. Is it just people using web browsers as the content delivery platform instead of e.g. Steam?
    - pdkl95 10y ago
      > who wants these to be in the browser Anybody that resents the user having ultimate control over the User Agent. A game in e.g. the Unity engine isn't important. Instead, there are a lot of people that would love to replace their (easily adblockable) web page with a small opaque binary that contains freetype, custom layout/UI library, and maybe "drm"-like obfuscation. You don't need the DOM if you intent to render everything yourself. At best, we will see a new wave of "flash intro"[1] style "custom user experience" replacing perfectly usable HTML pages. At worst, this could be the catalyst that replaces what remains of the open web with a locked down "cable tv"-like mess. [1] http://www.zombo.com/ http://www.zombo.com/
johncolanduoni 10y ago
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. [1]: https://github.com/WebAssembly/binaryen/releases/tag/version_28 https://github.com/WebAssembly/binaryen/releases/tag/version...
- callahad 10y ago
  Yes. Here's the announcement: https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html https://lists.w3.org/Archives/Public/public-webassembly/2017...
ClassyJacket 10y ago
>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.
- dalailambda 10y ago
  Since languages like Rust/C++/Swift compile reference counting into machine code already, there's no real reason why they shouldn't be able to compile it to WebAssembly.
- q3r3qr3q 10y ago
  > And are there disadvantages to reference counting that make it a bad idea? I thought it had a performance cost.
  - ktRolster 10y ago
    Not much of one. The amount of time it takes to allocate the memory and free it is the dominant factor.
    - comex 10y ago
      Maybe in the non-atomic case. Atomic refcounts force synchronization between CPUs when different threads access the same data, even if they only read it; that can have a quite significant cost.
      - repsilat 10y ago
        They also tend to prohibit some smart gc optimisations like moving your shit while you're not looking, and the cache behaviour can be bad because either, - the data isn't stored next to the count so you get two pointer indirection per access, or - the data is stored next to the count, and the object gets cached-in when it gets collected. Piggybacking on the thread because I haven't had much concrete experience with smart pointers: how does the "circular chain" problem seem to manifest? Is it - "goes wrong quickly," usually picked up and fixed without too much trouble, - "like any old memory leak" -- maybe a problem if processes run a long time, hard to track down, or - devs are usually smart enough to see them coming, knowing to keep the "has a pointer to" relation a partial order (either by type or some other natural hierarchy.) ?
kristianp 10y ago
When compiled from C/C++, does WASM do bounds checking of pointers and arrays? What kind of memory safety does it offer?
- azernik 10y ago
  WASM offers a virtual machine to the user, in which there are global variable slots, a stack for local variables, and one or more "linear memories" (chunks of RAM for heap allocations). The first two are completely bounds-checked - you tell the virtual machine to operate on a certain offset in a global/local variable ID, and you are safe from your access affecting anything outside of that variable. The linear memories, on the other hand, are up to you - you can execute operations on address within a linear memory, and it's up to you if you messed up and overwrote or read out data that you shouldn't have. What you do get is a) protection against heap overflows affecting values outside the heap, and b) protection against execution of heap data. In the future, they're also planning to support multiple linear memory segments, which would allow you to isolate memory used for potentially-buggy dynamically-allocated buffer code from memory used by less-fragile or more-sensitive code. WebAssembly.org's descriptions indicate that linear memories would be used both for C/C++ heap allocations and for any local/global variables accessed with operators (like the & reference operator) that make it hard to make these distinctions statically. More information on the security properties of the system: http://webassembly.org/docs/security/ http://webassembly.org/docs/security/ General information on linear memory semantics: http://webassembly.org/docs/semantics/#linear-memory http://webassembly.org/docs/semantics/#linear-memory
- deleted 10y ago
  [deleted]
- nenreme 10y ago
  No, it's like a virtual proccess but with simpler memory layout. If you try to read or write memory outside of the allowed range it will trap (which is like segmentation fault on Linux) but it doesn't check any individual array for out of bound access because it doesn't actually know where are arrays in the memory.
rocky1138 10y ago
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.
- wybiral 10y ago
  Agreed. But I've felt that way about minified JS for a long time too. I'm not sure there's a way around it.
- db48x 10y ago
  This is the same situation we're already in with minification. The debugger can reformat or decompile it, and if you have source maps you'll see the original source, even if the original source wasn't even javascript.
- tps5 10y ago
  The specifics of how this will work are not totally clear to me, but web assembly will have a text format that will be human readable and editable according to: [0] http://webassembly.org/ http://webassembly.org/ [1] http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web http://webassembly.org/docs/faq/#will-webassembly-support-vi...
- spyder 10y ago
  It will have a text format (or more than one), but yea probably it will be less readable: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
- jasonszhao 10y ago
  I agree with the others under this comment that websites already hide their source through obfuscation. What I am slightly more concerned is how this will go with the law. I think it is much harder to get into trouble when messing with obfuscated JS than when decompiling binary code. Yes, you can get into trouble when you decompile code: http://security.stackexchange.com/a/30375/93013 http://security.stackexchange.com/a/30375/93013
calahad 10y ago
What makes a compiled executable faster than interpreted code seems kind of self evident.
- callahad 10y ago
  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. :)
- Qwertious 10y ago
  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.
  - raarts 10y ago
    True fact but not really useful if this only applies to 0.01% of the cases.
aphextron 10y ago
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.
- themihai 10y ago
  That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e for video decoding)
  - vonklaus 10y ago
    They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.
    - gjjrfcbugxbhf 10y ago
      Actually many of us use es6 with a compiler to turn into some dialect of js that runs in browsers. We will hardly notice if our code starts getting compiled to wasm instead..
      - v413 10y ago
        JS will not compile to WASM.
        yumaikas 10y ago
        Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.
austinjp 10y ago
"the team working on React could replace their reconciler code (aka the virtual DOM) with a WebAssembly version." Is anyone working on such a thing?
hoschicz 10y ago
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.
tannhaeuser 10y ago
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 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 :)

338 points by nfriedly 10y ago

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".

greenhouse_gas 10y ago
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.
- astrodust 10y ago
  I seriously can't wait for a Flash in JavaScript so that all those old Flash games don't get shuttled off to the dustbin of history, never to be enjoyed again. I do not want to ever have to update Flash again. Ever.
  - greenhouse_gas 10y ago
    That's a dead Mozilla project called Shumway
batmansmk 10y ago
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.
- astrodust 10y ago
  Yes and no. In practice JavaScript was sometimes the thing that detected if Java was present and kicked off a Java applet. It also handled roll-overs before CSS was a thing, doing mundane stuff by comparison to what a full Java app could do. It was intended to be complementary.
- zeveb 10y ago
  Well, it's possible that if it hadn't been for Java JavaScript might have had a decent, parens-based syntax. I still wonder what might have been if Eich had been allowed to write the Scheme system he had been hired to do. While I'm not a fan of Scheme by any means, it is approximately 281,757,423,024,353 better than JavaScript. And Scheme's a great little language for implementing other languages. Imagine, we could have had transpiling years ahead of time. We might be using S-expressions instead of JSON. Heck, we might even have moved to an S-expression syntax for HTML & CSS by now. Imagine, one syntax for everything (thanks to https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_inner_html https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_... & https://www.w3schools.com/css/css_howto.asp https://www.w3schools.com/css/css_howto.asp for the examples): (html (head (title "Example") (style (body (background-color linen)) (h1 (color maroon) (margin-left (px 40))))) (body (h1 "What can JavaScript do?") (p (@ (id "demo")) "JavaScript can " (em "change") " HTML content.") (button (@ (type "button") (onclick (set! (inner-html (get-element-by-id document "demo")) "Hello JavaScript!"))) "Click me!"))) The world could have been so much better.
  - nessus42 10y ago
    I'm a HUGE fan of Scheme. And of Lisp, in general. But having seen in the "real world" how so many people are so adverse to Lisp's beautiful syntax, I'm pretty confident that JavaScript would never have caught on if it looked like Lisp rather than like C.
    - zeveb 10y ago
dragonwriter 10y ago
> 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.
- sandyarmstrong 10y ago
  "That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language." http://www.infoworld.com/article/2653798/application-development/javascript-creator-ponders-past--future.html http://www.infoworld.com/article/2653798/application-develop...
amorphid 10y ago
Until JavaScript offers a robust concurrency abstraction, I don't see it completely replacing anything that is used for that purpose.
- voxic11 10y ago
  Async/await and promises are quite good concurrency abstractions.
- brlewis 10y ago
  Based on the comment you're replying to I infer that you think Java offers a robust concurrency abstraction. I disagree. In moving to the single-threaded async style of JS concurrency, the hardest part for me has been to rid myself of the ugly habit I acquired from Java's threading model, i.e. asking myself at each line of code, what happens if my thread gets preempted here?
dominotw 10y ago
>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.
- lanna 10y ago
  > Its unlikely that javascript will replace it just because jvm is rewritten in java script. that is not what oc meant. he is talking about runtime env, not source language
andrewbinstock 10y ago
>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.")
nessus42 10y ago
> 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.

msoad 10y ago

I can totally see Qt a and .NET apps running on top WebAssembly. Imagine MS Word is running in your browser without them having to rewrite it in JS!

dmarcos 10y ago
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.
- mstade 10y ago
  Is this universally true – i.e. baked in to the wasm spec – or is it just true in a browser environment? Consider things like NW.js[1] or Electron[2] – might we see cross platform apps being developed where all or parts of it are written in <insert language here> and compiled to wasm, then packaged up with a runtime and delivered as a "native" application for desktop, mobile, or whatever? [1]: https://nwjs.io https://nwjs.io [2]: https://electron.atom.io https://electron.atom.io
  - johncolanduoni 10y ago
    No, the wasm spec doesnt mention web standards at all. It can be implemented without a JavaScript VM nearby, and at the moment isn't even capable of interacting with the DOM/JavaScript APIs directly when it is run in web browsers.
  - noam87 10y ago
    What would be the benefit of that? Might as well just compile to native and distribute that without all the overhead, no?
    - mstade 10y ago
      I probably should have specified but I was referring to GUI applications specifically. For things without a GUI, or that require deeper system integration than you get with these runtimes you're absolutely right – there's little point. But for a very large class of GUI applications it makes a lot of sense, working with technologies that not only have stood the test of time and are good enough for plenty of use cases, but also mean you can with very little effort package your application for multiple operating systems. Some of these applications will need stronger performance than can be provided by the JS engine, so hence the question re: wasm. Does that make more sense?

TazeTSchnitzel 10y ago

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.

chrisseaton 10y ago
> 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?
- coldtea 10y ago
  >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. Because its marginal returns?
- acqq 10y ago
  > 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? WebAssembly is treated just like other "real binaries" produced for the "real" OS. Whatever survived the static optimizations while producing the binaries is converted, at the end, to the pure machine code, you don't "trace" it in run-time by the user. > even very static languages like C benefit from speculative optimisations which may need to be reversed. I'm not aware of "speculative optimisations which may need to be reversed" in C, and I'd be very interested to read what you mean when you write that, possibly with some links and references. Do you mean run-time, by the user, or something else?

lacampbell 10y ago

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.

Taek 10y ago
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.
6nf 10y ago
It looks very promising, most major players have experimental support for web assembly already.
axefrog 10y ago
The W3C spec is now finalised and locked in, and Chrome and Firefox will release Web Assembly completely in their next releases, respectively.
hakanito 10y ago
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?

etimberg 10y ago

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?

pmontra 10y ago

> 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]. [1] http://webassembly.org/docs/text-format/ http://webassembly.org/docs/text-format/ [2] http://webassembly.org/docs/tooling/ http://webassembly.org/docs/tooling/

callahad 10y ago
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.
- matthewmacleod 10y ago
  Swift is garbage-collected – it might not have a tracing GC, but ARC is essentially compile-time GC – certainly, from the perspective of a developer, ARC is extrordinarily similar to a tracing GC (with some small caveats).
  - int_19h 10y ago
    Reference-counted GC is trivially implemented on top of WebAssembly memory model.
  - chatterbeak 10y ago
    Well, if you're going to say that, then C++ with smart-pointers is Garbage Collected, and nobody says that!
  - 10y ago

Svenskunganka 10y ago

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

AgentME 10y ago
You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if many do it soon for anything more than a small high-performance core or for a large application that has a small DOM surface area (a game that just renders to a canvas).
- Svenskunganka 10y ago
  Yes of course, but only during the early stages. The post-MVP roadmap for WebAssembly specifies DOM & Web API integration (http://webassembly.org/docs/gc/ http://webassembly.org/docs/gc/), so that specific case will too disappear with time. If you read point 3 on this page (http://webassembly.org/docs/high-level-goals/ http://webassembly.org/docs/high-level-goals/) you should realize that the need for JavaScript won't be required at that point. edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.

daurnimator 10y ago

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?

callahad 10y ago
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.
- daurnimator 10y ago
  > For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal My point was who wants these to be in the browser? I mean they're cool as demos, but I don't see the use. Is it just people using web browsers as the content delivery platform instead of e.g. Steam?
  - pdkl95 10y ago
    > who wants these to be in the browser Anybody that resents the user having ultimate control over the User Agent. A game in e.g. the Unity engine isn't important. Instead, there are a lot of people that would love to replace their (easily adblockable) web page with a small opaque binary that contains freetype, custom layout/UI library, and maybe "drm"-like obfuscation. You don't need the DOM if you intent to render everything yourself. At best, we will see a new wave of "flash intro"[1] style "custom user experience" replacing perfectly usable HTML pages. At worst, this could be the catalyst that replaces what remains of the open web with a locked down "cable tv"-like mess. [1] http://www.zombo.com/ http://www.zombo.com/

johncolanduoni 10y ago

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. [1]: https://github.com/WebAssembly/binaryen/releases/tag/version_28 https://github.com/WebAssembly/binaryen/releases/tag/version...

callahad 10y ago
Yes. Here's the announcement: https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html https://lists.w3.org/Archives/Public/public-webassembly/2017...

ClassyJacket 10y ago

>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.

dalailambda 10y ago
Since languages like Rust/C++/Swift compile reference counting into machine code already, there's no real reason why they shouldn't be able to compile it to WebAssembly.
q3r3qr3q 10y ago
> And are there disadvantages to reference counting that make it a bad idea? I thought it had a performance cost.
- ktRolster 10y ago
  Not much of one. The amount of time it takes to allocate the memory and free it is the dominant factor.
  - comex 10y ago
    Maybe in the non-atomic case. Atomic refcounts force synchronization between CPUs when different threads access the same data, even if they only read it; that can have a quite significant cost.
    - repsilat 10y ago
      They also tend to prohibit some smart gc optimisations like moving your shit while you're not looking, and the cache behaviour can be bad because either, - the data isn't stored next to the count so you get two pointer indirection per access, or - the data is stored next to the count, and the object gets cached-in when it gets collected. Piggybacking on the thread because I haven't had much concrete experience with smart pointers: how does the "circular chain" problem seem to manifest? Is it - "goes wrong quickly," usually picked up and fixed without too much trouble, - "like any old memory leak" -- maybe a problem if processes run a long time, hard to track down, or - devs are usually smart enough to see them coming, knowing to keep the "has a pointer to" relation a partial order (either by type or some other natural hierarchy.) ?

kristianp 10y ago

When compiled from C/C++, does WASM do bounds checking of pointers and arrays? What kind of memory safety does it offer?

azernik 10y ago
WASM offers a virtual machine to the user, in which there are global variable slots, a stack for local variables, and one or more "linear memories" (chunks of RAM for heap allocations). The first two are completely bounds-checked - you tell the virtual machine to operate on a certain offset in a global/local variable ID, and you are safe from your access affecting anything outside of that variable. The linear memories, on the other hand, are up to you - you can execute operations on address within a linear memory, and it's up to you if you messed up and overwrote or read out data that you shouldn't have. What you do get is a) protection against heap overflows affecting values outside the heap, and b) protection against execution of heap data. In the future, they're also planning to support multiple linear memory segments, which would allow you to isolate memory used for potentially-buggy dynamically-allocated buffer code from memory used by less-fragile or more-sensitive code. WebAssembly.org's descriptions indicate that linear memories would be used both for C/C++ heap allocations and for any local/global variables accessed with operators (like the & reference operator) that make it hard to make these distinctions statically. More information on the security properties of the system: http://webassembly.org/docs/security/ http://webassembly.org/docs/security/ General information on linear memory semantics: http://webassembly.org/docs/semantics/#linear-memory http://webassembly.org/docs/semantics/#linear-memory
deleted 10y ago
[deleted]
nenreme 10y ago
No, it's like a virtual proccess but with simpler memory layout. If you try to read or write memory outside of the allowed range it will trap (which is like segmentation fault on Linux) but it doesn't check any individual array for out of bound access because it doesn't actually know where are arrays in the memory.

rocky1138 10y ago

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.

wybiral 10y ago
Agreed. But I've felt that way about minified JS for a long time too. I'm not sure there's a way around it.
db48x 10y ago
This is the same situation we're already in with minification. The debugger can reformat or decompile it, and if you have source maps you'll see the original source, even if the original source wasn't even javascript.
tps5 10y ago
The specifics of how this will work are not totally clear to me, but web assembly will have a text format that will be human readable and editable according to: [0] http://webassembly.org/ http://webassembly.org/ [1] http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web http://webassembly.org/docs/faq/#will-webassembly-support-vi...
spyder 10y ago
It will have a text format (or more than one), but yea probably it will be less readable: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
jasonszhao 10y ago
I agree with the others under this comment that websites already hide their source through obfuscation. What I am slightly more concerned is how this will go with the law. I think it is much harder to get into trouble when messing with obfuscated JS than when decompiling binary code. Yes, you can get into trouble when you decompile code: http://security.stackexchange.com/a/30375/93013 http://security.stackexchange.com/a/30375/93013

calahad 10y ago

What makes a compiled executable faster than interpreted code seems kind of self evident.

callahad 10y ago
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. :)
Qwertious 10y ago
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.
- raarts 10y ago
  True fact but not really useful if this only applies to 0.01% of the cases.

aphextron 10y ago

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.

themihai 10y ago
That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e for video decoding)
- vonklaus 10y ago
  They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.
  - gjjrfcbugxbhf 10y ago
    Actually many of us use es6 with a compiler to turn into some dialect of js that runs in browsers. We will hardly notice if our code starts getting compiled to wasm instead..
    - v413 10y ago
      JS will not compile to WASM.
      - yumaikas 10y ago
        Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.

austinjp 10y ago

"the team working on React could replace their reconciler code (aka the virtual DOM) with a WebAssembly version." Is anyone working on such a thing?

hoschicz 10y ago

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.

tannhaeuser 10y ago

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 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 :)