Sencha vs. jQuery Mobile – what to use?

I’m involved now with a project architected using Sencha 2 and I have to say it’s really nice. On a call over the weekend with the development team, we had a little discussion of why we would want to pick Sencha over JQM. I’m trying to compare the two having had experience already moving a JQM project into production. This blog posting is just a little mind mapping of the differences between the two and why I think Sencha might work a bit better for a distributed team on this type of project.

There are many differences between Sencha and JQM and they are very well outlined here: http://css.dzone.com/articles/sencha-touch-v-jquery-mobile. I don’t want to rehash this ‘cage fight’ but want to specifically address why I think Sencha will work for my current project’s needs. I am a big believer of using the right tools for a given project, based first on an analysis of what needs building, and then choosing the toolset. This is after many years of having nontechnical people cram tools down developers’ throats because they fell in love with a tool and fell equally hard for the sales pitch before figuring out a business and project plan. It needs to be the opposite. First plan, then tools.

UI: For our situation, we are creating a unique user interface that needs to have a lot of interesting interactions and customized UX. Sencha is very good at this, as you can do heavy customizations of the UI. JQM tends to have a typical ‘look’ – it’s instantly recognizable especially if you use the Themeroller for JQM. I like using JQM to skin the same codebase for many different clients and have used this strategy in the past, but that’s not my use case here.

Speed: The project is going to depend on being able to pinpoint locations and quickly react to lat/long changes, so JQM may perform too slowly for our needs. There is a lot of buzz on Twitter right now about avoiding including third party .js libraries altogether to enhance the speed of an app, and native apps have always had the tendency to perform the most quickly of all on the various devices in question, but when your project calls for a speedy architecture that will perform across devices, I think Sencha will be very good as it is largely considered to be more performative.

Learning curve: This is the biggest downside to Sencha, learning ext .js and writing all that script. JQM is so easy, it ” just works”. However I tend to look at coding projects as good technological challenges and don’t mind adding another notch to my list of syntaxes learned, so this doesn’t bother me, and from what I have seen, it doesn’t look to be too horrible.

Code organization: This is the biggest win for me. JQM does not force any structure to your code, and it’s so very easy to start writing spaghetti unless you decide on an architecture from the beginning. Sencha 2 forces you into a tight MVC structure from the get-go which I really love. I like writing structured code, which is why I like Rails so much. I like it when the architecture forces team members into this same structure. Frameworks? You betcha.

Looking forward to starting this Sencha work!

Leave a Reply