
WebAssembly support now shipping in all major browsers - subir
https://blog.mozilla.org/blog/2017/11/13/webassembly-in-browsers/
======
KeitIG
A good occasion to watch Gary Bernhardt's talk "The Birth & Death of
JavaScript" [0] again, where he talks about the precursor of WebAssembly:
asm.js and the future implication it "could" have in the future in a really
humorous way. A few years old but still relevant.

You want Gimp for Windows running in Firefox for Linux running in Chrome for
Mac? Yeah sure.

[0] [https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
greenhouse_gas
There's another reason why I want JavaScript in the browser to die:

We haven't had a new browser engine written from scratch since KHTML. Firefox
is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit
which is itself a descendant of KHTML, Edge is closed source, but I'm almost
sure there's some old IE code in there.

Why?

It's simply too expensive to create a fast (and compatible) JS engine.

If WebAssembly takes off, I hope that one we'll have more than three browser
engines around.

~~~
austincheney
WebAssembly has nothing to do with JavaScript. When people make this
association it is clear they are painfully unaware of what each (or both)
technologies are.

WebAssembly is a replacement for Flash, Silverlight, and Java Applets.

~~~
45h34jh53k4j
and js. eventually!

~~~
austincheney
JS is a language and not a bytecode media. Perhaps chocolate will replace cars
and airplanes. I love me some chocolate.

~~~
sli
I am extremely unclear on whatever point you're trying to make, here, because
it really does seem to come from a place of ignorance on WASM and JS. It makes
no sense.

It seems like you're claiming, in a really roundabout way, that WASM will
never have DOM access, even though it's planned[1]. There are even VDOMs[2]
for WASM already. Future WASM implementations that include DOM access _can
absolutely, and for many folks will, replace Javascript._

[1]:
[https://github.com/WebAssembly/design/blob/master/FAQ.md](https://github.com/WebAssembly/design/blob/master/FAQ.md)

[2]: [https://github.com/mbasso/asm-dom](https://github.com/mbasso/asm-dom)

~~~
austincheney
> It seems like you're claiming, in a really roundabout way, that WASM will
> never have DOM access

I am not going to say _never_. It does not now and will not for the
foreseeable future though. I know DOM interop is a popular request, but nobody
has started working on it and it isn't a priority.

Part of the problem in implementing DOM access to a unrestricted bytecode
format is security. Nobody wants to relax security so that people who are
JavaScript challenged can feel less insecure.

~~~
tptacek
Which of the security concerns browser Javascript deals with do you think are
intrinsic to the language, as opposed to the bindings the browser provides the
language? If the security issues are in the bindings (ie: when and how I'll
allow you to originate a request with credentials in it), those concerns are
"portable" between languages.

~~~
austincheney
It isn't due to the language but to context of known APIs provided to the
language that can only be executed a certain way by the language.

How would a browser know to restrict a web server compiled into bytecode
specifically to violate same origin? The browser only knowns to restrict this
from JavaScript because such capabilities are allowed only from APIs the
browser provides to JavaScript.

~~~
tptacek
I really don't understand your example. Are you proposing a web server running
_inside the browser_ as a WebAssembly program, and the browser attempting to
enforce same origin policy against that server? That doesn't make much sense.

~~~
austincheney
Yep, it doesn't make sense and that is the problem. There is no reason why you
couldn't write a web server in WASM that runs in an island inside the browser
to bypass the browser's security model.

~~~
tptacek
This does not make any sense, sorry.

------
chkuendig
Unfortunately SIMD is still not supported on any browsers and with the move
away from SIMD.js it looks like this might take a while.

We've been working on porting over our fairly large barcode scanner library to
WebAssembly. While the performance is close to what we have on other platforms
( [http://websdk.scandit.com](http://websdk.scandit.com) ), the major
bottleneck for now is not being able to use optimized code relying on SIMD
(and not having an existing C fallback as all other platforms we target have
SIMD support)

~~~
josteink
> Unfortunately SIMD is still not supported on any browsers

Is SIMD portable though? Will it run good on mobile devices? And what about
other non-Intel architectures in general?

~~~
mastax
Yes. Phones have SIMD. Hell, the cheapo MIPS in my router has SIMD. You use
the portable simd instructions and they get compiled to native simd
instructions for your platform. Just like any other part of webassembly.

------
holydude
Can't wait for DOM interop and get away from JS on frontend. Seriously JS
should not be the lingua franca of the web :)

~~~
phkahler
>> Seriously JS should not be the lingua franca of the web

But neither should this. Really, keep your code off my computer as much as
possible.

~~~
nmg
I think it's darkly humorous that I have to install browser plugins to stop
sites from mining monero in my browser. It's like websites are those creepy
spider things in the Matrix, except instead of sticking humans in pods to
harvest their biochemical energy, they're just running up our home electricity
bills by maxing our CPUs.

~~~
meshy
What plugins do you recommend for this?

~~~
etatoby
uBlock Origin with the default choice of lists plus "Fanboy's Annoyance" makes
the web 100s of times faster.

It's now a default install on every browser of every computer I touch. Even on
Firefox on Android, which works really well btw.

------
blaze33
If you're looking for an introduction to WebAssembly my "WebAssembly 101: a
developer's first steps" post had some success here:
[https://blog.openbloc.fr/webassembly-first-
steps/](https://blog.openbloc.fr/webassembly-first-steps/)

HN discussion:
[https://news.ycombinator.com/item?id=14495893](https://news.ycombinator.com/item?id=14495893)

The awesome-wasm list is also a good start:
[https://github.com/mbasso/awesome-wasm](https://github.com/mbasso/awesome-
wasm)

------
indy
For people wondering about features like SIMD and GC support, here is a good
status page: [http://webassembly.org/docs/future-
features/](http://webassembly.org/docs/future-features/)

~~~
tom_mellior
Specifically for GC, all that page does is to refer to a GitHub issue that is
invisible to anyone but WASM contributors :-(

~~~
Ajedi32
Invisible? You mean locked?
[https://github.com/WebAssembly/design/issues/1079](https://github.com/WebAssembly/design/issues/1079)

I'm not a collaborator on the WebAssembly Org, but I can still see that issue
just fine.

~~~
tom_mellior
Yes, I see that there is an issue there, but the discussion is invisible.
Hidden. Locked.

~~~
Ajedi32
> invisible. Hidden

It's not. It's just that there are no other posts on that issue. GitHub does
not have a way to make an issue visible to the public but hide all discussion
on it.

> Locked

That's not the same thing. Locked just means you can't add your own comments,
not that you can't see comments from other users.

~~~
tom_mellior
Ah ok, thanks. That there is no discussion is even more disappointing.

------
dmix
The math site they linked to in the examples of sites powered by WebAssembly
is awesome: [http://mathstud.io/](http://mathstud.io/)

I almost wish I was a student again so I could relearn math for the first time
with all of these great tools...

~~~
ZeroCool2u
Wow, that is really cool actually. Impressive performance on my OG Pixel XL
too.

------
isaiahg
I'm not as excited for this as I used to be. In most user applications
JavaScript is good enough or better. If it wasn't then we wouldn't be taking
the browser to make desktop applications. Recently I decided to make a desktop
app and asked around about the different UI libraries. The answer I keep
getting is "just use electron and JavaScript". Why? Because love it or hate it
the Dom is fantastic and simple for making UIs that are interactive and
reliable. And you can't beat JavaScript for manipulating the Dom.

The only benefit I can think of that benefits is specialized software like
games or scientific analysis/simulation. But for what most users want,
JavaScript is fast enough. The example I keep hearing is "imagine gimp in the
browser" but it's already possible to make a gimp like application in the
browser using things like canvas and the file api.

So by the time webassembly is ready for the prime and has needed features like
memory management and Dom access, will it even by worth it beyond a few
specific applications?

~~~
zanny
> will it even by worth it beyond a few specific applications?

I'm sure if you sampled all developers the number that would say Javascript is
their favorite programming language would be in a substantial minority. So if
it makes it easier for developers to write client side code in their preferred
language its worth it.

That being said, I'm worried a bit. Javascript being awful has traditionally
kept developers doing as much runtime work as possible server side. In the
last 5 years the rapid growth of JS libraries, client side frameworks, and
recently ES6 have all reduced the pain points and correlated to a dramatic
rise in client side code being loaded on users computers with corresponding
huge page size bloat.

~~~
colordrops
> I'm sure if you sampled all developers the number that would say Javascript
> is their favorite programming language would be in a substantial minority.

I wouldn't be so sure of that.

~~~
dvddgld
Agreed, it'd likely be one of the largest shares

------
fergie
Can anybody ELI5? The documentation is pretty fluffy.

Does WebAssembly actually open up any new API hooks? I get that its a clever
way of transpiling existing programs to JavasScript, but surely we could do
that already?

Whats new avenues of development is WebAssembly expected to open up? Is the
whole point just to enable an easy way to compile games made on other
platforms (Unity) to the web?

~~~
exDM69
WASM is used to run native code in the Web browser without going through
JavaScript. With it, it should be possible to run code at near-native
performance in the browser.

WASM is an intermediate representation which is output by your compiler (of
your favorite language) and consumed by the browser's compiler to emit native
code.

WASM is a bit similar to LLVM IR, but it's architecture independent.

Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will
read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR
and emit assembly code for your CPU. With WASM, the developer will run the
"front end" and distribute the WASM code over HTTP and the web browser will
run the backend and turn WASM into native assembly code.

> I get that its a clever way of transpiling existing programs to JavasScript,
> but surely we could do that already?

No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM
that was a compiler-friendly variant of JavaScript that can be compiled to
native code.

~~~
qaq
But is this how it is implemented by actual browsers? if memory serves v8 is
pretty much reusing most of JS VM for WASM?

~~~
exDM69
Yes, the browsers do share parts of their JavaScript execution engine with
WASM. Which makes sense because WASM still needs to interact with JS. That
doesn't mean it can't be fast or start quickly (or at least quicker than
asm.js).

From the developer's point of view that doesn't matter. You're delivering WASM
and not C or JS code over to the clients.

------
rhabarba
WebAssembly is not worth the effort unless it finally is supported by the LINK
tag. Seriously, using JS to load a JS alternative is ridiculous.

~~~
themihai
I can't agree more...but I believe the issue is that WASM sold a lie. Right
now if you read between the lines it is argued that WASM is there just to help
JS do more not to replace it.

~~~
moosingin3space
> WASM sold a lie

What? The original WebAssembly announcement[1], which can be viewed as the
manifesto for how WASM was envisioned, it clearly says "once browsers support
the WebAssembly syntax natively, JS and wasm can diverge". Eich's goal with
WebAssembly is _not_ replacing JS, it's providing a better compilation target
for other languages. WebAssembly is a replacement for asm.js, not JavaScript.
No one is selling a lie here.

[1]: [https://brendaneich.com/2015/06/from-asm-js-to-
webassembly/](https://brendaneich.com/2015/06/from-asm-js-to-webassembly/)

------
vanderZwan
Aside: how is WebAssembly's binary form currently shipped? In a demo I saw
yesterday it was written out inline as a Uint8Array of integers between 0-255.
Even with gzip enabled this can't be very efficient.

For completely unrelated reasons, I was already thinking of adapting (my fork
of) the LZ-string library[0] to directly compress/decompress typed arrays to
"websafe" UTF16 strings, similar to the already existing `compressToUTF16`
functionality in LZ-string. Essentially, the strings would represent LZ-
compressed bitstreams, using 15 bits per string character.

Could this be useful for reducing the size of WASM binary when encoded in
plain JavaScript? (the minified library would probably be around 1kb after
gzip)

[0] [https://github.com/JobLeonard/lz-string/tree/array-
lookup](https://github.com/JobLeonard/lz-string/tree/array-lookup)

[1] [http://pieroxy.net/blog/pages/lz-
string/index.html#inline_me...](http://pieroxy.net/blog/pages/lz-
string/index.html#inline_menu_6)

~~~
esrauch
wasm files are already a binary format, an explicit Uint8Array should only
only necessary if you want to inline the wasm directly with the JS that
instantiates it.

~~~
vanderZwan
Right, I thought it was odd; I remember reading that part of the big benefit
of WASM was more compact, faster-to-parse source code. Going all the way up to
text form and back down to binary data is at odds with that.

> _an explicit Uint8Array should only only necessary if you want to inline the
> wasm directly with the JS that instantiates it._

Are there any realistic scenarios where this is the more sensible option?

Anyway, I should have searched MDN first, the relevant bit of documentation is
pretty clear:

    
    
        fetch('simple.wasm').then(response =>
          response.arrayBuffer()
        ).then(bytes =>
          WebAssembly.instantiate(bytes, importObject)
        ).then(results => {
          results.instance.exports.exported_func();
        });
    

[https://developer.mozilla.org/en-
US/docs/WebAssembly/Loading...](https://developer.mozilla.org/en-
US/docs/WebAssembly/Loading_and_running#Using_Fetch)

~~~
esrauch
I suppose you could avoid having the extra request roundtrip by inlining a
uint8array (or a base64 encoded string or something), and it also lets you
have wasm and it's associated JS be put together which would automatically
avoid cache/version mismatch without any extra work, but I would be surprised
if that makes sense in any normal scenario.

------
dalbasal
For those in the know, what doors is web assembly expected to open? Better
cross platform platforms via a browser wrap? Will new types of browser
applications be possible that aren't now in JS only world? What are they?

~~~
pjmlp
Expect every language out there to have a WebAssembly implementation,
including Flash.

~~~
tonyg
Until wasm supports proper tail calls, only the ones with uninteresting
control structures.

~~~
simias
Couldn't the compiler take care of optimizing those when necessary? After all
I don't know of any "real" assembly with tail call support...

~~~
panic
Most assembly languages have a "jump" instruction, though -- wasm supports
only structured control flow.

~~~
pjmlp
It has _br_ and _loop_ , good enough.

~~~
int_19h
I don't think it's sufficient for full-fledged generalized tail call
elimination. You can certainly optimize a self-recursive call down to a loop,
but consider a case where a function accepts another function as a pointer,
and invokes that pointer in a tail call position, for example (i.e. anything
written in continuation-passing style).

------
p49k
Do any mobile browsers support it yet? The article is unclear.

~~~
clouddrover
Safari does on iOS 11:

[https://webkit.org/blog/7956/new-webkit-features-in-
safari-1...](https://webkit.org/blog/7956/new-webkit-features-in-safari-11/)

[https://developer.apple.com/library/content/releasenotes/Gen...](https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Safari_11_0/Safari_11_0.html)

~~~
Klathmon
But does a WebView?

I recently discovered that while Safari supports WebRTC, a "WebView" or a
safari view that is added to the home screen does not.

~~~
om2
WKWebView and SFSafariViewController both support Web Assembly in iOS 11.

------
themihai
Without DOM it's not really that exciting.

~~~
steveklabnik
There is a lot of processing that doesn't inherently need the DOM, and there's
also server-side stuff as well. I think you'd be surprised!

~~~
themihai
Yeah, but WASM was supposed to democratise the web development not to do just
server-side stuff. Without DOM and Web APIs you can't do much Web related.

~~~
CyberDildonics
> not to do just server-side stuff

He didn't say anything about 'only server side stuff'. There is plenty that
has already been demonstrated with webasm - video editing and filtering, audio
editing and filtering, advanced computer graphics, direct porting of games,
etc.

~~~
themihai
>> There is plenty that has already been demonstrated with webasm - video
editing and filtering, audio editing and filtering, advanced computer
graphics, direct porting of games, etc.

Even for that it doesn't work without some js. The promise was that you can
use your favorite language for web development and that's not the case. WASM
is now more about the integration with JS.

~~~
CyberDildonics
The point also isn't that you don't need any javascript. It seems like people
really aren't getting that webasm enables new things to be possible. Using
javascript to bridge to certain APIs really hasn't been a problem. WebGL
already works well, even with pure javascript. Between JIT compiling and bulk
transfer functions, there aren't actually that many calls happening per frame.

> The promise was that you can use your favorite language for web development

I can see where you are confused. The promise was never about using your
favorite language for web development. It was about being able to compile
languages to a synthetic ISA that will run at near native speeds.

> WASM is now more about the integration with JS.

It was never about getting away from javascript, it was always about being
able to run software at near native CPU speeds in the browser.

------
bitL
How do I compile/target stuff for WebAssembly and integrate it with "usual
web" (I need to use some advanced math & WebGL real-time that is too slow in
JS)? Is there any good tutorial? Thanks!

~~~
steveklabnik
Currently, the best supported languages are C, C++, and Rust. Languages that
have runtimes require their runtimes to also be compiled in, and so are much
heavier weight.

For C and C++, you have emscripten. For Rust, we have an emscripten-based
toolchain that works today, but have a PR open for using LLVM's built-in wasm
backend.

For emscripten: [https://kripken.github.io/emscripten-
site/docs/#](https://kripken.github.io/emscripten-site/docs/#)

For Rust: [https://hackernoon.com/compiling-rust-to-webassembly-
guide-4...](https://hackernoon.com/compiling-rust-to-webassembly-
guide-411066a69fde) (slightly older but still should work afaik) And the new
backend [https://github.com/rust-
lang/rust/pull/45905](https://github.com/rust-lang/rust/pull/45905)

------
hannofcart
All the excitement around wasm seems quite puzzling to me. Yes, I understand
that you can program in whatever language you love but what new language are
you hoping would be supported? C? C++? Fortran?

As far as I am concerned, all the languages I care about already have
compilers that target JS.

~~~
bluejekyll
Rust is the big one for me, personally.

The idea of being to write in one language for embedded software, system
software, cli tools, web applications, distributed applications, and now the
web client?

That's a very enticing idea. It might finally be the realization of what Java
failed to accomplish ( _technically_ it did, but never gained a lot of
traction on the client b/c it was too slow at the time).

------
pfalke
„...all major browsers“

Is Internet Explorer not a major browser anymore? I’m talking relevant as in
_your webpage needs to work fine in Internet Explorer_.

For example, my company still has Internet Explorer configured as default
browser as Edge is not compatible with some internal pages.

~~~
olegkikin
IE is not a major browser anymore

[http://gs.statcounter.com/](http://gs.statcounter.com/)

Look at your Google Analytics, it's really not that important anymore.

~~~
sametmax
In corporate env it is.

~~~
foodstances
Either the computers in these mysterious corporate environments are exposed to
the internet, in which case they'd be reflected in these public stats
collected by them visiting public websites from IE, or they aren't, in which
case they don't matter in the slightest because they're not going to visit
webpages using WebAssembly.

~~~
romaniv
IE can account for a fraction of total _traffic_ , but it still can affect
large percentage of _users_. The same person can use several devices (work,
home, mobile) to browse the web at different times. I can't recount how many
times I saw some page at work only to send myself the link to read it later.
I'm not forced to use IE anywhere, but if I were, loosing that initial visit
would also lower the number of visits from other browsers.

------
dmitriid
Ok, now we need GC and DOM interop. Because reinventing layouts is pain.

~~~
amelius
In order to port other languages (Haskell, Go, Python) to target WASM, we
definitely need the possibility of writing a GC in WASM. But to build an
efficient GC, we need multithreading and synchronization/memory barrier
primitives.

~~~
bartwe
Multi threading brings in all kinds of security issues

~~~
marcosdumay
What kinds of security issues? I really can't think of any besides some issues
with too many threads spawned (that can be trivially blocked).

~~~
oconnor663
Could be a new source of undefined behavior and memory exploits, if threaded
code is allowed to access collections that allocate memory without taking all
the locks they should?

~~~
marcosdumay
Inside the VM, yes. But not a security threat for the host.

The VM should be sandboxing the pages from each other, so those are potential
security threats against targets on the same pages only. Not something to be
too concerned about.

~~~
oconnor663
Help me understand: What's the difference between that and process separation?

------
Yuioup
Can't wait for a port of Angular2+ to C#.

------
bitL
Soon we will all have JDK, .NET runtime and WAsm runtime running on our
machines.

------
jlebrech
I want to see a WASM+react framework where the application state/logic is
fully in WASM and merely the rendering is done by react.

~~~
twfarland
I would want the inverse of that, where the application logic is in some high-
level language, and the rendering is done in WASM, i.e. react-dom and the
diffing parts of react are in WASM.

------
r00fus
Based on the unbridled capabilities, I can't wait for a way to block WASM.
Does noscript do this yet?

~~~
steveklabnik
What "unbridled capabilities" are you referring to?

------
pier25
Any news on access to DOM progress?

~~~
steveklabnik
I commented elsewhere in the thread about the latest proposal.

------
capablemonkey
Who wants to write a faster CryptoNight miner in wasm?

------
singularity2001
did they improve external stacktrace support? the last time I checked
debugging was imposible due to bad stacktraces.

~~~
steveklabnik
My understanding is that the current debugging tools can show you the text
format of wasm, but showing the original code you compiled to wasm doesn't
work quite yet. It's under discussion.

------
kyzlaitis
Nice advertisement

------
etatoby
Great. We will soon have an entire JVM running inside each browser's tab, just
to run an animated slider. Maybe even more than one. Plus a .NET VM, several
Python and Ruby interpreters, and so on.

Because webmasters will keep loading ready-made plugins from CDNs, exactly
like they are doing now, except that the new generation of web software will
carry their own interpreter or runtime with them, because the developer wanted
to use Python or whatever.

The web is getting better by the day.

~~~
tzahola
I'd like to interject for a moment here, and pitch my idea about what I call
the "Web 4.0". It's basically a binary equivalent of HTML, without the many
inconveniences of HTML for content providers.

Web 4.0 pages are obfuscated WebAssembly payloads, that draw their contents
via WebGL. This way, adblocking becomes impossible, as the actual content and
ads are within the same opaque WebGL framebuffer. Stealing copyrighted text is
also made significantly harder, beause the Web 4.0 platform leaves it up to
the publisher to enable glyph selection and copying. You have concerns about
accessibility? Web 4.0 is 100% accessible thanks WebAudio based realtime
speech synthesis!

~~~
taf2
it'll also be harder to learn how things work... i wonder how much we've
learned from reverse engineering the easy to read inline script tags... I
definitely remember teaching myself JavaScript by reading blizzard.com's late
90s markup... figuring out that mouse over effect with onmouseover and
onmouseout... works in ie4... but whats that strange bug in netscape 4..

~~~
TremendousJudge
You can't really do that today anymore though

------
pjmlp
Great, time to port SWF to WebAssembly.

------
baybal2
Java applets 2.0, we are back to square one, yet again.

People don't learn. The web dev community have just managed to force
browsermakers to unify web development on browser side JS, and throw Java
applets, activex, and action script to the bucket, just to have a kind of JVM
being made a part of the web standard, and forced upon us yet again.

~~~
RX14
There are some clear and defining differences between Java applets and
webassembly. The core problems with Java were that the security sucked, and
that applets were non-native and didn't use the dom. I doubt there is any
desire in web developers to overuse canvasses and do layout in wasm, and the
security model should hopefully be as successful as JS's has been over the
years.

~~~
baybal2
> The core problems with Java were that the security sucked

The core problem with Java applets was that they were Java applets

An option to keep the source of the web app closed will fragment the web dev
community yet again.

~~~
eknkc
I don’t think there is a single web site with human readable javascript on the
web anymore.

With all the bundlers and minifiers manglers etc, delivered js is already as
closed as a wasm binary would be.

~~~
krapp
> I don’t think there is a single web site with human readable javascript on
> the web anymore.

Meaningless hyperbole - there are plenty. You're posting on one right now.

~~~
eknkc
Sorry, I forgot Hacker News, the representative of modern web development
practices.

~~~
krapp
Ok fair enough.

Hacker News and at least every Wordpress site. So that covers a significant
portion of the existing web.

