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

61–70 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#61

Post by AnIdiotOnTheNet »

jfbastien wrote: post #54
ams6110 wrote: post #47

Earlier quoted context omitted.

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

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.

Re: Bringing the web up to speed with WebAssembly

#62

Post by vbezhenar »

wlesieutre wrote: post #34
RubenSandwich wrote: post #31

Earlier quoted context omitted.

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

I've said the same, but you just know somebody comes along and says "If we render our entire site into a it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.

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

Re: Bringing the web up to speed with WebAssembly

#63

Post by weinzierl »

DiThi wrote: post #46
AnIdiotOnTheNet wrote: post #43

Earlier quoted context omitted.

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

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

From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1].

Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on.

[1] https://kripken.github.io/emscripten-site/docs/porting/conne...

Re: Bringing the web up to speed with WebAssembly

#64

Post by fasquoika »

pedrocr wrote: post #20

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?

>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

Re: Bringing the web up to speed with WebAssembly

#65

Post by lj3 »

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.

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.

Re: Bringing the web up to speed with WebAssembly

#66

Post by dang »

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.

Re: Bringing the web up to speed with WebAssembly

#68

Post by weinzierl »

otakucode wrote: post #58
AnIdiotOnTheNet wrote: post #43

Earlier quoted context omitted.

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

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

"Write once, run everywhere" was literally the motto of Java. Java bytecode does run everywhere there is a JRE and the JRE has been ported to a lot of hardware.

Re: Bringing the web up to speed with WebAssembly

#69

Post by mtgx »

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…

Sounds like good news for Chromebooks.

Re: Bringing the web up to speed with WebAssembly

#70

Post by weinzierl »

AnIdiotOnTheNet wrote: post #43
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…

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