Mobile development with HTML5
engineyard.com
Mobile development with HTML5
1–10 of 39 posts
Re: Mobile development with HTML5
#2Nice 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.
Re: Mobile development with HTML5
#3Real-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.
Re: Mobile development with HTML5
#4Real-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 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.
Re: Mobile development with HTML5
#5Real-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 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, p…
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.
Re: Mobile development with HTML5
#6In 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.
Re: Mobile development with HTML5
#7Real-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…
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.
Re: Mobile development with HTML5
#8Earlier quoted context omitted.
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, p…
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.
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.
Re: Mobile development with HTML5
#9I 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.
Re: Mobile development with HTML5
#10Earlier quoted context omitted.
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, p…
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.
That's not necessarily true; jQuery does all kinds of performance tricks that are far too complicated to do in straight JS code.