Bringing the web up to speed with WebAssembly

https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/

by yugoja • 9 years ago

167 166 9 years ago

blog.acolyer.org

WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic.

Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Everything running from WASM is in an isolated sandbox. For obvious security reasons this isn't likely to change.

hdhzy3• 9 years ago

Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic.

I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.

ChrisSD2• 9 years ago

There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc).

I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.

drdrey• 9 years ago

WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for the source language, not the target.

yaantc• 9 years ago

..., to the web

And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system?

For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.

austincheney4• 9 years ago

For your second point, JavaScript is also sandboxed.

There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on....

To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO.

WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.

jfbastien10• 9 years ago

You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an infinite register set and stack machine, with a very well structured control flow. You really don't need a smart compiler to lower this to semi-efficient code. The runtime in a non-JavaScript embedder then has to expose a series of syscalls, but that's not very big either.

markdog12• 9 years ago

Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't.

Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently.

http://webassembly.org/docs/future-features/

austincheney4• 9 years ago

I did not see native DOM interaction in that document and the thing it linked to is 404.

vvanders3• 9 years ago

Well anything that lets me run Lua in the browser[1] is cool by me ;).

But yeah, interop is something that you can't just hand-wave away. It needs to be done carefully and with the right semantics and performance. That said I think we well get there and for a certain limited use cases it's already there.

[1] https://github.com/vvanders/wasm_lua

Zelizz• 9 years ago

Oh man, with Lua in the browser, I'd actually start to write web stuff again. And we could get a really nice fast port of Love2D running!

ams61102• 9 years ago

more secure

Is it? How do we know? The attack surface in browsers is huge.

jfbastien10• 9 years ago

A few ways that come to mind:

1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind. 3. It's very static in that memory accesses are pretty easy to bounds check for the compiler.

Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.

krapp5• 9 years ago

Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't.

It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.

txdv• 9 years ago

Yeah, I wonder why OP thinks that the sandbox is bad.

Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors

umamimc• 9 years ago

My worry is, does this make it easier for the big companies to silo the internet more completely? From a developer POV with regard to performance, this seems great, but from the standpoint of open communication, it seems problematic.

gsnedders• 9 years ago

It doesn't make it any easier than minified, obfuscated JS.

jerf• 9 years ago

Out of curiosity, is there anybody in the last couple of years who would say that reading the source of websites was a significant component of their learning the web? (By "significant", I don't mean "primary" but I do mean more than "I once popped open a bit of source and found a method I didn't know existed".) Even in 1997, I was using free documentation, not reading websites, which even before minification and such were still often quite ugly to read.

sulizilxia3• 9 years ago

I wonder how this will affect Java in the long term. In the comments about the JDK9 release, there was discussion about the JVM becoming a sort of language-agnostic platform where Java is a small part. It seems WebAssembly is occupying a lot of the same space, but from a sort of opposite direction (in the sense of providing the compilation target first).

Java and the JVM obviously aren't going anywhere soon, but the history of javascript, node.js, etc. leads me to suspect WebAssembly could displace the JVM in the long term.

austincheney4• 9 years ago

Java is a language. It comes with a standard VM, compile mechanism, and bytecode. Fortunately, the Java platform is well segmented so that the language is a separate technology from those other pieces. Scala, for example, is a language different from Java, but still targets the compile mechanism and JVM.

WebAssembly, by contrast, is not a language. It is only a bytecode and conforming container. Java could compile to WebAssembly instead of its standard bytecode and the biggest difference is execution environment. In order for WebAssembly to displace the JVM it would have to run where the JVM can run with appropriate levels of support.

sulizilxia3• 9 years ago

I was a little unclear about this, but I meant Java in the broad sense of the Java ecosystem, including the JVM and the language. I was mostly wondering if languages will move toward WebAssembly as a target instead of the JVM, and what consequences that will have.

On the other hand, maybe I had Java the language in mind unconsciously at some level. You're right that you could have Java targeting WebAssembly instead of its standard bytecode, which I hadn't thought about.

At least now, it seems like the JVM offers some stuff that WebAssembly doesn't, but I have a hunch it won't stay that way in the long run.

There's been a lot of good discussion here about WebAssembly versus the JVM; it seems like lots of people have similar thoughts about this topic.

kodablah3• 9 years ago

In many ways, the JVM bytecode is a superset of WASM. That's why I wrote https://github.com/cretz/asmble.

sulizilxia3• 9 years ago

Interesting--this seems forward-thinking and useful.

whoisthemachine2• 9 years ago

WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on.

This could be a good thing, if done correctly:

1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and verified?) by browsers

2. "Web apps" could potentially go away - leaving web browsers for what they were intended, document sharing

zach43• 9 years ago

I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems.

If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?

baq• 9 years ago

If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.

jfbastien10• 9 years ago

In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.

flohofwoe• 9 years ago

WebAssembly itself is just (more or less) an instruction set, not a complete runtime platform. It doesn't define APIs for rendering, audio, input, filesystem access, networking, etc...

Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.

kuschku5• 9 years ago

You are lucky, Java 9 was just released.

Now you can ahead-of-time compile any JVM project into a single executable, it will run on all platforms, and it will have nice UI toolkits (JavaFX is quite awesome).

Even better, with Truffle + Graal in Java 10 also native interoperability with basically every other language is coming, so you can basically combine this with every language.

gwbas1c3• 9 years ago

Write once, run everywhere always has various tradeoffs. The closer you get to fundamental differences in operating systems, the more platform-specific code you need.

UI, for example, is hard to make platform independent if your application needs to look and feel native; or needs to plug into platform-specific features.

What would be useful is a way to easily call WebAssembly libraries from native applications. This way common business logic can be written cross-platform; but the parts of an application that need to remain native are left native.

pebers• 9 years ago

No, because at the least all three have different executable formats (PE, Mach-O and ELF respectively). I suppose it might end up being possible to ship some sort of HTML + WASM bundle that they all know how to interpret if it became common enough.

lmkg• 9 years ago

I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a <canvas> element.

RubenSandwich• 9 years ago

I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)

pjmlp6• 9 years ago

Same here.

I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.

Terr_• 9 years ago

Alas poor applets, they were before their time.

lj33• 9 years ago

Canvas is too slow and handles text rendering poorly. If browsers really want to take another step in that particular direction, they're going to have to expose a lower level API for graphics and text rendering.

lallysingh3• 9 years ago

The web is mostly documents, with a few apps sprinkled here and there. HTML will likely be around, and in good use, for a long time.

Even the apps will use HTML's model via their DOM tree.

amelius4• 9 years ago

Yes, and there will be a default WASM code that interprets and renders the rest of the HTML! (in case anybody still wants to use HTML as W3C defined it).

whoisthemachine2• 9 years ago

I don't think so, at least not from non-professional content producers. There will still be a desire to have an easily written, shared, and rendered document upon which you can give your thoughts.

HTML has always been best at that, and will still be good at that in the future. The only contender I know of would be markdown, which fulfills many of those needs while being even easier to write. Its greatest pitfall in a contest against HTML is that it is by design non-standard, as it is meant to be a pre-render stage document, and presumably your render stage will smooth out any non-standard markdown elements, giving you a standard document in a format like HTML.

krapp5• 9 years ago

It can't be that and that alone unless browsers somehow decide not to support the rest of HTML... which seems very unlikely.

AnIdiotOnTheNet4• 9 years ago

We had that in the 90s. We called it Java.

grondilu2• 9 years ago

https://www.quora.com/What-is-the-difference-between-Java-We...

DiThi4• 9 years ago

Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).

otakucode2• 9 years ago

Java never had, or tried to have, binary portability.

weinzierl6• 9 years ago

I'm quite excited about WASM (as I was, admittedly, about Java Applets in the 90s), but this is a question that haunts me. I wish someone with better understanding of WASM and Java than me could write up why byte code delivery to a sandboxed VM in the browser failed in the 90s and why we should believe it will succeed now, or what exactly WASM brings to the table that Java didn't.

primeblue8• 9 years ago

It was so ugly

catdog2• 9 years ago

After some time you realize: The hype train is traveling in a circle.

ams61102• 9 years ago

It may become the future platform that native, dekstop apps run on

So Flash, again?

pjmlp6• 9 years ago

Someone will most certanly implement a SWF to WebAssembly converter.

otakucode2• 9 years ago

My first thought reading the specification was '6 months before there's silicon that runs the bytecode directly.'

Ajedi322• 9 years ago

Obligatory "The Birth & Death of JavaScript" reference: https://www.destroyallsoftware.com/talks/the-birth-and-death...

METAL is coming.

weinzierl6• 9 years ago

No really. WASM is based on a stack machine and not a register machine. On the other hand there was PicoJava [1] and there is Jazelle [2]. So, maybe...

[1] https://en.wikipedia.org/wiki/PicoJava

[2] https://en.wikipedia.org/wiki/Jazelle

mtgx• 9 years ago

Sounds like good news for Chromebooks.

Ajedi322• 9 years ago

"Web apps" could potentially go away

I prefer to think of it instead as native apps going away. Or rather, the web becoming indistinguishable from native.

If native apps start being run on WASM, and web apps start being run on WASM, and the web continues to gain access to more and more "native" APIs... it may not be long before there's basically no difference between a native app and a web app, from the end-user _or_ developer's perspective.

krapp5• 9 years ago

I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.

flavio81• 9 years ago

I love Webassembly, because It will eventually remove Javascript's dominance from the web for good.

golemotron• 9 years ago

Eich's support is poetic.

primeblue8• 9 years ago

This is a brilliant result, make this toy broken language compete

bnolsen• 9 years ago

AKA how to bring more advertising and tracking crap to your browser...I really do hope it's not that.

pedrocr2• 9 years ago

We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?

jfbastien10• 9 years ago

Same organizations, different people, and enough time to experiment with (read: suffer pains from) things like asm.js and PNaCl for those people to agree that something like WebAssembly was a good idea.

fasquoika2• 9 years ago

We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible.

Technologically speaking, this has been possible since the days of p-code. The browser vendors have only just decided that it's something that's actually beneficial

always_good• 9 years ago

It's also been possible since Javascript.

gwbas1c3• 9 years ago

It's called the CLR. (Common language runtime, which is what C# runs on.)

The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.

pedrocr2• 9 years ago

There are plenty of VMs out there, the JVM and CLR being the biggest two. Up to now though none were usable on the web.

TheAceOfHearts2• 9 years ago

I was a bit skeptical of WebAssembly when it started popping up, but reading through this and the MDN docs has made me get a bit more excited.

In a few years WebAssembly might make for a great environment to learn about lower level programming. I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything.

What's the reasonable thing to do when a grow-memory instruction returns -1?

How are people using WebAssembly? Are there high-quality polyfills available for older browsers?

How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?

jfbastien10• 9 years ago

What's the reasonable thing to do when a grow-memory instruction returns -1?

A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you shouldn't need to worry: it's similar to having mmap fail on other platforms. What do you do when mmap fail? I usually just give up and abort, but in rare cases I'll do other fancy things.

Are there high-quality polyfills available for older browsers?

Work had started in 2015 for a solid polyfill, but now all major browser vendors have shipped WebAssembly so that work wasn't seen as necessary anymore.

How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?

Not that satisfying an answer, but https://github.com/WebAssembly/design/blob/master/FeatureTes...

avaer• 9 years ago

I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything.

Well... modern assembly is monstrously complex. Probably more so than your favorite high level programming language. Modern assembly is generally not a bare minimum, because it's designed to give compilers the interface to run code fast, not to be easy to program by people.

And WebAssembly is a bit of a misnomer since it's not quite your processor's assembly; it's designed to be assembled fast on the client side, while also being memory-safe. Ironically that makes it simpler than actual assembly.

fasquoika2• 9 years ago

It sounds like you're assuming they were talking about x86 when they didn't actually specify...

TheAceOfHearts2• 9 years ago

I learned assembly with an 8086 emulator, and I've had the pleasure of writing assembly for bare-metal ARM microcontrollers. But you're right, modern x86 assembly is a whole different beast. I've tried looking through their manuals, but as I recall their manuals are largely unapproachable +3000 page tomes.

My comment was written with the 8086 emulator in mind. It was great because you could view what was in each register, as well as the inspect any section of memory.

marcosdumay3• 9 years ago

What's the reasonable thing to do when a grow-memory instruction returns -1?

99% of the time, you proceed to try to write into address (-1) and your process is killed by the supervisor. Despite what many people say, that's a perfectly reasonable thing to do, if you can afford to have your process killed.

The rest of the time, you'll do something very application dependent, like cleaning caches, optimizing for space instead of time, postponing some task, etc.

solnyshok• 9 years ago

Once you mentioned "bare minimum of concepts and tooling from which you can build everything" I immediately thought of js module-for-everything situation. We might be getting even more of them written in webassembly.

grondilu2• 9 years ago

This is probably hand-waving but : instead of implementing threads directly into the WebAssembly language, would it make sense to compile a known micro-kernel to WebAssembly and then compile the C standard library (which, IIRC, implements threads)?

AnIdiotOnTheNet4• 9 years ago

Yes. Let's combine the renowned safety of the C standard library with the speed and efficiency of a web browser!

Rusky6• 9 years ago

This wouldn't help at all. Kernels (micro or no) can only implement preemption with the help of hardware timers (and, if you want parallelism, hardware cores), which Webassembly cannot access. (The C library does not implement threads; it merely wraps the kernel's implementation of them.)

So at some level WebAssembly itself must provide some sort of primitive for threading, or else at best you'll get cooperative coroutines/an event loop.

gwbas1c3• 9 years ago

I'd rather see something like async/await before true threads. So much of web programming is network IO bound; that what we really need are primitives that make async programming easier.

Threads can come later.

The problem is that when async programming is hard due to language or framework difficulties, threads are the easier choice. But then, older code is locked into patterns that are hard to refactor to async/await.

batmansmk• 9 years ago

Yet, almost one year after its release, nobody makes money directly or indirectly with wasm... despite the beauty of its engineering, I'm starting to worry. Who will continue funding it if nobody uses it?

tannhaeuser2• 9 years ago

Exactly. WASM stories always bring up wild fantasies of platform world domination, when in reality there aren't APIs for even the most basic things, let alone practical apps.

In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want to rid browsers of Java in the first place just to start all over with it?

Rusky6• 9 years ago

Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.

ern• 9 years ago

It hasn’t got a big installed base yet[1], so it’s hard to justify the investment. Also, remember that experience with Applets/Flash/Silverlight has burned developers, and probably made them fearful. I expect that once a big player makes a move, momentum will build.

[1]https://caniuse.com/#search=Wasm

panic• 9 years ago

Figma is using it (though I'm not sure how much money they're making at this point): https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...

Animats2• 9 years ago

I suspect that the use cases for WebAssembly will be something like this:

- < 10% user-beneficial compute in the browser

- 60% ad and tracking obfuscation

- 20% annoying scrolling and transitions

- 10% hostile code

justinpombrio• 9 years ago

That's about the breakdown for Javascript too, right?

Animats2• 9 years ago

Probably, but only the first use case needs more performance.

CaptSpify• 9 years ago

It's frustrating to watch because it feels like we've learned nothing from the past 10+ years of web development.

primeblue8• 9 years ago

We've learned JavaScript is a toy

userbinator• 9 years ago

Add DRM to the 60% and I'd agree.

na85• 9 years ago

Can't be overstated. Web assembly is going to be a disaster for users in the long run.

The helpless feeling as a bunch of people actively destroy the web for no reason other than that it's more convenient for them is so frustrating.

dang• 9 years ago

Url changed from https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s..., which points to this.

acolyer.org's glosses on papers are excellent and I like reading them myself, but sometimes it's a bit of a struggle knowing where to situate them on HN given the original source rule (https://news.ycombinator.com/newsguidelines.html).

Edit: changed my mind. Like I said, a bit of a struggle.

krallja• 9 years ago

I think you made a good choice: acolyer.org posts provide enough additional analysis, comparisons to previous posts, and meta-commentary to stand on their own.

primeblue8• 9 years ago

JavaScript is so 2015, long live C++

Asdfbla• 9 years ago

Really interesting paper. When I first heard about what WebAssembly was trying to achieve, I naively wondered why people didn't just slap some existing interpreter for bytecode into browsers (JVM, .NET, maybe even adapt LLVM?) and go with that. I knew people had been burned by Java applets, but I was still curious why they invented something new again instead of possibly adapting existing stuff.

Of course I accepted that they surely had some good reasons for doing it the way they did, but the paper has some interesting specific points in favor of the Webassembly and against existing stuff like the JVM (easier verification of the bytecode etc.).

dangjc• 9 years ago

Webassembly is incredibly hard to debug in the browser. Source maps give you a decent stack trace, but you can't evaluate variables. I'm hoping this situation improves.

haberman• 9 years ago

nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.

I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.

Bringing the web up to speed with WebAssembly

Related Stories