5 ms·

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 ha

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 enter sluggish territory. Something you'll notice reading about HTML5 is most books and online articles are written by people who have never built or released web-app to be run on phones less powerful than an iPhone 4. They picked up an HTML5 book and regurgitated everything and every new nifty feature into their own words and examples. My advice? Don't use jQuery or any framework. Use native JS and only the functions you need, don't use CSS3, keep the DOM structure as simple as possible, and test from day one. My entire web-app's JS is 60KB minified, because I don't rely on framework's like jQuery (86KB) or Sencha Touch (250KB). These sizes don't matter on a desktop computer, but on an HTC from last year running Android 2.3, size greatly affects performance.

geowa4 15y ago
I agree that it is important that you keep your application small. However, using the application cache like the author suggests means that you will never have to download the specified content, like jQuery, again. Additionally, since you have 5MB of storage, I really don't think the 31KB of jQuery really matters. I agree that client-side rendering is not optimal, but for different reasons. This isn't 2006 anymore, phones are more powerful now. Unless I absolutely have to, I'm not going to care about your Nokia from back in the Stone Age. My problem with client-side rendering is that it chokes on large data-sets. You also have to pay the penalty to download the dynamic content after you download the static content, but this can be mitigated by only updating the content, rather than using AJAX to load it all to begin with. That also kills the author's use of the plug-in that stores AJAX data locally, but that's a separate issue. My advice: Use jQuery, jQuery Mobile, and AppCache. When combined, jQuery and jQuery Mobile (including CSS) take up 58KB of space. Oh, and since you're storing it all locally from now on, there's no need to cry about the time (less than 1s on 3g) it takes to download all those fancy JS files.
- dreamdu5t 15y ago
  I'm not talking about download times, I'm talking about execution time. Size affects execution performance, whether it is cached or not. This is because almost invariably the larger the JS is, the more code you're likely executing.
  - HardlySarcastic 15y ago
    This is exactly why I run my text editors in Windows 95 still. There is far less code than current versions of windows and I find a huge performance hit when using these newer versions.
    - VMG 15y ago
      HN isn't the place for novelty accounts
  - wvenable 15y ago
    That's not necessarily true; jQuery does all kinds of performance tricks that are far too complicated to do in straight JS code.
ubi 15y ago
All of your points are well taken. The purpose of this article was to collect and explain a number of things I wish I knew when I started working with mobile HTML5. I stated in the article that the topics are basic ones, tho I think valuable, I fully agree they are not ment for a serious scale application.
rimantas 15y ago
> don't use CSS3 Be careful with your advice. Using CSS3 3D transforms gives you hardware acceleration.
- earnubs 15y ago
  Only on iOS AFAIK, coming in later Android (3.0?)
epidemian 15y ago
Asking from nearly complete ignorance here but: with a JS compiler/optimizer like Google's Closure [1] wouldn't it be possible to still use jQuery but have all the unnecessary code that's not used striped out? [1]: http://code.google.com/closure/compiler/ http://code.google.com/closure/compiler/
- chrisbroadfoot 15y ago
  I'd take a guess that you need to write your JS with Closure in mind. I wonder how much jQuery code would be stripped out with the Closure compiler.
  - epidemian 15y ago
    That might be the case. This blog post [1] shows some examples of what the advance optimizations do and it seems that, while it'll shorten everithing up, things that are put in the global namespace (window) will not be stripped even when they aren't called. As jQuery adds the 'jQuery' and '$' variable to the global namespace and all it's functions are attached to that object, I would assume that the Closure compile connot remove any of them. Of course, this is all pure speculation, it'd be much better to test this out. [1]: http://www.bitstorm.org/weblog/2010-8/Introduction_to_the_Google_Closure_Compiler.html http://www.bitstorm.org/weblog/2010-8/Introduction_to_the_Go...
    - chrisbroadfoot 15y ago
      Closure can definitely remove functions that are never called - but I wonder if its static analysis can figure out jQuery style code. My guess is that it'll do a decent job, but jQuery would need many changes to get it to compile.
johnbender 15y ago
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.
- dreamdu5t 15y ago
  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 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.
jc123 15y ago
Don't use jQuery or any framework http://zeptojs.com http://zeptojs.com is worth considering for some cases (~5k micro-library for mobile WebKit browsers)
DanielBMarkham 15y ago
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 start trying to replicate huge pieces of frameworks on my own?
- dreamdu5t 15y ago
  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 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.
megaman821 15y ago
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?
- dreamdu5t 15y ago
  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.

geowa4 15y ago

I agree that it is important that you keep your application small. However, using the application cache like the author suggests means that you will never have to download the specified content, like jQuery, again. Additionally, since you have 5MB of storage, I really don't think the 31KB of jQuery really matters. I agree that client-side rendering is not optimal, but for different reasons. This isn't 2006 anymore, phones are more powerful now. Unless I absolutely have to, I'm not going to care about your Nokia from back in the Stone Age. My problem with client-side rendering is that it chokes on large data-sets. You also have to pay the penalty to download the dynamic content after you download the static content, but this can be mitigated by only updating the content, rather than using AJAX to load it all to begin with. That also kills the author's use of the plug-in that stores AJAX data locally, but that's a separate issue. My advice: Use jQuery, jQuery Mobile, and AppCache. When combined, jQuery and jQuery Mobile (including CSS) take up 58KB of space. Oh, and since you're storing it all locally from now on, there's no need to cry about the time (less than 1s on 3g) it takes to download all those fancy JS files.

dreamdu5t 15y ago
I'm not talking about download times, I'm talking about execution time. Size affects execution performance, whether it is cached or not. This is because almost invariably the larger the JS is, the more code you're likely executing.
- HardlySarcastic 15y ago
  This is exactly why I run my text editors in Windows 95 still. There is far less code than current versions of windows and I find a huge performance hit when using these newer versions.
  - VMG 15y ago
    HN isn't the place for novelty accounts
- wvenable 15y ago
  That's not necessarily true; jQuery does all kinds of performance tricks that are far too complicated to do in straight JS code.

ubi 15y ago

All of your points are well taken. The purpose of this article was to collect and explain a number of things I wish I knew when I started working with mobile HTML5. I stated in the article that the topics are basic ones, tho I think valuable, I fully agree they are not ment for a serious scale application.

rimantas 15y ago

> don't use CSS3 Be careful with your advice. Using CSS3 3D transforms gives you hardware acceleration.

earnubs 15y ago
Only on iOS AFAIK, coming in later Android (3.0?)

epidemian 15y ago

Asking from nearly complete ignorance here but: with a JS compiler/optimizer like Google's Closure [1] wouldn't it be possible to still use jQuery but have all the unnecessary code that's not used striped out? [1]: http://code.google.com/closure/compiler/ http://code.google.com/closure/compiler/

chrisbroadfoot 15y ago
I'd take a guess that you need to write your JS with Closure in mind. I wonder how much jQuery code would be stripped out with the Closure compiler.
- epidemian 15y ago
  That might be the case. This blog post [1] shows some examples of what the advance optimizations do and it seems that, while it'll shorten everithing up, things that are put in the global namespace (window) will not be stripped even when they aren't called. As jQuery adds the 'jQuery' and '$' variable to the global namespace and all it's functions are attached to that object, I would assume that the Closure compile connot remove any of them. Of course, this is all pure speculation, it'd be much better to test this out. [1]: http://www.bitstorm.org/weblog/2010-8/Introduction_to_the_Google_Closure_Compiler.html http://www.bitstorm.org/weblog/2010-8/Introduction_to_the_Go...
  - chrisbroadfoot 15y ago
    Closure can definitely remove functions that are never called - but I wonder if its static analysis can figure out jQuery style code. My guess is that it'll do a decent job, but jQuery would need many changes to get it to compile.

johnbender 15y ago

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.

dreamdu5t 15y ago
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 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.

jc123 15y ago

Don't use jQuery or any framework http://zeptojs.com http://zeptojs.com is worth considering for some cases (~5k micro-library for mobile WebKit browsers)

DanielBMarkham 15y ago

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 start trying to replicate huge pieces of frameworks on my own?

dreamdu5t 15y ago
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 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.

megaman821 15y ago

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?

dreamdu5t 15y ago
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.