Sencha Touch 2.0(sencha.com)
sencha.com
Sencha Touch 2.0
http://www.sencha.com/blog/announcing-sencha-touch-2
13 comments
There's no native code. The themeing is done using different stylesheets based on sass.
unoti probably means 'javascript' by 'native code'. So, yes, the structure and behavior is defined through javascript (working in tandem with the appropriate stylesheets, of course), as opposed to defining a scaffolding of HTML and manipulating the DOM as needed as with JQMobile.
Both are nice. Sencha Touch expects certain conventions be followed which can be great if you don't trust your (or your team members') discipline. But it can also be a bit full of magic if you don't know your way around the ecosystem. Luckily the documentation is pretty great, the team is responsive to their forums and the community is pretty engaged and helpful. Also, the Designer is wonderful!
JQMobile is wonderful for teams that are used to more 'traditional' (read: more server side heavy) web apps and/or know JQuery like the back of their hand (which is many of us these days) and that can put together disciplined code without much supervision.
I use them both and I like them both. I am looking forward to developments on both sides.
Both are nice. Sencha Touch expects certain conventions be followed which can be great if you don't trust your (or your team members') discipline. But it can also be a bit full of magic if you don't know your way around the ecosystem. Luckily the documentation is pretty great, the team is responsive to their forums and the community is pretty engaged and helpful. Also, the Designer is wonderful!
JQMobile is wonderful for teams that are used to more 'traditional' (read: more server side heavy) web apps and/or know JQuery like the back of their hand (which is many of us these days) and that can put together disciplined code without much supervision.
I use them both and I like them both. I am looking forward to developments on both sides.
Looking at the source code of the example projects, it seems that Sencha Touch continues to use HTML/JS/CSS as a development environment for native apps, not to be used on the web in any other way than as mobile apps. For instance, a search engine cannot read any content presented by a Sencha app, unlike a jQuery Mobile app. To me, this makes their description of Sencha Touch 2.0 as an HTML5 framework disingenuous. All attacks that have been made against Flash for compromising the accessibility of content for a slick user interface can be levied against Sencha Touch. Can this be avoided?
You can pretty easily add a print page and point the search engines to that. They use this for JsDuck - https://github.com/senchalabs/jsduck
I'm currently working on an offline web app based on ST2. So far the experience is positive. Since the framework is easy to add into a html5 appcache manifest, it's relatively easy to turn it into an offline app. The ui components are very high quality. I'm also really digging the mvc architecture with device profiles, which let you adjust your views for tablets or phones with common models and controllers.
Ofcourse it's not a native app, and you can tell. Fidelity is the downside of using ST2 instead of native. The upside is easier deployment (it's just a web app), and ios, android and blackberry support from a single codebase (windows phone is coming, but not ready yet).
Ofcourse it's not a native app, and you can tell. Fidelity is the downside of using ST2 instead of native. The upside is easier deployment (it's just a web app), and ios, android and blackberry support from a single codebase (windows phone is coming, but not ready yet).
A bloated, poorly documented, needlessly abstracted 300KB mess with slick marketing.
Don't waste your time: Grab iScroll and roll your own mobile webapp.
Don't waste your time: Grab iScroll and roll your own mobile webapp.
Bloated - yes a bit. I tried doing a custom build removing classes I didn't need manually, I could go down about 220KB and still have my app run. Similar things can be done to the css. It would be great if their jsbuilder could also pick and reject used/unused sencha classes to produce optimal build.
Choice of sencha touch also depends on where the majority of your user base lives. If I've to deliver something to India, 300KB in a webapp would be impossible given the great connectivity over phones here.
Poorly documented - well not exactly, in fact they've made a great effort to produce useful guides. API docs let your own add comments within the docs too.
Themeing - delightful, I get great control over how my app looks. I've built a nice abstraction atop their scss code that enables me to produce new themes for my app with 10-15 lines of code and deliver it to new customers. Thx to scss/compass.
Frequency of Pain in the Ass while working with it for 2+ months - very less compared to most other frameworks.
Amount of code you write over about the 300KB - quite less, unless your UI is completely completely different (mine is).
Integrating with your backend's APIs - smooth as silk, thanks to the awesome data store and model classes. They've been there since 1.1. They've been there since pre-backbone era.
Now they've got scaffolding tools to produce skeletons too, in case you were confused about the MVC approach which was unclear for quite some time. Studying examples helps a lot. My app has become too heavy - 20+ views, 15+ custom UI components, 8+ stores, 20+ controllers. Their MVC & the new class system results in a very maintainable code. Though I'm in the phase of re-architecturing my app and implement a view cache as seen in kitchen sink. I also feel putting in many sencha classes is heavy, I plan to reduce the views and controllers as much as possible. Our initial UI was done by a graphic designer in photoshop, it didn't care much about sencha touch's existing components. In turn trying to replicate the photoshop work as much as possible, has also resulted in some slow performance (translucent backdrops, shadows)
I'm heading on for a re-write with performance in mind. Been using sencha touch 2 right from alphas in Nov/Dec AFAIR. It's gone through some really sweet changes from 1.1. Kudos to sencha team for knowing what exactly their user-base needs.
Choice of sencha touch also depends on where the majority of your user base lives. If I've to deliver something to India, 300KB in a webapp would be impossible given the great connectivity over phones here.
Poorly documented - well not exactly, in fact they've made a great effort to produce useful guides. API docs let your own add comments within the docs too.
Themeing - delightful, I get great control over how my app looks. I've built a nice abstraction atop their scss code that enables me to produce new themes for my app with 10-15 lines of code and deliver it to new customers. Thx to scss/compass.
Frequency of Pain in the Ass while working with it for 2+ months - very less compared to most other frameworks.
Amount of code you write over about the 300KB - quite less, unless your UI is completely completely different (mine is).
Integrating with your backend's APIs - smooth as silk, thanks to the awesome data store and model classes. They've been there since 1.1. They've been there since pre-backbone era.
Now they've got scaffolding tools to produce skeletons too, in case you were confused about the MVC approach which was unclear for quite some time. Studying examples helps a lot. My app has become too heavy - 20+ views, 15+ custom UI components, 8+ stores, 20+ controllers. Their MVC & the new class system results in a very maintainable code. Though I'm in the phase of re-architecturing my app and implement a view cache as seen in kitchen sink. I also feel putting in many sencha classes is heavy, I plan to reduce the views and controllers as much as possible. Our initial UI was done by a graphic designer in photoshop, it didn't care much about sencha touch's existing components. In turn trying to replicate the photoshop work as much as possible, has also resulted in some slow performance (translucent backdrops, shadows)
I'm heading on for a re-write with performance in mind. Been using sencha touch 2 right from alphas in Nov/Dec AFAIR. It's gone through some really sweet changes from 1.1. Kudos to sencha team for knowing what exactly their user-base needs.
We had a quite similar experience (not just with Sencha Touch, but with jQuery Mobile too): http://blog.roveb.com/post/17259708005/our-experience-with-j...
Painfully slow on my Samsung Tab 10.1 running Android 3.2. It even crashes on the stock browser.
Also, for some weird reason I can't view the main content on Sencha's site. http://dl.dropbox.com/u/2664274/SC20120307-203127.jpg
Also, for some weird reason I can't view the main content on Sencha's site. http://dl.dropbox.com/u/2664274/SC20120307-203127.jpg
About performance.. or more importantly "feeling", how does it compare with native iphone app? I.e. does it have a 2 secs lag on everything that is clicked, etc.
Open this URL on your phone to see:
http://dev.sencha.com/deploy/touch/examples/production/index...
My impression- there is still a huge different in the "feeling" of a native app v. a Sencha app. As a "mobile first" developer, I wouldn't dream of using Sencha.
The good news for Sencha is that many companies will prioritize cost/platform reach and a "good enough" experience will be, well, good enough.
My impression- there is still a huge different in the "feeling" of a native app v. a Sencha app. As a "mobile first" developer, I wouldn't dream of using Sencha.
The good news for Sencha is that many companies will prioritize cost/platform reach and a "good enough" experience will be, well, good enough.
At least on Android, it "feels" fast enough. However, it breaks navigation when you use the Back button (in the interface) and the Back button (part of Android).
This alone, makes the app clunky.
This alone, makes the app clunky.
Not if you use routes properly. I've been able to get the browser back and device back button on android work right for my work.
On "feeling fast enough", let's pick a jquery mobile case, I tried http://www.jqmgallery.com/2012/02/11/sharksfrenzy/ on galaxy s2 (dual core, etc) and iPhone 4s. The list (notice its translucent, and overly decorated) scrolls like snail on the android phone. While it flows very smoothly on iPhone 4s.
A similar list would do better than that on Android if done in Sencha Touch 2.
On "feeling fast enough", let's pick a jquery mobile case, I tried http://www.jqmgallery.com/2012/02/11/sharksfrenzy/ on galaxy s2 (dual core, etc) and iPhone 4s. The list (notice its translucent, and overly decorated) scrolls like snail on the android phone. While it flows very smoothly on iPhone 4s.
A similar list would do better than that on Android if done in Sencha Touch 2.
I don't experience the sluggishness on my Galaxy Nexus in Chrome Mobile Beta (16.0.912.77). It scrolls very smooth (no lag, or jitter), although the refresh button is a little off (square corners on the bottom).
If you are getting a two-second lag on something it is because you are building an application that is blocking on remote assets, not because you are rendering using HTML; there are many native applications on the iPhone (including ones from Apple) that have two-second delays when you click things, and it is because they are pulling information from some API, such as YouTube, to render the content.
As for "feeling", however, there are a ton of little things that are broken: the blue touch highlight sometimes clears and sometimes doesn't (seemingly dependent on the target of the link, not the source), they are doing some silly HTML5 pushState mechanism to mess with the back button incorrectly (specifically, pushing a new state when you go "back" in the UI when that should really pop a state), etc..
The thing that is really freaking me out is that I'm having a hard time figuring out if they are using native scrolling or not (as in, on iOS 5.0, you can just say "this div is scrollable", and not have to re-implement the behavior): the curve seems wrong and glitchy, but they have nailed enough of the actual visual elements that it is no longer obvious to me that it isn't just that they figured out a way to make the native scrolling perform poorly. ;P
As for "feeling", however, there are a ton of little things that are broken: the blue touch highlight sometimes clears and sometimes doesn't (seemingly dependent on the target of the link, not the source), they are doing some silly HTML5 pushState mechanism to mess with the back button incorrectly (specifically, pushing a new state when you go "back" in the UI when that should really pop a state), etc..
The thing that is really freaking me out is that I'm having a hard time figuring out if they are using native scrolling or not (as in, on iOS 5.0, you can just say "this div is scrollable", and not have to re-implement the behavior): the curve seems wrong and glitchy, but they have nailed enough of the actual visual elements that it is no longer obvious to me that it isn't just that they figured out a way to make the native scrolling perform poorly. ;P
They're not using native scrolling, here's the code: http://docs.sencha.com/touch/2-0/source/Scroller.html#Ext-sc...
In my experience, performance on iOS is fantastic, while Android lags behind a small amount. Sencha isn't quite at the Native speed level yet, although it's certainly close.
Well just remember, you're building your homes inside the browsers, the day Android fucks up or the day apple announces a radical change to their browsers, it might affect everyone. Well for all good reasons everyone has an incentive to improve their browsers so far.
That is true of any platform you write for.
Performance on iOS is superb. Performance on Android is workable - I test regularly on Desire HD and Galaxy S2. Without animations android performance is really usable, even in a heavy app like mine (shit loads of decorations, 3k js)
Of course it doesn't have a lag. You can't actually differentiate a native and a sencha app.
Was your post sarcastic? I'm wondering because if you try http://dev.sencha.com/deploy/touch/examples/production/kitch... on an ipad, it's really slow.
Their kitchen sink demo is really slow on my Touchpad with CM9 alpha0.6.
Good stuff. We use ST for everything and have anxiously been awaiting this release.
Yup it was a joyful evening :) We were just talking about some core issues with our apps and poof! there comes the tweet announcing the release. They've been rolling out updates pretty fast when you look at Beta1,2,3 and RC1,2 dates.
So far been fairly happy with SC2, my client has built a proof of concept app that probably pushed the limits of the framework for controllers/models/views/etc but it's still performent on most of the iOs/apple devices.
Anyone here who has used both PhoneGap and ST? How do they compare?
They're not mutually exclusive.
I've used Sencha Touch before to provide a nice fat-finger-friendly version of Sencha's Ext-JS user interfaces on the iPad and it's a nice framework for providing rich UI components and also helps you segregate your UI itself into models, views and controllers.
I've used PhoneGap to wrap web-based projects for native device access to APIs you can't get a hold of using plain javascript or that wouldn't be exposed via Sencha Touch - PhoneGap provides an app shell, a UIWebView to execute your web app inside and a lot of nicely wrapped device level APIs accessible to your javascript code.
If you just want the web app stuff, Sencha Touch is really nice but a little heavy compared to options like jQuery Mobile so I'd use it in future for things that are very custom-component heavy like grids and complex forms, and for bigger applications where compartmentalisation is more important - whereas I'd stick to something like jQuery Mobile for just mobile-friendly UI elements like buttons and basic form controls or for a more simple app.
Sencha Touch has a bit of a learning curve compared to typical web app work, as the entire interface is typically declared within Sencha and UI elements instantiated and passed around, whereas with jQuery Mobile or the likes you can get away with just making it up mostly in HTML and throwing in JS components as and when you need them. To me, Sencha Touch is a slightly bigger all-or-nothing approach.
PhoneGap I would use in general any time I had to get access to device level APIs that ST v2.0 hasn't provided or anything else in bespoke native code that can't be done within a web app.
I've used Sencha Touch before to provide a nice fat-finger-friendly version of Sencha's Ext-JS user interfaces on the iPad and it's a nice framework for providing rich UI components and also helps you segregate your UI itself into models, views and controllers.
I've used PhoneGap to wrap web-based projects for native device access to APIs you can't get a hold of using plain javascript or that wouldn't be exposed via Sencha Touch - PhoneGap provides an app shell, a UIWebView to execute your web app inside and a lot of nicely wrapped device level APIs accessible to your javascript code.
If you just want the web app stuff, Sencha Touch is really nice but a little heavy compared to options like jQuery Mobile so I'd use it in future for things that are very custom-component heavy like grids and complex forms, and for bigger applications where compartmentalisation is more important - whereas I'd stick to something like jQuery Mobile for just mobile-friendly UI elements like buttons and basic form controls or for a more simple app.
Sencha Touch has a bit of a learning curve compared to typical web app work, as the entire interface is typically declared within Sencha and UI elements instantiated and passed around, whereas with jQuery Mobile or the likes you can get away with just making it up mostly in HTML and throwing in JS components as and when you need them. To me, Sencha Touch is a slightly bigger all-or-nothing approach.
PhoneGap I would use in general any time I had to get access to device level APIs that ST v2.0 hasn't provided or anything else in bespoke native code that can't be done within a web app.
Thank you for the detailed response. I really appreciate that, and it's helped me better understand the intended purpose of these frameworks.
They're different products for different purposes. Using Sencha Touch and PhoneGap together works really well. You can develop your app in a browser using the Sencha Touch framework then simply drop your code into a PhoneGap Xcode or Eclipse project and your pretty much ready to submit to the relevant app stores.
My app doesn't need native capabilities as of now. I'd stick to their native packaging tools - zero learning.
See towards the end - http://vimeo.com/37974749 . The Ext.device.[Camera,Device,Connection,Geolocation,Notification,Orientation] APIs support both Phonegap and their own native packager.
See towards the end - http://vimeo.com/37974749 . The Ext.device.[Camera,Device,Connection,Geolocation,Notification,Orientation] APIs support both Phonegap and their own native packager.
Using ST2 for one of our apps, running within Phonegap. Performance is so-so. No match for native. Pretty easy development though.
You can get great performance (at least for iOS) if you develop it right. Besides much of the performance cost is due to CSS3 and not Sencha Touch in particular. Put $include-highlights : false in the SASS file and you'll see the difference.
Nice work John ;)
What is up with the use of the font "klavika-web-1" on their site for <h2> styling? It renders pretty ugly in Chrome.
Looks okay here (in both Safari and Chrome on OSX):
http://civicit.com/~tvon/sencha-heading-font.png
http://civicit.com/~tvon/sencha-heading-font.png
But then I found that I'm kinda having to roll a lot of my own UI elements, using old school CSS and Javascript. I'm combining iScroll (a javascript scroller for touch drag scrolling). It's all very interesting and exciting, but it certainly feels like more of a "Research" project and less of a "Development" project, because there are no real models of how things are done to look at. I feel like I'm constantly blazing a trail of semi-undiscovered country.
It looks like Sencha is taking a different approach, and implementing some of these UI elements in native code, with different implementations on different platforms, rather than it being just a traditional DOM app?