Java still exists and is a valid deployment platform.
Why is WebAssembly outside of the browser needed?
https://www.java.com/en/download/faq/chrome.xml
The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore.
All the other browsers killed it as well.
There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something?
I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser.
Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)
That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it.
As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details.
So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.
Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications.
Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to.
I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI.
Why does WASI need to exist if Java already exists for the intended uses?
IMO, the reason is that the market showed that Java never got used like that. I can only speculate on the reasons, but as far as I can tell it comes down to:
1) The sandbox isn't good enough. See my sibling comment -- the separation between WASM and WASI makes a lot of sense, and I don't think Java had that.
2) The fact that you can't port C code to the JVM easily. In fact WASI addresses exactly that -- the API is more like POSIX than a brand "new" bunch of JVM APIs, which makes it easier to port existing native apps (C, C++, Objective C, Rust, etc.)
In other words, there's still a lot more "value" in native code apps than JVM apps. And it's too hard to port native code applications to the JVM.
For example, Photoshop, Illustrator, Word, Excel, etc. were never ported to the JVM. There are actually better analogs in the browser than on the JVM.
I ran windows for 15 years and Linux for 10-15 years. On neither of those platforms have I ever needed a JVM. I used to play online chess in a Java applet, and that's about it. Most common desktop apps avoid dependencies on the JVM. Probably the only reason I could think of installing one is to use Eclipse or IntelliJ.
The browser is the main reason why anybody had a JVM installed in the first place. Without that hook, the JVM becomes much less important on the client. It's still very important on the server.
Java is important and successful, but it empirically did not succeed at some of its design goals. Of course, WASM and WASI may also fail -- that remains to be seen. But to me they look like a good attempt, based on significantly different technical foundations.
There seems to be such a compiler here: https://github.com/bedatadriven/renjin/blob/master/tools/gcc...
1) There's a large difference between a compiler that exists and an efficient one. The JVM is designed for Java and not C, which makes efficient compilation hard / impossible. Graal as mentioned is an extremely unusual research technique that may make it feasible.
This comment is related:
https://news.ycombinator.com/item?id=19065829
Basically people underestimate how hard it is to make a VM that can run multiple languages. JRuby and Jython work, but it takes heroic efforts.
2) The interface to the OS, as mentioned. You can maybe run some algorithms like image processing, but try running the native sqlite code on the JVM, or something even hairier involving networking. It's not straightforward.
WASI provides something that's closer to what C programs expect than what Java provides. As I said, the market voted with its feet. All the friction adds up. If you try hacking on that compiler or manually porting code, you'll probably get a sense of why that is.
This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages.
The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.
You can run all those languages on top of the JVM!
The JVM also runs many other languages which weren't designed for it, like Ruby and Python.
That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associated environment/binding system are a portable way to encode C binaries, with significant benefits over JVM bytecode- that's probably the comparison I should have made.
But I wasn't comparing to WebAssembly, so you'll need to argue that point with someone else.
You could build a WebAssembly interpreter on Truffle, yes. I'm not sure anyone's tried it yet so that project is available.
Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.
I use it to run unmodified C extensions for the Ruby programming language on top of the JVM.
Truffle C is another example https://www.manuelrigger.at/downloads/trufflec_thesis.pdf.
(But this is pedantry, you clearly know what I meant.)
> Why: Developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines.
It allows you to use the same code both inside and outside of the browser. For example, Figma might use it, they already have a web app and a regular app, both using WebAssembly, so WASI would perhaps simplify their code or allow them to add more native integration to their app.
Making a product that's a slight variation of an existing product is often enough to gain significant market share. For example, was Chrome needed when there was Firefox? Was Figma or Adobe XD needed when there was Sketch? Is Rollup or Parcel needed when there is Webpack and Gulp? This could go forever. I mean, should Java be the only universal deployment platform?
It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)
https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....
Java is not a responsible or ethical choice for anybody to use for any purpose.
They deserve what they get.
It isn’t that the JVM is bad, it is that it isn’t the universal compilation target that WASM is.
Remember folks getting excited about LLVMIR, Bitcode? WASM is this but with a clean sandbox and minimal tractable semantics.
The JVM is awesome, esp with Graalvm and Truffle. WASM is the next evolutionary step.
It's arguably a better standard runtime than Java, for certain use cases. You don't see modern compilers targeting the JVM as an output target, but you do see them targeting WASM, there's probably good reason(s) for that (both technical and political/legal).
Furthermore, my understanding of WASI is that it allows standardization of _multiple_ runtimes, each domain specific.
For example, Functions as a Service. Currently AWS Lambda requires building a blob specially for them targeting their APIs and ABI. But what if Fastly, Fly.io, and the other "App CDN" FaaS providers come up with their own standard for "syscalls" for a WebASM-FaaS-1.0 spec? As a really bad example, the syscalls could be:
- 1 GET URL
- 2 POST URL
- 3 Cache Read
- 4 Cache Write
- 1 Storage Read
- 2 Storage Write
- 3 Contract Call
Furthermore, the barrier for entry as a syscall provider becomes much simpler too! If I want to make a local sandbox for FaaS testing, I just need to implement the syscalls from WebASM-FaaS-1.0 using local stubs, now I can test my FaaS locally. Way easier than the months/years probably spend reverse engineering the lambda environment for local testing. And if I come up with a novel solution for servicing one of those syscalls, hey, maybe I'll take my own stab at being a FaaS CDN. :)
Likewise for Ethereum and eWASM. Maybe I want to make a local test environment sandbox. Instead of re-implementing the EVM I "just" need to implement those syscalls outlined in the eWASM WASI spec (if such a spec existed). So now maybe light clients ship those syscalls over the wire somehow, and don't need to keep gigabytes of block chain data locally anymore.
edits: minor formatting
No matter what language I use, no matter what platform I deploy to, if I want to interact with a service or with infrastructure, I'm going to have to use the provided API(s), WASM included.
If I deploy a pre-compiled binary to an AWS Lambda and an Azure Function, and it works on both, it's because I had to have that in mind when I wrote that software. Will that not be true for a runnable WASM binary? It sure seems like it would be true that I would need to detect which platform I'm running on and then execute the proper stuff for the detected platform.
If all APIs are going to be compatible with each other, so that, say, storing a file uses the same API call no matter what system or platform you're on (never going to happen; bear with me) implementing that in WASM outside of the browser does not suddenly make it possible.
This is an opinion, and on HN this is likely to be a very unpopular opinion. I don't expect anyone to adopt this opinion, nor do I expect to sway anyone's thought with this opinion. This really (really, really, really) feels like JavaScript/web people wanting to do things outside of the browser, with performance better than JavaScript alone can provide, and then, rather than simply using an existing language and runtime, deciding that the best route forward is to pave their own road to this destination with web technologies. This does not feel like the best route to take if you want to write software that performs well outside of a browser.
There are lots of other languages, runtimes, and platforms, that allow this today. And the web is a bag of chaos: I can't even get a consistent design or UI language across major websites, today. Buttons sometimes look like links, links sometimes look like menus, and buttons sometimes look like any of those, but somehow WASM outside of the browser is something everyone (except me) can agree on?
I'm skeptical that this is a good idea for anything serious.
Just like there are implementation problems with Java, there are going to be implementation problems with these runtimes that every platform is going to need in order to run this code, now. There are going to be many security concerns because (warning: incoming opinion) nearly all developers are terrible at thinking about preventing security vulnerabilities. Those same developers are usually OK when it comes to fixing them, and terrible at thinking about vulnerability prevention.
It's _not_ a requirement, but at least to me it seems like a pretty good _possible_ solution.
I sense you're pretty jaded about web development, and I get that, but I don't agree this is "web people" trying to do things outside the browser, but rather I see it more as "systems people" trying to bring _some_ order to the chaos.
> nearly all developers are terrible at thinking about preventing security vulnerabilities
I totally agree. Which is why you should have a solid abstraction between the sandboxed code and what it's allowed to do, which WASM seems particularly good at (by only exposing services as syscalls). In theory, sandbox escapes in WASM should be the same level of difficulty as modern kernel exploits, so still _possible_ but _pretty hard_. And if multiple runtimes are using WASM for different things, if one is exploited it can be a learning lesson for all the other WASM runtimes, vs. the bespoke scenario where each custom VM has to go through the security bug discovery process by itself.
If _think_ what you're against is some sort of future where a "WASM-based-Electron" becomes the de facto standard for modern apps, and _that_ I largely agree with. In fact, re-reading the WASI standard I do feel like they are already "baking in" too much w/ WASI-core; I was expecting the core to just focus on a simple syscall ABI, not to include syscalls like filesystem reads and writes.
Some maybe what I'm really looking for is a "wasi-minium-abi" that just standardizes _how_ syscalls are made without actually standardizing any actual syscall numbers.
In summary, I feel like syscalls are a _very_ tried and true way to specify the API/ABI for a runtime, and that I hope we see more runtimes use WASM and a syscall ABI vs. rolling their own VM, but I agree that I'm in no rush to see WASM/WASI become the "Electron 2.0" of local app deployment.
The web development community haven't even solved their own problem space very well; spreading to new problem spaces will likely not suit them as much as they believe it will.
But this technologie comes not from javascript webprogrammers, but from browsermakers.
People who specialize in sandboxing, performance and portability since years. And they had to do this with javascript... and now they want a better foundation, BECAUSE of the flaws of javascript.
So I don't know if they will succeed making a better jvm either, but they certainly have the expertise that they might succeed.
This REEKS of developers who are psyched about WASM and want to create solutions where no problem exists.
If they want performant code outside of the browser, use any one of the 2-3 dozen languages that already do this! WHY is a new runtime, with the inevitable serious security issues that will be exposed throughout it's life, needed for this?
Right now there's no reason to conclude that this will turn into something that's no better than Java.
the solution is not to create another sandbox to run software in.
One advantage in this new push to build another sandbox is that Rust is leading the charge and is the de facto language of choice when building a greenfield WASM project. Given its propensity for memory safety and WASI's emphasis on capability-oriented security, I think the WASI team has a good chance of building something with a lot of value. Nothing here is novel (except perhaps Rust's extreme prioritization of memory safety) but that doesn't mean it can't or won't be an improvement over prior attempts.
I wonder how many of the previous sandbox vulnerabilities were viable due to some quirky memory manipulation techniques? Quite a few I would imagine.
No. Like Java, they just reinvented DEL again:
This basically means your language needs to work nicely with stop the world garbage collection.
(And yes, I know that modern garbage collectors aren't really stop the world, but the tradeoffs are still there.)
Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.
The problem is that the CLR comes with the the C# memory model and garbage collection.
If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection.
That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane.
If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model.
At that point, you might as well target your language to compile natively and use standard libraries in the operating system.
Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it.
And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.
Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises?
I'm asking honestly - why is WebAssembly outside of the browser needed?