Hacker News Reader

Comment by kettlecorn | Hacker News Reader

Increasingly I’m becoming convinced that something like this may become the backbone of future computing.

Imagine truly cross platform code that performs well, and can be written in whatever language you care for.

The web illustrated certain advantages to developing software that can be easily delivered and run on other systems. However, the learnings of the web were always coupled to the browser.

WebAssembly, through projects like this, may soon be able to empower cross platform code that delivers small, well performing programs on whatever platform a user desires to use.

View on HN

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.

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

Both Burroughs/Unisys and IBM had same idea about future of computing in the late 70's and then went to build AS/400 and Burroughs large systems, which are both based on kernel-space JIT compiled "bytecode" (with significant difference in granularity of the thing that gets compiled on first use and how the compilation results are cached, which for IBM i5/OS essentially means that it is on-demand AOT compiler), which is the reason that these systems are currently based on commodity hardware (ie. Power and Xeon).

And the AS/400 used to be the huge success.

We are going in circles here, this is how mainframes started in the early 60's, bytecode with microcoded CPUS.

Notable examples, Burroughs B5500, Xerox PARC workstations, ETHZ Oberon/Modula-2 workstations, UCSD Pascal, ..., iOS bitcode, Android DEX and UWP MSIL.

Operating systems don't work like that, you could program something high level but in the non-web world you need ensure data is written to storage and syscalls which are not portable even between architectures.

For WebAssembly programs to work syscalls and storage stuff would have to be wrapped so that each platform has its own implementation with the same interface.

This isn't that strange of a concept, it's how stuff like Java has worked, but for it to truly feel native the companies that control the platforms would have to coordinate on it and integrate it. Unfortunately I don't see that happening quickly, but perhaps eventually.

Would never work, how do you emulate real capabilities on say Linux or IOCP, etc.

Genuinely ignorant question, what's the difference with C from this perspective? I thought the whole point of C was to be a common language.

Nasal demons

Binary compatibility across architectures, no undefined behaviours are the primary ones.

Yes of course, here is an example of a well defined, no ub, == overloads.

https://slikts.github.io/js-equality-game/

It is all bound to make JS kernel programing a Pilar of OS Stability.

Does that apply to web assembly?

None of that applies to web assembly, as I'm sure you know.

You're confusing JS with wasm and undefined behavior with confusing behavior. JS and wasm are strongly defined and the specifications consider undefined behavior a bug.

C has to be recompiled per platform.

The advantage to something like using WebAssembly is you could write a program in C, compile it to WebAssembly, and then it could be run on anything that supports WebAssembly.

This could enable a future where you write one program that can run in a web browser, as a phone app, as a desktop program. All with only tweaking the UI.

Additionally the divide between a “web app” and a desktop app from a user perspective increasingly comes down to: do I need this to run fast (as a native program), or do I want it to be convenient to use (as a web app)? WebAssembly may very well become fast enough that it is fast and convenient for all but the absolute most demanding of applications.

WebAssembly's closest analog would be LLVM's IR, which many compilers like clang (for C/C++) or rustc output so that they can use LLVM's existing codegen. In WebAsm's case, however, the backend would be the different browsers and their sandboxes.

The C ABI describes a common calling convention and a few other details to allow different compilers to use each other's binaries, but C is hardly a common language in the way WebAssembly is meant to be.

I agree 120%.

It's weird nobody seems to really complain about platform lock in, which is the main problem created by software companies, that create so much pain for developers.

Even if one looks at the software market, I really doubts that lock in really works at all. Developers quickly figure out ways to do things run on multiplatform.

It's no surprise JavaScript grew to be so popular, because it was just 100% multi platform. It's quite sad to realize js has so many drawbacks.

Attempts at lock-in just seem to delay the inevitable and make software worse in the meantime.

For companies like Microsoft and Apple those delays have been enormously profitable, but long term there may be a hefty cost from their avoidance of truly great crossplatform software development tools.

Reply on news.ycombinator.com