Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla announces WebAssembly System Interface, what JVM should have been

theregister.co.uk

Post reply on HN
Print view View original

71–80 of 156 posts

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#71

Post by asdkhadsj »

dmitriid wrote: post #68
neilv wrote: post #4

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article: > ...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…

> WebAssembly has been designed to scale from tiny devices to large server farms or CDNs 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.

I would hope it's opt in for those scenarios. If the host is too "tiny" to carry around GCs, then a whole host of languages are not viable anyway. Requiring a GC wouldn't do them any favors.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#72

Post by phkahler »

neilv wrote: post #4

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article: > ...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…

From TFA:

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

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#73

Post by TimTheTinker »

0815test wrote: post #51
iforgotpassword wrote: post #48

Earlier quoted context omitted.

You mention it in your last sentence, but most of these tales forget to mention it at all: java was slow. I mean, slooooooooooooooow. And that reputation stuck for much longer than it was actually true. Java applets were an abomination and you wanted to repeatedly stab yourself in the head while using even a simple one. On a then-average p166 with 24mb of ram, your browser would go unresponsive while loading, jumpy m…

> On a then-average p166 with 24mb of ram, your browser would go unresponsive while loading, jumpy mouse cursor, os starting to swap, and then some irregular annoying hangs while the GC did its thing. Reminds me of client-side JS frameworks. Or Electron apps. > Not to mention how ugly awt and swing looked even back then. Web UI is still as ugly as ever, of course. Peak UX usability was native UIs in the 1990s and ear…

> Reminds me of client-side JS frameworks. Or Electron apps.

Even big framework web apps on a core 2 duo running old Firefox, that is nowhere as bad as early Java trying to run something as a web applet.

I remember staring at that crazy Java applet load spinner and hating Java, and this was already in the early 2000s (on the first white iBook running Mac OS 9). It would have been much worse 7 years earlier.

It was really just the JVM’s startup time and the clunky AWT-based UI that made Java lose on web clients. Flash easily dethroned Java there because it started almost instantaneously and could do fancy animations (recall dial-up speeds meant video wasn’t an option).

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#74

Post by dmitriid »

asdkhadsj wrote: post #71
dmitriid wrote: post #68

Earlier quoted context omitted.

> WebAssembly has been designed to scale from tiny devices to large server farms or CDNs 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.

I would hope it's opt in for those scenarios. If the host is too "tiny" to carry around GCs, then a whole host of languages are not viable anyway. Requiring a GC wouldn't do them any favors.

Hard to say without reading all the specs/proposals: https://webassembly.org/docs/future-features/

But yeah, even specification itself is WIP

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#75

Post by asdkhadsj »

neilv wrote: post #4

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article: > ...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…

I'm so often confused by these comments.

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

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#76

Post by asdkhadsj »

manigandham wrote: post #28

I wonder what new standard we'll come up with 10-15 years from now that'll be titled "What WASM should have been".

Isn't that what the goal of software should be? Solving problems with older implementations?

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.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#78

Post by fluffything »

manigandham wrote: post #28

I wonder what new standard we'll come up with 10-15 years from now that'll be titled "What WASM should have been".

That would be a good thing for those working on WASM, their work would have had an impact.

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.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#79

Post by wongarsu »

avian wrote: post #58
ksec wrote: post #47

Earlier quoted context omitted.

>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 Silic…

I often wonder why this is the fact in software development and not nearly much so in other fields. Isn't the point of education that each generation doesn't have to learn past mistakes by repeating them? Do computer science curricula not include enough historical perspective? I feel like other fields of engineering don't have such a dismissive approach to their own pasts. Show an electrical engineering class an old…

I wonder the same thing. I suspect the age of the field plays a role. While theoretical computer science is about 200 years old practical computers only exist for 70 years and are widespread for about 40 years. Many professors teaching computer science today couldn't study computer science back in their days because it simply wasn't offered.

This has wide reaching effects, one of the more obvious ones being that 20 year old knowledge seems ancient to most.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#80

Post by jcranmer »

olliej wrote: post #22
throwaway2048 wrote: post #18

Earlier quoted context omitted.

Web browsers also have all those things.

Yup, and work super aggressively to restrict it -- back when the JVM was supported, a large amount of the browser sandbox had to be extended to support the arbitrary behavior of the JVM, subsequently moving it out of process still required providing unrestricted access to OS components that you would rather they didn't. At a very basic level it can be summed up with: the JVM approach to GLSL was to just throw it at t…

By the time browsers were considering out-of-process plugins, the JVM was already thoroughly eclipsed by Flash. I think Flash's general brokenness (over half my browser crashes/hangs were caused by Flash) was the main motivation for out-of-process, not JVM's hugely broken sandbox.
Post reply on HN