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

21–30 of 156 posts

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

#21

Post by threeseed »

chubot wrote: post #9

This previous thread covers differences between the JVM and WebAssembly: 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 / et…

That last one is really stupid.

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.

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

#22

Post by olliej »

throwaway2048 wrote: post #18
olliej wrote: post #8

Earlier quoted context omitted.

The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.

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 the GPU, whereas the browsers worked on restricting WebGL to a super constrained subset (this was my fault, but is the correct thing to do :D )

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

#23

Post by dang »

tus87 wrote: post #20

If you want to pull the chain on this diarrhea: https://github.com/stevespringett/disable-webassembly

Please don't post name-calling dismissals of other people's work to HN. This is in the guidelines: https://news.ycombinator.com/newsguidelines.html.

The article you've linked to is much better than this and deserves a better representation than that.

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

#25

Post by quantummkv »

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 old things instead of trying to improve upon the existing systems.

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

#26

Post by kevingadd »

pjmlp wrote: post #17
olliej wrote: post #8

Earlier quoted context omitted.

The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.

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 regret letting type safety and other features slide.

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

#27

Post by neilv »

TimTheTinker wrote: post #11
olliej wrote: post #6

Earlier quoted context omitted.

1. is true 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…

I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s. 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.

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 appropriate UI for that type, on the fly, and integrate it into UI, and it would all be secure.

(I first saw Java when it was called Oak, and Sun had great people doing major things, Java only one of them. When Java applets first hit conventional Web browsers, most people thought they were for replacing animated GIFs, thanks to a demo program. I probably wrote some of the first Java desktop application code outside of Sun, partly to demonstrate that Java was a real applications development language. Well, the language was there, and in many ways a huge improvement over the C++ that most shrinkwrap and technical desktop application developers were moving to, though the library support took a while to catch up, and performance took longer.)

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

#29

Post by manigandham »

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…

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

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

#30

Post by chubot »

threeseed wrote: post #21
chubot wrote: post #9

This previous thread covers differences between the JVM and WebAssembly: 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 / et…

That last one is really stupid. 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.

That you don't have to rebuild such apps from scratch on WASM is exactly the point.

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.

Post reply on HN