Sencha Touch vs jQuery Mobile: High Level Review

With the advent of the iPhone and later Android based phones, the need to build applications that conform to the profile of these devices has become a very popular and important job.  With the addition of the tablet based devices based on the operating systems in these leading platforms, this need has grown further.  The time and energy required to deliver a mobile application is multiplies for each device platform.  Mobile web applications can address this problem to some extent.

This research topic will be looking at Sencha Touch (ST) and jQuery Mobile (jQM).  The goal is to understand how the two stack up.  In the end hopefully it will be clear which is a more powerful framework based on tangibles and some intangibles.

Admittedly, I have a bias in having experience with Sencha frameworks, specifically ExtJS 3 and 4.  Their Touch framework is new to me.  I have only dabbled in jQuery in the past and the extent by which I used it was rather limited.  However, in terms of some of the enterprise level features, ExtJS has been a more powerful framework.

Sencha Touch Website - v2.0 Beta 1

jQuery Mobile Website - v1.0.1

Device support is important to some.  For my purposes, I am mostly concerned with targeting the iPhone and Android-based phones.  This will simplify the rest of the research, however it's important to note the device support today by each framework.

• jQM, lists support for iOS, Andriod, BlackBerry, bada, Windows Phone, palm webOS, symbian, MeeGo.  See the full report on Browser Support.
• ST v1.1.1 supports, iOS, Android and BlackBerry.  While v2.0 is in beta, the support for Android versions 3.x is labelled as "fundamentally broken, and do not plan to officially support it in Touch 2." [Raising The Bar].  Issues with transitions in the ICS browser have been raised with Android development and appear to have been resolved.

ST v2.0 Beta 1 Kitchen Sink

jQM v1.0.1 Pages & dialogs screen

These screenshots give a general feel for the default look and feel of the both frameworks.  ST tries to mimic the look of the iOS styling whereas jQM uses a theme similar, but varies drastically from the iOS look.  These themes apply the same on an Android based device (tested in an Android Emulator).

jQM is based off of the popular framework jQuery.  This is prevalent in the script loads as well.  Among the javascript files loaded, are jquery-1.6.4.min.js and jquery-mobile-1.0.1.min.js.  This results in a payload of 32111 and 24840 bytes respectively gzipped or 56.9 KB.  

ST on the other hand loads one file with ExtJS framework requirements in addition to the Touch framework.  The total payload 28658 bytes, or 28.6 KB.  A 28.3 KB larger smaller download.  This is a minimal factor as long as caches are utilized properly and occurs on a occasional basis per user.  In slow network situations this could leave a user less frustrated.

Both frameworks pay some lip service to PhoneGap.  A solution that may be a very valuable and easy way to deploy an application to a large customer base while having complete control over the user experience for deploying updates.  A huge drawback to native applications is the platform dependent implementation.  While these javascript-based frameworks are still very new and maturing they do provide relatively good experiences compared to the native based application.  For more information on PhoneGap, please review the documentation provided by the two frameworks or visit http://www.phonegap.com.

Anyone who has done a any amount of studying iOS application development will now that it follows the MVC pattern very religiously.  I won't discuss the details of MVC here but you can read up more on the pattern on Wikipedia.  One of the feature additions in ExtJS 4 was full scale MVC support.  The model was formalized and additional classes were built to support the concept of view and controller.  After doing some work with iOS, I found that I actually appreciated that concept very much.

With that, I would personally look to building new web-based applications following that pattern.  ST is based on ExtJS 4 and brings the MVC pattern to the table.  A cursory search on the google machine, I could not find a concise document on using jQ or jQM to implement MVC based applications.  I think this is knock on the framework and may for some be a deal breaker.

I was also more impressed with the transitions by ST.  I have an iPhone 3GS running iOS 5.0.1.  Anyone running this combination will feel the pain I do on occasion with regards to performance (small price to pay for some of the adds).  The transitions were seamless and very smooth.  With jQM, I found that transitions were not as good.  Here is a set of screenshots of what I am referring to.

The first screen shot appeared after clicking the "Page & dialog" option on the front demo page of jQM.  A page load occurred, the first screen shot appeared and then after enough time to capture the image the second screen shot appeared.  Now, I am not sure if this an intended feature.  What I will say, from a expectation level as User evaluating this demo, I did not expect this transition.  I suspect that the demo application is formed in a way to easily adapt into a tablet/large form factor and adjusts down to the resolution of my iPhone.  That is my uneducated guess.

With these very basic criteria, ST seems to be a better fit for greenfield web application development.  Developer experience with jQuery or ExtJS may be another deciding factor.  As stated earlier, I have more experience with ExtJS.  I feel that it would be a smaller learning curve to learn the ST framework, understand the documentation styles, and implement the application and features necessary to build an application.

REST - Taking a Closer Look (Part 4)

In the previous posts, we've discussed the general project, defined the concept of REST and taken a look at the list, show and save operations.  Now, let's talk a little shop and dissect the concept of REST a bit further.

REST has some very important design concepts that need to be leveraged to be successful.  First, a rich and easy interface.  This is important for two reasons.  Building a client implementation around a set of REST services can focus on user experience and ignore the data needs.  That is to say, the data is well-defined and the developer building the client can rely on those services to provide specific data.  The application will be built around that data without intermixing the client specific code.

The second important reason is, a developer can build any client around a set of REST services.  Why?  The data has no complicating details blurring the line between the user experience and the data.  In doing so, it makes it more adaptable to move from a purely web-based client to say a mobile web client.  Later, moving to a native client or game console becomes a reality.  Later on down the road, the REST API is published and developers are developing custom applications, much like Twitter, Amazon and others.

Another idea I have read about but do not fully understand is the concept of idempotent resources.  Idempotent is defined as an element multiplied by itself remains unchanged.  The simplest case I can come up with is 1.  1 multiplied by 1 is still 1.

So how does this apply to resource in your system?  Making a request to the same URI should result in the same operation time and time again.  In other words, creating an entry for a book with the same title should result in the same book being created or denied every time.  Only one book is created with that title.  Both PUT and DELETE methods are idempotent.  The GET method is also idempotent given that there are no lasting changes on the resource being requested.  POST is an update operation and can result in attributes of a given resource being altered.  It does not qualify as an idempotent method.

Now, we have defined why REST has good qualities. It provides a rich and easy interface to resources or decouples the client from the data, in doing so, making the data and services scalable.  We have cleared up the concept of idempotent and what that means to a resource in our system.

It is important to remember that REST isn't a specification like SOAP.  It is merely a suggestion of an architectural design around how to serve data.  There are goals within the design to decouple data from the client so that these services are scalable, reliable and well-defined for future client implementations.

REST - Taking a Closer Look (Part 2)

First goal is understanding the request model as stated in my previous post REST - Taking a Closer Look (Part 1).  For this portion of the exercise, I will start take a closer look at the Book implementation.

The book model is simple concept and one that we would recognize from our daily lives.  A book has basic properties,

• title
• description
• author
• ISBN

What is REST?  REST is representational state transfer (see Wikipedia for more details).  More or less, it's a software architecture by which we transfer state from one place to another.  In terms of the web, transferring state of resources from the client (browser) to the server (web server->database).  I strongly suggest reading the Wikipedia entry, as it has some very useful and important details on implementation and separation of concerns.

REST sets out to model the concept of CRUD operations (Create, Read, Update, Delete).  It mimics these operations by using POST to Create, GET to Read, PUT to Update, DELETE to, well, Delete. 

With a simple understanding of REST, let's look a little closer at a Book implementation.  Initially, you'll want to see a list of books that are available.  We would model a URL using the guidance of REST like this.

GET http://localhost:8080/research-grails-rest/book/list

This URL has no unique pieces to it.  The resource is defined by book and the operation is defined by list. As a result, all defined knowledge of the representation of a book will be listed.  We can say this about any resource that is available in the system that provides an authorized list operation.  Within the context of the Grails application, all of the work is done on the server and returned in an HTML page.  However, in an Ajax based client, the list operation would return all of the data as a data structure and decouple the operation from the client view.

Screenshot: Result of book/list.

As a part of the architecture, the GET request could be marked as cacheable.  In other words, the browser could use a copy of this data from it's local cache rather than making a request to the server.  The resource, book, would have to mark the list operation as cacheable and provide a timeframe in which that cached data is considered fresh.  Once that cache entry is considered stale by the browser or by revalidation by the server, a new version of the resource will be made available to the end user.

For a simple operation like, GET, this about the extent of it.  In the next post, I will discuss the POST method (Create).

REST - Taking a Closer Look (Part 1)

One of the challenges that I have found in regards to REST is really understanding how it used in practice.  Looking across the internet, there appears to be a vast amount of documentation that talks about the basics.  I have two goals for gathering a better understanding of REST.  First, understand the request model which is well documented all over the internet.  The best way learn something is by doing.  Secondly, look at how more complex operations are constructed and how they impact the design of application.

To frame this out, I am working with Grails and building on top of the implementation discussed in the screencast, Jump Into Grails 2.0.  My experience with Groovy is limited, but I have a good background in Java which I am hoping to leverage in learning/understanding Groovy.  The screencast takes an approach of building a basic application in Grails encompassing the following,

• Setting up application configuration and plugins
• Building basic model, view and controller implementations of 
• User
• Role
• User Role mapping
• Discuss Unit testing - in my opinion very handy and largely automated
• Building a new model, view and controller of a Book.

I don't intend to reproduce the screencast here.  However, as part of this first part I would like to make sure there is enough understanding about the Grails project and how it is built for those looking to understand and answer the same questions I am setting out to answer.

For complete source, access the git repository through git : git://github.com/mhorner/research-grails-rest.git or view it at https://github.com/mhorner/research-grails-rest.