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.
What is the advantage of creating Firefox OS using Cordova (if you're only creating firefox os apps)?
If you all you need for firefox os apps are: html, css, js then why do I need to add additional cordova library? The big plus of Cordova is you can use HTML5 and write apps that run on other platforms where HTML5 is not natively supported but Firefox OS claims to be HTML5 first.
Cordova seems useless for FireFox OS apps..specially if I'm not using Cordova for any other platform, since performance wise it's not as fast as native on Android/iOS.
There is no advantage of using Cordova if you're only creating Firefox OS apps.
The advantage is if you are already using Cordova to write cross-platform HTML apps, you can simply run `cordova platform add firefoxos` and it'll run on Firefox OS now (barring any issues with the API shims).
Eventually, the Web APIs supported in Firefox OS will hopefully become the standard APIs for hardware access, and Cordova will change their APIs to match it, and in the end you will just need to write apps against the Web APIs and we can get it to run everywhere. But we are not there yet.
>What is the advantage of creating Firefox OS using Cordova (if you're only creating firefox os apps)?
I suppose the advantage would be the ability to have your app run on the current biggest app stores, and a possible up-and-coming popular app store.
I'm assuming Mozilla is aware that most developers don't want to create apps that only run on Firefox OS, since it has such a small install base. But if they show how easy it is to write cross-platform apps they can get some traction.
I think you are on the right path: If you're making an app exclusively for Firefox OS, wrapping it in Cordova is not the path I would take.
However, if you're also planning on submitting it to the iOS app store, then making a Cordova app is useful.
Similarly, if you already have a Cordova app that you submitted to iOS and Android's stores, then you are now able to turn it also into a Firefox OS app fairly easily without having to fork your entire project.
> What is the advantage of creating Firefox OS using Cordova (if you're only creating firefox os apps)?
The post doesn't seem to say anything about that. I figure this would just be one step for your Cordova app. You would also use it to target Android or iOS (I don't know enough about Cordova to know if iOS is a target).
Cordova is good because you can make the app in HTML and then publish it to be multi-platform (i.e. android and ios). This is just adding a platform to that process.
The fact that the platform they are adding already running apps in the same framework you've written your mockup in is secondary. Wrapping an HTML app into a firefoxOS app is fairly simple, but this will now handle that process for you.
It simplifies your life if you don't need quality (tailored platform experience). Makes it simpler to tick the mark that you have a version of app you don't really care about on every platform.
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.