Live data from Hacker News

What makes WebAssembly fast?

hacks.mozilla.org

11–20 of 238 posts

Re: What makes WebAssembly fast?

#11

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 meanin…

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.

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.

Re: What makes WebAssembly fast?

#12

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 meanin…

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

Re: What makes WebAssembly fast?

#13

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 meanin…

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.

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.

Re: What makes WebAssembly fast?

#14
post #3

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!

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!

Re: What makes WebAssembly fast?

#15

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…

> 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 prac…

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

Re: What makes WebAssembly fast?

#16

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…

> 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 prac…

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

Re: What makes WebAssembly fast?

#17

Earlier quoted context omitted.

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.

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.

That's a dead Mozilla project called Shumway

Re: What makes WebAssembly fast?

#18

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 meanin…

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

Re: What makes WebAssembly fast?

#19

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…

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

Re: What makes WebAssembly fast?

#20
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.
Post reply on HN