Live data from Hacker News

Bringing the web up to speed with WebAssembly

blog.acolyer.org

71–80 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#71
post #46

Earlier quoted context omitted.

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

> Java only had one closed source implementation... This is not true. There were alternative implementations from very early on, most notably the Microsoft one. > ...and had many security issues during its life. True, but WASM hadn't had much of a life so far, so we will see. > 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…

> most notably the Microsoft one.

My bad. However it was closed source too, and abandoned rather quickly.

> True but WASM hadn't had much of a life so far, so we will see.

It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code.

> from what I see I think it's ugly as well

Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour.

> Java was designed with a sandbox and a bytecode verifier from very early on.

They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.

Re: Bringing the web up to speed with WebAssembly

#72
post #45

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…

> It may become the future platform that native, dekstop apps run on So Flash, again?

Someone will most certanly implement a SWF to WebAssembly converter.

Re: Bringing the web up to speed with WebAssembly

#73
post #46

Earlier quoted context omitted.

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

And how much of that is true today?

All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).

Re: Bringing the web up to speed with WebAssembly

#74
post #18

Earlier quoted context omitted.

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…

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.

Yup, we need an stdlib (and not libc)

Re: Bringing the web up to speed with WebAssembly

#75
post #12
post #5

Earlier quoted context omitted.

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

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.

I mean Flash had a dedicated IDE. WebAssembly can be compared to ABC (ActionScript Bytecode) not to Flash.

Re: Bringing the web up to speed with WebAssembly

#76

Earlier quoted context omitted.

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

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.

If it were just the bytecode then it would not have failed. JVM bytecode and WASM have plenty of similarities. What cost Java is the stdlib surface area and security model. Also that it is a separate runtime was annoying, like Adobe with Flash, there was one primary vendor.

So many JVM bugs and a huge stdlib. WASM has no real lib, and when it does, it's security model is already restrictive... there's no disk, network, threads (yet), etc.

Re: Bringing the web up to speed with WebAssembly

#77
post #52
post #5

Earlier quoted context omitted.

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

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

That's his/her point; they were trying to point out why Flash and WebAssembly aren't analogous.. Flash was a cohesive toolchain; not a build target.

Re: Bringing the web up to speed with WebAssembly

#78
post #52
post #5

Earlier quoted context omitted.

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

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

Exactly. So the patent can compare WebAssembly to ActionScript byte code or swf binary format not to Flash.

Re: Bringing the web up to speed with WebAssembly

#79
post #48

I suspect that the use cases for WebAssembly will be something like this: - - 60% ad and tracking obfuscation - 20% annoying scrolling and transitions - 10% hostile code

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

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

Re: Bringing the web up to speed with WebAssembly

#80

Earlier quoted context omitted.

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

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.

That's very much the question indeed. All that's really needed for a native experience on both Android and iOS is a native ARM binary, optionally bundled with webkit, but then that's what native runtime environments for Android and iOS have already built-in.
Post reply on HN