Isn't most of the work done already with LLVM intermediate representation? Stick to POSIX (and Qt if necessary) in the code, distribute the IR with a compiler which compiles and installs it, and job done.
Mozilla announces WebAssembly System Interface, what JVM should have been
41–50 of 156 posts
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#42Isn't most of the work done already with LLVM intermediate representation? Stick to POSIX (and Qt if necessary) in the code, distribute the IR with a compiler which compiles and installs it, and job done.
There's no such thing as a single LLVM IR. It's actually a family of IR's where the actual representation is always dependent on target architecture.
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#43Earlier quoted context omitted.
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.
Sorry, which point were you referring to? (I recognize the article as bad, I'm just not sure which problem you're referring to :D )
I think the article author knows exactly what they're doing. "Write once, run anywhere" was literally Java's strapline.
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#44Is there a link to the WASI spec?
[deleted]
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#45No 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…
MS and Oracle claimed copyrightability of APIs. Think about that. It surely didn't help accepting .NET and Java as worthwhile universal tools. Too bad for them. Good thing WASM avoided this pitfall.
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#46No 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 entirely sure how WASM would work for that segment.
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#47No 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…
>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.
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#48Earlier quoted context omitted.
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 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 mouse cursor, os starting to swap, and then some irregular annoying hangs while the GC did its thing. Not to mention how ugly awt and swing looked even back then.
Modern web is a joke regarding resource usage and complexity etc., but java was a shitshow in practice, except on beefy servers.
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#49No 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..." 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 MIP…
Forget full computers, an official Java subset even runs on every GSM SIM card. It is incredible!
Re: Mozilla announces WebAssembly System Interface, what JVM should have been
#50Earlier quoted context omitted.
.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.
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.