6 ms·

Mobile development with HTML5

90 points by ubi 15y ago

jbail 15y ago
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 a timestamp to each request so its unique.
- jammus 15y ago
  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.
  - jbail 15y ago
    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).
    - jammus 15y ago
      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.
dreamdu5t 15y ago
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.
  - 15y ago
warmfuzzyapps 15y ago
In addition to powering full blown web apps, web technologies can also be used from within web views to create hybrid native/web apps. I have a post on idevblogaday.com today on calling Objective-C from JavaScript, calling JavaScript from Objective-C, and logging to the Xcode console from JavaScript.
keeperofdakeys 15y ago
I recently visited a site from HN on my phone, but its text was a bit too small for me to read, so I tried zooming in. To my surprise, it didn't zoom at all! From this article, the website must have set user-scalable=no. I don't really see the point of this option. The website can (presumably) scale to many different devices already, surely it can then scale with zooming as well. I'd think you could use percentages to create any kind of 'static' ui, if you really wished to do so.
- count 15y ago
  Setting user-scalable=no makes me RAGE at the developer, and then generally close the site.
  - aphexairlines 15y ago
    Shouldn't you rage at your browser for respecting the flag?
    - count 15y ago
      That's a constant low level burning though.
- deleted 15y ago
  [deleted]
- rokekr 15y ago
  user-scalable=yes breaks presentation on iPad when switching orientation http://adactio.com/journal/4470/ http://adactio.com/journal/4470/
  - keeperofdakeys 15y ago
    As annoying as it is, it makes sense that some web developers would choose this option. Although, limiting the experience for everyone just because one mobile browser has a bug? I'm pretty sure something similar happened with a certain browser called ie6. From the link you gave, it looks like you can just detect an iPad and disable zooming in that case (although, that requires some javascript or server side programming). So, which version of iOS do they plan on fixing this (or did fix this)? But then, that doesn't factor the people who don't know about OS updates and never sync.
saurik 15y ago
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 the HTML5 application cache and how cool it was, this didn't make any sense: I believed I must be doing it wrong. Then, one day, I decided to read the source code for WebKit's implementation of the HTML5 application cache, and found it to have tons of race conditions that would lead to whole-browser crash conditions (which I was even experiencing in my app). I even found a bug on the bug tracker with my most-occurred bug on it. https://bugs.webkit.org/show_bug.cgi?id=43506 https://bugs.webkit.org/show_bug.cgi?id=43506 Only, that bug had been filed only months before, and this feature of WebKit had been "in production", with these bugs, for a couple years. My only guess is that no one really uses this feature very often. Reading into the bug tracker some (to find more bugs), staring at the commit messages for the previous year, and even reading some of the posts on the mailing list, I found choice quotes from the people maintaining it that explained that no one knew how this code works, and that the one guy who did forgot. In iOS 4.3 (I believe it was only 4.3, not 4.2, but I'd sort of believe 4.2, /maybe/ even 4.1), the crash bugs have been "fixed" (or I'd have given them to comex to maybe build another jailbreakme.com), but the race conditions remain: the code doesn't actually /work/, it just sort of doesn't fail. Specifically, the issue is that the application cache loader for a page is tied to a specific frame: the one that started loading the cache. If that frame is freed, such as by the simple act of the user hitting the reload button, while the download is occurring, the entire thing gets wedged, and you can no longer get any parts of your page cached, nor can you recover or fix the process without the user totally closing the web browser and reopening it. In practice, this actually happens constantly: if the user has a reasonably slow connection, and things are taking a while in the background to cache, they will hit reload. This deletes the old frame, but associates a new frame with the same cache builder. When the current download stops, the frame it was using is gone, and it ends up in this horrible wedge state. Ok, I no longer even remember why I'm bothering to type this here (does anyone care? does anyone actually intend to try to use this feature? ;P), but I also no longer seem to have anything more to say, so I'm going to click "add comment" ;P.
andybak 15y ago
"user-scalable=no". Is this really the way forward? Why the assumption that the only reason I might zoom in is 'accidental'? Also I am uneasy about populating all content via JSON but I can't put my finger on the precise technical reasons (but then neither could Gawker wrt desktop browsers so they went ahead with it anyway)

90 points by ubi 15y ago

jbail 15y ago

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 a timestamp to each request so its unique.

jammus 15y ago
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.
- jbail 15y ago
  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).
  - jammus 15y ago
    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.

dreamdu5t 15y ago

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

warmfuzzyapps 15y ago

In addition to powering full blown web apps, web technologies can also be used from within web views to create hybrid native/web apps. I have a post on idevblogaday.com today on calling Objective-C from JavaScript, calling JavaScript from Objective-C, and logging to the Xcode console from JavaScript.

keeperofdakeys 15y ago

I recently visited a site from HN on my phone, but its text was a bit too small for me to read, so I tried zooming in. To my surprise, it didn't zoom at all! From this article, the website must have set user-scalable=no. I don't really see the point of this option. The website can (presumably) scale to many different devices already, surely it can then scale with zooming as well. I'd think you could use percentages to create any kind of 'static' ui, if you really wished to do so.

count 15y ago
Setting user-scalable=no makes me RAGE at the developer, and then generally close the site.
- aphexairlines 15y ago
  Shouldn't you rage at your browser for respecting the flag?
  - count 15y ago
    That's a constant low level burning though.
deleted 15y ago
[deleted]
rokekr 15y ago
user-scalable=yes breaks presentation on iPad when switching orientation http://adactio.com/journal/4470/ http://adactio.com/journal/4470/
- keeperofdakeys 15y ago
  As annoying as it is, it makes sense that some web developers would choose this option. Although, limiting the experience for everyone just because one mobile browser has a bug? I'm pretty sure something similar happened with a certain browser called ie6. From the link you gave, it looks like you can just detect an iPad and disable zooming in that case (although, that requires some javascript or server side programming). So, which version of iOS do they plan on fixing this (or did fix this)? But then, that doesn't factor the people who don't know about OS updates and never sync.

saurik 15y ago

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 the HTML5 application cache and how cool it was, this didn't make any sense: I believed I must be doing it wrong. Then, one day, I decided to read the source code for WebKit's implementation of the HTML5 application cache, and found it to have tons of race conditions that would lead to whole-browser crash conditions (which I was even experiencing in my app). I even found a bug on the bug tracker with my most-occurred bug on it. https://bugs.webkit.org/show_bug.cgi?id=43506 https://bugs.webkit.org/show_bug.cgi?id=43506 Only, that bug had been filed only months before, and this feature of WebKit had been "in production", with these bugs, for a couple years. My only guess is that no one really uses this feature very often. Reading into the bug tracker some (to find more bugs), staring at the commit messages for the previous year, and even reading some of the posts on the mailing list, I found choice quotes from the people maintaining it that explained that no one knew how this code works, and that the one guy who did forgot. In iOS 4.3 (I believe it was only 4.3, not 4.2, but I'd sort of believe 4.2, /maybe/ even 4.1), the crash bugs have been "fixed" (or I'd have given them to comex to maybe build another jailbreakme.com), but the race conditions remain: the code doesn't actually /work/, it just sort of doesn't fail. Specifically, the issue is that the application cache loader for a page is tied to a specific frame: the one that started loading the cache. If that frame is freed, such as by the simple act of the user hitting the reload button, while the download is occurring, the entire thing gets wedged, and you can no longer get any parts of your page cached, nor can you recover or fix the process without the user totally closing the web browser and reopening it. In practice, this actually happens constantly: if the user has a reasonably slow connection, and things are taking a while in the background to cache, they will hit reload. This deletes the old frame, but associates a new frame with the same cache builder. When the current download stops, the frame it was using is gone, and it ends up in this horrible wedge state. Ok, I no longer even remember why I'm bothering to type this here (does anyone care? does anyone actually intend to try to use this feature? ;P), but I also no longer seem to have anything more to say, so I'm going to click "add comment" ;P.

andybak 15y ago

"user-scalable=no". Is this really the way forward? Why the assumption that the only reason I might zoom in is 'accidental'? Also I am uneasy about populating all content via JSON but I can't put my finger on the precise technical reasons (but then neither could Gawker wrt desktop browsers so they went ahead with it anyway)