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

81–90 of 172 posts

Re: Bringing the web up to speed with WebAssembly

#81

Post by kodablah »

sulizilxia wrote: post #4

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…

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

Re: Bringing the web up to speed with WebAssembly

#82

Post by Ajedi32 »

otakucode wrote: post #57
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…

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

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

METAL is coming.

Re: Bringing the web up to speed with WebAssembly

#83

Post by tannhaeuser »

batmansmk wrote: post #42

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?

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?

Re: Bringing the web up to speed with WebAssembly

#84

Post by weinzierl »

DiThi wrote: post #71
weinzierl wrote: post #63

Earlier quoted context omitted.

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

> The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy.

> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.

Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will.

[1] https://web.archive.org/web/19980214233937/http://java.sun.c...

Re: Bringing the web up to speed with WebAssembly

#85

Post by vvanders »

Zelizz wrote: post #53
vvanders wrote: post #40

Earlier quoted context omitted.

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

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!

Yeah, probably wouldn't be too hard. I've got Lua things drawing to an HTML5 canvas that runs at 60 FPS on a private project.

As long as you don't make 1000's of calls per frame it runs pretty well.

Re: Bringing the web up to speed with WebAssembly

#86

Post by DiThi »

weinzierl wrote: post #84
DiThi wrote: post #71

Earlier quoted context omitted.

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

> The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy. > W…

"functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.

Re: Bringing the web up to speed with WebAssembly

#87

Post by jerf »

gsnedders wrote: post #15
umamimc wrote: post #3

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.

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

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.

Re: Bringing the web up to speed with WebAssembly

#88

Post by weinzierl »

vbezhenar wrote: post #62
wlesieutre wrote: post #34

Earlier quoted context omitted.

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

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.

Re: Bringing the web up to speed with WebAssembly

#89

Post by Ajedi32 »

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…

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

Post reply on HN