Thursday, June 17th, 2010

Sencha Touch: The end of native; A new touch framework for the Web

Category: JavaScript, Library, Mobile, Sencha

As I walked around Moscone last week, I saw some prophets speaking of a future that isn’t all Native. A future where the Web is the platform. Others saw it too:

I pondered who would be behind the act and smiled as I had a good idea. The group behind this all is the newly named Sencha (formerly Ext JS). On the back of news of the new company and Sencha Labs, we get a glimpse of their new product: Sencha Touch:

Sencha Touch allows your web apps to look and feel like native apps. Beautiful user interface components and rich data management, all powered by the latest HTML5 and CSS3 web standards and ready for Android and Apple iOS devices. Keep them web-based or wrap them for distribution on mobile app stores.

There are some good demos of apps such as GeoCongress, which shows off:

  • HTML5 Geolocation
  • Sench Touch icon set
  • JSONP Proxy
  • YQL Data Proxy
  • Momentum scrolling
  • Scroll touch event
  • Pop-up Overlays
  • Mobile form elements
  • CSS3 Gradients
  • CSS3 Transitions
  • Multi-Card Layout
  • Tab Panel Component
  • Scrollable list view
  • Swappable headers

Once you see what the framework can do with examples, what better way to get a deeper look than walking though as much of it as possible? Michael Mullany, VP Products, sat down and gave us just that. Sencha Touch comes with a “kitchen sink” demo that shows off much of its abilities. Here we see Michael showing off said demo:

After seeing this at work, we asked Michael some questions about the new product:

How are Ext JS, jQTouch, and Sencha Touch related?

We talked about some of this in the Sencha name change post. Jonathan Stark is taking over jQTouch maintainership, Dave Kaneda will remain involved but he’s been spending most of his energy on Sencha Touch. Sencha Touch has some Ext JS DNA (OO javascript, a lot of the data package is common), but the UI components are completely different.

Having David part of Sencha Touch has been incredibly important. That’s one of the reasons why the UI components are staggeringly beautiful, and there’s been so much attention to ease of styling.

With respect to jQTouch vs. Sencha Touch. jQTouch is a good solution for people who need some progressive enhancement of web content, but it’s not a full application framework.

What is the licensing plan for Sencha Touch?

The initial beta is under a GPLv3 + FLOSS license. We’d like to give open source folks the benefit before we introduce a commercial trial license. And we’d like to take the opportunity to emphasize something that many people miss: that we have Free and Open Source exceptions as part of our GPLv3 license. So if you want to, you can include Sencha Touch in your Apache and OSI approved licensed projects without triggering the GPL’ing of your project.

Can I make native looking controls for the particular platform at runtime?

In the beta, you can build multiple themes easily (for example, our Android theme is 20 lines of customized SASS), and serve them up to different clients based on user agent. We do want to provide a client-side switcher by release time. SASS is really an extraordinary technology. This would be far, far harder without it.

Are there any differences between it running on various platforms?

There are some minor differences, for example CSS 3D Transitions don’t work on Android, for example (no cube transitions). And Apple GPU accelerates more stuff. You can look at our demo apps across iPhone and Android. They really do work cross-platform.

How do I do layout with Sencha Touch?

We think most people will use fairly simple layouts with the built-in components since the screen sizes are small. Tabs, carousels, lists. If they want to get more complex, they can use the more complex layouts or just extend the built-in classes.

Can I create native apps from these? How do I access native services on the device?

Right now, you’re going to take Sencha and wrap it with phone-gap. But about two third of non-game apps don’t do any special device access, and camera access is on its way.

How does Sencha Touch feel to program (e.g. just like Ext?)

It’s still object oriented javascript but it’s really very simple. People can just look at the source to the demo apps (which are reasonably rich apps) and make their own decision.

Can I progressively enhance a mobile Web app and sprinkle in some of this goodness?

I think the success of iPhone native mobile apps shows that for mobile factors, it’s better if you think about layout and navigation first, then pour content into your containers & paths. In many ways, I think it’s the reverse of the desktop web. Desktop web apps can be random access in their user pathing, mobile apps have to be hierarchical or otherwise constrained — because you don’t have a lot of space and you can’t waste it on navigation controls.

Posted by Dion Almaer at 8:00 am

2.8 rating from 6 votes


Comments feed TrackBack URI

As I note in my own post on Sencha Touch (, it would be really great if someone built a cross platform App Store mechanism for web apps. I think that something like this could really get web applications the momentum that they need. Native apps are pretty ingrained in these devices, so a web app store would need to break that trend. Very nice work, Sencha team!

Comment by devongovett — June 17, 2010

Does Sencha work with Titanium?

Comment by triptych — June 17, 2010

Yeah, for me it was making no sense that jqtouch would stay on top of jQuery,

Until this.

This is a bit weird, now we will have Sensa touch that will not be free for commercial use,

and jQtouch that will be free, I kind of feel jQtouch cannot really grow that much in this context, what would be the point financially?

but anyway, the jQtouch beta is ages old and any update would be good at this point…

Comment by karnius — June 17, 2010

Devon — First off, thanks so much for the kind words, I love your feeds. Second, I totally agree, there’s still space for a web app store.

Triptych — Not sure how this would integrate with Titanium. I love Titanium and have a lot of respect for those guys, but their method is about porting web languages to create native widgets. We are fully recreating native feel within web apps. I think PhoneGap may be a better tool to use with Sencha Touch.

Comment by davidkaneda — June 17, 2010

What a bunch of marketing nonsense. Where to start? 225K+ for a mobile “framework?” The whole thing is based on UA sniffing. Yes, UA sniffing. It’s if Android do this, else if iPhone do that. Are they kidding? New devices come out all the time. Existing devices change on a dime. And you want the users of these things to download another 225K+ blob of JS every time “Sencha” issues another patch?! Forget it. :(

* Mobile users do not always have access to high-speed connections. * Mobile users have limited caches and memory.
* Mobile users are sometimes charged when they go over their download allotments.

Successful (i.e. faster and lighter and simpler than your competitors’ efforts) browser scripting has always been about *context*. Even the staunchest defenders of wasteful GP JS libraries have to admit that their “arguments” make zero sense in a mobile context.

Don’t drink this tea. ;)

Comment by DavidMark — June 18, 2010

@David. If you’re worked with mobile browsers, you know that feature-sniffing (the approach you’ve always advocated in your past criticisms of JQuery, Prototype, etc.) doesn’t work yet. Features that show up the same when they’re “feature-detected” don’t actually work the same, and for now, there is no alternative to user agent detection. Perhaps it will work some day. The base framework for Sencha is less than 80k gzipped – I’m not sure that you’re measuring. Yes mobile users do not always have access to high speed connections, that’s also what manifests and localStorage are intended to address.

Comment by ajxmullany — June 18, 2010

@ajxmullany (an ExtJS shill)

“If you’re worked with mobile browsers,”

I certainly have/do. I specialize in Mobile WebKit these days, so your attempt at a rebuttal is on shaky ground from the get-go. :)

“, you know that feature-sniffing (the approach you’ve always advocated in your past criticisms of JQuery, Prototype, etc.) doesn’t work yet”

That’s a ludicrous generalization and, as it happens, patently false. What doesn’t work (and will never work) is UA sniffing.

And I don’t advocate anything called “feature sniffing”. But I did write the proverbial book on feature detection and feature testing. I know there are some things that can’t be tested to 100% certainty, but that doesn’t mean you throw your hands up and use UA sniffing for *everything*. Clearly the developers of this thing, which is neither cross-browser nor progressive enhancement (as it is described in the promotional materials) have the slightest clue what they are doing.

I’ve leveraged all of the same features that you have (e.g. CSS3 standards and proprietary extensions), SQL, HTML5 audio/video, etc. It’s true that HTML5 audio – for example – cannot be pinned down on which audio formats it supports, but it sure as hell can be detected. I looked at your HTML5 audio rendition and it uses a UA sniff, falling back to an EMBED. It detects nothing and tests nothing. That’s about as regressive as it gets. Same goes for virtually everything else in there. Would you like me to post a public review of the code? Perhaps you would prefer to pick *any* feature in the thing and I’ll tell you how it could have been done competently. ;)

“Features that show up the same when they’re “feature-detected” don’t actually work the same, and for now, there is no alternative to user agent detection.”

That’s why you have to use feature *testing* for such cases. You are clearly years behind the times. It is really unbelievable that you would seek to argue such a case with me (in public no less).

“Perhaps it will work some day.”

Perhaps some day you will know what you are talking about. ;)

“The base framework for Sencha is less than 80k gzipped”

LOL. There it is. Marketing BS 101. You didn’t do your homework on me at all, did you?

Everything is smaller when ZIPped, isn’t it? Doesn’t make much sense to bring that up, unless you are trying to pull the wool over the eyes of the hopelessly naive. HTTP compression is not a *constant* and other assets aren’t typically measured in compressed form. The simplest way to compare specific scripts to other assets (e.g. other scripts, documents, etc. that reside next to them on the server) is in the form that they are deployed (i.e. minified but *not* compressed). Therefore yours is 225K, jQuery is 70K.

And, as an aside, my entire library, which does 50x more than this piffle (and includes features to detect CSS3 styles, proprietary events, etc.) is about 140K (and free for all). The Transform add-on adds about another 7K. It has audio to boot. With real feature detection per format. I recently wrote an HTML5 add-on for audio and determined that using that is silly at this point as you can’t reliably detect which formats will work (most major browsers seem to play only OGG’s). But I will post it as it is a major improvement over the pablum you are pushing.

Note that the server does not feature GZIP compression (nor is it on a CDN) and that it is a relatively huge all-in-one demo, with themes, audio, frames, etc. But once loaded, in my estimation, it outperforms your kitchen sink demo (i.e. it doesn’t drag my *desktop* test boxes to hell on every action). And the *uncompressed* script that makes it all go is about 80K (what a happy coincidence!) I have no idea how much smaller it would be after GZIP. Let’s just say much smaller than 80K. ;)

But you don’t need *any* script to use CSS3 and/or proprietary extensions, do you? You can get by just fine with 0K of script and degrade gracefully for agents that do not support such styles.

“I’m not sure that you’re measuring.”

You know *exactly* what I am measuring. And on the very remote chance that you didn’t before, you do now. Live and learn. :)

“Yes mobile users do not always have access to high speed connections, that’s also what manifests and localStorage are intended to address.”

You can’t solve problems for dial-up users (or those relegated to 25K cache limits for scripts) with 225K scripts. ;) And you certainly don’t need your script to dynamically create attributes and META’s (or to use local storage). You can simply include the required attributes and META’s in your mark-up. As for storage, the API’s (those of them that are actually usable today) are fairly straightforward. In that vein, look for a SQL add-on to my library in the near future. I’ve used that feature enough to know it is viable (and testable). Your thing is all pretty packaging (i.e. graphics) with no real substance to speak of.

And yes, that 25K limit is based on measuring the *uncompressed* script. The iPhone – for example – will clock you at 225K. And seeing how interdependent the code is, there is no use in creating partial builds. I’m afraid the entire thing is a non-starter on the Web (and I suspect you knew that already). Much of what you are pimping can be done in well under 25K of (uncompressed) script. As mentioned, some of it with 0K of script. ;)

Comment by DavidMark — June 18, 2010

And, so there are no misunderstandings, unlike your set pieces, that linked demo is not aimed at mobile devices. I’ve had reports that much of it works on handhelds, but it is does not attempt to deal with mobile idiosyncrasies in any way shape or form. For instance, the audio stuff is all about plug-ins with a proprietary fallback that works only for MSHTML derivatives (i.e. IE).

Taking audio as an example, to make it work (properly) with mobile devices, it would need to be taken one step further. The IE fallback (BGSOUND) is eminently detectable, so the final fallback would be to blindly use an OBJECT element (not a non-standard EMBED as seen in your script). If the agent in question could not handle the supplied format (e.g. MP3), no sound would be heard (same as with yours). No UA sniffs required and no need to “upgrade” the script when new agents are introduced or existing assumptions about known agents are invalidated.

So pick any sniff “enabled” feature in Sencha and I will post a non-sniffing, future-proof example that works in the two agents that you “support”, as well as anything else (present or future) that implements the required interfaces. You can be sure that none of them will require more than 25K of script (and as mentioned, some will require no script at all).

Comment by DavidMark — June 18, 2010

And I should add that talk of manifests and offline storage miss the point entirely. The scripts still must be *downloaded* and mobile connectivity is not high-speed or bust. One of the scenarios I alluded to was that mobile users are often stuck with low-speed connections.

Furthermore, a monolithic (as opposed to modular) browser sniffing (as opposed to feature testing) script must be downloaded repeatedly as inferences break, holes emerge and are subsequently patched over. This will run up the end-users’ phone bills for no good reason.

How curious that marketers don’t understand these issues. I suppose it they did they would still seek to obfuscate them with techno-babble and hype. Some things never change. ;)

Comment by DavidMark — June 18, 2010

// for old browsers
window.undefined = window.undefined;

The very first line and it’s a classic rookie blunder. Well, blunders in this case. First of all, to save you some time, this script hasn’t got a chance in hell in working in such old browsers. Second, why would such an “HTML5 framework” be concerned with such browsers at all? Third, do not augment host objects. In the global execution context, the – this – object is the Global Object. There is no need to reference the (host) window object at all (let alone attempt to modify it!)

isTablet: /ipad/i.test(Ext.userAgent),

Even the browser sniffing is poorly implemented. :(

isPhone: /android|iphone/i.test(Ext.userAgent) && !(/ipad/i.test(Ext.userAgent)),

Now there’s a stretch if there ever was one. :)

if (Ext.platform.isPhone) {

Tangling up UA the string with your CSS is not a strategy rooted in reality (let alone standards). Think about what this is doing and the much better alternatives available in CSS.

if (Ext.platform.isPhone) {
cfg = {
tag: 'embed',
type: 'audio/mpeg',
target: 'myself',
src: this.src || this.url,
controls: 'true'
} else {
cfg = {
tag: 'audio',
src: this.src || this.url

As alluded to previously, this is about as regressive and brittle as inferences get. Anything that is “not a phone” (at least not one the developers have heard of) supports HTML5? Anything that “is a phone” should use a non-standard EMBED element and supports MPEG’s? What sort of standards are these? This is supposed to be the latest and greatest thing for mobile standards-based development (if you believe the promotional materials) and it uses logic that would have been dismissed out of hand ten years ago, even for more forgiving desktop browsers.

if (Ext.platform.isPhone) {;

Again, you don’t need to know anything but basic logic to see that is a bogus inference. If some unrelated boolean is set then assume that has a callable property called “show”?

Search the Web for “isHostMethod”. :)

The way you detect HTML5 support is by creating an AUDIO element and detecting/testing its properties. To determine plugin support you check navigator.plugins and/or navigator.mimeTypes. If you can’t (as in the case of IE which does not populate these objects), which is determined by checking properties of the objects in question, then you check BGSOUND support in similar fashion.

And yes, I know that scripted HTML5 AUDIO elements behave in different ways, depending on the agent (or even the version of the agent). The answer about what to do about that depends on the context of the application. For example, is the intent to play a background sound? See how general-purpose aims paint developers into bad corners? All easily avoided by simply avoiding such aims. How many mobile apps do you need to write today? And (assuming it is more than one) does it make sense to tether them all to a single jack-of-all-trades script?

It should be noted that HTML5 is not even a standard yet, so messing with it at all at this juncture is playing with fire.

hasTouch: ('ontouchstart' in window)

Bad inference as the property could be anything. And never use the – in – operator with host objects (the results are not predictable).

if (this.useTouch) {
var target = Ext.platform.isAndroidOS ? document.body : document;
target.addEventListener('touchstart', this.onTouchStart, false);
target.addEventListener('touchmove', this.onTouchMove, false);
target.addEventListener('touchend', this.onTouchEnd, false);
else {
document.addEventListener('mousedown', this.onTouchStart, false);
document.addEventListener('mousemove', this.onTouchMove, false);
document.addEventListener('mouseup', this.onTouchEnd, false);

This is what I’m talking about. The useTouch flag indicates that the window object has an ontouchstart property (which could be anything). The above code then proceeds to add three listeners to either the document or body. That’s another bad inference. Worse still, the decision of whether to attach to the document or body is by UA sniff. (!) So if – for example – the Android changes its behavior to use the document or the iPhone changes its behavior to use the document, the script falls apart. And the question then becomes: what to do next? Swap the bad inference for another based on the observed behavior, breaking the script for everyone with older versions of the device (or OS)? Obviously that can’t fly. So you are left with the unappetizing prospect of adding another fork based on the version, adding more bloat and complexity to an already huge and complicated monlith, requiring end-users to download it yet again.

In short, the above is UA sniff nested in a sniff by object inference masquerading as feature detection. Inferences don’t come any more brittle than that. This is not a cross-browser strategy by any stretch of the imagination. As detailed, it’s not even a good multi-browser strategy. Even competent multi-browser scripts can only be expected to work in environments where they have been demonstrated to work. Think about that and how quickly things change on mobile platforms and it should be clear that such scripts are doomed to fail.

So what would I do for this case? I think it is quite clear how the detection should shake out. You shouldn’t need to know anything about Javascript, browser scripting, iPhones, Androids or anything but basic logic to figure it out.

First of all, detect whether the body supports the touch events in question. If it does, add the events to the body. From there, there are two ways to go. The safest bet would be to add the event to the document as well. You will be able to remove one of them after the first time through. The alternative would be to assume that if the body supports the events you don’t need to attach any listeners to the document. I don’t recommend the latter approach.

If the body does not support the events in question, you could do a less reliable test on the document (similar to the window test, but using the typeof operator). If that fails add the mouse events.

You could also add both sets of events for all agents. You could remove one set after the first time through.

// Safari absolute incorrectly account for body offsetTop.
if (Ext.platform.isWebkit && this.isStyle('position', 'absolute')) {
y -= body.offsetTop;

What a sweeping (and likely fleeting) generalization, clearly based on observed quirks in agents that were available (and not ignored) at the time the code was written. Things change fast on the Web, particularly in the mobile arena. Isn’t that the usual justifications for using such libraries? ISTM, such code is counter-productive if the goal is to shield developers from ever-shifting browsers. Furthermore, that issue is a piece of cake to feature test. There are numerous examples of such tests in My Library.

That’s after about ten minutes inspection, which indicates that the level of expertise of the best of those paid to work on this thing is lacking (else someone would have corrected these design mistakes before unleashing this thing on the general public). Instead, caches are filling up with dubious code that will soon have to be replaced (likely with more dubious code).

I could go on and on with that stuff, but ISTM that browser sniffing is just one of the problems for this thing. As mentioned, the size and monolithic nature of the script are even worse prospects.

For those wondering what to do instead of downloading 20MB of graphics + 225K of dubious script: decide what features you need to implement for your application’s context and implement them in as few lines of script as possible. Features like CSS3 transitions, animations, gradients, rounded corners, etc. can be implemented with no script at all. From what I’ve seen, even a browser scripting beginner should be able to come up with better logic than that found in Sencha Touch (which is basically a Frankenstein-like hybrid of a jQuery plug-in and a subset of ExtJS). And try not to tangle the functions up as you may want to re-use them individually.

If you want to offer an offline app, add a manifest. Want a special icon? Add a META element. Using for a script to do these things is a waste, not to mention contrary to established best practices.

Yes, this will require some work on your part, but you will learn in the process and if your competition takes the low road with an incompetently written monolithic monstrosity, you are sure to win in the end. End-users don’t know anything about the process. They only measure relative speed and reliability. And, of course, the more compatible the design, the more users will get your message. Excluding users of older, newer, unknown or otherwise unsupported devices in exchange for some pretty graphics is a really bad deal. Hint: artists work cheap; it’s the programmers who are expensive. That’s why the download is 90% graphics. ;)

Comment by DavidMark — June 18, 2010

Still trying to figure out what any of this (minus the audio/video glossing over) has to do with HTML5. (?)

if (Ext.isString(config.tabletStartupScreen) && Ext.platform.isTablet) {
rel: 'apple-touch-startup-image',
href: config.tabletStartupScreen
} else if (Ext.isString(config.phoneStartupScreen) && Ext.platform.isPhone) {
rel: 'apple-touch-startup-image',
href: config.phoneStartupScreen

This decision should not be tied to an arbitrary series of characters. ISTM I’d look at the viewport dimensions to determine whether the smaller or larger image makes sense. And shame on Apple for this collision. :(

From the (highly dubious) absolute positioning code (which you should never need):-

var body = document.body || document.documentElement,
dom = parent = this.dom,
x = y = 0;

if (!dom || dom === body) {
return [0, 0];

The body assignment is complete nonsense, as is the idea that the body is the origin.

// Fix bug caused by this:
if (Ext.platform.hasRightMarginBug && marginRightRe.test(prop) && out != '0px') {
display = this.getStyle('display'); = 'inline-block';
result = view.getComputedStyle(el, ''); = display;

Programming by mystical incantation. It’s all the rage in browser scripting, but there’s certainly no room for such dubious code on mobile devices. And the punchline is that Ext.platform.hasRightMarginBug doesn’t even exist. :)

if (app.getAttribute('name')) head.appendChild(app);
if (statusBar.getAttribute('name')) head.appendChild(statusBar);

if (appIcon.getAttribute('href')) head.appendChild(appIcon);
if (startupScreen.getAttribute('href')) head.appendChild(startupScreen);

Impossibly bad form (not to mention inefficient and error-prone) as the code that precedes this bit is responsible for setting the attributes in question. There is absolutely no reason that this script should be trying to read attributes at all (and this is the only place that it does).

getAttribute : function(name, ns) {
var d = this.dom;
return d.getAttributeNS(ns, name) || d.getAttribute(ns + ":" + name) || d.getAttribute(name) || d[name];

Oh brother. They could certainly lose this. This script hasn’t got a prayer of working in an XHTML DOM. And the code that calls this function does not pass the second argument. And the last disjunction is complete nonsense (DOM properties are not attributes).

* Sets the passed attributes as attributes of this element (a style attribute can be a string, object or function)
* @param {Object} o The object with the attributes
* @param {Boolean} useSet (optional) false to override the default setAttribute to use expandos.
* @return {Ext.Element} this
set : function(o, useSet) {
var el = this.dom,

for (attr in o) {
if (o.hasOwnProperty(attr)) {
value = o[attr];
if (attr == 'style') {
else if (attr == 'cls') {
el.className = value;
else if (useSet !== false) {
el.setAttribute(attr, value);
else {
el[attr] = value;
return this;

What can you say about such code? Like other “major” DOM scripting projects, this demonstrates a complete lack of understanding of basic DOM operations (i.e., they don’t understand how to manipulate attributes and properties any better than they know how to read them).

nodes = root.querySelectorAll(q[i]);

Where’s the try-catch? To assume that all “supported” browsers will work with the exact subset of possible CSS selector queries is madness.

// even though newer versions support DOMContentLoaded, we have to be sure
if(Ext.platform.isWebKit) {
var intervalId = setInterval(function(){
if(/loaded|complete/.test(document.readyState)) {
intervalId = null;
}, 10);

Near as I can tell, this thing is designed to support Webkit only, so what’s with the sniff? What I don’t see is direct detection of the property in question (document.readyState).

getOrientation: function() {
return window.innerHeight > window.innerWidth ? 'portrait' : 'landscape';

Good night. No use for the window.orientation property at all? And those are non-standard properties that should be avoided.

translatePoints : function(x, y) {
y = isNaN(x[1]) ? y : x[1];
x = isNaN(x[0]) ? x : x[0];
var me = this,
relative = me.isStyle('position', 'relative'),
o = me.getXY(),
l = parseInt(me.getStyle('left'), 10),
t = parseInt(me.getStyle('top'), 10);

l = !isNaN(l) ? l : (relative ? 0 : me.dom.offsetLeft);
t = !isNaN(t) ? t : (relative ? 0 : me.dom.offsetTop);

return {left: (x - o[0] + l), top: (y - o[1] + t)};

Pure gobbledygook. Called only from the setXY function, which is also nonsensical. Basically, they are trying to “simplify” positioning by tangling up absolute offsets and CSS positions (e.g. left/top rules). They’ve only made things worse. Much worse. Trust me. ;)

Doesn’t look like there is much of anything in this mess even remotely related to HTML5. Don’t see any CSS3 either, though there is a ton of proprietary (non-standard) Webkit stylings that could have easily been made to work cross-browser. Built on standards? What standards?

Who would have thought that two guys holding signs and dressed as Obi-Wan Kenobi could be so wrong? :)

Comment by DavidMark — June 19, 2010

Looks like a localStorage wrapper and some completely dubious audio/video creation functions are all that represent HTML5. That’s out of 225K of JS (not the 80K advertised). And every headline is screaming that this is the “first” HTML5 framework. As it is, it’s not even the first Webkit-specific mobile all-in-one-page wonder. That dubious distinction belongs to IUI (which is also a piece of trash). It will be interesting to see if developers are ignorant enough to buy this line. If junk like jQuery can become popular on marketing alone, then anything is possible.

Note to Sencha marketing department: CSS3 is not HTML5 and Webkit proprietary styles are not CSS3 either. Sheesh. :)


Comment by DavidMark — June 19, 2010

Oh sorry, it is actually 228K.

So where do the marketers come up with a “svelte” 80K? That’s the size it would be transported as if the client and server both support HTTP compression. That’s a perfectly useless figure for comparison purposes (and what other purpose could such a figure serve?)

GZIP is not a constant. For example, not all servers support HTTP compression.

The file system on the server sees it as 228K. The file system on the client see it as 228K. The software that must parse the script sees it as 228K of Javascript (most of which will likely go unused by the typical mobile Web application).

If you have a 50K HTML document and a 30K style sheet, is Sencha Touch bigger or smaller than the two combined? Does it make sense to ZIP the two and then compare the compressed total? Well, of course not; Sencha Touch is 228K, which is just under 3 times as large as 80K. Clearly that is the only comparison that matters (unless you are in advertising).

Furthermore, the size issue is not just about download time, but loading time and resource management. A 228K script will be be a drag on document responsiveness. It will also use a lot of resources which could have been otherwise used for the application code (or for more pretty graphics).

Don’t be hypnotized by the graphics and animations in the demos. The truth is that competent applications of this sort should have more CSS than script. The last one I wrote had roughly 20K of CSS and 5K of script (uncompressed of course). The documents (yes, more than one) were around 10K each and had to request assets only once due to far future expiration dates (so no manifests were needed). This left plenty of room for the graphic designers to go nuts (and did they ever). Furthermore, it attached no unload listeners, so fast history navigation allowed browsing back and forth between the views to be instantaneous (no complicated, error-prone faux navigation schemes required), the DOM state to be preserved for each. And I think it goes without saying that bookmarks worked as expected. :)

My application works on a whole hell of lot more than Webkit (e.g. Firefox, Opera, IE and their mobile variants) to boot. As a matter of fact, I’d be hard-pressed to find a browser it wouldn’t work with (granted, they wouldn’t all be animated) as it doesn’t even need XHR. I’d venture it will never have to be updated for new browsers either. That’s the benefit of using proper feature testing, sticking (mostly) to standards and keeping things as simple as possible. Sencha Touch is the polar opposite with browser sniffing, non-standard hacks and outrageous amounts of unneeded complexity needed to achieve a similar result in two browsers (and you have to wonder how much bigger and convoluted it will get when they try to add a third). It’s hard to see how anyone but marketers could spin that as progress.

I suppose if you don’t know what you are doing, you could download Sencha Touch, but it would be a better strategy to download graphics and start reading up on CSS3. There’s little need to worry about HTML5 yet (it’s still an unfinished draft and therefore years away from widespread adoption) and this script buys you virtually nothing in that area anyway.

I commented about some of these concerns on the official announcement blog post, but my entry seems to have been held up. Apparently nothing but “wowie, how cool is that?!” comments get past the censors. :(

Comment by DavidMark — June 20, 2010

Looking further into the one unique bit (an attempt at a cross-platform touch event wrapper), it appears to be an ill-advised series of mystical incantations. I don’t recommend intercepting those events at all on the Web (I’ve always left them to the browsers).

Could be useful for native apps built on HTML/JS, but certainly not as implemented in this thing.

I’ve been toying with the idea of a slimmed down version of My Library with a few extra features for Mobile Webkit (and perhaps a tiny bit of HTML5). After reading this thing from start to finish, I see that virtually everything they’ve crammed in there (save for touch events) exists in far better shape in My Library (or an add-on). Never bothered with geolocation either, but that’s all of a dozen lines of code. I’ll post a freebie reality check when I have a chance.

Comment by DavidMark — June 21, 2010


You’ve clearly spent a lot of time on your criticisms and I look forward to reading them thoroughly — I admit, I’ve only had chance to skim at this point. I’ve worked a fair amount on Mobile WebKit as well, in building jQTouch. I guess I also count as a marketer for Sencha Touch. I regret that you appear so upset by our release. A few very quick points:

* We promote 80kb downloaded & GZipped, because most good web developers make sure they’re on a proper server and GZip there code. jQuery also promotes this number.
* Both the JS and CSS for every component, like Carousel, List, Tabs, etc. can be disabled in a custom build, for performance.
* This is a beta.

We did grab some parts from Ext JS, like DOM manipulation, and try to optimize for Mobile WebKit. You’ve listed some great ways to optimize further above. Ultimately, we’re not perfect developers. But our new library covers our target devices with a unparalleled feature list and a lot of people already saying much they love it. I think we’ll see it really shine as more tablets emerge.

At any rate, this is why we have a beta. There’s no need for any sort of hostility — any constructive feedback you have is welcome on our forums.

Comment by davidkaneda — June 22, 2010

@David Kaneda,

“You’ve clearly spent a lot of time on your criticisms”

I really haven’t and that’s a big indicator.

“and I look forward to reading them thoroughly — I admit, I’ve only had chance to skim at this point”

There’s not a lot new there. This project is making all of the same mistakes as jQuery and the rest of the lot.

“We promote 80kb downloaded & GZipped, because most good web developers make sure they’re on a proper server and GZip there code. jQuery also promotes this number.”

jQuery is just as disingenuous with their marketing. They advertise a version with comments and white space and a GZIPped version. It’s the one in the middle that is missing (and it is the only useful number for comparison purposes). This has nothing to do with using a “proper server” or promoting best practices. It has everything to do with making the script sound smaller than it is when compared to other scripts and documents. Also, developers should not “GZIP their code”. That’s something that is left to the server and client agent to sort out. There’s no good reason to manually compress code, so compressed sizes are distinctly inconvenient for comparison.

“Both the JS and CSS for every component, like Carousel, List, Tabs, etc. can be disabled in a custom build, for performance.”

But you can’t prune very deep into the dependencies. Sure you can throw out some (or all) of the widgets, but you will still be left with a lot of unneeded syntactic sugar. And, of course, the CSS is hundreds more kilobytes on top of the script. You are asking developers to swallow half a MB before they’ve written a single line of code. What’s left for the application and assets (e.g. graphics, movies, etc.)?

Also, what builder?

“This is a beta.
We did grab some parts from Ext JS, like DOM manipulation,”

Beta or not, much of what I’ve noted are very basic blunders. Why did you copy DOM manipulation code from ExtJS? And why doesn’t ExtJS have better DOM manipulation code (after all of these years). It’s a very long way from browser sniffing to feature testing. Just how long is this Beta supposed to last?

” and try to optimize for Mobile WebKit.”

More like lobotomize. :)

“You’ve listed some great ways to optimize further above.”

Thanks, but I don’t recall talking of optimization at all. Changing bad logic (e.g. UA sniffing) to better logic is not optimizing.

“Ultimately, we’re not perfect developers.”

Clearly you are very new to cross-browser scripting (as was Resig, Stephenson, etc. when they designed and implemented their libraries). Why should mobile developers abdicate responsibility to you?

“But our new library covers our target devices with a unparalleled feature list”

Marketing BS. Do you really think that your “90%” grade is an A-? :) And your feature list is quite paralleled. You’ll see what I mean.

“and a lot of people already saying much they love it.”

I’ve seen the pictures of the clueless Web developers with the gushing blurbs beneath. You can fool a lot of the people a lot of the time in this industry.

“I think we’ll see it really shine as more tablets emerge.”

That makes no sense. New tablets will likely be the kiss of death for your script. You haven’t had a chance to observe those, so the bad inferences made for the two you have observed will likely break. Then it’s another 228K+ download to “correct” the problems, likely with more observation-based browser sniffing.

“At any rate, this is why we have a beta.”

The marketers haven’t really emphasized the Beta angle, have they? More like it’s the “first HTML 5 framework”. I see mentions of cross-browser capabilities as well, which is ridiculous. As noted, it isn’t even a proficient dual-browser script at this point. Are the developers going to suddenly acquire cross-browser proficiency after years of copying and pasting jQuery and ExtJS code? I can’t see it.

“There’s no need for any sort of hostility — any constructive feedback you have is welcome on our forums.”

Who’s hostile? And are you implying that my feedback so far has not been constructive?

Comment by DavidMark — June 26, 2010

I’m just a bystander here, far from having your knowledge, but as a modest being I must admit there are ways to express oneself and you sure took the rough and tough one. I guess all of what you expressed could be said in a more mild mannered way, the way peers use when reviewing their works.
Kind Regards,

Comment by stephaneeybert — July 5, 2010


I call ’em like I see ’em. :)

And this is not a peer review. This is basically an infomercial for a defective product, which I’ve done my best to warn you away from. This is a peer review:-

…but of course, with a script as mind-boggling bad as Sencha Touch, it’s going to come off as brutal (at least to the uninitiated). That’s hardly my fault. If there was anything positive to say about it, I certainly would have. As it is, there isn’t so I didn’t.

Code doesn’t have feelings and neither do corporate marketing departments. The latter are typically out to fleece you as well. So don’t cry for them. ;)

Comment by DavidMark — July 16, 2010

I’m surprised that somebody that claims to be so smart and awesome (DavidMark) that your web site looks like I took a dump in Dreamweaver MX and it somehow made it onto the web. I think it’s extremely UNproductive to crap all over someone’s work in long rants. Takes a lot of effort to just troll a message board about it. **ROLL EYES** I am glad I don’t have to work with anyone so brash and critical as you. We’re not all genius programmers and sip on our Bawls all day. I hate for this to come off so personal but I think naive people like you think you’re doing some kind of service to the development community, but you just perpetuate the stereotype that “good” programmers are assholes like you. By the way I do agree with the point that it’s crap that you all are licensing this instead of providing it free.

Comment by hoffmabc — July 24, 2010

@hoffmabc I think DavidMark has the right to be critical and angry at people who lie about how great their product is and take advantage of dumbfounded people to make some cash. These guys are no different than dirty mechanics. They promote web standards, but really? Take one peek at what’s under the hood (the code). Like David says, they are using these great marketing terms to draw naive people. It’s pretty ironic you would call David “naive”. He’s far from it and it’s funny you would bash on his site and imply he made it with dreamweaver. I don’t think he ever said he was a graphic designer and I bet he is cringing now with the mention of dreamweaver. I know you’re trying to be some nice guy who wants to say something to the bully but your whole post actually confirms how naive you are. You have no idea who the bad guy is.

Comment by gdesigner — August 13, 2010

Dude, the stuff you’ve been bashing is all kitchensink demo code, not even the framework itself. Yeah, they need to improve lot of things but it doesn’t change the fact that this is currently by far the best touch device framework out there.

Comment by hummerabi — August 24, 2010

Leave a comment

You must be logged in to post a comment.