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

141–150 of 156 posts

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

#141

Post by democracy »

asdkhadsj wrote: post #123
pjmlp wrote: post #117

Earlier quoted context omitted.

Yes, because WASM is basically politics due to the refusal of other browser vendors to adopt PNaCL, and it doesn't provide any security for memory bound and null pointer exploits inside the sandbox.

So where were JVM targets for all my favorite languages, or any browser support for that matter? I'm not going to debate any points against the JVM, but all I know is that I can compile languages I want to all browsers today . Why can't I do that for the JVM? Something must be a massive, gory failure of the JVM and/or the companies involved with the JVM for it to be an equal to that of WASM, and yet have zero tractio…

If only there was something else but web development...

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

#143

Post by tracker1 »

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

s/10\-25/20\-25/ Even then, WASM does a LOT of things right that Java absolutely failed. Namely: security.

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

#145

Post by mooman219 »

tracker1 wrote: post #144
ragerino wrote: post #54

Kind of funny. WebAesembly is basically like a pre-installed Java Browser Plugin.

Without all the bugs and security holes.

Everything was intended to be secure but no one writes perfectly secure code, same goes for WASM. Java exposed a lot of system access (files, devices, I/O) that you just don't have in WASM. In that aspect it's more secure, but it also does less. If you're going to include the browser APIs, you can argue they're just as insecure as Java given their less than stellar history.

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

#146

Post by tracker1 »

mooman219 wrote: post #145
tracker1 wrote: post #144

Earlier quoted context omitted.

Without all the bugs and security holes.

Everything was intended to be secure but no one writes perfectly secure code, same goes for WASM. Java exposed a lot of system access (files, devices, I/O) that you just don't have in WASM. In that aspect it's more secure, but it also does less. If you're going to include the browser APIs, you can argue they're just as insecure as Java given their less than stellar history.

Name any technology that loads and executed remote content with a better track record than browsers and JavaScript. At least anything with even 1% the capability.

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

#147

Post by manigandham »

moogly wrote: post #140
manigandham wrote: post #134

Earlier quoted context omitted.

Why not? Works fine in our tests, and a large part of .NET apps are internal apps that work great with this kind of framework. I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the serve…

I mean, sure, if you have tens of internal users maybe (but then it could be argued that it could just as well be deployed as a desktop app -- I could buy the deployment method as an argument, mind you). But thousands? Call me sceptical. It just makes me think of `asp:UpdatePanel` all over again.

Are you referring to the session state and websockets connections? Both scale horizontally with minimal effort, I don't see the problem.

Asp:UpdatePanel was great for it's time, and no different than doing an XHR request now and replacing the contents of a div with the response. You can still get basically the same effect with libraries like Turbolinks which is what Github does.

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

#148

Post by dmitriid »

BubRoss wrote: post #131
dmitriid wrote: post #105

Earlier quoted context omitted.

I didn’t say Mozilla, I said Google. I didn’t say iron fist, I said disproportionately affected.

And it isn't true, because Mozilla is very involved, and every browser engine will have to get on board.

First and foremost Chrome has to get onboard. Hardly anyone cares if Mozilla implements anything.

A few people will care if Safari does.

Edge is out if the picture and is being replaced by Chromium (aka Chrome).

On WebAssembly specifically. Here’s WebAssembly working group: https://www.w3.org/2000/09/dbwg/details?group=101196&order=o...

I count 18 people from Google, and only one from Mozilla. The second largest representation is from Microsoft (8 people), but their input is now Chrome/Chromium input.

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

#149

Post by afiori »

olliej wrote: post #2

It's kind of true -- it's designed with a recognition that computers are real things, and shouldn't be abstracted out in terms of a specific programming model. The JVM approach (somewhat by design) limits the easer of interaction with other systems. The biggest drawback in WASM to me has alway been the memory model. While it is memory safe, it's currently opaque to the host environment which means that the general im…

In the future wasm can add more memory flexibility, for now you can only use one big byte array but the standard can be extended to allow for many of them and for some dynamics or special host semantics. That was my impression in reading the standard, that a lot of restrictions are of the form "we still do not know the best way to standardize this". Like RISC-V 128 bit

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

#150

Post by afiori »

snazzycalynx wrote: post #52

I see nobody's mentioned that Kotlin can compile to WebAssembly (in addition to Java bytecode, native binaries and JS). Kotlin is a beautiful language and hopefully WebAssembly will help it to gain traction outside the Android world.

What Kotlin is now has no bearing on what JVM was then or even what JVM is now
Post reply on HN