
Mobile Apps: HTML5 vs Native - Rexxar
http://www.ericsink.com/entries/html5_vs_native_apps.html
======
rodion_89
The argument that HTML5 apps cannot provide sufficient quality is growing
increasing weak. There is no question that native apps provide better UI's,
especially in the case of iOS.

As for Facebook, they built a terrible iOS app and blamed the technology. It
doesn't matter what technology you use: own up and build good products.

HTML5's problem is mobile browsers. They are all non-compliant with a myriad
of quirks. You can build nifty native-like UI's in the iOS browser, but it
takes lots of time to understand exactly how Mobile Safari implements 3d
transforms and how they are so terribly bizarre. I won't even start with the
Android browser because the situation is significantly worse[1].

We can build good mobile browsers. The problem is that mobile OS venders have
had little incentive to build browsers capable of hosting competing apps with
their respective marketplaces. They all build browsers that can view
traditional webpages well, but no more.

[1] Anyone who brings up mobile Chrome will get a mouthful about why that's
terrible as well.

~~~
melling
Rather than provide an academic argument as to why HTML5 apps are as good as
native, it would be better to provide great examples of where it has worked.
Even Steve Jobs originally thought web apps were all you needed but he was
eventually convinced otherwise.

In short, how about some proof by example? Lots of examples...

~~~
rodion_89
> There is no question that native apps provide better UI's

This is was me talking about mobile. Then I went on to explain why. So I don't
think I need to provide any examples there.

As for HTML5 on the desktop you can peruse the Chrome Web Store to find some
good stuff. iCloud.com is actually an excellent example of HTML5 done right
(for the most part).

~~~
blub
Your html5 done right example fails to work on all three browsers on my phone
(opera,firefox,native). Quite a performance...

~~~
rodion_89
> HTML5 on the desktop

I wasn't talking about mobile.

Try iCloud.com on Mac Safari, it's quite nice. Not sure what browsers Apple is
targeting for this.

My assumption is that the 5 major desktop browsers can host web apps of this
quality if the app developer chooses to target them. Hopefully as time passes
the "chooses to target them" part won't be an issue if standards-compliance is
a norm.

------
georgemcbay
We are now into year 5 of "HTML5 is going to obsolete native apps in the next
couple of years"... with no end in sight.

~~~
marknutter
Come on now, it took at least this long for web apps to obsolete most native
desktop apps. As mobile devices get more powerful with every passing year, I
see no reason why history won't repeat itself.

~~~
TheFuture
Yeah, none of us are using Microsoft Word any more.

Ever print anything from Google Docs? Look at the typography. Look at the
letter spacing and kerning. It's a joke.

And don't even get me started on javascript.

I like to use word processing as an example because it's probably been the #1
client app for 40 years with no web app competitor even close. I would argue
1992 WordPerfect is better than Google Docs in quality, features, and
reliability.

The last decade of software development has been focused on web apps, and the
promise that it's write-once-run-everywhere. So we've all been suffering by
taking a huge step backwards in UI/UX by shoving everything in a browser.

It is just not there. So you can keep struggling with your ugly javascript
hacks and unsupported CSS quirks. But the best stuff is being made on the
client right now. It's cleaner, easier to maintain code, and the UI/UX is
delighting users. User's don't care about cross-platform.

~~~
ssk42
Would you mind elaborating on how WordPerfect in 1992 is better than modern
day Google Docs?

------
elpool2
I'm not seeing how thick vs thin clients has anything to do with the html5 vs.
native debate. You can build an html5 based app that's just as "thick" as a
native iOS app, it just uses a different technology to render the UI.

~~~
rodion_89
UI rendering and a sane threading model are two major steps that could end
these premature HTML5 vs native debate.

I wait for the day when these debates are equivalent to arguments about
programming language preference.

~~~
wahnfrieden
What's insane about web workers? (Just curious.)

~~~
rodion_89
I actually like the way Web Workers can't touch the DOM. It's nice to finally
give the DOM it's personal space for UI operations, which often leads to much
more responsive apps especially at a large scale.

The pain points for me come in the form of shared dependencies. Large pieces
of code that are accessible to multiple threads, and perhaps the UI thread,
must get imported several times.

The lack of access to localStorage hurts in a lot places because any cache
access must send data back and forth on the UI thread for operations that are
probably entirely unrelated.

The lack of console.log makes debugging considerably worse. There are a couple
of hacks to get around this but it's a bit crazy to pass messages between
threads just to get a log printed.

Having to create a file per thread is very much a pain. Certain operations are
tiny in terms of code and make more sense in the context of where you want to
run theme. It'd be nice to run any function on a separate thread. Conceptually
that would get weird because it would violate several properties of JavaScript
closures. But it'd be nice to find some acceptable way of doing this sort of
thing.

Web Workers are pretty good but can be unfriendly to developers at times.

~~~
wahnfrieden
Thanks for elaborating :) Good points.

------
hxf148
My two latest HTML5 apps, <http://appeio.com> for App.net which made it into
the Apple iOS store and brand brand new <http://podglass.com> which is my
personal solution to podcast headaces.. and a reason to start pushing
boundaries with <audio> and <video>.

It's getting there, in two years a good HTML5 app will be very close and in
some situations a better choice. Native will improve also but browser tech is
due to leap by 2014.

iOS will have a good run and so will Android but the web is open and will
never get obsoleted.

------
hnriot
I can't help but find his arrogance about being right annoying, especially
when he points to how battery technology hasn't improved since Kennedy was in
power, which is just ignorant and wrong. Much of the limiting growth in mobile
computing power has been gated by battery power and steadily the technology
has improved.

The debate has been going on since the browser was created, and it's really
not a debate at all, the HTML to render a text box and the iOS native code to
do so all call the same operating system library anyway, it's just a matter of
where the development team decide to draw the line between ease if install and
development vs speed and a richer user experience. This is fluid and shifts
over the years as browser technology becomes more expressive.

But I dislike reading articles that are just full of weasel wording, no
examples to back up his points and technology inaccuracies.

------
pjmlp
This is quite right, HTML 5 sucks for application development.

It has come to replace Java with code once, debug everywhere.

Every single browser version, even from the same vendor, or operating system
has a different understating what CSS, HTML, JavaScript means.

~~~
rimantas
And all this on top of the fact that HTML was not intended to build apps and
it shows. No matter what is built on top foundation will still be messy and
shaky. Just a few months ago I was working on moderately complex web app and
even with some nice tools helping to bring some sanity into it (backbone,
coffeescript, etc.) we had to reinvent a lot of thing that native APIs give
you for free.

It really makes me wonder about those proclaiming superiority of HTML5 over
native: did they build anything nontrivial in it and did they try to do the
same with native approach.

Alas, I see html approach as "mediocre everywhere and pain to develop". And I
say this as a guy who _does_ know HTML, CSS and JS :(

~~~
pjmlp
As a contractor most of the projects I work on are web based ones.

Every time I manage to land a native application contract I am thrilled to get
away from such headaches.

Specially the ones discussing pixel level behavior with the customer or trying
to making him/her understand why certain desktop like features are not
possible at all in a browser world.

------
ripperdoc
Nice analysis, but only half of the story. As pointed out in the comments, you
can make thick or thin clients in both native and HTML5. The issue is rather
the one about lowest common denominator. HTML5 aims at working in very varied
"runtime environment", where standards are bendable, bugs are rife and feature
support a few years behind what native could muster. HTML5 is more difficult,
and does not have all the tools, of the native environment. So the question is
rather - will HTML5 develop faster than native and thereby be on par with it,
or will it always be the straggler?

~~~
chii
There is incentive from the platform creators to make their native UI better
and better, but not the same incentives for making the HTML5 support (if they
are in charge of it, e.g., a browser).

By this argument, native will always have features that HTML5 is not able to
achieve.

------
javis
The reason everyone asumes HTML5 apps can't work on mobile is because how
awful UIWebView is on iOS. Apple really need to explain how limiting
JavaScript speed in WebView makes it anymore more secure.

~~~
rodion_89
JavaScript execution speed is no longer a major limiting factor on mobile. In
terms of UI JavaScript execution speed will help you if you're using jQuery
(or any naive animator) to animate 2d CSS properties. The DOM, 3d transforms,
etc are the real pain points.

As bad as UIWebView is, it somehow manages to be the best webview out of any
mobile OS.[1]

[1] as for BB10, I'll believe it when I see it.

~~~
notatoad
I'm going to assume you're getting downvotes for saying that jquery animations
are better performing than native CSS animations. From everything I've seen,
that's simply not true, regardless of the platform.

I sure hope the downvotes aren't for saying that iOS's uiwebview is the best
one we've got. Android web views mean using the android browser rendering
engine, which is terrible. It might not be intentionally crippled like apple's
is, but it is less capable to begin with.

~~~
rodion_89
I'm pretty sure I made no comment as to which is better, jQuery or CSS3
animations.

On mobile there is no question whatsoever that CSS3 animations are much
better. The big issues tend to be regarding 3d stacking contexts. You can end
up with strange artifacts, z-index breaking transforms, and sometimes
downright wrong positioning. Also GPU accelerated elements can sometimes come
out blurred. jQuery animations fix this but perform much worse.

On desktop it really depends. Browser compliance is an issue a lot of the
time. You can actually slow down a 2d transition by using translate3d or any
other GPU accelerated value. GPU acceleration hasn't had all its kinks worked
out yet in browsers but its very likely that CSS3 transitions will be miles
ahead for regular use cases in the future. I'm not saying that CSS3
transitions are worse, just that they are not better all of the time (only
most of the time).

------
johnyzee
I don't get it. Client thickness is one area that seems to have no bearing on
the HTML5 vs. native debate. A canvas and Javascript based application will
most often be as thick as a native app, the client downloads it once off the
web never to be heard from again. With the HTML5 game I'm developing[1] I can
reboot the server with hundreds of active players and no one is the wiser.

Tell me HTML5 apps feel wrong, are unresponsive, a pain in the ass to develop
or lack features, but framing it as thin vs. thick client makes it sound like
we are talking about native versus the page-based web apps of the 90's, which
is unfair to the web. The art has developed and HTML5 in particular, with the
immediate mode graphics of the canvas element and the increasingly
sophisticated Javascript frameworks, is as capable a platform for rich clients
as any, imho.

[1]: <http://www.webworks.dk/enginetest>

------
joelhooks
My single biggest headache with "HTML5" mobile browser applications has been
the text fields/inputs.

------
ABS
take a look at Calatrava then <http://calatrava.github.com/>

open source, mobile cross-platform logic, freedom to build great UIs

------
89a
Not even a question at this point. Mobile is still too limited for HTML to
even begin to compete with native.

