Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing the web up to speed with WebAssembly

blog.acolyer.org

Post reply on HN
Print view View original

101–110 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#101

Post by jfbastien »

AnIdiotOnTheNet wrote: post #61
jfbastien wrote: post #54

Earlier quoted context omitted.

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

And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other. If anyone had actually cared about security on the web we wouldn't be where we are now.

Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/

Re: Bringing the web up to speed with WebAssembly

#102

Post by jfbastien »

weinzierl wrote: post #88
vbezhenar wrote: post #62

Earlier quoted context omitted.

We can port webkit to wasm, so our developers won't have to deal with browser inconsistencies anymore :)

Yeah, and V8, so we could just write JavaScript again and wouldn't have to deal with WASM. With a bit support from WASM and a few tweaks to V8 it could run near native JavaScript speed. Let's call it JavaScript paravirtualization.

Interpreters can go a long way, but JIT code generation is required for really fast dynamic language implementation. That's quite a bit off for WebAssembly: https://github.com/WebAssembly/design/blob/master/FutureFeat...

Re: Bringing the web up to speed with WebAssembly

#103

Post by jfbastien »

slededit wrote: post #91
jfbastien wrote: post #22

Earlier quoted context omitted.

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…

I'm actually working on an effort in this space. Specifically we're at the point where it's time to stand up a libc in a non web embedding. If anyone is interested in the effort they should let me know.

I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.

Re: Bringing the web up to speed with WebAssembly

#104

Post by jandrese »

weinzierl wrote: post #70
AnIdiotOnTheNet wrote: post #43

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.

A big reason Java failed was that it was painfully slow. Starting the VM and importing everything took tens of seconds on old machines, and still takes a couple of seconds on new ones.

Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process.

I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.

Re: Bringing the web up to speed with WebAssembly

#105

Post by amelius »

lj3 wrote: post #65
lmkg wrote: post #27

Earlier quoted context omitted.

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

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.

Yes, something like OpenGL.

Re: Bringing the web up to speed with WebAssembly

#106

Post by AgentME »

jandrese wrote: post #104
weinzierl wrote: post #70

Earlier quoted context omitted.

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.

A big reason Java failed was that it was painfully slow. Starting the VM and importing everything took tens of seconds on old machines, and still takes a couple of seconds on new ones. Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process. I have to admit I don't know much about the security model of WebAssembly, but I wonder if it w…

>I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.

WebAssembly in browsers executes similarly to javascript in the same sandbox with the same platform APIs with the same kind of delivery methods, so I don't think we have that to worry about.

Re: Bringing the web up to speed with WebAssembly

#107

Post by catdog »

weinzierl wrote: post #70
AnIdiotOnTheNet wrote: post #43

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.

I think it mainly failed because Sun basically abandoned it. Security was not the issue I think (Flash was the same, maybe worse, still widely used) but the UX was quite terrible and never really improved: You had the jvm with its long startup times which was more than noticeable in the 90s and early 2000s. Applets always felt very alien inside a Website and using the applet simply to call into optimized code from JS was, while possible not really what it was used for.

Security maybe more of an issue today but WASM probably is not worse than JS in that regard (basically it's just another turing complete language). As others have said APIs are more problematic, which I suspect will ever get worse while browsers further and further try to transform from document viewers to application runtimes (think of such "brilliant" ideas like WebUSB). WASM is not the key issue here, it's running untrusted code on the client which, even if it's sometimes not outright harmful takes control away from the user in one way or antother. In the end the main difference is that it's now a feature of the Browser rather than a plugin which has a hard time to fit in nicely.

Re: Bringing the web up to speed with WebAssembly

#108

Post by lallysingh »

lmkg wrote: post #27
whoisthemachine wrote: post #8

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…

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

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.

Re: Bringing the web up to speed with WebAssembly

#109

Post by lallysingh »

amelius wrote: post #105
lj3 wrote: post #65

Earlier quoted context omitted.

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.

Yes, something like OpenGL.

Say... WebGL?
Post reply on HN