* Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM)
* Proprietary (vs based on an open standard)
* They couldn't run in the browser seamlessly
#include <stdio.h>
#include <stdlib.h>
int main() {
char *s = "world";
s[0] = 'o';
s[1] = 'w';
s[2] = 'n';
s[3] = 'e';
s[4] = 'd';
printf("Hello, %s\n", s);
}The point of Wasm is - programs can and will malfunction (and some will be malicious), so we have to protect the environment that runs it.
That was definitely not my experience at that time using a linux desktop.
Everything _else_ was able to do this just fine, in particular it's main competition, Adobe flash. That was actually _almost_ a first class experience and I didn't need to track down and install "icedtea" to make it all work. It just worked out of the box.
The JVM promised "write once, run anywhere." You can blame me for that failure, if you like, but it was then and always was a flat lie. You simply choose to ignore this.
That said, GWT was ahead of its time in a lot of ways, but it had warts galore.
I actually enjoyed using them to get around a few browser limitations around the mid-to-late 00s, and they seemed feature/performance competitive with Flash unless what you were doing fit the media authoring model closely. But by then people were skeptical about Java and if you had to do anything to get it installed they wouldn't, and the direction was native web.
That web application is still in use, in production, today.
In a few cases there were JVM exploits that weren't based on that approach, almost always involving reflection or JIT compiler bugs.
The people saying WASM is easier to sandbox than the JVM are sort of half right and half wrong. The hard part of sandboxing is exposing safe APIs to the sandboxed code. WASM solves that by simply not exposing any APIs at all. This essentially punts the sandbox construction to the user and will allow WASM vendors to claim a good security track record, which they will get by not doing very much.
On the other hand, the OpenJDK guys are retreating from providing any sandbox at all and are taking it out of new Java versions. So you'll end up with mandatory exposed APIs that don't even try to be safe.
Neither approach is really all that great if what you want is the ability to run a useful set of normal-ish programs in a safe way. GraalVM has its own sandboxing features which look like a decent compromise, and you can still use process or VM sandboxing on top.
> It’s designed from the ground up to have an extremely simplistic model of execution that prevents common exploits like buffer overflows and such.
So is the JVM and CLR and dozens of prior runtimes for that matter.
WASM for guests is mostly a security regression as all the design focus was on protecting the host. Things in the runtime got thrown under the security bus (such as no ASLR)
> The JVM is not architected the same way, the VM has a bunch of APIs exposed to it and you have to attempt to constrain those down to make a program secure.
You're confusing concepts here. The JVM bytecode runtime has very few APIs and WASM has no inherent requirement on being minimal or capability-based. WASI, which is what's being used here, has neither of those design attributes, for example. It's just regular POSIX apis. No permission system + massive API surface, yet still WASM all the same
Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations.
Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either.
The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.
Not entirely true, but of course there has never been any official support. http://nestedvm.ibex.org/
You can compile c to wasm and run that.
In the same way one could compile c to java byte code, write a wrapper program to allocate the "heap", disable the gc and execute it in close to the same way it executes in a wasm runtime.
[1] https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an old dream that others have had before.
So, that means that the remake of an OS that we call a browser is likely to be the pinnacle of computing for our lifetimes.
Hopefully after the Great Reboot of 2038, the next generation will learn from our computing mistakes, but since we've never learned from those that came before us, it's highly unlikely. But at least they will have to start from scratch, so there's a chance!
At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-)
One of my favorite lunch breaks of all time.
I'd be very leery of trusting the specifics too much. E.g. the reference to "Roman war chariots", which are not a thing the Romans ever used.
Snopes entry: https://www.snopes.com/fact-check/railroad-gauge-chariots/
God, I had forgotten about those email FWDs. The old people I know totally abandoned email.
It can be run outside a browser, and is much more performant than using the whole browser. The future is very likely going to consolidate around WASM and WebGPU, regardless of what hardware you're targeting. If you want more performant specs, it will be driven through a public and consensus driven way... there are far too many economies of scale to standardization for it not to be.
The days of building an ecosystem around a closed, proprietary language/protocol/spec are over. The browser was just the first to bridge the gap... now we move on to WASM, and maybe 10 years from now something newer
Largest /s imaginable.
Your comment is pretty far into LARPing territory.
The innovation of "docker containers" as a total solution is more akin to a POSIX standard than the Go language. Containers only became popular because of Docker, not because of containers themselves. Docker is a solution to a dozen different problems. "A container" is really just a chroot in a unique namespace. Again, that's basically just one problem solved. The functional combination of all the features of container orchestration software and interoperability is where the actual value of containers lies. Not in the container, but in the 12 different problems that are now all solved in a universal way by all the different solutions that deal with containers in the same way.
If WASM can evolve an entire ecosystem and standard around all the problems needed to be solved to run software easier, then sure, it could be revolutionary. We'll see if that happens in a way that is easy to use. My bet is it won't happen.
WASM simply closes the performance gap between “widely accepted open standards” and native.
You seem confused… fewer and fewer people are writing software in OS locked apis/contexts. Back in the day it was much closer to 100%
Software development always goes in cycles. "Apps" were great now maybe not so much so...
In the late 80s/early 90s, the CEO of ETA Systems (a supercomputer company) had a vision that by 2000, the world would be split between supercomputers and workstations. I have seen some evidence that people are considerng that once again... The Circle of Dumb is always with us in software land.
Comparing WASM and JVM is like comparing a truck and a bus because they are relatively the same size, move at the same speed etc.
I mean sure you can load people in trucks and cargo into buses - and both have been done with JVM (eg. people built C compilers) and WASM (people are building GCed runtimes on top of it despite lack of GC support from platform).
Almost 30 years later nobody sane is running C on JVM and there were many attempts posted here over the years.
Similarly, many managed compiled languages don't depend on C.
Finally, cybersecurity legislation will speed those efforts.
All angel companies that do no evil.
You mean in a OCI image, a bit like this? - https://docs.docker.com/desktop/wasm/
and then deployed using Kubernetes? - a bit like this - https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...
Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode.
We're heading in circles in a lot of ways