Live data from Hacker News

Bringing Asm.js to Chakra and Microsoft Edge

blogs.windows.com

61–70 of 88 posts

Re: Bringing Asm.js to Chakra and Microsoft Edge

#61

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

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 constructs that C/C++ programs employ. Mapping them to instructions is a pretty straightforward job, but of course you are not getting 100% exact same results on every browser - just like you are probably not getting 100% exact same results from clang and GCC for the same C source code.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#62

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

I don't think it will be all that hard from a security standpoint. This means mostly fixing the major mess that has been security at the OS level and isn't changing any time soon.

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

#63

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

Some examples of non-standard extensions which have fallen by the wayside (or failed outright):

    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

#65

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

We already test every PR against Android with Rust, but you can't use any of the native toolkit stuff afaik, it's the same as if you used C.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#66
post #45

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

That doesn't make it not proprietary! It's open-source, sure, but it's not something easy for other browser vendors to implement and only has a single implementation.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#67
post #2

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

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.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#68
post #2

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

By native code do you mean assembly language? That would be very insecure and CPU-specific.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#69

Earlier 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…

It's more that I'd like browsers not doing an absurd amount of unnecessary work and overhead. Leaving aside opinions on JavaScript as a scripting language for humans, it's not a sensible intermediate format for compiled binaries. It happens to work as a (very impressive) hack.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#70

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

I'm not sure I understand the purpose of your comment. Google's optimizations can achieve asmjs-like performance outside the well-defined subset so it doesn't necessarily benefit Google. If compile-to-js language authors target the subset ubiquitously and exclusively it may actually hurt Google.
Post reply on HN