You half assed it. That is why your PhoneGap application sucks.

Two days ago a company called Iconoclast Labs published and article comparing PhoneGap to RubyMotion where the author walks us through their experience creating the mobile application Chatoms with both frameworks. The post is well written and both codebases were made available on github. If you haven't already, go read the article.

Most people would agree that being a great software developer is about understanding your tools and exercising good judgement in how (and when) to use them. The application developer that has the most success is the one that makes the tradeoffs that best facilitate the goals of the project in a way that enables the developer to quickly learn and iterate on the needs of the users.

The application in question is very simple. It has two screens. The main screen gives you a button to refresh chat topics, a stage for chat topic to appear, and a button to go to the configuration screen. The configuration screen has a list of topics to toggle the categories and return to the main screen. The application then has a simple slide transition from one screen to the other and uses the client side data store for caching the data. Pretty basic stuff.

Now I'm not one to say that PhoneGap should be used in every circumstance but in the case of Chatoms it is absolutely nonsensical to conclude that RubyMotion is the best tool for the job. In no way is it a better fit than PhoneGap. To start with, you have a couple major drawbacks when choosing RubyMotion...

1. Multiple Codebases

Chatoms is available today as a mobile web app, iphone app, and android application. Going with RubyMotion for Chatoms requires at least three codebases to get the same reach that the application currently has with PhoneGap. In my opinion any more than one codebase is too many and RubyMotion fails right out of the gate for this reason alone.

2. RubyMotion requires you to understand Apples development environment.

Don't kid yourself. This isn't your typical ruby app. You are not going to get very far without also having an reasonable understanding of native iOS development. RubyMotion swaps one language for another, thats it. Remind me what is gained by doing this? This most likely isn't even a worthwhile swap considering it would be easier to find an Objective-C iOS developer than a Ruby iOS developer.

What about Performance?

PhoneGap drastically lowers the bar when it comes to knowledge required to build a cross platform mobile application. As a side affect of this, the number of novice developers building mobile applications has increased dramatically. The web has always been a place where the strong excel and weak survive. It does not mean that creating amazing mobile experiences is not possible or even that difficult with PhoneGap. I just means that many people don't, or can't. PhoneGap is an attractive solution for novice developers and has allowed a much larger spectrum of developer to fulfill some of the demand in mobile. This is a good or bad thing depending on your perspective.

Just because PhoneGap lowers the bar doesn't mean it removes it completely. Doing mobile development with PhoneGap takes some finesse and good judgment. Taking a look at the Chatoms codebase we can see that several beginner mistakes are being made in their PhoneGap implementation. It seems clear to me they haven't learned the nuances of the mobile web environment. Here are just a few rather obvious mistakes they make.

1. Uses JQuery (and JQuery Mobile)

JQuery is enormous and has no business being on a phone. Footprint still matters in mobile and there are much better alternatives (such as Zepto or XUI) that do the job just as well. As for jQuery Mobile, despite the version number, it really is alpha software (those are the kindest words I can muster at this time). I wouldn't recommend using JQM based on the jQuery dependency alone, but even without that problem I would sill advise avoiding that library.

2. Massive Footprint. 248k wowsers

Just to expand on the this a bit further, 240k of tools and libraries are loaded for an application that has two screens and one transition? An application like this can effortlessly be put together without any UI framework and with proper use of hardware accelerated css transitions the performance would be amazing. With a re-write this footprint could probably be reduced to 20k-30k total.

3. click instead of tap

To be clear, I think jQuery Mobile bails you out on this one by doing a bit of magic for mobile devices. But still, the author is clearly leaning on jQuery Mobile too much. onclick is an event for a mouse. It waits up to 300ms before firing to see if the user intends to double click. Why would anyone chance paying this penalty? Using ontouchstart will make your application feel much more responsive. This has been well understood for quite some time.

4. setTimeout animations

For some reason the author knows that jQuery based animations should be avoided because they use setTimeout, yet still choses to use it. Here is a quote from the article.

Using simple jQuery transitions pales in comparison to the smooth flow of a native application.

Ok, so use hardware accelerated CSS transitions and your transitions will be virtually indistinguishable form native. It's really not that hard. Here is simple css code that could be used for the fade-in.

#content {
   opacity: 0;
   -moz-transition: opacity .15s ease-in-out;
   -webkit-transition: opacity .15s ease-in-out;
   transition: opacity .15s ease-in-out;
}

#content.faded-in {
  opacity: 1;
}

Just apply the class faded-in and bam! you're done. Even doing your own page transitions is not very difficult once you get your feet wet.

Conclusion

PhoneGap is no trump card but I fail to see how in this particular case any sensible developer could conclude that RubyMotion wins this shootout. Especially if some well understood improvements were made to the PhoneGap codebase. That said, doing PhoneGap development definitely has some pain points to get over and although in this case the UI would be an easy problem to solve, in many cases it is not. A great open source UI tool is still a need IMHO.

At the end of the day, good software developers produce good software, and poor ones create poor software. Pull up your socks, learn the strengths and weaknesses of your tools, and do what it takes to make your product great.

Discuss on Hacker News