Live data from Hacker News

Bringing Asm.js to Chakra and Microsoft Edge

blogs.windows.com

31–40 of 88 posts

Re: Bringing Asm.js to Chakra and Microsoft Edge

#31
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.

The choice isn't between "support HTML/CSS/JS" and "don't support HTML/CSS/JS". No Web browser can drop backwards compatibility. We haven't even been able to get rid of backwards compatibility for much worse things than CSS, such as , because sites you need to use (such as Hacker News) won't update their markup to use CSS for layout.

asm.js is attractive because it is a small extension to the Web platform, so the overall additional complexity of an HTML/CSS/JS engine (which we are likely never going to be able to drop) doesn't go up much by implementing asm.js optimizations.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#32

Earlier quoted context omitted.

Speaking of which, wasn't Microsoft supposed to add WebRTC/ORTC support in its new browser, too? I don't think I've heard anything about it in the recent official announcements other than last year's rumors.

WebAudio is in, and WebRTC/RTC seems to be in development: http://dev.modern.ie/platform/status/

WebRTC was in development even for IE (and it requires Opus), but Opus was never enabled for the audio tag. I don't see Opus mentioned anywhere in that list (while WAV is).

Re: Bringing Asm.js to Chakra and Microsoft Edge

#33

Earlier quoted context omitted.

I think I see what you are saying, but your statements aren't completely right which might be why you are being downvoted. "asm.js represents LLVM bytecode" is not right, just because you can compile one thing to another does not mean it represents it. You make a good point though; it's not like we are seeing helpful warnings when writing our frontend JS apps. But those warnings are still crucial when actually buildi…

I see, you were not talking about errors, but about predictability of performance. I see it now in your comment, too. Sorry for the misunderstanding. And I didn't know it was just derived from it; I thought asm.js was idempotent with llvm ir!

> And I didn't know it was just derived from it; I thought asm.js was idempotent with llvm ir!

LLVM IR is SSA and strongly typed, while asm.js is non-SSA and only has a simple, machine-level type system, just to name two large differences.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#34

Earlier quoted context omitted.

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.

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.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#35
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.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#37

Earlier quoted context omitted.

Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code, at least for WebGL, the performance behaviour on Chrome between WebGL and Pepper's GL wrapper is basically identical, and most other exposed API features are so similar to their HTML5 counterparts that it is almost certain that there's the same code underneath.

> Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code It's still wasted effort, though. Maybe they share some code, but Pepper is an unnecessary extra API. One that's non-standard and results in vendor lock-in.

Do you think Google could be persuaded to contribute PNaCL as an open standard?

Re: Bringing Asm.js to Chakra and Microsoft Edge

#38
post #37

Earlier quoted context omitted.

> Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code It's still wasted effort, though. Maybe they share some code, but Pepper is an unnecessary extra API. One that's non-standard and results in vendor lock-in.

Do you think Google could be persuaded to contribute PNaCL as an open standard?

Judging from their FAQ [0] on it, it doesn't seem like they are generally opposed to the idea, just see it as premature at this time.

[0] https://developer.chrome.com/native-client/faq

Re: Bringing Asm.js to Chakra and Microsoft Edge

#39
post #37

Earlier quoted context omitted.

> Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code It's still wasted effort, though. Maybe they share some code, but Pepper is an unnecessary extra API. One that's non-standard and results in vendor lock-in.

Do you think Google could be persuaded to contribute PNaCL as an open standard?

There were beginnings of talks to get cross-vendor consensus on Pepper (which would be a prerequisite to any standardization attempt of PNaCl) in 2010: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

The general consensus among non-Google browser vendors was that just using the existing browser APIs was a more desirable approach than Pepper. Since then, Pepper has remained a Chrome-specific technology.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#40
post #5

Earlier quoted context omitted.

Why? asm.js is a hack relative to NaCL.

In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ ). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only…

If I want to implement NaCL execution, I only need to support a (sane) bytecode and a reasonable "syscall" surface (pepper -- and only if I want to support pepper. I may not want to for things like server-side sandboxing).

I can AOT compile a complete binary, and can run on (just about) any target.

If I want to implement asm.js, I have to implement a full JavaScript JIT (if I want decent performance). This is Hard. I can't AOT compile, by the nature of JavaScript.

So, no, there is a difference. One of these technologies brings the entire bloated browser technology stack along with it, and one finally cleans up that bloat.

Post reply on HN