Live data from Hacker News

InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

innative.dev

91–96 of 96 posts

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#91
post #89
post #86

Earlier quoted context omitted.

Usually being hyped by people that apparently don't know the history of bytecode formats since the early 60's.

I'm well aware of the history of bytecode formats, Java was pretty successful for a while, even managed to get in the Browser and only failed there due to a lack of a DOM Interaction story and similar integration problems. There is already plenty of companies that deployed WASM on their stack (like Ebay, they use Wasm for their barcode scanner), it's not going away any time soon.

What lacking of DOM interaction story?!

https://docs.oracle.com/javase/tutorial/deployment/applet/ma...

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#92
post #91
post #89

Earlier quoted context omitted.

I'm well aware of the history of bytecode formats, Java was pretty successful for a while, even managed to get in the Browser and only failed there due to a lack of a DOM Interaction story and similar integration problems. There is already plenty of companies that deployed WASM on their stack (like Ebay, they use Wasm for their barcode scanner), it's not going away any time soon.

What lacking of DOM interaction story?! https://docs.oracle.com/javase/tutorial/deployment/applet/ma...

The CDAPI barely worked when it was released. It worked but poorly to the point that the Java Devs would have better not bothered at all. It's such a poor story for DOM Interaction that it effectively does not exist. Everyone prefered to use some UI library to render UI themselves.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#93
post #87

Earlier quoted context omitted.

LLVM IR is not architecture-independent. It encodes architecture and ABI assumptions, and is not portable. Also, this is not "JITed bytecode", it is compiled AOT.

The PNaCL and Apple's variants are architecture independent.

Well. They pick an architecture and stick with it, more like. But one is dead in favour of WebAssembly and the other is an internal format.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#94
post #87

Earlier quoted context omitted.

The PNaCL and Apple's variants are architecture independent.

Well. They pick an architecture and stick with it, more like. But one is dead in favour of WebAssembly and the other is an internal format.

It doesn't change the fact that they do exist.

PNaCL died in favour of WebAssembly due to politics.

With Chrome today's might, the decision would most likely be a different one.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#95
post #88

Earlier quoted context omitted.

Oracle could have easily done as Google has done with Android, and make sure that the client end wouldn't run without some kind of proprietary extension[a]. They are the world leaders in deploying the Ask toolbar, and with that comes the end users. It is only because we aren't using Java that we don't see this happening. a] Yes you can make android apps run on AOSP, but as many comment with regards to Huawei losing t…

I never had Ask Toolbar on my computer, why would you ask? 1 - I always read what I get proposed to install and disable what I don't care about. 2 - The JDK didn't had such "feature", only the consumer JRE

Yeah I know, it was in jest, as a reminder as to the practices of Oracle. Also most consumers do use the JRE, and the size of the audience is what Oracle would make decisions on.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#96

Isn’t it also using 32 bit pointers on 64 bit machines? That should also improve performance a bit. It’s a shame that the x32 ABI is almost abandoned nowadays, it has some modest improvements for applications that don’t need that much memory.

why u bully me? ily and ur game diep.io
Post reply on HN