6 ms·

The slide deck touches on sectors, in the sense of Consumer, Professionals and Enterprise (but no what's games etc). It would be interesting to have numbers for

by rnyman 12y ago

The slide deck touches on sectors, in the sense of Consumer, Professionals and Enterprise (but no what's games etc). It would be interesting to have numbers for, say, number of how many apps are made through PhoneGap and what they do. With games, though, there's is a strong evolution in the direction of other alternatives than native: through asm.js, Unity engine and more: https://blog.mozilla.org/blog/2014/03/18/gdc-2014-mozilla-and-partners-prove-the-web-is-the-platform-for-gaming/ https://blog.mozilla.org/blog/2014/03/18/gdc-2014-mozilla-an...

empressplay 12y ago
This depends on how you define "native" -- asm.js code is run-time compiled to assembler (I'm assuming that's where the name comes from) so is running "natively", as if you shipped your C++ application with the source code and a compiler, and compiled and ran it when the user opened the app. The Unity engine has 98% of its hardware-intensive functionality compiled natively on the device, with only a small percentage of the remainder being interpreted code. Once again, it's hard not to call such an app "native" since there's no interpreter layer between the instructions and the bare metal of the device. I worry that by suggesting these examples are "non-native" you're placing them on the same bar as HTML5 / JavaScript which is largely interpreted. I think a distinction needs to be made between languages/engines whose code is largely native and / or compiled at runtime, and languages / engines whose code is largely interpreted while running. There's huge performance implications between these two categories.
- rnyman 12y ago
  In general, for what asm,js covers, and what it doesn't, it's probably best to look at http://asmjs.org/faq.html http://asmjs.org/faq.html With Unity and the Epic Unreal Engine, the goal is to be able to build games that will be able to run anywhere in a web/WebGL context: https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/ https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlockin... I believe it's also about finding ways to make interpreted code much more optimized as well. We also fairly recently had a blog post about asm.js and where it's going: https://hacks.mozilla.org/2014/05/asm-js-performance-improvements-in-the-latest-version-of-firefox-make-games-fly/ https://hacks.mozilla.org/2014/05/asm-js-performance-improve...

by rnyman 12y ago

empressplay 12y ago

This depends on how you define "native" -- asm.js code is run-time compiled to assembler (I'm assuming that's where the name comes from) so is running "natively", as if you shipped your C++ application with the source code and a compiler, and compiled and ran it when the user opened the app. The Unity engine has 98% of its hardware-intensive functionality compiled natively on the device, with only a small percentage of the remainder being interpreted code. Once again, it's hard not to call such an app "native" since there's no interpreter layer between the instructions and the bare metal of the device. I worry that by suggesting these examples are "non-native" you're placing them on the same bar as HTML5 / JavaScript which is largely interpreted. I think a distinction needs to be made between languages/engines whose code is largely native and / or compiled at runtime, and languages / engines whose code is largely interpreted while running. There's huge performance implications between these two categories.

rnyman 12y ago
In general, for what asm,js covers, and what it doesn't, it's probably best to look at http://asmjs.org/faq.html http://asmjs.org/faq.html With Unity and the Epic Unreal Engine, the goal is to be able to build games that will be able to run anywhere in a web/WebGL context: https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/ https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlockin... I believe it's also about finding ways to make interpreted code much more optimized as well. We also fairly recently had a blog post about asm.js and where it's going: https://hacks.mozilla.org/2014/05/asm-js-performance-improvements-in-the-latest-version-of-firefox-make-games-fly/ https://hacks.mozilla.org/2014/05/asm-js-performance-improve...