Back when we were just getting started - the first "public preview" was in February 2011, almost exactly two years ago - we had threads like this, but arguing the same point for desktop games! Everyone was saying we should develop a Flash exporter, HTML5 was a fad, it performed terribly, it didn't even run anywhere (this was before IE9, IE8 was the latest IE and had no HTML5 support at all!). We also received a lot of pressure to write a DirectX or OpenGL native desktop exporter, similar to what we had for Classic. And they had a point: no browsers had hardware-accelerated canvases, so you were lucky to get 30 FPS even on a powerful desktop computer that could run the top 3D games. None of the games ran in IE at all, because IE9 wasn't even out yet at that time. Mobile was hardly even mentioned. It looked like a joke.
IE9 launched with a hardware accelerated canvas. Not to be out-done by IE, Chrome and Firefox followed up with hardware-accelerated canvases, and then exceeded IE with their WebGL support. The platform matured, bugs were fixed, performance was tuned, and now even the strongest HTML5 critics seem to admit it runs great on desktop, it's just mobile is the problem. So in two years it went from virtually unsupported to working fantastically on all desktop systems. And boy am I glad we didn't write separate exporters! We would be a long way behind where we are today if we had, because we would be having to maintain multiple codebases. Writing two codebases isn't twice as hard, it's more like squared (to the power two) as hard, because of all the extra effort to make sure both codebases are functionally identical in all circumstances, and that extra work never goes away if you keep adding features like we do.
The problem I have in threads like these is trying to persuade people where things are going. Just like the threads about desktop support two years ago, you have a point, there are lots of problems: crappy performance in PhoneGap, a Firefox bug that slows down WebGL on Android, the general browser mess on Android, whether iOS will support WebGL, and so on. What I am trying to say is we are repeating the desktop situation. These are real problems, but they will be solved with time. I would go so far as to say in two years HTML5 will be working great on mobile. In the mean time there are workarounds like directCanvas and cocoonJS, which are not themselves perfect either, but a lot better in many ways.
I know two years is a long time, and many of you have projects you need to be done before then. But I don't think it's an exaggeration to say it could take 12 months to get native exporters that are better than what directCanvas and CocoonJS already provide. Browsers do a *lot* for you: things like XML parsing and XPath support on mobile can be tricky, and that's potentially a whole project for one feature. Web Audio API equivalent features is another. If we just say we don't support things like that, then we're not going to do much better than solutions like CocoonJS already do. If we do support things like that, it will take a great deal of time to get every last tiny feature in Construct 2 working equally well as in a browser, because the project amounts to partially implementing a real browser (and Chromium is ~6,600,000 lines of code and over a thousand contributors). If your game is renderer bottlenecked, it probably won't be faster with a native engine anyway. And then we have the ongoing problem of multiple codebases, which will slow down the rate of updates considerably. (Perhaps this is why many of our competitors release updates a lot more infrequently than us.) In the same amount of time, HTML5 on mobile would be half way to great, possibly even already working great by then. Which means our small startup just wasted a whole year's worth of development time. Comparing that to the amount of progress we could make with our HTML5 support in that time, I think it's fair to say it's just not worth it. So yes, we're stuck with some difficulties in the mean time, but I am totally sure given time everything will be much better, and for right now today, there are workarounds like directCanvas and CocoonJS, as well as things like the Safari for iOS browser working very nicely, especially with iOS 6+.
"A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be." This is what we do, and I feel it has proven to work with the desktop support. There's an awkward wait while we get to where the puck is going to be, but I don't think there's anything we can practically do to get there quicker. But we will get there!