Question

What are the basic difference Sencha Touch and Backbone.js, actually have built a project in backbone.js but not aware of Sencha Touch. I have to built a PhoneGap application which one is better for that?

Answer 1

Sencha Touch (our product) is intended to be an all-in-one application framework that provides all the functionality you need to create great looking apps. Everything is designed to work all together on all the major mobile browsers. It’s a cleanly architected object-oriented approach to developing apps.

As an “all-in-one” framework, it gives you a full set of resolution-independent UI widgets (carousels, lists, tabs, toolbars, etc. etc.) an MVC library, event management, utility libraries, animation, a theming system, object lifecycle management, a layout system, a drawing and charting library and more stuff than you can shake a stick at… Because it’s all designed to work together, the initial learning is higher, but once you’re there people swear it’s light-years more productive than anything else.

vs.

Backbone.js, which is a simple MVC library. It’s about 1,000 lines of code and gives you 5 classes:

• Model
• View
• Router
• Collection
• Events

It has a dependency on underscore.js for utility functions, so you’ll need that too. You will also probably need to use a separate templating library as well as a DOM abstraction/manipulation library like jQuery or jQuery Mobile which also has some UI widgets and a bunch of other libraries to build a full app. But some people prefer to research and hand-curate their individual libraries.

Update: I wanted to add more detail to repond to Ben Bishop’s answer below. Aaron Conran, who’s our Sencha Architect lead and a Sencha lifer has helped me out with this addition.

There is a definite world view difference between Sencha and backbone. In general, Sencha tends to stay in the JS world and we expect that your JS will generate your HTML content. Backbone on the other hand is kind of a mishmash between an HTML and JS. There’s no cut and dry reason to using one or the other, although we believe that data-driven apps of any complexity are better served by the Sencha approach. Ok on to details.

First off re: Classes, Ben’s example of declaring a class in JS would put a copy of every property and method in every instance of the object. Typically working in raw JavaScript, you want to put these on the prototype so that they are shared across instances of the class MyClass. The Sencha class system does this automatically for you.

Additionally in raw JavaScript, users have to grok prototypical inheritance correctly in order to properly inherit from or mix in a particular class. Sencha takes care fo thsi without you having to worry.

As far as “magic strings” go (although I’d argue that’s a rather negative characterization) you don’t have to use them if you don’t like them in 4.x , instead you can use Ext.extend with direct identifiers (although this is officially deprecated since 4.0.0 http://docs.sencha.com/touch/2-1/#!/api/Ext-method-extend).

Using magic strings is useful in a few ways.

First off we can worry less about dependency order and when any class is defined/extended from. This matters in complex apps

For example

Ext.define('Turtle', { extend: 'Animal' }); 
Ext.define('Animal', { });

Works because Sencha waits until the Animal class is defined before defining the Turtle class.

In contrast:

Turtle = Ext.extend(Animal, {
});
Animal = Ext.extend({}, {
});

Does’nt work because we can’t find the variable reference Animal.

Second, using strings means we can support dynamic loading. For example if we have

Ext.define('MyApp.foo.MyClass', {
    extend: 'MyApp.foo.ParentClass'
});

If you follow a strict class name to JS folder convention, the class loader knows where to load the class namely:

• MyApp.foo.MyClass lives in app/foo/MyClass.js
• MyApp.foo.ParentClass lives in app/foo/ParentClass.js

This technique makes it easy for Sencha to do useful things:
– The class manager will automatically create proper objects without you having to create & manage namespaces
– Determine the classname of any class or instance
Ext.ClassManager.getName(myInstance) -> “MyApp.foo.MyClass”

• Perform some action when a particular class is defined

  Ext.ClassManager.onCreated(function() {
  }, scope, ‘MyApp.foo.MyClass’);

• Support namespace rewriting, for example if you need to run two versions of the same set of classes concurrently in the same page… you can rewrite the namespace of Sencha Touch’s “Ext” top level namespace to something else.

Ok, on to Templates.
In the Sencha templating system, users can embed their templates within any HTML tag that won’t muck with it: for example script tags with a custom type (or more typically in Sencha’s case a textarea)

var myTpl = Ext.XTemplate.from('theIdOfMyTpl')

You can also store your templates in separate files and load them via an XHR. Though we generally recommend you write something on the server side to manage this for good performance.

re: IDE’s
Sencha Architect handles this stuff automatically out of the box (including any places it’s referenced in the project, etc). I believe our Eclipse plugin also handles this, but I’d have to check.