When we first released Construct 2 no browsers had hardware acceleration and the games only worked on Chrome and Firefox. We had threads just like this one, but saying that HTML5 sucked for desktop browsers, go make a native engine or use Flash instead, etc. etc. I think by now it is obvious - as mentioned in this thread - that desktop browsers generally work excellently. I am totally convinced we cannot beat node-webkit for quality of desktop exporters. So I would like to assert that there is no need for a native engine on desktop (barring dumb decisions over hardware acceleration on XP and Vista which I hope they reverse). In fact I would go so far as to say that having written a native or Flash engine for desktops in the first place would have done a great deal to hold us back. Here are some of the technical problems raised by writing a native/different tech port:
- exact compatibility with a browser is probably impossible, without actually writing what amounts to a new browser engine. So inevitably there will be a list of features that are incomplete or simply not supported.
- exact compatibility with the features that are supported is very difficult. There are likely to be subtle bugs or variations in behavior that trip up games in obscure ways and make ports more difficult. All third party addons can probably be assumed to never be supported.
- the rate of improvements to the engine and editor would have been significantly slowed while we were bogged down by the technical debt of having to maintain multiple codebases in parallel. We probably could not have got to where we are today if we had taken on that extra work.
- the whole point of the exercise is to improve performance, but on GPU-bottlenecked games, the GPU is still the same, so making a native engine would still not actually improve performance at all in that case.
- eventually the work is redundant, because HTML5 on desktop is good enough, but we would be obliged to keep supporting the native ports since some users would by then depend on them.
In short we'd just trade one set of complaints for another: difficult to know which features work on which platforms, annoying random bugs when porting, things aren't progressing fast enough, etc. If you look at some other tools you can see they are definitely affected by those problems. I do think it's actually a good thing for users that we made this decision on desktop. And this may be a tough pill to swallow right now, but we're making the same decision on mobile, and I'm convinced it will pan out just as it did with desktop.
Mobile performance is already excellent on many devices: my Nexus 5 can get 20,000 sprites on-screen at 30 FPS - faster than many desktop systems. Crosswalk is effectively the node-webkit for Android, and matches that performance. Crosswalk will support IAP, ads and screen orientation lock within a few months - we're working with Intel on that, and it only first released recently as beta, so it was always going to take some extra time to sort out all the features everyone wants.
We often get complaints about mobile performance which are clearly limited by the GPU hardware, such as the fillrate. For example if 'Low quality' fullscreen mode improves your game's performance, the engine is doing identical work, except the GPU hardware has less work to do, so it's clearly hardware-limited and nothing would be gained with a native engine. In this case we usually have a tough time explaining that it's not a problem with Construct 2, you just designed your game in such a way as to exceed the hardware capabilities of the device. In these cases, a native engine would not be faster, because it uses the same GPU. For low end devices you have to be extremely careful, and a native engine won't stop you throwing more sprites at the GPU than it can handle.
So we could make a native engine, but it would have incomplete feature support, probably introduce obscure bugs when porting, slow down overall development at Scirra, not actually improve performance on GPU-bottlenecked games, and have ongoing technical debt even after HTML5 becomes excellent on mobile. There is no magic bullet that makes everything perfect, and a native port would just trade one set of problems for another, and I don't think they'd even be a "nicer" set of problems.
There are some cases where performance is a problem, particularly the Android stock browser and iOS native apps. These are often solvable with software updates. Just as with desktops being slow due to no hardware acceleration, subsequent software updates fixed that and now in many cases it's super fast. Chrome for Android is replacing the stock browser steadily, and future iOS updates could introduce features like WebGL and JIT for apps. There is a lot more going on in the tech world, all moving in that direction. So working on native ports could even become redundant fairly quickly. That's why we think it's best, even with our plans to expand the team this year, to stick to the HTML5 engine and work on other compelling and highly-demanded features like multiplayer. I know some of you won't like this choice, and we'll likely keep seeing threads like this for some time. But I would encourage you to spend more time thinking about where things are likely to be in the near future. Things are not standing still; they are literally changing month by month. If we didn't think HTML5 was an absolutely solid choice for the long-term prospects of our engine, we'd already be working on native ports.