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

81–90 of 156 posts

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

#81

Post by DebtDeflation »

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…

Who is downvoting this?

>Peak UX usability was native UIs in the 1990s and early 2000s

So much this. Give me Win2K and Office2K style applications - multiple tiled or overlapping windows, modeless views, regular menus and toolbars, context sensitive right click menus, etc. over this single pane with a hamburger button and search box crap any day of the week.

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

#82

Post by redbergy »

phkahler wrote: post #72
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-impl…

I thought the point of WASI was to give you an API that allows you to bring your WebAssembly apps out of the browser and run on the OS itself, not to allow deeper integration of the app in a browser to the underlying OS.

Edit: words

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

#83

Post by ashleyn »

dmitriid wrote: post #70
e1ven wrote: post #32

Regardless of any technical merit or reasoning, one big advantage is that Javascript/WASM is not controlled by any one large company or organization. This provides substantial differentiation from .Net/Java/Flash/etc. That said, this advantage risks diminishing if Google's influence continues to grow.

> Javascript/WASM is not controlled by any one large company or organization It’s disproportionally affected by Google.

Exactly, did we ever move beyond monoliths dominating a standard or did they simply evolve to calling something "open" while exerting disproportionate influence on the standards body?

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

#84

Post by moogly »

manigandham wrote: post #29
quantummkv wrote: post #25

Earlier quoted context omitted.

I am not surprised. As someone who cut his programming teeth on Java and .Net, modern web development feels really out of touch with reality. 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 o…

.NET ecosystem is fantastic right now. .NET Core is fast and efficient, asp.net is better, faster and more full-featured than ever, and MS is ahead of everyone with Blazor Components that finally provide a real alternative to JS frontend frameworks and can run either server-side or as WASM modules.

IMO, server-side Blazor is a non-starter, basically just a proof-of-concept to get something up and running before the WASM version is usable, but definitely not something I would use in production.

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

#85

Post by that_jojo »

asdkhadsj wrote: post #75
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…

> Are you saying that we could stick a JVM in the browser

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

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

#86

Post by Faark »

quantummkv wrote: post #25
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 am not surprised. As someone who cut his programming teeth on Java and .Net, modern web development feels really out of touch with reality. 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 o…

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

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

#87

Post by ktta »

IshKebab wrote: post #66
steve19 wrote: post #49

Earlier quoted context omitted.

Forget full computers, an official Java subset even runs on every GSM SIM card. It is incredible! https://en.m.wikipedia.org/wiki/Java_Card

People keep bringing this up but Java Card is a really small subset of Java so you can't draw any conclusions. In particular it has no garbage collection, which is easily the heaviest part of Java. > Many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Fur…

To add on, here's a quick intro to the headache that goes into writing Java for GSM cards - https://youtu.be/31D94QOo2gY?t=607

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

#88

Post by that_jojo »

TimTheTinker wrote: post #73
0815test wrote: post #51

Earlier quoted context omitted.

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

Thanks for teaching me something totally unrelated on accident today. I was under the impression that all of the post-clamshell iBooks were OSX-only and had to check everymac. Now I'm slightly wiser on a topic that no one gives a shit about.

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

#89

Post by vorpalhex »

dmitriid wrote: post #70
e1ven wrote: post #32

Regardless of any technical merit or reasoning, one big advantage is that Javascript/WASM is not controlled by any one large company or organization. This provides substantial differentiation from .Net/Java/Flash/etc. That said, this advantage risks diminishing if Google's influence continues to grow.

> Javascript/WASM is not controlled by any one large company or organization It’s disproportionally affected by Google.

Given that Mozilla has done tons of WASM work, and that one of the earliest implementors was Rust, comparing WASM to Oracle's iron fist over the JVM doesn't seem to jive with reality...

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

#90

Post by majewsky »

ksec wrote: post #46
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…

The only difference is that WASM will be available ( I assume ) in most PC Chrome Browser within 2 - 3 years of releasing, that is 800M+ assuming Chrome with stable market shares. Along with Android, that is a potential of 2-3B devices, assuming stable upgrade cycle and shipment. 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 ent…

> Android [...] assuming stable upgrade cycle and shipment

Good one.

Post reply on HN