This doesn't really say much about sectors, though. Sure, lots of people are creating apps that are HTML5 wrappers, but what do these apps actually do? Are they just wrappers around websites? Do they preform any serious functions?
Obviously, 95% of graphics- or CPU-intensive apps (eg. games, graphics utilities) are going to be native, but this isn't implied in the slide deck -- indeed it almost suggests (somewhat disingenuously) that the "trend" toward non-native includes games, which is silly.
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-an...
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.
Comments
This doesn't really say much about sectors, though. Sure, lots of people are creating apps that are HTML5 wrappers, but what do these apps actually do? Are they just wrappers around websites? Do they preform any serious functions?
Obviously, 95% of graphics- or CPU-intensive apps (eg. games, graphics utilities) are going to be native, but this isn't implied in the slide deck -- indeed it almost suggests (somewhat disingenuously) that the "trend" toward non-native includes games, which is silly.
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-an...
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.
In general, for what asm,js covers, and what it doesn't, it's probably best to look at 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-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-improve...