I tried DreamWeaver a bit, but mostly stuck to HomeSite back then. BBEdit never managed to lure me in. And yeah, I think Sublime Text wasn't available when I switched to Vim from TextMate as well
[Presenter here] Not sure how it would be misleading when the region is clearly stated in respective slides and in the linked resources. Naturally it's interesting to talk both about global trends and more local ones (like in the US).
That said, for obvious reasons, most research is being done in the US. I'd love to see more surveys and studies target more markets and globally.
Well it's presented as a trends piece, and unless I read the fine print, it's not clear if I'm being presented with US trends or worldwide trends and that changes from slide to slide... Perhaps you made it abundantly clear in the video/in-person, but I think it's a valid point not to have to read the asterisk, and instead just expect things to be consistent.
Basically, the definition of tools is third party tools such as: ad networks, cloud computing, cross-platform (e.g. PhoneGap), games (Unity etc) and more.
It would be vice versa: developers who use third party tools (outlined in detail in the linked report) would make more money (according to the survey).
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.
Unfortunately not, it wasn't filmed. And I agree, slide decks need the presentation to go with them. With numbers, there's a lot up to you to draw conclusions.