I have just spent about half a day installing and configuring the latest version of Apache Cordova. I've used Cordova for several years now, it remains a great way to write a cross-platform mobile app.
The reason for this article though lies in the first line. I spent half a day simply installing and configuring a mobile framework, I haven't opened an IDE yet, less still written a line of code. Let's consider that for a minute, this is a mobile framework, not an OS distribution! I am guessing I would have spent less time reinstalling Debian than I did yesterday to end up with a few megabytes of mobile project.
Because that's all Cordova is, when you get down to it. A set of ready-to-go mobile projects for each platform that you pull into your IDE and start pushing HTML and Javascript into. And until version 3 that was how it was distributed. Unpack the downloaded archive, pick up the directory for your platform, pull it into the IDE, start coding. Have your prototype app in front of the boss at the end of the day.
Cordova 3 changed all that, and going by my experience yesterday Cordova 4 hasn't fixed it. You install Node, use npm to get Cordova, run a command line to create your project, then another command line to add your chosen platforms and plugins to the project. The project directory has one master www directory in which you put your app code, and a simple command line builds each platform-specific project from that www directory. Putting aside the version and configuration hell that marred yesterday afternoon's install for me it sounds really elegant.
Unfortunately though that is not the way apps are written in the real world. It would be great to write one copy of your HTML5 app and then deploy it to each platform and compile it from the command line on the same computer, but sadly cross platform app development doesn't work that way.
Picture for a minute the office of a typical Cordova developer who produces apps across more than one platform. They may have a Linux box for Android development, running Android Studio or maybe Eclipse. Their Windows Phone apps will be developed on a Windows box with Visual Studio. And finally they will have a Mac running Xcode on which they develop their iOS apps. This is not a choice but a necessity, try asking Tim Cook or Satya Nadella for permission to develop for their mobile platform on the other's OS and you won't get very far. It's possible that the Android apps could be developed on the Mac or the Windows box, but it's still largely true that if you want to do cross platform app development for multiple target platforms you are going to have to have multiple development platforms and more than one IDE. It's not ideal and none of us really want it or like it, but it's the harsh reality of developing software for closed-source commercial platforms.
In that environment Cordova's elegant project build structure is almost completely useless. Putting aside the unfortunate fact that each platform demands subtly different code for its in-app browser, it is impossible to load the generated Cordova projects directly into Android Studio, Xcode, or Visual Studio and develop them from their Cordova build directories because each time the project is rebuilt at the Cordova end the project you see in your IDE is overwritten. So you end up using Cordova's build system to create vanilla projects for Android, iOS and Windows Phone that you copy somewhere else and load into the IDEs before never touching the Cordova build system again. Instead of being an elegant and useful addition to the project it has become an annoyance and a significant inconvenience.
So there's my Cordova rant. It's a bit unfair, Cordova remains a really useful piece of software. In reality I think it would be better to characterise my rant as one against the tendency in open source software to incorporate features not because they make sense for the software itself, but because someone thinks they are a good idea. In the same way that the developers of PHP who are not PHP coders but C and C++ coders seem to be on a mission to turn a sequential scripting language into a clone of C++, it makes sense to them but is increasingly divergent from the use case for the vast majority of PHP developers.
Every open source project risks this pitfall as a side-effect of success. People write software because they want to solve a problem in their lives, but eventually they transition from being the people with a need for the software to being the people who only write it. They lose touch with why and how the end users use the software and imagine that they and not their users know best how it should be used.
There is an obvious difference between the open source movement and the closed source commercial world. But one thing remains constant in both worlds: the customers will dump your product if you ignore their needs and try to dictate to them what they will have. IBM learned this the hard way in the 1980s with the PS/2; the customers and the rest of the industry continued evolving the PCs they already had rather than taking the direction IBM wished to impose on them.
I find it sad that the same tale is played out in the open source world. Open source software could be a rich dialogue between users and developers, instead each successful project eventually loses its way just as commercial entities do. I suppose moribund companies spawn upstart competitors just as moribund open source software spawns vigorous forks, but there are times when the wait for a fork seems awfully long.
