What makes WebAssembly fast?

https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/

by nfriedly • 9 years ago

338 230 9 years ago

hacks.mozilla.org

astrodust3• 9 years 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_gas2• 9 years 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.

astrodust3• 9 years 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.

batmansmk• 9 years 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.

astrodust3• 9 years 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.

zeveb3• 9 years 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_... & 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.

dragonwriter• 9 years 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• 9 years 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-develop...

amorphid• 9 years ago

Until JavaScript offers a robust concurrency abstraction, I don't see it completely replacing anything that is used for that purpose.

voxic11• 9 years ago

Async/await and promises are quite good concurrency abstractions.

brlewis3• 9 years 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• 9 years 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• 9 years 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• 9 years 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.")

nessus424• 9 years 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• 9 years 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• 9 years 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.

mstade2• 9 years 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

[2] https://electron.atom.io

flukus• 9 years ago

Not a problem, we can just wait for the inevitable security vulnerabilities.

coldtea4• 9 years ago

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

Can't wait!

robotresearcher3• 9 years ago

Nothing improved for me as a consumer

Nothing to install, no updates, no license key, not tied to a machine.... ?

TazeTSchnitzel3• 9 years 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• 9 years 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?

coldtea4• 9 years 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?

acqq5• 9 years 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?

acqq5• 9 years ago

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:

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

johncolanduoni3• 9 years ago

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.

TazeTSchnitzel3• 9 years ago

A big part of the advantage is more consistent adoption by browsers. […] Firefox/SpiderMonkey and Edge/Chakra have AOT compilation for asm.js, but notably Chrome/V8 doesn't

Not quite. SpiderMonkey has AOT compilation, whereas Chakra and V8 throw it at the JIT, though Chakra's compiler is specially optimised for asm.js AIUI.

Thing is, specific support for asm.js is unnecessary, a sufficiently good JIT is good enough. V8 hasn't implemented asm.js AOT because it doesn't need to. I assume the same would be true of WebAssembly.

Asm.js also still hasn't become a formal spec

Though it is a spec.

lacampbell2• 9 years 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• 9 years 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• 9 years ago

It looks very promising, most major players have experimental support for web assembly already.

axefrog• 9 years 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• 9 years 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• 9 years 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• 9 years 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/

[2] http://webassembly.org/docs/tooling/

callahad4• 9 years 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• 9 years 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).

verletx64• 9 years ago

Isn't WASM a compile target?

hellofunk2• 9 years ago

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.

ktRolster3• 9 years ago

If your algorithm is such that everything can be placed on the stack then GC gets you nothing.

kebolio• 9 years ago

At least in Rust's case, RAII/lifetimes provide mostly the same development experience without GC overhead.

deburo• 9 years ago

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.

Salgat• 9 years ago

It's not a benefit, it's simply a temporary compromise to get it out faster.

hacknat• 9 years ago

It doesn't prevent a language from adding its own GC.

Svenskunganka2• 9 years 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• 9 years 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).

Svenskunganka2• 9 years 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/), so that specific case will too disappear with time.

If you read point 3 on this page (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.

the_duke• 9 years ago

Direct DOM access including manipulation is planned for WebAssembly.

They wanted to progress on the spec and push it out without that, but it's on the roadmap. (Along with GC integration).

bluejekyll10• 9 years ago

Can someone explain what the option is for accessing the dom initially? Is there some wrapper JS that will be needed to call into the wasm?

ncantelmo2• 9 years ago

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.

shadowmint2• 9 years ago

something else that offers native bindings to other languages will eventually...

No it won't.

This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.

Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop?

Microsoft? Come on. Apple? Google? Google tried with dart and failed.

Who else, seriously, is going to step up?

We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work.

Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices.

You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse.

Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/

ZenPsycho4• 9 years ago

no, WASM will not replace JS unless somehow, overnight, the idea of downloading 30mb of compiled runtime libraries to read an inaccessible-to-screenreaders news article becomes appealing.

but i wouldn't hold my breath for 1990's style java applet loading throbbers to come back into fashion. there's a reason that stuff got outcompeted by the supposedly "inferior" javascript.

what wasm competes with is flash games, insecure java applets, and npapi and nativeclient in general.

bostik• 9 years ago

If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually

When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib.

One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib?

skybrian3• 9 years ago

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.

ktRolster3• 9 years ago

Garbage collection is coming to WebAssembly.

nanolith2• 9 years ago

To be fair, a generational mark-sweep GC algorithm doesn't take much more space over the compile-time modifications to the code itself. A reasonably performant GC algorithm suitable for most front-end work would probably only add about 10 kilobytes to 20 kilobytes of code to an executable. That can be downloaded and cached in the blink of an eye.

greggman• 9 years ago

Isn't debugging just a short interation away from being like native debugging? You get a source map, you see C++ in the devtools with C++ variables and a C++ call stack and an option to "view webassembly"

I have to assume the browser teams are working on this

K0SM0S• 9 years ago

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.

daurnimator2• 9 years 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?

callahad4• 9 years 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.

daurnimator2• 9 years 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?

jlebrech2• 9 years ago

forget the DOM it's a steaming pile. In future we'll be thinking either rasters,vectors or something higher level like ratios and components.

johncolanduoni3• 9 years 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...

callahad4• 9 years ago

Yes. Here's the announcement: https://lists.w3.org/Archives/Public/public-webassembly/2017...

ClassyJacket• 9 years 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• 9 years 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• 9 years ago

And are there disadvantages to reference counting that make it a bad idea?

I thought it had a performance cost.

ktRolster3• 9 years ago

Not much of one. The amount of time it takes to allocate the memory and free it is the dominant factor.

mintplant• 9 years ago

GC integration is on the roadmap for WebAssembly, as I understand it. At the moment languages can bring their own GC implementations written in WebAssembly, but eventually they should be able to hook into and take advantage of the browser's native GC facilities. I believe this is considered a blocker for exposing a standard DOM API directly to WebAssembly code.

kristianp• 9 years ago

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

azernik• 9 years 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/

General information on linear memory semantics: http://webassembly.org/docs/semantics/#linear-memory

nenreme• 9 years 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• 9 years 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.

wybiral3• 9 years 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• 9 years 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• 9 years 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/

[1] http://webassembly.org/docs/faq/#will-webassembly-support-vi...

spyder• 9 years 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...

jasonszhao• 9 years 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

calahad• 9 years ago

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

callahad4• 9 years 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• 9 years 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• 9 years ago

True fact but not really useful if this only applies to 0.01% of the cases.

aphextron3• 9 years 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.

themihai5• 9 years 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• 9 years 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.

charlieflowers3• 9 years ago

True. I agree with it all.

However, by then, TypeScript might be so darn good that people choose to keep going with it!

It really does have a better type system than C# in a lot of ways.

tonyedgecombe2• 9 years ago

It could be another target for TypeScript though.

throwaway010317• 9 years ago

Could you please elaborate on how TypeScript's type system is better than C#?

KurtMueller• 9 years ago

F# has an even better type system :)

scriptproof2• 9 years ago

You can write wasm. It is the official shortcut (not an acronym). Source: http://webassembly.org/

unwind• 9 years ago

*Abbreviation (https://github.com/WebAssembly/design/issues/980).

amelius• 9 years ago

Is it possible to run an efficient garbage-collected runtime system on top of WASM? And how about a multithreaded one?

jlebrech2• 9 years ago

Leading to real IDEs, real languages, real libraries.

downsides will be some proprietary solutions will crop up.

vikas0380• 9 years ago

There is no harm in that

zurn• 9 years ago

JS provided that already without WebAssembly, no?

mkawia• 9 years ago

I don't understand why the downvotes , JS is one of the most target languages. Elm,GHJS(Haskell),Purescript,Clojurescript and supersets like Typescript which come with their own toolchains.

bluejekyll10• 9 years ago

Asm.js was exactly what your talking about.

You can think of webassembly more like a common standard akin to the JVM specification. Anyone can implement the spec.

It's a formal definition of what people are doing with JS.

austinjp• 9 years 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• 9 years 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• 9 years 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).

Right now, the discussion evolves around finding fecalia-/coprophilia-inspired names for the WebAss ecosystem. Can't wait until America Awakens to contribute :)

What makes WebAssembly fast?

Related Stories