> ...you can't run Java code in a browser without a plugin...
> ...WASM, being memory safe and tuned for validation, also has security advantages over Java applets...
> ...explained the difference between WebAssembly and Java thus: "WebAssembly has been designed to scale from tiny devices to large server farms or CDNs...
> ..."That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link...
> ...But a write-once, run anywhere binary represents a worthwhile effort...
What's ironic is that the "tiny devices" and even "high end professional desktop workstation and server devices" that Java was originally designed to run on when it was started in 1990 were MUCH tinier than the devices considered "tiny" today.
How many more times faster is a typical smartphone today (Raspberry Pi 3: 2,451 MIPS, ARM Cortex A73: 71,120 MIPS) that a 1990 SparcStation 2 pizzabox (28.5 MIPS, $15,000-$27,000)?
I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel.
It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems.
I think it might have to do with people considering 40 as very old in Silicon Valley and those in their late 20s and early 30s have barely learned this lesson.
I hear that often in regard of programming languages. But I see a lot of value in remixing a lot of existing ideas in a new package. A wheel can only be so round and its interaction with the road is quite simple, but tech is different. Systems have widely different requirements. Old implementations have shortcomings and a hard time fixing those, especially due to backwards compatibility of complex systems. I cannot imagine how hard is to remove null from an existing programming language, as C# is currently trying. At some point it's just easier to start from a clean slate.
Is all the effort worth it? I don't know. But I wouldn't want to imply they are just doing it because their out of touch with reality.
2. Yeah, I read that and was super confused. Literally that was one of the main point of the Java language itself, enforced by the JVM itself.
3. I think this is more a matter of expected level of abstraction, but I agree this is fairly weak.
4. This just seems like standard "the new thing is vastly superior to the old thing", with a valid touch of "the JVM is too heavily abstracted from how computers work"
5. Yeah, this was also weird.
Java was the solution that would provide a robust, symmetric (server+client), secure, highly capable, and portable platform for complex web applications.
Early Java folk weep because Java failed so badly on the client, and something else is stepping in to do what Java could not.
Are you saying that we could stick a JVM in the browser and ship Java applets around to be progressively/streaming loaded and executed in browser?
I don't know much about the JVM but it seems the goal of WASM and the JVM were quite different, no? And yes, WASI has overlap with JVM, but if WASM catches on and people like it, how does WASI make any less sense?
Are you advocating we have WASM and JVM but no WASI? Is that better? Not sure why anyone is crying here..
More or less. I mean, that used to be a thing you know.
> the goal of WASM and the JVM were quite different
WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems
JVM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems
That is more penetration than Java could ever get on Desktop and Mobile.
Although Java is actually doing ok in embedded space, I am not entirely sure how WASM would work for that segment.
Java is the most used programming language in the world (https://www.tiobe.com/tiobe-index/)
It not only powers all kinds of desktop things, it is foundational to Android, which currently powers ~85% of all mobile devices.
How can you get more penetration than "most used programming language" and "foundational to the largest mobile OS"? I mean there isn't even a category that fully encompasses the degree of dominance of Java. The next step, I assume, would be to rename "Programming" (all of it) to "Java".
Good one.
>> Mozilla this week announced a project called WASI (WebAssembly System Interface) to standardize how WebAssembly code interacts with operating systems.
This is just another implementation of holes that allow web sites access to the rest of your system. It really is supposed to be the operating systems job to manage resources and what can be accessed. The problem is this functionality keeps getting re-implemented by others with different agendas.
Well, unlike systems designed in the 90s, it's designed for the modern "everything-is-a-threat" mindset rather than the optimism of the 90s that everything would be safe.
People have been experimenting with "WASM outside the browser" for a while now, and WASI is just an API for making OS calls that a runtime can implement.
Edit: words
Has it, though? What we have now is an MVP, and easily 90% of the features aren’t there yet.
When WASM gets garbage collection, will it still be able to run on tiny devices? We don’t know yet.
This provides substantial differentiation from .Net/Java/Flash/etc.
That said, this advantage risks diminishing if Google's influence continues to grow.
It’s disproportionally affected by Google.
The biggest drawback in WASM to me has alway been the memory model. While it is memory safe, it's currently opaque to the host environment which means that the general implementation is to over allocate address space and essentially implement pointers as integers. That results in pointers that can't be trivially shared between environments.
That said, I think that if I /were/ to be making an app that had plugins, or an OS from scratch, etc I would define an interface via WASM. Screw loading unbound untrusted code into my process. My code is 100% bug free, I don't want to other people to break it.
This is not remotely true :D
* I am biased here.
IMHO, the success of these products has very little to do with how good they might be technically. It's all about sales and marketing and, eventually, politics. Perhaps that's where the motivation to re-write recent history is coming from.
Not in this case. Java failed because it sucked from a technical point of view. It traded better 'OO purity' in exchange for worse security, portability and performance.
The end result is that users got something that was slower and buggier for no gain.
While it's clear that Javascript has been successful in the "run code in a web page" sense, it's primary deployment target remains the web browser; even when it's marketed as a cross-platform solution it's often targeting something like Electron.
WebAssembly has its work cut out for it trying to succeed in both of these spaces. I think the project might enhance it's chances for success by remembering Java and its browser plugin rather than pretending they are the first.
Do people think WASM is not better than the JVM for streaming browser based usage? Did it learn nothing from the JVM? The sarcasm in these threads always confuses me.
The worst thing that can happen is that in 10-15 years from now nobody remembers the WASM fling, and all these man hours go to waste.
Be _the_ language (Java)
Be _the_ platform (JVM)
Wasm is a compilation target, it's better to compare it to the JVM than Java. The thing that has me excited is that _every_ language will be write once run everywhere not just some new and unproven language (like Java was at the time).
All the tools were there.
WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.
https://news.ycombinator.com/item?id=19502702
tl;dr
- JVM doesn't do enough to separate computation and I/O
- JVM doesn't run C code very well, or it requires research-level technology to do so (Graal). This applies to both computation and I/O -- it has a completely different I/O interface than C programs rely on.
- Photoshop / Word / Excel / etc. were never ported to the JVM. The browser actually has better equivalents of them.
The reason they weren't ported is because they were legacy codebases with some code going back to the original versions including lots of assembler. It was always going to be a monumental task to rebuild them from scratch.
You can compile legacy codebases in C and C++ to WASM. It was designed for that. Doing that on the JVM requires "research-level" techniques because the bytecode has a completely different design.
Kotlin is a beautiful language and hopefully WebAssembly will help it to gain traction outside the Android world.
The article you've linked to is much better than this and deserves a better representation than that.
> To be fair, many of the threats above also apply to Javascript
It was poorly suited for the browser from the earliest days, and even now the language and runtime have evolved to make it a round peg for that square hole no matter how WASM develops.
Yet because students and younger webdevs see it through the prism of trying to be a browser-side solution, it taints the brand for people who lack business application experience. Java is thought of as "insecure", even though the OVERWHELMING majority of security patches are for the browser applet plugin, which hasn't been widely used in twenty years and now being retired. Instead of being "a thing that makes large-scale business server applications more performant, and more tenable for large teams to work on", it is often seen by newbies as "a failed React.js alternative" where it comes up short.
Actual Java developers stopped thinking of it that way decades ago, but the history unfortunately persists.
