What are the advantages of PhoneJS over a regular backbonejs/HTML5 app?

Question

I tried using PhoneJS - it's pretty easy to get started, and seems to provide a good framework. However, I usual prefer to avoid pre-built framework as they limit my flexibly. My main 2 concerns are:

1. PhoneJs uses Jquery, while a lot of people recomend using Zepto for better performance
2. Can I use native trigger.io/phonegap plugins?
3. As a rule of thumb, one should avoid using 'large' frameworks for mobile apps (for performance reasons) - that's why some people are against Jquery Mobile. PhoneJS is fairly large. Does anybody have any experience with PhoneJS performance?
4. Frameworks reduce flexibility - how easy is PhoneJS to customize/extend?

Answer 1

1. PhoneJs uses Jquery, while a lot of people recomend using Zepto for better performance

If you're set on using Zepto, despite the fact that certain benchmarks indicate that it doesn't perform any better than jQuery overall, it's likely that you'll be able to sub it in for jQuery without any great difficulty. Zepto is a jQuery clone with the code which handles edge cases for older browsers removed. Since you're developing for mobile I suspect this won't be an issue. The Foundation 4 framework, just as an example, allows you to choose between the two.

2. Can I use native trigger.io/phonegap plugins?

There's no reason why you couldn't use PhoneJS to structure your code and PhoneGap OR Trigger.io to build, package and deploy it. PhoneJS and PhoneGap / Trigger.io are frameworks which aim to solve completely different (but complementary) problems. In fact, the PhoneJS page specifically mentions packaging applications using PhoneGap. You would certainly be able to take full advantage of the APIs and plug-ins offered by whichever of the two (PhoneGap or Trigger.io) you decide to use with PhoneJS.

3. As a rule of thumb, one should avoid using 'large' frameworks for mobile apps (for performance reasons) - that's why some people are against Jquery Mobile. PhoneJS is fairly large. Does anybody have any experience with PhoneJS performance?

Aside from the effect on download times, which won't be an issue if you're using trigger.io / PhoneGap to package your code as a native application, there isn't necessarily a correlation between the size of a framework and the quality of the performance. From what I understand, the main problem with jQuery mobile is the amount of mark up it generates to render its UI components (link). That said, I used jQuery mobile recently on a mobile application packaged using PhoneGap and the performance was fine. In all likelihood I expect PhoneJS will be the same.

Note that any answer you get regarding performance of the framework from somebody who has used it is likely to be fairly subjective. If you're concerned, the best suggestion would be to download the framework, use it to prototype a representative subset of the functionality of your app, and test it on the lowest specced device you plan to target.

4. Frameworks reduce flexibility - how easy is PhoneJS to customize/extend?

A good framework may limit your flexibility somewhat but, I would argue, in a positive way. It will encourage you to structure your code so that it is consistent, de-coupled, and maintainable. Why waste your time reinventing the wheel when somebody has already done all the hard work for you?

Using a framework will save you from having to make a lot of boring decisions about file and code structure, and free your time so that you can concentrate on being creative and flexible in your solutions within the actual problem domain (ie. the stuff that is unique to your app).

PhoneJS consists of a suite of UI components and the Knockout MVVM framework, so it's roughly analogous to a combination of jQuery mobile and Backbone. If you don't like the UI components you could edit the code to improve them or choose not to use them at all. You'll get an idea of the flexibility of Knockout by looking at the documentation, but referring to my first point, if you find yourself fighting with it you're probably not getting the best out of it.

---

TLDR: The person best placed to assess whether the framework is a good fit for your requirements, in terms of performance and flexibility, is you. Download it, have a look at the code, play around with it, prototype some functionality yourself, and then make a decision based on your experience.