Cordova is wonderful if you know how to use it. It allows for cross platform apps with a single codebase.
The problem lies in how it is used. Our project tried to incorporate a ton of native UI/UX conventions that screwed us over royally. CSS transitions, layered divs, swipe gestures, all of these were far too complicated for a little phone to handle. Stay away from these, and do simple hides and shows. Or go the hybrid method of having barebones native wrappers and web-views inside of those views.
The web (i.e. HTML/CSS/JS) promises a lot but mobile browsers are nowhere near where they should be in terms of pure processing power. As of right now, native is still the way to go.
There's very little processing power needed for that demo, outside access to the GPU via WebGL for rendering. It's a completely different model from HTML/CSS. And WebGL will not be available for Android WebViews (or iOS ones for that matter) for quite a while yet.
It's sad, Google and Apple try protect their walled garden app-stores by all means.
Android 4.4+ are based on Chrome/blink for the WebView but they deactivated the hardware acceleration for Canvas2D and removed WebGL support, as well as Web Audio API. [1]
iOS 4+ support WebGL in the webkit engine, but it's only enabled for iAds. [2]
I don't quite see the argument here. To quote from your link:
> Chrome for Android supports a few features which aren't enabled in the WebView, including:
If Google was trying to protect the app-store walled-garden - surely that would mean the reverse? Currently in-browser games that bypass the appstore completely have access to more features than native apps?
Both companies cripple HTML5 support on their mobile OS. Developers are left with almost no choice but to write native apps for their platform (if they care about execution speed).
It fits perfectly in the picture that Apple doesn't allow alternative browser engines. Chrome for iOS just embeds UIWebView and there is no Firefox for the same reason. The JavaScript JIT is disabled for UIWebView, and only enabled for Safari.app.
In an ideal world, one could write powerful HTML5 apps that run on Android, iOS, FirefoxOS and desktop browsers. And AppsStores would allow one to add an entry to the apps web URL or at least provide an non-crippled WebView so that one can write a simple wrapper app (or use phonegap/etc).
Google allows many browsers on Android, you can install Firefox or Aurora and use Firefox apps. You can run all the newest HTML5 features on Chrome for Android. The promise of HTML5 is the open web, not apps in the Google Play store.
Right now I'm running WebGL apps on my Android phone, and in Chrome you can put web apps on your homescreen with a single click in the menu. You don't need to go through any store, and you can open it like any Android app from the homescreen.
I think you underestimate what can be done with bad hardware if the motivation is there - FirefoxOS phones are really bottom end hardware and the UI (app opening, or changing screens, for example) is built using CSS transitions etc. They are just as smooth as native transitions on much more powerful hardware. With a good implementation and a good understanding of exactly when you hit the fast path optimisations you can do wonders.
The problem is not with web technology, but with the implementation and use of web technology. Of course, since this is mostly out of the hands of app developers, this doesn't help much. But I think it is important to be blaming the right culprits.
(Hopefully we are not too far off bringing these optimisations to Firefox on Android at least, for now they exist only for Firefox OS).
I second that. We had to build pretty simple application for iOS and Android and all the swipes and buttons that were animated via css were horribly laggy.
Not to mention you have so little control over device itself, only thing you can do is rely on Cordova plugins (which are horrible to begin with).
Yeah, I would say that the problem is the "little phone" hardware moreso than the web tech. I wouldn't be surprised if a "native" (ie. Dalvik) Android app had similar issues on the same hardware.
I second that. For mobile the key is to focus on responsiveness not glitz. People open your app for a reason, and hopefully the reason isn't your CSS animations.
I really don't buy the "web is native on Firefox OS" argument that you and others make.
Architecturally, it's really no different than a PhoneGap or web app running on Android, iOS or BlackBerry OS. They all involve an "app" typically written with HTML+JavaScript, executed in a web browser (often full-screen and without chrome), which in turn runs on an operating system of some sort.
If it's "native" on Firefox OS, then why isn't it just as "native" on Android, or iOS, or BlackBerry OS, or other mobile OSes?
What I think we really see is Firefox OS totally lacking any sort of real native software development support. This creates the illusion that web apps are somehow "native", when this is just a result of there being no other viable option.
Web as native on Firefox OS is not an argument or an illusion. Seriously, no kidding, it's the entire point for the existence of Firefox OS.
There will never be access to run native binaries on a Firefox OS device. Web APIs are as close to bare metal that it will ever expose.
Seeing that as "totally lacking any sort of real native software development support" misses the whole purpose of the OS, because the web is native on Firefox OS.
As far as I'm aware, the intent is to develop any non-standard Firefox OS API into a web standard API. Any API that starts out as non-standard on FxOS, starts that way so that it can be shaped to serve practical uses before it gets standardized.
The problem lies in how it is used. Our project tried to incorporate a ton of native UI/UX conventions that screwed us over royally. CSS transitions, layered divs, swipe gestures, all of these were far too complicated for a little phone to handle. Stay away from these, and do simple hides and shows. Or go the hybrid method of having barebones native wrappers and web-views inside of those views.
The web (i.e. HTML/CSS/JS) promises a lot but mobile browsers are nowhere near where they should be in terms of pure processing power. As of right now, native is still the way to go.