Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mobile development with HTML5

engineyard.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Mobile development with HTML5

#31

Post by megaman821 »

dreamdu5t wrote: post #3

Real-world web-app development is much different than the ideal of HTML5. jQuery? Just including that puts your mobile web-app at 86KB of JavaScript and you haven't even written a single line of your app's code. Rendering on the client-side with jQuery templates is not anywhere near practical for the majority of web-enabled phones – if not all of them except the iPhone. More than 100-150KB of JS and most phones will…

Except for testing most this advice is awful. jQuery is 31KB not 86KB. CSS3 is or has plans to be hardware accelerated on all major platforms.

Also what exactly is your claim on how size is greatly affecting performance? That Android takes a long time to deflate a large zipped javascript file or that it takes a long time to parse a large javascript file or the large javascript libraries are ineffecient? Do you have any evidence on these things?

Re: Mobile development with HTML5

#32

Post by jbail »

jammus wrote: post #24
jbail wrote: post #2

Nice overview. One note of caution: Rendering on the client side using jQuery Templates as the author suggests is great for small amounts of content, but even a list with 40 items will nearly freeze the UI while its rendered. I've experienced this on both iPhone and Android. Also, using a cache manifest will cache your AJAX/JSONP calls. Either explicitly list these URLs in the network section of your manifest or add…

Was this a straight HTML list or were you using a jQueryMobile listview to pretty it up? When we've used templates to render a list (using either underscore or ejs) it was taking 10-20ms to generate the initial HTML but around 10-15x as long to call listview on it.

I was using jQuery Mobile. The listview framework is a big part of the performance problem.

Needless to say, the best advice I would give (that others have said here as well) is to avoid frameworks like jQuery Mobile. There many other reasons too...not least of which is that jQuery Mobile doesn't work on T-Mobile or O2 in the UK and parts of Europe. It appears these networks intercept all traffic and try to minify the JS and CSS before they deliver it to the phone. There is some part of jQuery Mobile that they choke on and the page doesn't render correctly. I've tested extensively using Perfecto Mobile and even the jQuery Docs & Demo pages don't work right (so I know its not just me).

Re: Mobile development with HTML5

#33

Post by fortes »

masklinn wrote: post #29
saurik wrote: post #21

I use the HTML5 app cache. I have tens of millions of users on this in-production product. I only really feel safe doing this because I have a custom web browser, and as I only target jailbroken devices I can hack at WebKit a little to make this work. When I started using it, it seemed awesome. Then I played with it a little, and it started failing. Given that I have friends who actually give talks at conferences on…

> does anyone care? does anyone actually intend to try to use this feature? ;P Yes, that's a very interesting (if disheartening) exposé on the risks of trying to use the application cache.

Agreed, this is the type of specific, practical content that is so hard to find.

Re: Mobile development with HTML5

#34

Post by jbail »

saurik wrote: post #21

I use the HTML5 app cache. I have tens of millions of users on this in-production product. I only really feel safe doing this because I have a custom web browser, and as I only target jailbroken devices I can hack at WebKit a little to make this work. When I started using it, it seemed awesome. Then I played with it a little, and it started failing. Given that I have friends who actually give talks at conferences on…

I've experienced this too and no longer use the app cache either. I use the browser cache and that means that yes, the user must have network connectivity to load the page, but at least it always works and the cache doesn't get into a jacked up state.

Re: Mobile development with HTML5

#35

Post by dreamdu5t »

megaman821 wrote: post #31
dreamdu5t wrote: post #3

Real-world web-app development is much different than the ideal of HTML5. jQuery? Just including that puts your mobile web-app at 86KB of JavaScript and you haven't even written a single line of your app's code. Rendering on the client-side with jQuery templates is not anywhere near practical for the majority of web-enabled phones – if not all of them except the iPhone. More than 100-150KB of JS and most phones will…

Except for testing most this advice is awful. jQuery is 31KB not 86KB. CSS3 is or has plans to be hardware accelerated on all major platforms. Also what exactly is your claim on how size is greatly affecting performance? That Android takes a long time to deflate a large zipped javascript file or that it takes a long time to parse a large javascript file or the large javascript libraries are ineffecient? Do you have a…

jQuery 1.6.2 is 94KB minified. Gzip compression is not applicable here because the code being executed is not 31KB, that's just the download size.

The amount of JS that has to be interpreted by the browser does noticeably affect performance. At least in my experience testing and building webapps for mobile phones, over 100KB of JS and many devices start to manifest performance issues. I find it interesting so many people here question JS size affecting performance, when this has been the main focus and selling point of browser development for the last year.

CSS3 animations and gradients are not really feasable for anything but the iPhone at this point. On HTC devices running Android 2.3, just adding a CSS3 gradient to each item in a list slows my scrolling speed significantly and introduces stutters in the scroll, versus using a PNG of the same gradient I'm using CSS for. This is just one example of many, but CSS3 support is very shoddy on devices outside of the latest iPhones.

Re: Mobile development with HTML5

#36

Post by dreamdu5t »

DanielBMarkham wrote: post #28
dreamdu5t wrote: post #3

Real-world web-app development is much different than the ideal of HTML5. jQuery? Just including that puts your mobile web-app at 86KB of JavaScript and you haven't even written a single line of your app's code. Rendering on the client-side with jQuery templates is not anywhere near practical for the majority of web-enabled phones – if not all of them except the iPhone. More than 100-150KB of JS and most phones will…

Ok, I'm getting ready to write an HTML5 app for cross-platform use. I grok what you're selling, but looking at JQuery, and especially Sencha Touch, I'm asking myself: how the heck could I make a native-looking app in plain JS without having to dive deep and beating the hell out of myself with all this crap that's already been solved? Are you saying that the extra UI snazzle just isn't worth it? Or to buck up and star…

It's not that making native-looking apps in plain JS isn't worth it – it's not possible unless you're only targeting iPhone.

There may be a place for jQuery, but stay away from Sencha Touch. It's a huge library, and barely runs on any device but an iphone. Don't be fooled by their slick marketing and examples.

Essentially, trying to replicate a native app in JS is a losing battle, unless your app is extremely simplistic. The majority of smartphones are simply too underpowered to replicate a native experience.

Aim for a site like http://m.twitter.com instead of trying to replicate a native experience. Test on real devices you intend to support as soon as possible, even if you've barely written the app.

Re: Mobile development with HTML5

#37

Post by dreamdu5t »

johnbender wrote: post #16
dreamdu5t wrote: post #3

Real-world web-app development is much different than the ideal of HTML5. jQuery? Just including that puts your mobile web-app at 86KB of JavaScript and you haven't even written a single line of your app's code. Rendering on the client-side with jQuery templates is not anywhere near practical for the majority of web-enabled phones – if not all of them except the iPhone. More than 100-150KB of JS and most phones will…

I'm curious what browsers you're supporting and experience you're aiming for with your hand rolled javascript. Targeting phones outside of iOS and Android with anything but the most basic functionality is a difficult task without help. A prime example being the 500+ ms delay created when adding event listeners for click instead of touch events. Click covers everything but it creates a perceptibly slow ui for the user…

Browsers supported are IE6+, IE Mobile, Opera Mini, Safari 3+, Chrome, Firefox 3+, blackberry browser, android browser, symbian's web browser, pretty much everything that renders the important parts of CSS1/2 and has JS support.

Pretty much an experience like http://m.twitter.com

The click delay workaround is like 15 lines of JS. It's one of the few issues (along with foreach) requiring a major workaround, if you design your HTML/CSS layouts properly. Also, don't forget you can take what you need from jQuery or other libraries. For example, the click delay workaround I think I grabbed from HTML5 mobile boilerplate, and my foreach function I grabbed from jQuery.

Re: Mobile development with HTML5

#39

Post by jammus »

jbail wrote: post #32
jammus wrote: post #24

Earlier quoted context omitted.

Was this a straight HTML list or were you using a jQueryMobile listview to pretty it up? When we've used templates to render a list (using either underscore or ejs) it was taking 10-20ms to generate the initial HTML but around 10-15x as long to call listview on it.

I was using jQuery Mobile. The listview framework is a big part of the performance problem. Needless to say, the best advice I would give (that others have said here as well) is to avoid frameworks like jQuery Mobile. There many other reasons too...not least of which is that jQuery Mobile doesn't work on T-Mobile or O2 in the UK and parts of Europe. It appears these networks intercept all traffic and try to minify th…

Thanks for this info. I wasn't aware of potential carrier-specific issues so I'll make sure we take this in to account while testing. Have you raised this with the networks? I guess there's a chance that it could also affect non-jqm powered code.
Post reply on HN