Hacker News Reader

Comment by ummonk | Hacker News Reader

Well, the JVM was supposed to be this, but turned out to be too closely tied to the Java language, as well as too heavyweight for a lot of webpages (getting replaced by HTML5 instead). It's interesting to see us coming full circle with WebAssembly, albeit with a much more language neutral, multi-vendor framework.

View on HN

I was going to bring up the JVM because it definitely was an attempt at the same goal. I think the obstacles this time around will be very similar for WASM, but it stands a far better chance due to its language and vendor neutrality, as you mentioned.

For user facing applications there remains the question of what sort of cross platform UI framework could accompany WASM. Or should WASM just remain coupled to the Web? Java’s UI solutions were often received very poorly and led to Java’s bad reputation amongst consumer software.

Analyzing the desires and goals of the big players (Google, Microsoft, Apple) with regards to how Wasm might develop is interesting.

> Well, the JVM was supposed to be this, but turned out to be too closely tied to the Java language, as well as too heavyweight for a lot of webpages

Agreed, but want to add wrt tied to Java the language, that stdlib it carries around is a large burden too. WASM will need a stdlib one day or suffer portability, so here's to hoping whichever one is adopted is small and simple (no, posix is not good enough like emscripten and this lib work with).

As we've seen with JS, an anemic standard library is also a big problem. Hopefully npm-isms dont infect WebAssembly, but I don't hold out much hope.

Why does WebAssembly need its own standard library? No one is going to be writing code directly in it, any more than they would write Java bytecode by hand.

I can't even write a function accepting a string because there is no notion of string. Every piece of WASM written carries the runtime of the source language making sharing code much more difficult and bloating binaries with duplicate logic.

It doesn't need one stdlib as part of the WASM project, but sooner or later people are going to want to share, e.g. a socket. Even without a full blown stdlib, known data types need to be shared beyond just the structs that are coming with the GC proposal.

That's fair, even C has chars and char arrays. I don't know about strings, since every language has its own idea of what a string is. Even something as simple as an "array" has different behaviors between different languages... some languages only have maps that also act like arrays, some index from 1 rather than 0.

If Webassembly wants to remain as agnostic as possible, I don't think there's much more complexity they could add.

Being agnostic is a good goal, but being useful is more important.

Hopefully they get it right, because the JS ecosystem is a bloated mess that we've been stuck with because there's no other game in town.

I believe we would miss it dearly if wasm gains significant traction.

I wouldn't like running closed binaries with monolithic architectures through my browser. Maybe for a few selected high performance applications.

Not because the security aspect but I think it will be detrimental to an open web. Maybe not, we'll see.

edit: I don't really understand people that are not horrified by the thought of replacing general javascript code with one that is written in c/c++... Because string operations are awesome in these languages, right?!

The point of webassembly isn't to replace general javascript code but to be a better compile target for C/C++ etc than javascript, and to optimize performance critical parts of javascript when necessary.

Plenty of people want it to be a complete replacement for javascript, but I don't see that happening. I certainly don't think the doomsday scenarios that sometimes get mentioned whereby the entire web becomes nothing but closed, DRM ridden WASM binaries is likely. Large corporate owned sites and streaming services will almost certainly leverage it as much as possible, though.

"closed binaries in the browser" have existed since the days of Java applets and Flash. And no one is stopping anyone from providing or distributing the source for their webassembly modules, so I don't see webassembly as being any less free in that regard than any other language that compiles to a binary. Arguably, webassembly is more free because it isn't owned by a company or restricted to a single language.

> have existed since the days of Java applets and Flash.

That it what I was thinking about and it is something I wouldn't want to get back to. And having javascript as compile target would net you a more readable and therefore more open code. Painful process, sure.

But yeah, for specialized application webassembly could very well be worth it.

Javascript and C for example are like completely distinct circles of friends and you don't necessarily want them to meet each other.

The JVM as a kernel module would be interesting

I'm not sure where the hate for this comment is coming from though given the submission is also talking about adding a runtime into kernel space.

Sun did actually implement a Solaris kernel JVM.

"Writing Solaris Device Drivers in Java"

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92....

Reply on news.ycombinator.com