Hacker News Reader

Comment by Hisoka | Hacker News Reader

I may be ignorant, but to write a complex app, don't you need HTML5 AND a mobile javascript framework like JQuery Mobile and Sencha? Or does HTML5 handle that too? If it does require a Javascript framework, that's when the quality deteoriates... I think imitating the look and feel of native apps is easy. Making the performance smooth on the other hand is hard.

View on HN

I'd say they're both hard. As an interface designer who works on iOS apps, it always pains me to see a web technology mobile app that's trying to look like it was built with UIKit but it's ever-so-slightly off. Some pixels are broken, text looks wrong, padding is off. I know why it's alluring, but I'd much prefer to see them craft their own interface style without aping Apple's UIKit look and feel.

If someone is trying really hard to emulate a native app's interface but without native technologies, I think they're already doing it wrong. Focus on the UX, not taking a different framework's exact visual style and copying it pixel for pixel.

HTML5 is JavaScript. Without JavaScript, HTML5 is just a few semantic HTML tags (like header and section) and a few extra form input attributes (like required and placeholder).

As far as JavaScript frameworks go, you could use Sencha or jQuery Mobile or one of the other few dozen frameworks out there --- or you could roll your own.

I've been doing mobile web development for about a year now. I've done both PhoneGap and over-the-air mobile web/native apps (with embedded webviews that load HTML/CSS/JS from the web when requested). Both types of apps accepted by Apple and in the Appstore as well as in the Android Market. I would recommend rolling your own and not trying to imitate the look of native apps. One of the strengths of using HTML5 is that you can create a custom look and feel that doesn't look like every other app out there.

Since you mentioned Sencha and jQuery Mobile, here's what I think having used both:

Using Sencha is nothing at all like using HTML5. You don't even write HTML or CSS. You write JavaScript that uses Sencha's classes/methods. The look and feel very much tries to mimic native and they do a pretty good job at it...except that most widgets look like they were ripped from an iPhone, which is disorienting for users on Android. That said, you get good performance and a boatload of widgets/ui controls out of the box. The price for this is a large, multi-hundred kb framework and a commercial license.

jQuery Mobile doesn't really try to look native and it really doesn't "feel" native either. jQuery has it's own ui controls that more or less look identical on iPhone or Android. With jQuery Mobile, you do write HTML and have a more transparent view of that as well as of the CSS. But, you have to write HTML the "jQuery Mobile way" to utilize the UI built into the framework. You don't get as many widgets and ui-controls as you do in Sencha and overall, the look and feel is not of the same caliber either. But, it's smaller than Sencha, has your standard MIT license and is more easily modified.

Neither is perfect and both have pluses and minuses. If you know some HTML, CSS and JavaScript, you will absolutely get better performance and and a smoother look and feel by rolling your own light JavaScript for your app that does just what it needs to do.

If you'd like to see an example app I built using PhoneGap and handrolled HTML/JavaScript/CSS, you can download Easy Baby from the Android Market. It's free. You'll find a link to it on my website: http://newbabysleep.com

I can't see why anybody would actually use jQuery Mobile and Sencha for web app development. I've tried them last week and they were impressive on a desktop browser. On a mobile device, not so much. Both jQuery Mobile and Sencha feel slow, very slow. The animations are choppy. Response times on clicks are way too long. Everything flickers like mad. Focus borders are drawn at all the wrong places. I can actually feel that it's a web app trying too hard to be a native app. On my Android phone it's even slower than on my iPad 1.

I'm not blaming jQuery Mobile or Sencha. I think mobile browsers are just not ready for delivering a smooth UI experience that's up to par with native apps.

I agree somewhat, and would add that I wish jQuery Mobile would focus more on being a solid compatible framework for mobile 'websites' than in emulating the features/transitions of a native app.

Agreed. When i first heard about jQuery mobile i was hoping they would take the familiar jQuery syntax and add things like touch events and optimize it for mobile. However, you really can't make your own custom jQ mobile site without getting the 'app' thing. Also, you need to include the normal jQ library, which is a pretty big download and includes lots of cross-browser code for fixing old IE bugs.

Right now i guess either rolling your own framework or looking into alternatives like Zepto.js makes more sense.

Mobile web development requires a different way of thinking about code. Every line counts. More lines equals a larger code graph in browser memory and starts to affect your app's performance.

Mobile web frameworks get you an immediate boost in developer productivity, but down the road, those gains are given back as you try to achieve reasonable performance, which to some extent is a fools errand because you just have so much library code bogging down the browser/webview.

Other parts of a mobile web app, like CSS3 transitions, will perform as well as the browser/phone lets them. Using CSS3 for transitions and animations is definitely "the right way", but as of now, these are pretty clunky on most phones.

I've been using phonegap and jQM since pre-alpha, and I've found it to be a near-native experience on the iphone and impressively responsive on android and palm. I think the alpha version had some flickering, and it is a bit slower on android, but if there is "mad flickering" something likely wasn't done right.

Somehow we ended up with very different experiences. I played with Sencha Mobile Kitchen Sink demo on the iPhone 4 and it was quite impressive. http://www.sencha.com/products/touch/demos/

Yes, it lags ever so slightly, but faster CPU in iPhone 5 should take care of that. My only other complain is that they messed up calculating tap areas for tabbar/toolbar items - Sencha has tap area equal to the visual size of the button, whereas UIKit assigns entire section of the toolbar (44 pixels tall in portrait), which makes a lot of difference in tap detection. But I don't see why they can't fix it, and then it would be pretty good...

To be clear, I am still staying away from UIWebView in favor of UIKit, but I am getting increasingly interested in this.

Yes, it lags ever so slightly, but faster CPU in iPhone 5 should take care of that.

This is always the reply of web developers -- even on the desktop! "Yes, it's slow now, but it'll be faster with new hardware!".

Meanwhile, the native applications use that additional processor power to do more stuff, and the webapps fall further behind again.

So? Desktop HTML/JS was too slow for a while, all the way until the point when it became fast enough to handle maps, email, finance etc. Remember MapPoint? It used o be a desktop map application. No one uses it anymore.

I have to wonder who is the downvoting person, who beleives the above post does not contribute to the discussion? Would you rather this not be posted at all? Because if you keep with the downvotes that's what's going to happen - no links to Sencha demo, no keen observations about tap areas, no personal opinion from experienced i-thing developer.

I also wonder where are the people who would appreciate this sort of contribution. They gotta be somewhere...

> The price for this is a large, multi-hundred kb framework and a commercial license.

Sencha Touch is free now (not sure when that happened). And the multi-hundred kb framework isn't much of an issue since it's bundled up in the native download and always local to the device.

The overall size of the code graph in browser memory matters. It's not just about the size you're delivering over-the-air. That said, I have apps in both the Apple Appstore and Android Market that have embedded webviews that pull down the mobile web app portions from the air. This allows 100% freedom in changing/fixing things. In these cases, yes, size matters.

Reply on news.ycombinator.com