
Mobile development with HTML5 - ubi
http://www.engineyard.com/blog/2011/mobile-development-with-html5/
======
dreamdu5t
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
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
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
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
HN isn't the place for novelty accounts

------
jbail
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
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
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
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.

------
keeperofdakeys
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
Setting user-scalable=no makes me RAGE at the developer, and then generally
close the site.

~~~
aphexairlines
Shouldn't you rage at your browser for respecting the flag?

~~~
count
That's a constant low level burning though.

------
andybak
"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)

------
saurik
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>

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.

~~~
masklinn
> 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.

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

------
warmfuzzyapps
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.

