Apache Cordova: after 10 months, I won't using it anymore | Hacker News Reader

Apache Cordova: after 10 months, I won't using it anymore

geekcoder.org

107 pointsyla9289 comments

On performance, the new WKWebView on iOS (with Nitro JS + GPU rendering, including WebGL), and the Chromium webview on Android 5.0+ (or Crosswalk for Android 4.0+, similar features all round), radically changes the performance story. It's almost identical to the system browsers now. Facebook's comments about HTML5 were back in the dark ages when the webviews generally used horribly slow software rendering and didn't have JIT for Javascript on iOS. It's a completely different picture today. In fact, our performance-sensitive HTML5 game engine[1] targets the iOS 8 webview and Crosswalk for Android for making native apps, and they generally work as well as in the browser, which is very good, especially on newer devices. Modern web APIs are also asynchronous which helps offload work from the UI thread, and Web Workers can do that for arbitrary JS code too. For example our game engine runs A* pathfinding in a web worker, offloading any performance impact from the CPU intensive algorithm and running it in parallel to the game.

I think it's time to stop accusing webviews of being slow.

[1] scirra.com

> the Chromium webview on Android 5.0+

The Chromium based webview is available already in Android 4.4. So about 50% penetration at this point. It is indeed a huge boost to performance.

Oh, good point. I mentioned Android 5.0+ because the 4.4 one is missing some major features including IIRC WebGL, Web Audio and WebRTC, which still rules it out for some use cases (such as a game engine).

Does WKWebView work with file:/// urls needed by Cordova?

Is there a reason they don't ship with a simple web server to server out the static files, similar to `python -m SimpleHTTPServer`?

Why would they want to? Both platforms have webviews that can render HTML from a file, or passed in strong form, or whatever you like. Why point it at an internal web server? If anything, it'd add overhead to the system that's unnecessary.

Apparently WKWebView does not support loading from file. That's why he suggested wrapping it in a localhost HTTP server.

The Android Cordova platform used to do this by including OkHttp but they moved away from that because it's now unnecessary.

Last time I checked (a few months ago) you couldn't use file:/// with a WKWebView at least on iOS8. Apparently, latest iOS9 beta allows you to load a local file.

No, but there is a drop-in plugin that adds a webserver and converts your webview to WKWebView: https://github.com/Telerik-Verified-Plugins/WKWebView

It has a few limitations, but it's quite nice for games.

Check out https://github.com/Telerik-Verified-Plugins/WKWebView

> radically changes the performance story

So that it's only 100 times slower than a native app instead of 200 times?

the facebook app used to be slow partly due to the fact that the devs working on it had no idea what they were doing (at the time, Facebook really stepped up their game lately).

The dev team at my ex company built a demo to show that the same app could have been made to perform acceptably using the right strategies.

https://www.sencha.com/blog/the-making-of-fastbook-an-html5-...

> It's almost identical to the system browsers now. Facebook's comments about HTML5 were back in the dark ages when the webviews generally used horribly slow software rendering and didn't have JIT for Javascript on iOS.

Incorrect at least as far as Android goes. Android's WebView literally was the system browser until Chrome was released complete with the JIT since Froyo (V8) and hardware rendering since Honeycomb. And the first several versions of Chrome on Android had much worse performance than the old WebView did.

This aside the bulk of HTML content is still software-rendered. It's software-rendered into tiles which are then GPU composited. It's a different story if you use <canvas>, but at that point you aren't gaining much by paying the browser tax so why not just drop to C++ and write GLES directly and get like 10x the performance?

That aside while there have been improvements in JavaScript performance, HTML/CSS & rendering performance really has not improved much if at all over the years. Browsers are still dreadfully slow to actually produce pixels compared to any other UI toolkit.

We've been using Cordova for almost 2 years (one in production, mind you), so I beg to differ.

Granted, our applications may be different and yes, Cordova, if not done right, can be excruciatingly slow. But we have managed well. Simple things like properly paginating data (rather than trying to infinite scroll), cleaning up CSS, avoiding repeated query selections (which is a bad habit of some jQuery developers) made a huge difference[1].

Our older app is built on jQuery Mobile. The latest one is Ember. The next R&D project I'll try will probably use React with Cordova. Mobile browsers are always getting better. After a while, I have the option of using App Cache instead of Cordova, without any significant code changes (I'm not using plugins yet).

[1] Edit: And not abusing local storage.

There's a use case for everything. I for one am not wasting resources creating and maintaining two versions of fairly simple applications in a corporate BYO environment, like the one I'm working in. There are plenty of convenient and easy to use frameworks out there that make positioning and screen creation just as straight forward as Xcode or the android development tools.

Actually, I always find it a bit surprising Cordova doesn't have more competition.

Edit; I find the title misleading. It's not so much about Cordova as it is about hybrid app development

I agree with this. If someone thinks Cordova is bad, what are you comparing it to? Maintaining two separate native code bases (including test suites and finding third party libraries for both that do what you need) to support iOS and Android isn't exactly a walk in the park either.

Coding is all about trade offs. There is rarely a perfect solution for all cases otherwise frameworks like Cordova would never exist in the first place.

> Actually, I always find it a bit surprising Cordova doesn't have more competition.

You mean Xamarin, Qt?

So I was reading this, and the only things that kept repeating in my mind were "Ionic, Crosswalk, Webworkers, Ionic, Crosswalk, Webworkers..."

(Yes I know Crosswalk is Android only, but it works wonders).

Exactly, I absolutely love Ionic and it's the fix for most of the issues raised in the article.

"To bundle Chrome, you will see a small (~10-15MB) size increase in your Android Apps."

I wonder what kind of apps they run that make them call 10-15mb call "small".

One game I play is 500mb. A few people complain about it, but honestly, with today's flash sizes, who cares?

Don't judge about others based only your used hardware! There are a lot (!) people with devices out there that only have 10MB storage left and can't install a app because it's size is bigger than that. ;)

Big Ionic fanboy here, but it's not all sunshine and rainbows. You absolutely need Crosswalk if you want to publish on Android. The default WebView performance blows, and is so inconsistent. We have two LG G3's with different WebView versions!

There are a few downsides though. Added complexity/possibility for bugs, and APK size.

The Crosswalk website says it should add 10-15MB to your. In our app, it's adding over 55MB to the installation size. These numbers are based on unminified JS/HTML (and I think we still have some outdated resources sitting in www/img/), but iOS: 18.0MB, Android: 78.4MB.

And then there's the additional bugs. Did you know localStorage is completely broken in the current "stable" release of Crosswalk? Once you kill/reopen your app, all storage is cleared. You'll need the latest Canary build if you want localstorage to work (and who knows what's broken in that build).

Every time I read one of these "this common, popular tool actually SUCKS", it seems like the author is trying to use it in a way it wasn't really intended (or obviously shouldn't be used).

Of course you aren't going to get native performance out of cordova. You are going to get webview performance out of it. If you need native performance, write a native app.

The article makes some good points, but I wish he'd asked someone else to proofread and correct it... it has way too many mistakes (I understand English is not the author's mother tongue, but it's not mine either).

For me, the more glaring problem is that the article simply makes statements, with no argumentation to back them up. There are no examples, no data to support his claims, no follow-through on any of his categorical declarations. The only useful information I got from it is that the author is frustrated with Cordova.

There is no sens to spend time trying to do your app multi-platform from the beginning. If your app do not works on iOS, it will not works on android neither.

Conversely though, if your app is a success on iOS then it's very likely that you'll want to get an Android version out before the clone-ware makers copy it, so if (and it's admittedly a big if) your app is something that Cordova can do well there's very few reasons against using it. For some use cases it's a good framework, notably "information viewing" apps, business CRUD apps and simple 2D canvas games.

For doing database work in a separate thread, you used to be able to access WebSQL from a web worker on both iOS and Android, but sadly that's been dropped as of Chrome 39 and iOS 9: https://github.com/pouchdb/pouchdb/issues/2806

Also I don't believe you can use the SQLite Plugin in a web worker either: https://github.com/litehelpers/Cordova-sqlite-storage/issues...

Luckily, you can still access IndexedDB from a web worker on both platforms (if you are able to use Safari's partial implementation). Also depending on what kind of work you're doing in the database, most of the action happens at the native level rather than the (DOM-blocking) JS level.

If background data access was really removed in newer browser version, than just WOW.

Well, WebSQL was deprecated in favor of IndexedDB. LocalStorage is also quasi-deprecated (synchronous access == problems), which is why it's not available from a worker either.

I tried Cordova three weeks ago, on my Nexus 10 (Android 5.1.1). I wanted to have a native UI, so I tested angular-material and Polymer. I wasn't too happy with the result, due to stuttering animations kind of ruining the UX.

Having a shared C++ code base and the respective native UI code works perfectly fine for me, so I wouldn't use Cordova again. I don't see why I should. I'm just as productive there as I am with the web stuff, with the difference that I get a truly native look and feel, without having to watch performance all the time. I'm sure that, if you want to take the time, you can get perfectly well running apps. But for me, it isn't worth the trouble.

I also tried Qt and it was nice, but the app took ages to load on an actual devices (because of QML) and their licenses get more and more messed up.

> I wanted to have a native UI, so I tested angular-material and Polymer

Aren't Web Components still heavily polyfilled in most mobile browsers? I'm wondering how much of the problem was due to the Polymer library than Cordova proper.

I thought that would make sense, too. But I found them to be working OK in Chrome on Android, so I thought I could give it a try.

I should have said that I wouldn't create any hybrid mobile apps anymore, not just Cordova. That's not because I don't like it - it's simply because the other options work just as good for me. At least for now - can't say anything about the future.

Right.

> I should have said that I wouldn't create any hybrid mobile apps anymore, not just Cordova

I must admit, I'm still quite enamored with them, if only for development time and maintainability. I'd rather not develop 3 different apps for desktop (browser), Android and iOS. As I said elsewhere, I'm waiting to rely on App Cache instead of Cordova in the future.

> I must admit, I'm still quite enamored with them, if only for development time and maintainability.

That's a very good reason for many developers. My UI code is usually rather small, with the C++ code being the biggest part. I really like C++ and Java, and Objective-C is OK. I'm pretty sure if I didn't, I would take a different route.

I'm still pissed off because loading in Qt apps can take very long. Writing the apps in QML, JavaScript and C++ was a lot of fun, but I couldn't recommend anything that destroys the UX so much.

> But I found them to be working OK in Chrome on Android, so I thought I could give it a try.

They probably would have run well with the Crosswalk browser plugin, then. It's basically bundling the latest version of Chrome within your app, so all your users have a consistent and up-to-date WebView, instead of whatever the OEM decided to lock it at.

Of course, that doesn't fix every issue, and adds a few more of its own. But really, any non-Crosswalk benchmarks/performances tests on Android can be simplified to: It's slow as hell.

I do the same approach for my mobile OS hobby coding, between Android and WP.

I guess C++ scares the web devs to go native and prefer to stay in their little sandbox.

Also tried to play around with Qt, but got disappointed that their story is more about bringing C++ apps into mobile not much the license, than a full cross-platform support like Xamarin. Even the new 5.5. still requires a lot of manually wrapping code across all mobile OSes.

However if I would be doing this commercially, Xamarin might be the way to go, as I wouldn't be willing to write glue code all the time.

react canvas renders at 60fps

https://github.com/Flipboard/react-canvas

Hmmm, I note in his closing para: "Facebook wrote a good article when they have decided to switch from a web app to a native one." A three year old blog post from Facebook.

Now the circle has turned with React and React Native…

To be fair, react native compiles to native according to their keynote were it was introduced. FB gave up on the web app/hybrid app and in the same keynote strongly said the experience will never be the same or good enough as native.

react native doesn't compile to native. It's javascript with native GUI controls instead of the DOM for the presentation layer. (You can still have parts that are objective C or swift and are thus compiled, of course).

I'm not sure it has though – React Native apps are demonstrably not web apps. It's a very different approach.

I guess my thought was that in contrast to the thrust of the blog post - FB is going back to the "build as much of it as you can with one codebase (React) and native-app-ify it as late as possible (with React Native)" approach.

React came before React Native. In one sense, React Native is just a tool to turn React HTML5/Javascript webapps into native ones - in a similar way to maybe an AngularJS webapp turned "native" with Cordova.

React native uses UI widgets from plateform SDKs, so Facebook point still stands. Their hybrid app sucked and they lost real money as the result of this.

So full circle that Facebook went C++ with their latest app.

http://www.computerworld.com/article/2935408/app-development...

Interesting; looks like a hybrid approach:

"Counting by lines of code, roughly one-third of the codebase on each platform is shared C++ code."

Source: https://code.facebook.com/posts/498597036962415/under-the-ho...

They are using a custom version of Djinni for cross-platform support.

Looks like Microsoft is going down a similar path with Visual Studio:

https://www.visualstudio.com/en-us/features/cplusplus-mdd-vs...

The team at facebook wasn't exactly the best at squeezing performance out of the browser to be fair. Their article was a little misinformed. I think they have learned a lot since then.

FUD.

Ever heard of WebSQL for storing your data? After 10 months, you should have been able to work around nearly anything you mention in your article.

> After 10 months, you should have been able to work around nearly anything you mention in your article.

But that's exactly the point. Ages ago this comment on HN summarized the situation perfectly... https://news.ycombinator.com/item?id=7442766

"It takes less time to learn and build native instead of trying to hammer Javascript into a hole it doesnt fit into, and spending hours attempting to optimize it's performance to no end."

> It takes less time to learn and build native instead of trying to hammer Javascript into a hole it doesnt fit into, and spending hours attempting to optimize it's performance to no end...

...depending on the size of the app.

I have an open source project that I devote a handful of hours a week to. I absolutely do not have the capacity to create native apps for desktop, iOS, and Android. It's great if the writer of that comment has either a tiny app that does nothing important or has a ton of free time, but not everyone is so lucky to be able to maintain an app on 3+ separate platforms.

Javascript is the one language all devices speak well, so as someone who is proficient in it, has an existing (somewhat complicated) app, and wants to port it to mobile as quickly as possible, rebuilding everything twice in two different languages and two different UI platforms is just not an option.

WebSQL is pretty much dead (which is unfortunate, and you should direct stern words towards Mozilla), so relying on that would be pretty risky.

Just use https://github.com/mozilla/localForage and be happy ... ;)

There's IndexedDB. Both Mozilla and Microsoft opposed on standardizing on a specific implementation of an SQL database (sqlite v2), and rightly so. There's loads of commentary/rationale on this issue on the web, so I won't re-iterate it here.

iOS has IndexedDB since v8.0 though the implementation is poor. I don't know if they've fixed it in any 8.x release. However, you're (mostly) not using IndexedDB directly anyway but a storage library, which supports IndexedDB, WebSQL and maybe localstorage as a fallback (e.g. localForage[1] for a simple key-value DB).

[1] https://mozilla.github.io/localForage/

> you should have been able to work around

The problem right here, to have to "work around" for 10 month.

WebSQL is deprecated in both the latest versions of Chromium for Android and in iOS 9.

HTML5 is working for Instagram and Apple Music, I don't think many people would say they're inherently slow.

Instagram and Apple Music aren't running through an abstraction layer than brings it's own variable overhead. It's not a good comparison.

I don't think of Cordova as much of an abstraction layer. They just expose things to the `window` global.

Can anyone using Xamarin chime in as to whether the situation there is better?

Well you are getting native app with xamarin, so it must be better.

I heard a talk lately by two students that came to the result that it was a lot time consuming to debug. You have to get from native-code failures to your JS implementation. But I didn't try it myself by now.

Xamarin and Titanium compile to native code and use native components, so they wouldn't have the same problems as a JavaScript and HTML solution like Cordova does. Particularly re performance since they don't run in the web view widgets like Cordova.

The downside of xamarin is slightly unstable tooling, the occasional regression, and headaches associated with using native oss libs, though it is very much possible. And of course price.

On the other hand, native-equivalent performance is no joke and c#/f# are great languages. Xamarin comes with some very sophisticated stuff like databinding, and high-level concurrency like rx, async/await, and akka.net which can really be a boon for performance, especially compared with js's comparatively meager concurrency options.

This is a very bad article. The real problems with Cordova are:

* Core functionality is broken between releases. If you ask in the IRC support channel, they will even tell you not to update if things work well! What if I need a new feature?

* Documentation is absurdly horrible or even plain wrong. I have been told several times to refer to the source code to find out how something works.

* If you face any problem, chances are you will never find an answer in Google. You may find some StackOverflow thread if you are lucky, where several clueless people argue about things they do not know and then arrive to a wrong conclusion. (The programming skill levels of Cordova users on those communities are usually very low.)

* Critical functionality (things such as local notifications) is not included. You must rely on 3rd party plugins, that could be well maintained, or could be not maintained at all.

Yes obviously a Cordova app does not look native. It's not native and it will never be. Period.

This would of made for a much better article. I couldn't agree more!

I'm currently working on a Hybrid React app, performance issues aside the real issue is documentation and support. As soon as you are beyond a basic web app wrapped in a container you realise quickly Corodova will always be a second class citizen.

On a more positive note React Native (https://facebook.github.io/react-native/) is mind blowingly amazing. I really can't recommend it enough, especially for Javascript developers.

I'm looking to use something like Cordova to develop a fairly simple app for both Android and ios,

so far it looks like React is for Mac only, looking at https://facebook.github.io/react-native/docs/getting-started... ?

Edit: It looks like i'm missing something as I can see Android apps built with it on http://www.reactnative.com/built-with-react-native/

That's React Native, not standard React for the Web.

http://facebook.github.io/react/

Ah gotcha, looks like Android support is coming to React Native soon, fingers crossed

There's also http://reapp.io/ It can produce apps that run on Android but last time I checked the documentation was pretty iOS centric.

I think it is also a question of ressources, I built a pretty good backbone app with cordova, I would say that you can get 90% there (https://www.cakemail.com/mobile).

The question is also what can you afford. Can you afford to have 2 ios & 2 android devs? Can you afford to build 2 times all the UI features, etc.

For a small company, small budgets, if you have strong front-end devs & designers you are probably going to get a good cordova app & you can move your company much faster.

You have big bugdets? Hire the native devs, get the 100% performance & experience from native.

For basic application there's no need for very deep knowledge of the platform, so you can find people who know iOS and Android equally well and just write two different apps. As Cordova might introduce more problems than advantages, writing two identical apps might actually be faster, if app is not that huge.

And native fast responsive app with smooth animations might earn you more, than HTML container.

I wrote a simple game using cordova and I won't do it again. HTML+CSS+JS just not suited for mobile app development (I didn't try react native, those guys might change the game). Either you use frameworks and everything is just bad or use vanilla JS and everything might work, but you have to write a lots of spaghetti-code and device support might be limited.

The real unmatched benefit of using cordova (or any other webview) is the ability to deliver updates for your app without bothering with App Store moderation.

You seems to only think about consumer apps, there is a lot of companies doing b2b. I agree that for games cordova is a very poor choice.

Unfortunately I can't agree that you can easily find easily good IOS & Android devs, I'm sure that some that can do it out there, but generally one platform always suffers more.

Has for Cordova issues, from my experience, nothing was so atrocious that writing 2 apps would have been faster.

"Either you use frameworks and everything is just bad or use vanilla JS and everything might work"

I think you might be thinking about games saying that, again I can't agree, if you don't understand what your framework does in your back that's another thing, but you can easily write optimized code when you control your render.

For example Ionic is a very good mobile UI framework for angular. It however wont save you if you start adding random things to the DOM while doing an animation.

> but you have to write a lots of spaghetti-code

What? As someone who does a LOT of vanilla JS, what do you consider "spaghetti code"?

"vanilla spaghetti" might be a new term we can start using :) leaves a bad taste in everyone's mouth!

You can get the same with Xamarin, Qt and similar tools that offer a better native integration than a web view.

Even if I have to code native like widgets in QML, it is surely way better than hacking around the DOM.

I've found loading QML-based interfaces to be slow on low to mid range android phones. It feels sluggish to start the app. I wonder if the alternate (QWidgets on an OpenGLContext) is still better than random DOM hacks?

The commercial version compiles QML into native code.

http://doc.qt.io/QtQuickCompiler/

Sweet, will check try this out tonight! Thanks for the tip!

These right here are the problems with Cordova.

Cordova is not a replacement to build native apps. Its a tool that allows you to build really good apps that works on all platforms.

My app[1] wouldn't have exist without Cordova. And based the feedback, most users are fine with it.

I have yet to find a solid native app that is available on all platforms, not belongs to a big company or a startup with huge funding, and made by 1/2 developers.

[1]

https://play.google.com/store/apps/details?id=com.premii.hn

https://itunes.apple.com/us/app/hacker-news-yc/id713733435?m...

http://hn.premii.com/ (HTML5)

I think it was a great article. A lot of people go in with the assumptions that the author has. At my last position we used Cordova. Like you, I was against it from the beginning because it is so unlike native. Yet many are under the impression that using Cordova means writing half the amount of code and/or taking half the amount of time that it would take to write separate iOS and Android apps. They think it's possible for reasons specified in this article (generally: that experiences are native-like and development is not harder than native); namely:

- that it can be like native; I regularly heard from management "What is so difficult about CSS? Why is it taking so long to build widget X?"

- that there is no reason why it can't be fast; I regularly heard from management "iPhones have >1ghz processors after all -- why can't it be faster?!"

- that the plugin ecosystem is bad -- "Why can't we just do X? Why do we have to build this?"

I agree with your criticisms as well. The lack of documentation, plugins, breaking between releases, and general help is surely lacking. But this is by no means a "bad article."

Non-engineers are the biggest problem building HTML5 apps.

Everyone from VPs, Directors, to HR knows HTML, and they all have opinion about how it should be. They all want you to build a Facebook like app with 2 developers and works on all platforms.

> Yes obviously a Cordova app does not look native. It's not native and it will never be. Period.

You can get pretty close to looking native with a framework like Ionic: http://showcase.ionicframework.com/

Of course, it's not native, so there are going to be corner cases where things don't look quite the same, but I'd be hesitant to make such an absolute statement about the future when you can already get so close today.

Performance and compatibility issues for Cordova apps can be often traced back to outdated webviews, and you can resolve much of it by embedding an up-to-date webview with your app: https://crosswalk-project.org/

I dont know from Cordova but a former employer bet the far on Solr without evaluating in any way. When I tried a search for solr sucks I got 600,000 hits. No one ever answered my questions on stackoverflow.

Solr and Cordova are on different realms, I don't see how that's relevant in this discussion. FWIW I've used Solr a lot and it's great for faceting and geometric search.

they are both apache projects.

I have used many apache codebases, all the others were excellent. ai expect my former employer chose solr because of thevapache foundation's great reputation. I looked forward to using it and so was completely dumbfounded by its poor quality.

I searched for solr sucks and got 20k hits.

Not here to defend solr specifically, but every tool has trade offs. Solr is popular and there is a lot of documentation, so it is not a bad choice for a document search database. Now, picking solr without understanding a document database and its tradeoffs is a problem, but not solrs.

I tried that search in june 2013.

In another news, water is wet.

Reply on news.ycombinator.com