Sencha updates framework for building native-looking mobile Web apps

Sencha has released a major new version of Sencha Touch, an Ext JS-based …

Sencha, a company that develops JavaScript libraries, announced this morning the availability Sencha Touch 2, a major new version of the company's framework for building mobile Web applications. The new version brings improved performance, broader platform support, and additional functionality.

We discussed the update with Aditya Bansod, the senior director of product management at Sencha. He described how Sencha Touch fits into the company's product roadmap, which includes an evolving suite of tools, frameworks, and services for building applications with standards-based Web technologies. We also conducted some hands-on tests with the new version of the Sencha Touch framework and used it to build a simple mobile application.

The heart of Sencha's technology stack is Ext JS, a JavaScript library that originally emerged from Yahoo's YUI project. Sencha maintains Ext JS and distributes it under a dual-licensing model. The code is available under the terms of the GPLv3 for use in open source software, but adopters will need to purchase a commercial license to use it in a proprietary setting.

Ext JS provides an extremely sophisticated model-view-controller (MVC) framework and binding system for building data-driven Web applications with HTML and JavaScript. It offers a comprehensive collection of data presentation controls and a charting system for data visualization. Ext JS controls can easily be bound to remote API endpoints that expose JSON or XML data. The framework's MVC system allows this to be done declaratively with very little code.

Sencha Touch uses much of the same underlying data binding system, but has its own separate set of user interface controls that are tailored for building mobile Web applications. It allows developers to create native-looking mobile experiences for touch-enabled devices such as smartphones and tablets.

User interfaces built with Sencha Touch are rendered entirely with HTML, but the result looks more like a mobile application than a conventional website. The framework is platform-neutral, but has historically required an HTML rendering engine that supports the latest Web standards. It relies on modern Web functionality to enable advanced features like animated transitions.

The Sencha Touch feature set and collection of user interface widgets are somewhat similar to those of jQuery Mobile, another open source framework for building mobile Web applications. Sencha Touch is more mature, however, and benefits from the powerful Ext JS data binding system.

The new version of Sencha Touch includes greatly-improved support for the Android platform. As Bansod explained to us, Sencha had to work closely with Android hardware manufacturers in order to ensure the best possible experience when running Sencha Touch applications on Android handsets. Due to this effort, the framework's touch event handling and performance now have parity between Android and iOS.

The Sencha developers have also added support for several new browsers. The new version of the framework is compatible with BlackBerry devices, the Kindle Fire Web browser, and Chrome on Android. Support for Microsoft's Windows Phone 7 is under development and will be added in another update later this year.

Another major new feature in Sencha Touch 2 is support for deploying your Web applications as native software. The SDK comes with a set of tools that can bundle up Web content into native package formats, allowing them to be distributed as standalone applications for Android, iOS, Windows and Mac OS X. These tools are fully cross-platform compatible, which means that developers can use them to build Sencha Touch applications for iOS without needing a Mac.

In addition to broader platform support and a number of major feature enhancements, Sencha Touch 2 also brings a lot of noteworthy improvements under the hood. The company says that its layout system has been heavily optimized, which will reduce the initial startup time for applications and reduce the amount of time it takes for the interface to be redrawn when device orientation changes. You can see a more detailed overview of Sencha Touch 2 changes in the official developer documentation.

The Sencha Touch 2 feature set

Sencha

Sencha Touch commercial license is available at no cost, a factor that has helped accelerate adoption of the framework. According to Bansod, Sencha's desktop and mobile frameworks are used by over 1.6 million active developers and have been licensed by 25 percent of Fortune 100 companies.

The frameworks are the core of Sencha's business, but the company also sells development tools: Sencha Animator and Sencha designer. As the name suggests, the Animator tool allows developers to create interactive animations with HTML and CSS transitions. Sencha Designer is a drag-and-drop user interface design tool that was created for building Ext JS interfaces.

The company is in the process of overhauling its applications and expects to release major updates this year. Sencha Designer 2, which is currently in the beta stage, is expected to release within the next two months. It will introduce full support for building mobile applications with Sencha Touch. I tested the latest beta release of the design tool and used it with Sencha Touch 2 to build a simple mobile client for the reddit website.

The application that I built required very little code. I was able to bind reddit's JSON API to an Ext JS data store and then connect it to a list view. It was possible to do this in the design tool without writing a single line of JavaScript code. I was able to customize the manner in which each item is displayed in the list view by editing a simple HTML template.

One of the coolest features of Sencha Designer is that it will let data stores connect to their specified remote data sources during development so that you see a preview with live data as you design your application's user interface.

A simple reddit client that I built in the Sencha Designer 2 beta

Sencha Designer and Animator were both created with the company's own frameworks, which means that their user interfaces are built almost entirely with HTML. It's a fairly compelling illustration of what Ext JS can do when it is used intensively for building large-scale applications.

The open Web is an increasingly capable application platform. Ongoing efforts by Mozilla and the W3C Device APIs working group are bringing an even richer feature set to the mobile Web. As more platform and hardware capabilities get exposed through JavaScript APIs, making it possible for Web applications to be fully competitive with native software, frameworks like Sencha Touch will become even more compelling.

Surely you could have found one criticism of this product? This reads like a press release; a comparison of all the mobile UI frameworks would be much more welcome. I tried 4 different frameworks to develop some movile sites at work, and ended up using jQuery mobile, despite not being a jQuery user prior to that. For ease of use and browser compatibility it beat Sencha's product hands down.

Surely you could have found one criticism of this product? This reads like a press release; a comparison of all the mobile UI frameworks would be much more welcome. I tried 4 different frameworks to develop some movile sites at work, and ended up using jQuery mobile, despite not being a jQuery user prior to that. For ease of use and browser compatibility it beat Sencha's product hands down.

jQuery mobile might be easier to use but I find it hard to believe that it had a better user experience that Touch. No one is even close to the compatibility list of phones/mobile OSes that Sencha works well with.

One point of criticism - they've been actively marketing Sencha Touch to Adobe Flex developers as a replacement for developing enterprise applications.

"See it's object oriented just like you are used to". No, it's javascript with some helper code that fakes inheritance but without any compile time type checking. In fact, there is no compile time with Sencha, it's all run time in the browser. It may be a very nice, concise framework, but there are many many gaps for the enterprise developer.

That was a year ago, perhaps things have improved, although list of compatible devices don't mean much without the accompanying compatibility.These were iOS devices, some of them old iPhone 3s, and Sencha's framework was trying too hard to emulate iOS. It was clunky and ugly due to loads of JavaScript problems. JQuery mobile doesn't try to emulate iOS, it just uses a mobile-friendly interface.

Looks great, wish there was cheaper than $279 .edu pricing so my work might consider buying this to experiment with.

The Sencha Touch framework itself is free, even for commercial use (as opposed to the desktop version, Ext JS, which isn't). Animator and Designer cost money but they aren't required.http://www.sencha.com/products/touch/license/

@joshv It's true, we're targeting Flex developers who are looking for an alternative, and there's been giant interest in the switch. Also true that JS is runtime and the language itself is not OO on its own, but again, there are literally thousands of Flex/Flash devs out there, looking to work with HTML5, that appreciate the fact that we're more OO than other frameworks, provide a richer UX, and are closer to their level of professional development.

At the end of the day, I love jQuery, but it doesn't come close in providing the app-like experiences we can.

The commercial license for Touch is completely free. The $279 refers to the current price of Sencha Designer (which does come with free trial period). Designer is a desktop tool for building Sencha Touch (and Ext JS) apps with drag and drop, code editing, etc.

That was a year ago, perhaps things have improved, although list of compatible devices don't mean much without the accompanying compatibility.These were iOS devices, some of them old iPhone 3s, and Sencha's framework was trying too hard to emulate iOS. It was clunky and ugly due to loads of JavaScript problems. JQuery mobile doesn't try to emulate iOS, it just uses a mobile-friendly interface.

Surely you could have found one criticism of this product? This reads like a press release; a comparison of all the mobile UI frameworks would be much more welcome. I tried 4 different frameworks to develop some movile sites at work, and ended up using jQuery mobile, despite not being a jQuery user prior to that. For ease of use and browser compatibility it beat Sencha's product hands down.

On top of that jQM is the only reasonably mature mobile JS framework that takes progressive enhancement seriously.

By doing this you can do things like support JS-disabled users and low end devices without having to have two completely separate codebases. You will need to write new CSS for the low end flow, but that sure beats authoring each of your pages twice!

I guess I'm not the target demographic. I am building an e-commerce website and would like to add a mobile-optimized version in the future. One that looks and acts a lot like a native mobile app, cross-platform, despite being a website.

Using frameworks like this sound useful, but what I really want is something to tack on to my existing website. This sounds like I'm supposed to create the entire application within this framework, meaning my existing work would not be reused and have to be rewritten within the separate framework.

Maybe jquery-mobile is targeted closer to me, as I am using a fair bit of jquery in the site right now. It's all progressive enhancement kind of stuff, so no OOP attempts in JS, which has always struck me as a bit of a fool's errand.

That task is a minimum of 6-12 months into the future, so I admit to not having researched options quite yet. The current website is ASP.NET MVC, so the idea is that I'm mostly just a new set of views away from a mobile site. The entire model and the vast majority of the controller remains the same.

While using Ext JS everday isn't so bad, I wonder if the Sencha Touch forums are moderated by different staff than the Ext JS forums because they've got some of the rudest developers that post there that I've ever seen for a "support" community.

@icrf if you serve the data to a Touch 2 app via JSON instead of rebuilding your views will create a much better experience for your users, as only the data will be traveling to the device instead of the whole presentation layer's code. I understand it's a bit of a paradigm shift but you should think about it more as an "app" instead than a website, and it will immediately become easier to understand the whole model.

Your use case seems to be what we created Designer 2 for... disclosure: I'm the PM for the tools, meaning Designer and Animator. If you have questions, come troll our forums, my handle is CaliLuke.

BlueD, semantic HTML and JSON are both data formats. There's nothing that fundamentally improves the user experience by switching to sending a JSON object instead of markup. BTW, apps routinely parse markup as their data format too, usually in the form of XML.

This have given me quite a bit of things to think about for a mobile project that I am working on.Going to check out Sencha for sure, among other products mentioned here.

[edit] Checked out the products page, and the examples. Appeared to work on my phone with ginger bread, both the stock browser and Dolphin.Many of the kitchen sink examples, though, didn't work on my TP running CM9a2. Not sure if it is CM9 or the ICS browser that is failing.

@Kethinov size matters when you're mobile. Also, we're much more efficient with stuff like painting your UI compared to Jquery. This creates a very perceptible increase in responsiveness that in turn improves the user experience.

Thanks for that update.Since ICS penetration is rather low, atm, I suppose this is not *that* bad of an issue.Hopefully the implementation of chrome code makes it into the stock browser, and we can "advise" ICS users to use Chrome for Android.And... ST2 works fairly well in iOS4.

we're still in beta but it truly slashes the time it takes to get started with Touch. The generated code strives to adhere to our internal best practices and the structure we create for you is very readable and extendable. This is NOT the design view in FrontPage or Dreamweaver, what comes out it's not just a prototype, it's 100% production quality.

@Kethinov size matters when you're mobile. Also, we're much more efficient with stuff like painting your UI compared to Jquery. This creates a very perceptible increase in responsiveness that in turn improves the user experience.

I won't dispute your argument about Sencha's UI painting performance compared to jQM. You guys do excellent work there.

But that argument about "size mattering in mobile" when comparing JSON vs. HTML is pretty silly. The bandwidth difference between JSON and markup is negligible. Consider this sample comparison:

Difference in data consumption between the two: JSON is 44 bytes smaller.

Seriously. 44 bytes. And I even used the most verbose markup I could think of!

I'm going to need a better reason than saving 44 bytes over the wire to see why sending all data to the client in JSON rather than HTML is worth the overhead of then having to transform that JSON data into HTML with a client-side library in order to ultimately render it into the DOM. Why add extra complexity (and CPU usage) if all we're getting out of it is negligible savings in bandwidth?

I'm going to need a better reason than saving 44 bytes over the wire to see why sending all data to the client in JSON rather than HTML is worth the overhead of then having to transform that JSON data into HTML with a client-side library in order to ultimately render it into the DOM. Why add extra complexity (and CPU usage) if all we're getting out of it is negligible savings in bandwidth?

The power is not that you are saving 44 bytes in data transfer, but that by receiving a JSON record (or array), it is easy to load into a data store for data manipulation, updating, and posting back to the webservice.

If all you wanted to do was render the data to the user, then HTML is fine. However, if you want the user to interact with the data, then JSON would be my preferred format.

The power is not that you are saving 44 bytes in data transfer, but that by receiving a JSON record (or array), it is easy to load into a data store for data manipulation, updating, and posting back to the webservice.

If all you wanted to do was render the data to the user, then HTML is fine. However, if you want the user to interact with the data, then JSON would be my preferred format.

Can you think of a specific use case where the data being semantic markup rather than JSON somehow hinders interacting with the data using JS?

The power is not that you are saving 44 bytes in data transfer, but that by receiving a JSON record (or array), it is easy to load into a data store for data manipulation, updating, and posting back to the webservice.

If all you wanted to do was render the data to the user, then HTML is fine. However, if you want the user to interact with the data, then JSON would be my preferred format.

Can you think of a specific use case where the data being semantic markup rather than JSON somehow hinders interacting with the data using JS?

Sorry noob programmer here. But how does receiving all the semantic data and CSS related stuff help in parsing the data? The markup will further more have structural divs etc as extra baggage. JSON and XML in many frameworks like Rails, is rendered directly at the controller layer efficiently.

The point @blueD was trying to make, I think, is that you could let Sencha Touch do the rendering of your views and you focus on structuring your data. Plus, your web devt doesn't have to worry about changing his views anytime he likes without breaking the mobile app.

But how does receiving all the semantic data and CSS related stuff help in parsing the data? The markup will further more have structural divs etc as extra baggage.

The right question is how would it hinder? I don't see that it would. You can use query selectors on well written markup to access the data as easily as if it were JSON.

daemonsy wrote:

The point @blueD was trying to make, I think, is that you could let Sencha Touch do the rendering of your views and you focus on structuring your data. Plus, your web devt doesn't have to worry about changing his views anytime he likes without breaking the mobile app.

Neither well written markup nor well-formed JSON should require structural modification unless you're adding new data to the response. In this sense, they should be technically equivalent approaches. If you're changing markup because you need the view to look different, you're probably not writing very semantic markup. Visual changes should be done entirely with CSS with no markup changes. See also: http://www.csszengarden.com/

@Kethinov you're confusing a bunch of unrelated stuff here. I suspect you're not very familiar with how Touch does things, and it's fine, but you should really check out a demo app to get clarity on how we handle presentation vs. data.

But how does receiving all the semantic data and CSS related stuff help in parsing the data? The markup will further more have structural divs etc as extra baggage.

The right question is how would it hinder? I don't see that it would. You can use query selectors on well written markup to access the data as easily as if it were JSON.

daemonsy wrote:

The point @blueD was trying to make, I think, is that you could let Sencha Touch do the rendering of your views and you focus on structuring your data. Plus, your web devt doesn't have to worry about changing his views anytime he likes without breaking the mobile app.

Neither well written markup nor well-formed JSON should require structural modification unless you're adding new data to the response. In this sense, they should be technically equivalent approaches. If you're changing markup because you need the view to look different, you're probably not writing very semantic markup. Visual changes should be done entirely with CSS with no markup changes. See also: http://www.csszengarden.com/

Firstly, I think there's no argument that XML and JSON can be equivalent.The fight over there is about which is more efficiency, personal preference etc. As an example, Rails, at the controller layer, you can render an object as XML / JSON just by specifying a renderer.

@blueD suggested that the previous poster bring his view markup into the touch framework and use JSON to communicate data (correct me if I'm wrong). Let's get back to this HTML markup, which you suggested is no different vs JSON. But we're comparing oranges to apples here. This markup being implied here is at the frontend views layer of his web site. Considering a generic ecommerce Order object, no matter how semantic you are and how religious you are in using only CSS to affect the presentation of the content, you'll probably end up with structural divs, text formatting etc.

How are you going to pass all this data as markup? Yes you can ignore the formatting related tags, you may use html5 specifiers like <header>, <section>, it's still heavy. I believe most web frameworks have an ability for you to pass objects as raw jsons before reaching the views layer to aid the writing of APIs / apps. I dare say that is the most popular way it's being done. I surmise frontend designers will tell you that it is difficult to do changes on a site without the ability to inject new structural divs and whatnot.

Sorry for being angsty, I think @blueD simply gave the poster a suggestion. I think you're pushing hard on something that can be theoretically done (but uncommon and difficult) just to prove a point.

Given that the issue which concerns me about Sencha Touch is that it lacks progressive enhancement, which I've factually demonstrated, I suspect I'm familiar enough with how Sencha Touch does things. But let me know if there's something else I should be considering.

daemonsy wrote:

I think @blueD simply gave the poster a suggestion. I think you're pushing hard on something that can be theoretically done (but uncommon and difficult) just to prove a point.

I've been critical of JSON being used as the preferred data format for web apps for quite some time. Maybe there's something about it which makes it so trendy that I've yet to see, but from my vantage point all I'm seeing is unnecessary additional complexity. Since the browser needs the data to be rendered to the DOM as HTML anyway, so why not send it as HTML to begin with?

@Kethinov There are several good reasons to send data as data, not as (HTML) markup - and there are some good reasons to choose JSON over XML for data transport.

Sending data as data provides a nice disconnect between the data and the markup you will render to users. CSS works well for many aspects of visual rendering, but many other areas of presentation require specific markup or data manipulation (date formatting, or displaying "time ago" rather than date, paginating results, displaying a graph in place of tabular data, etc.) You could process a table, such as your book table, and transform that data into your desired markup (and call it "progressive enhancement") but I think you'd be stretching the concept. PE wasn't about formatting dates and the like, it was about bringing modern visual enhancement to your pages selectively based on capabilities. So I think sending data that looks like markup but is never going to be displayed as markup is confusing, dangerous, awkward, and provides no benefits.

And once your data grows beyond simple row/column - using a table becomes difficult. What if you decide to include the authors DOB. With JSON it is just "author":{ name: "Stuart Langridge", dob: "1972-01-31" }. Representing that in non-HTML XML would be reasonably easy, but in HTML markup XML it would get ugly quickly (nested tables?).

And finally - reading the DOM is slow - so for larger datasets, you want to choose JSON, which is native to JS, fast to read, and doesn't make a trip to the DOM first.

All good arguments. When you say that I'm stretching the concept of progressive enhancement, you're certainly right. I do believe it was meant for this though despite its apparent inadequacies. HTML5 even includes additional support for metadata, so you can embed semantic information that the user won't ever necessarily see that could (and should) be manipulated by Javascript in that fashion. But the weaknesses in the standard (as opposed to more free form XML or JSON) preclude much of that dream in the real world and as such I have to concede the point.

None of this quite addresses my other complaint about Sencha though. When you author a mobile web app in Sencha, what happens when you want to add support for older mobile devices or JS-disabled users? Or add a desktop flow without forking your templates? It sucks to rewrite your templates for multiple contexts. As such it seems like jQM is the way to go for broader device/browser support and its progressive enhancement even allows for supporting non-mobile browsers with new stylesheet.

True - it is unfortunate to have to write separate for desktop/mobile web.

But now that the Safari browser for iOS is on par with desktop browsers, and Android is getting closer - the same technologies can be used for both. So the question is more one of building for "app-like" behavior, or "web pages-like" behavior. It is also about touch vs. mouse. It can also about recognizing the different needs of phone users, tablet users, and desktop browser users.

I think that if you want app-like behavior (custom navigation, no back-button, native speed expectations, native-like or customized UX widgets, transparent "login", etc.), you will *want* to write for that specifically. Trying to coax that behavior via progressive enhancement from a standard web site will be more work and maintenance overhead than maintaining two projects (of course they can and should share backend services, certain graphic/CSS elements).

This has been my experience at least. So we went ahead and wrote our own web-app framework that can be used with both touch and mouse, leverages the YUI3 framework, and provides the rich scrolling/navigation, gestures, etc. expected with native apps. For our framework, authors start with valid HTML (peppered with data- attributes) to build the basic content/navigation. It can then be extended further with javascript. This seemed more intuitive to us.

But we have yet to try to utilize the base HTML of our web apps for a standard web site. We have always written that separately.