Earlier quoted context omitted.
Asm.js has several benefits over NaCl. It's readily compatible with just about every browser in the market, and manufacturers just need to add some asm.js-specific optimizations to their JS runtime to fully unleash its execution power (but Chrome too already runs asm.js code very fast with just its generic JIT optimisations). Secondly, it's based on a self-contained open source spec that constitutes a logical subset…
As mentioned in my previous comment, NaCl and Pepper are not the same thing. Browsers could support NaCl without committing to support Pepper. > Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted I'm going to have to stop right there. asm.js is a lot of things, but "not convoluted" is certainly not one of them.…
Bringing Asm.js to Chakra and Microsoft Edge
61–70 of 88 posts
Re: Bringing Asm.js to Chakra and Microsoft Edge
#62Earlier quoted context omitted.
On the other hand, for the first time in history, you have true "write once run everywhere". I can take my native C/C++ GL demos that normally run on the desktop, compile them to asm.js, distribute them via a simple URL, and users just click on a link and run the demo on every OS. No download and installation, no browser warnings about dangerous executables, no virus scanner scare popups. Compare this with iOS, where…
Sounds like the sandbox-escaping game is going to get pretty intense in the coming years.
We're not supposed to be giving any application all power they want. We just want to let them use the GPU and take inputs on focus, and if they misbehave we kill them. If they need anything else, they'll have to ask the user. It took Microsoft what, two decades? to realize this. And it's only sightly better now. The mobile OSes were the first to grasp this but it's still imperfect.
Java almost got there but I believe it lost traction because of UI, lack of clear leadership and being tied to a language.
We're going to have to go with browsers because although it's a big pile of hacks they are finally realizing the obvious (in hindsight) way we should develop most applications. I have no doubt it will continue to catch on.
Re: Bringing Asm.js to Chakra and Microsoft Edge
#63Earlier quoted context omitted.
Meanwhile, platforms that don't even try to wedge their technology into the HTML/CSS/JS universe have better applications.
We're talking about Web browsers. Technologies that try to integrate into Web browsers specifically but don't have a good compatibility story with the platform haven't had a lot of success.
ActiveX
Java Applets
Flash
Silverlight
VBScript (and other non-JS scripting langs)
NaCL
Dart (via a native VM)Re: Bringing Asm.js to Chakra and Microsoft Edge
#64Re: Bringing Asm.js to Chakra and Microsoft Edge
#65Earlier quoted context omitted.
I would really love to see Native Client on Android as alternative to the dreaded Android NDK, and I really don't understand why this hasn't already happened, it's so incredibly obvious. Just give us the ability to deploy and run a PNaCl executable directly as normal Android application, and without all the Java and JNI shenanigans. The Pepper API has a lot more to offer than what's exposed through the NDK headers, a…
Yeah, I'd like to see that, too. It might make supporting Go on Android easier, too. Even Rust could probably be used then for Android apps.
Re: Bringing Asm.js to Chakra and Microsoft Edge
#66Earlier quoted context omitted.
There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?). Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not u…
Pepper is not proprietary, it's completely open source.
Re: Bringing Asm.js to Chakra and Microsoft Edge
#67Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....
Google has done a number of optimizations that enhance asm.js performance while not specifically targeting asm.js. This results in real time performance that sometimes beats Firefox, which has asm.js built in. While I would like to see more effort to the areas of asm.js that are slow, I can't discount the Chrome/v8 team's approach.
Re: Bringing Asm.js to Chakra and Microsoft Edge
#68Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....
I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.
Re: Bringing Asm.js to Chakra and Microsoft Edge
#69Earlier quoted context omitted.
As mentioned in my previous comment, NaCl and Pepper are not the same thing. Browsers could support NaCl without committing to support Pepper. > Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted I'm going to have to stop right there. asm.js is a lot of things, but "not convoluted" is certainly not one of them.…
The level of "convoluted" depends on which level you want to look at. The asm.js spec is dead-simple, almost purely "mathematical" if you like. But if you require that whatever GCC/clang would have outputted for a specific C file is the exact same binary code that gets executed in the browser, then yes - you are not getting that. But then again, asm.js just - on a high level - specifies the primitive low-level constr…
Re: Bringing Asm.js to Chakra and Microsoft Edge
#70Earlier quoted context omitted.
Google has done a number of optimizations that enhance asm.js performance while not specifically targeting asm.js. This results in real time performance that sometimes beats Firefox, which has asm.js built in. While I would like to see more effort to the areas of asm.js that are slow, I can't discount the Chrome/v8 team's approach.
But the Chrome/V8 teams is still benefiting from the existence of asm.js, because the subset of JS that people can use and expect good performance from is now well-defined. Prior to asm.js this kind of certainty wasn't available for either JS engine developers or JS authors.