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

51–60 of 156 posts

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

#51

Post by 0815test »

iforgotpassword wrote: post #48
neilv wrote: post #27

Earlier quoted context omitted.

Thank you for clarifying that. Also, one thing less-known than that Java applets were in the popular Web browsers at one point (when JavaScript was said to be just a glue language to invoke the Java applet), was that Sun already had a richer, Java-centric Web browser, which used Java for content-type handlers. Imagine providing content as data of some type/format, and the browser would automatically download an appro…

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 early 2000s, after that it was nothing but steady decline.

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

#53

Post by sdfsdfsdfsdf3 »

thefounder wrote: post #38
nwah1 wrote: post #35

Earlier quoted context omitted.

I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

With 5g that won't be an issue anymore...

In 2026 maybe...

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

#55

Post by quantummkv »

thefounder wrote: post #38
nwah1 wrote: post #35

Earlier quoted context omitted.

I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

With 5g that won't be an issue anymore...

Until they decide that 5g is good enough to allow them to ship the browser with every website. Net speeds have been increasing every year and yet the websites take longer to load.

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

#56

Post by TomMarius »

kevingadd wrote: post #26
pjmlp wrote: post #17

Earlier quoted context omitted.

Actually only when one did not bothered to spend any effort with Security Managers, Classloaders separation and JAAS. All the tools were there. WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regr…

Using the WASM GC part instead of lieanr memory will solve that, right? I know it's not a possibility for all programs, but overall, it'll help?

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

#57

Post by namelosw »

davidhyde wrote: post #50
nwah1 wrote: post #35

Earlier quoted context omitted.

I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

> “30 kilobytes for React” This is just not even close to being true.

There's 3kb Preact with almost identical API.

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

#58

Post by avian »

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

>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 analog instrument and there's generally wonder and curiosity. Show a computer science class a slide with a 1 MB hard drive compared to an 1TB SD card and there's generally ridicule and laughter. "Look how stupid they've been", not "we've learned many valuable lessons since".

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

#59

Post by StevePerkins »

Speaking as someone who has made their career with Java, "what the JVM ought to have been" is marketed for server-side use from the beginning.

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.

Post reply on HN