
HTML5 Is An Oncoming Train, Native App Development An Oncoming Rocket Ship - danielrhodes
http://techcrunch.com/2011/02/09/html5-versus-native-apps/
======
edw519
_Let’s be honest: right now, most HTML-based mobile apps are a joke when
compared to their native counterparts._

2007: Let’s be honest: right now, most native mobile apps are a joke when
compared to their desktop counterparts.

2002: Let’s be honest: right now, most web apps are a joke when compared to
their desktop counterparts.

1999: Let’s be honest: right now, most Windows apps are a joke when compared
to their Apple counterparts.

1993: Let’s be honest: right now, most client-server apps are a joke when
compared to their multi-user counterparts.

1988: Let’s be honest: right now, most PC-based apps are a joke when compared
to their mini-computer counterparts.

1983: Let’s be honest: right now, most mini-computer-based apps are a joke
when compared to their mainframe counterparts.

1978: Let’s be honest: right now, most on-line CICS-based apps are a joke when
compared to their batch counterparts.

1965: Let’s be honest: right now, most computer-based apps are a joke when
compared to their pencil and paper counterparts.

~~~
dkarl
In every one of those comparisons, the new technology offered a fundamentally
new potential that the old technology lacked. Even in 1965, people could
appreciate automation. Even in 1988, people could see the potential in putting
a computer on every desk. Even in 2002, people could see that web apps were
accessible wherever the web was accessible, instead of needing to be installed
separately on every computer where you wanted to use them.

What do HTML-based apps offer the user that native apps don't? They're easier
to create and update, and they offer an inferior user experience. It may be an
exciting new paradigm for developers, but from a user's point of view, it's
just a cost/quality trade-off. The only distinction that is meaningful to
users is installed app versus web app.

~~~
wvenable
> They're easier to create and update, and they offer an inferior user
> experience.

No, they're not. _Good_ web apps have never been easier to create but what
they offered was extremely easy distribution. What Apple did on the iPhone was
make distribution _almost_ as easy as going to a web page, knocking out HTML-
based apps best advantage.

~~~
extension
If you account for the requirement to reliably maintain per-user state, native
apps pull into the lead. In most cases, they can store state on the device
with no extra work from the user, whereas web sites require tedious signup to
remember even the most trivial personal settings.

Also, don't discount the joy many consumers get from _shopping_ and _owning
things_.

~~~
bricestacey
HTML5 includes support for localstorage, which removes the need to signup to
save state.

------
siddhant
The author mainly focuses on mobile devices. I would like to add that even on
desktop, native apps feel way better than their web based counterparts.
Switching from Google Reader to NetNewsWire, from GMail to Sparrow, Twitter
web to Twitter desktop app, SoundCloud web to SoundCloud native app, are just
some examples. Ideally, data synced on the web, with clients on the desktop
seems like an ideal possibility to me. Or maybe its just me who thinks this
way.

~~~
jpeterson
Couldn't disagree more. I switched to Twitter web and Gmail from desktop
counterparts several months ago, and haven't looked back since.

~~~
siddhant
Well, you should use whatever rocks your boat. Personally, I think its a
little weird that Twitter Web consumes a lot of CPU as compared to the Desktop
app. As for GMail, I find switching between labels (on the web interface) very
slow, if you have a ton of labels/emails. So instead of setting up Gears or
something, I just started using a native app.

~~~
jace
What native app do you use? I use Apple Mail since IMO it has the best IMAP
support of the lot, but archiving and filing under labels is a pain. Apple's
way is to use drag and drop, which doesn't rock my boat.

~~~
siddhant
Sparrow (<http://sparrowmailapp.com>). Its quite literally, a godsend.

~~~
keyle
Yeah but $10? Where did try before you buy go?

~~~
loire280
That's an unfortunate side-effect of the Mac app store. It's too bad, because
functional demos was one of the nice things about the Mac software ecosystem.

I hope demos are a feature they're working on.

~~~
tofumatt
There's Sparrow Lite, an ad-supported free version that's set to release in
the Mac App Store but hasn't been approved yet.

Seems they're working on a non-Mac App Store version too.
[http://blog.sparrowmailapp.com/post/3197243085/sparrow-1-0-i...](http://blog.sparrowmailapp.com/post/3197243085/sparrow-1-0-is-
now-available-on-the-mac-appstore)

------
extension
Web apps have been "oncoming" for over a decade now. The buzz was the same in
2000, but instead of HTML5, it was DHTML or Java applets or ActiveX that was
going to completely replace traditional shrink-wrapped software.

The web is a phenomenal success. It has created a massive new ecosystem and
changed the social order of the world. It also catalyzed the collapse of the
Windows empire, something that had been looking for a way to happen for a
while. But that doesn't mean the web will replace Windows as the One True
Platform.

Windows has some particular flaws that ultimately brought it down, the most
significant being, in my opinion, its model of app distribution and
installation. _All_ of the new platforms adequately address this issue.

But the new native platforms also have a fundamental advantage over the web.
They are designed from the ground up to support applications that can take
full advantage of the latest hardware capabilities and present ideal user
experiences. The web was not designed for applications _at all_ and only by
hiding the mountain of legacy cruft under layers of hacks has it even
approached what native apps can do.

The web _has its strengths_ \-- it makes it super easy to publish gobs of
content that is accessible to anyone, anywhere, anytime. It's very good at
universal, generic interaction. But it always has and always will lag behind
in rich, client-specific functionality. As fast as new capabilities can be
finagled into browsers, new features, uses, and form factors will come to
devices. You may be able to imagine some future in which widely deployed
browsers can do any given thing, but you have to account for change across the
whole technology spectrum. It's not just about possibilities, it's about
_pace_.

There is no need to force a dichotomy. We have native apps, we have the web,
both have their place and neither are going away any time soon. If you're a
developer, learn them both and choose the technologies that are right for each
individual project.

------
dasil003
It's not all about capabilities.

Desktop apps got their lunch eaten by the web based purely on the deployment
and portability benefits, the UX still lags behind to this day. Granted the
app store model mitigates the installation pain, but portability is non-
existent, so my hunch is that HTML5 will pick up steam over the long-term as
mobile browser support and developer knowledge coalesces.

Interestingly I think a lot of apps could go HTML5 today, were it not for
subtle issue of web pages being awkward on mobile. Bookmarks and google
searches just don't have the immediacy they do on a computer, so the very fact
that native apps are easier to get to is a significant hurdle in terms of user
behavior, even if it is possible to develop a excellent mobile-browser-based
UI.

It's possible Apple, Google, et al could parlay this into a longer dominance
of native apps, but that raises two questions: do they really care enough to
attempt to sabotage HTML5? and will developers put up with the hassle of the
fragmented mobile landscape? It's unlikely any of them would cripple their
mobile browser ala IE6 because web is important one way or another, but if
everything shakes out to an iOS/Android duopoly then developers may decide the
pain is worth it. So no bold predictions from me, but it's definitely an
interesting question.

~~~
loewenskind
It's not as straight forward as you describe. The "instantly and globally
released" nature of web apps is both an advantage and a disadvantage. What if
I have a client that needs to keep the only interface for some reason? It's
easy to just not upgrade, provided you have that option...

~~~
tomkarlo
Most commericial web sites already deal with this issue - they have new/beta
features that are initially only visible or available to a subset of users.
Google Apps lets you choose if you want the new or old version... it's not
impossible to let users stay with a static implementation, but it's just
generally not worth the trouble.

Conversely, native apps suffer from the problem that once you deploy a package
out the store, you have to support it (unupgraded) for the foreseeable future.
That creates its own bucket of issues.

~~~
loewenskind
Agreed, both are trade offs. One is not "clearly a winner", it depends on your
goals.

------
u_fail
Am I the only one that thinks that mobile browser development is possibly not
moving as fast as it should. I mean dual core phones with over a gig of ram
are being released and these webapps performance are still bad.

Steve has created a new revenue stream for Apple, not only on developers fees
but mainly in app purchases and percentage of sales. WHY would he give that up
? So while he is telling everyone how much he loves HTML5 and is promoting it,
there are no intentions for apple to ever promote web apps other than lip
service. Its really up to developers to stop this developer lock in, and
refuse to build native apps. Build for the web, and do whats best for the
future of mobile. Other than games and few apps that rely on hardware, most
are just layouts calling webservices in the back end.

~~~
pdelgallego
You are not the only one.

> Its really up to developers to stop this developer lock in, and refuse to
> build native apps.

Well, many developers has found that is easier to make money on mobile apps,
than with their web counterparts. Why would they give that up? Is again a
conflict of interest.

I hope the web will came back stronger after the native apps crisis, till them
I will try to make money in both ends of the spectrum.

------
marknadal
It is a lot easier for a corporation to mandate an API, slap it into an SDK,
and kick it out the door with guns-blazing full hardware accelerated support.
It is another thing to create an open standard that seamlessly and securely
interoperates with absolutely any browser on any device.

The great mistake of the author is that he assumes it is a spec contest.
Native apps will always have a slight advantage, but "having to have one or
two developers per platform" is the exact reason why the web will win out.
They aren't at war because they don't have the same goal. Native apps will
never be able to be universally distributed across platform or device. Period.

~~~
steverb
True. Which is why the Netflix app is basically just an HTML app with a thin
native wrapper.

When native means only iOS then it make sense to just write a native version
instead of a mobile web app, but when it means having to write a version (or
two) for iOS, one for Android, one for Blackberry and one for Windows Mobile 7
then it makes a lot more sense to write a mobile HTML version that works on
all of them.

And then there's the same old update headache.

------
inkaudio
On a side note, despite the native app hype, Apple initially did not support
third party native apps. Apple has always supported web apps on the iphone.

Apple first supports Web Apps in 2007
<http://www.apple.com/pr/library/2007/06/11iphone.html>

News about the app store coming 2008
<http://news.cnet.com/8301-13579_3-9798932-37.html>

~~~
blub
It's not hype if it works. Web apps are hyped because they over-promise and
under-deliver.

If I had a penny for every comment on HN that said how web apps are going to
take over the world... finally someone woke up to the reality and wrote a TC
article.

------
nerdyworm
Haven't we seen this movie before? At one point the web was a complete joke to
the average user and now we have an incredibly diverse ecosystem of web
applications.

I think that applications that require high performance will always require a
native app, but for the simple business applications out there mobile web apps
will certainly do just fine. The devices will get faster, the designers will
work out the user interface issues, and the programmers will make it easier.

The next five year will be dominated by native mobile apps, after that I
really don't think we are all going to continue to pay the expense of
developing on multiple platforms.

------
swix
God... I LOVE HTML5 and Javascript/CSS etc, I wrote a couple of PhoneGap based
apps, and to be fair I think 70% of the apps in the apple app store (Not
counting games) can be created using just HTML5, most are simple
list/todo/map/location apps and so on.

I want to write only in HTML5 to be fair, why? Deploy to multiplatform with
small changes, no Objective-C or Java headache ;-P , but... it just feels as
if it's not quite there yet, we are missing a little bit of performance in
JavascriptCore, for animations (CSS the accelerated transitions work quite
well) heck you can even achieve smooth parallax scrolling with some (mostly)
css tricks on mobilesafari/UI WebView.

Now what's really missing here is a standard animation container, instead of
doing CSS-sprite animations by creating loops that modifies background-
position on elements (which will awlays be slower) there should be some other
thing that lets you generate an animation (As a sprite or whatever) then play
it accelerated in the DOM or Canvas... instead of using javascript to do
everything.

Canvas performance is still horrible, but perhaps when apple comes around add
adds more natively hardware accelerated stuff for the canvas and so on we
could do some neater stuff. Whats my point, you can develop the vast majority
of "apps" with no problem what so ever for iPhone/Android with HTML5, you do
need a "FrameWork" to deploy to the appstore, such as PhoneGap, but in the end
it's basically javascript/css.

Games on the other hand is harder, we're still missing a standard animation
container, performance amongst other things. Add WebGL on top of this and you
can probably come up with some cool stuff, not sure if WebGL is supported on
the latest iOS/Android?

For me, Javascript/CSS/HTML is the UI future of apps, the backend can be
whatever, Java/Python/PHP/C++, but for UI stuff, Javascript/CSS just tastes
damn good and gives you a lot of freedom... my 2 cents.

~~~
mckoss
I agree. BTW, re animations is this what you're looking for?

<https://developer.mozilla.org/en/CSS/CSS_transitions>

~~~
swix
Um, well thats fine and thats what I am using, the problem is that only a few
are hardware accelerated (Opacity, translate3d) are the ones I know are
hardware accelerated in iOS at least.

What I want is some sort of container format for making animations, so I don't
have to "hack" with background-position for a running animation as an example,
sort of like GIF is a container for animations but obviously we'd need some
sort of container that we can interact with... using javascript :P if that
makes any sense.

------
bad_user
I would build my app in HTML5 for the iPhone if image uploading was possible
(on iOS Safari all file input fields are disabled).

Considering that this feature is crucial for my project's success (i.e. the
ability to take a photo and upload it with geolocation), a web app for the
iPhone is the same as not having one in the first place (or worse, since it is
crippled).

And for example, another limitation is that you cannot automatically put the
focus on an input field, unless it originated as a response to a user action.
Why is that? There are instances where I just want the user to start typing
immediately after a page loads (typing itself is hard enough, finding the
input element and tapping on it is an extra chore that I could do without).

HTML5 and other browser technologies are fine, if only phone makers would not
put stupid limitations on what you can do with it.

~~~
lukifer
> Another limitation is that you cannot automatically put the focus on an
> input field, unless it originated as a response to a user action.

This is actually an intentional limitation of all mobile versions of WebKit,
and it's driving me nuts too. See:
[http://discussion.forum.nokia.com/forum/showthread.php?12772...](http://discussion.forum.nokia.com/forum/showthread.php?127724-javascript-
set-focus-to-input-text-box)

The official explanation I've seen is that it would be jarring to the user for
the page to automatically zoom and/or scroll by popping up a keyboard when the
user isn't expecting it. This might make some sense for websites, but
unfortunately has a side effect of crippling web apps. :(

------
ern
To torture the analogy: trains have been ridden by billions of people, rocket
ships by around 500. Less exciting experience, but far more accessible.

------
toddmorey
Legitimate question: Would Apple allow you to put the lightest possible
wrapper around an HTML5 app and charge for it through the App Store? Or would
the review board tell me that I should just make the app available through the
browser instead? I ask because customer expectations are set up to make it far
easier to charge for a native application. Even if that isn't your primary
source of revenue, charging a dollar or so for the application could help
recoup development costs.

~~~
mcav
Generally, yes. I have a Mac App Store app that is just a wrapper for a
WebView.

------
fingerprinter
I think it varies greatly.

Gmail is by far the best email client I've used. I actually like tweetdeck
online version...

But I still use a native chat client and IRC client. I still prefer an office
application (LibreOffice) to Google Docs.

I personally think more and more web apps are going to push the boundaries and
we'll see more things like Tweetdeck, but I also see a real native
need..things like music players and video players etc. I prefer Google reader
b/c I have the same experience on everything (including my iPhone and Nexus
S).

If I had to wager, and ironically, I do (my job after all), I think there is
going to be an uneasy balance struck where some people make hard stances and
only write native apps or only support this platform just as they've always
done IF there application is more than something that pushes data around. But
if their app is very much something that pushes data around (like JSON or
something) I see it going the route of Tweetdeck/Gmail.

I see this for a couple of reasons but mostly about 1. distribution model and
2. shoestring budgets. eople

Now, mobile is a bit of the same as desktop, but more or less lagging by a
generation. I don't see anything non-native winning in mobile for quite some
time (as it didn't in desktop for what, 20 years?). Mobile is quite young and
needs time to grow up. That is part of the reason why I think we are going to
see at best three dominant platforms: iOS, Android and something else (not
convinced it is windows, meego or anything we've seen yet).

No easy answers here and people are going to be second guessed quite a bit no
matter their decisions in this realm. Heck, we've seen it with Nokia today.
People are calling for Nokia to adopt android instead of doing their own
thing. Well, doing their own thing could be the best or the worst thing for
them, but no matter what they choose, it will be open for questioning (no easy
choices).

------
olalonde
MG Siegler is such an Apple fanboy it's not even funny. (regardless of this
article)

~~~
alttab
Also states " _But the fact that very few, if any, choose to go HTML5-only is
telling_ " and then " _Facebook is seemingly all-in on HTML5 (at least going
forward)_ " which seem contradictory statements.

How can it be telling when no one uses HTML5 completely, and then you follow
it with an example of the hottest thing in tech since Windows going all HTML5.
Doesn't make sense.

------
lukifer
I'm currently developing an HTML5 tablet app for iPad and Android, and so far
the biggest limitations are coming not from the HTML5 spec, but WebKit itself.
Specifically, there is no way to programmatically trigger focus on form
fields, and input fields for some reason do not respond to ontouch events.

Still, I consider it a good gamble long-term. Even though I'll have to degrade
gracefully for devices that don't support multi-touch or CSS 3D transforms,
it's still less work than trying to maintain two codebases, and I get to use
the dev stack I know best.

~~~
Me1000
This is because of artificial limitations placed on browser apps by iOS.

Think about it, Facebook, one of the largest photo sharing WEBSITE has a
native app. Why? Because you can't upload photos on iOS.

iPhone OS 2 comes out, native apps get a full SDK with supporting frameworks.
The browser gets "touchStart" events.

Apple simply doesn't want people writing browser apps because they dont make
money nor lock users in.

~~~
lukifer
I tested it on Android, and its WebKit also lacks programmatic focus on input
elements. Didn't test the ontouch problem. Mobile Firefox does the right
thing.

The funny thing is I intend to package my app in native wrappers and
distribute on both App Store and Android Market, so Apple does stand to make
money. But, they still lose exclusivity, and it's unfortunate that they have a
strong disincentive against improving HTML5 as an app platform.

~~~
Me1000
I dont mean to comment on your situation specifically… I'm simply pointing out
you're at a disadvantage: 1\. Mobile Safari isn't feature complete 2\. Apple
has no incentive to make it feature complete

------
adriand
From the perspective of a small (web-focused) dev shop that is getting lots of
RFQs for mobile apps, I think there are really two main reasons why our
clients and prospective clients want to have a mobile app developed. Either
they:

1\. Have something (a website, a business, a city department, whatever) that
they want it to be "on mobile", i.e. they need a mobile app just because they
need to cover the mobile angle. However, the mobile app itself is not usually
the core revenue strategy, it's just part of the bigger picture.

2\. Or, they want to sell a mobile app that is not suitable for building with
HTML5. I.e. the app is the revenue-generator, and it must be
performant/integrate closely with native hardware/etc. (such as a game).

I think we can satisfy the people in category 1 by building HTML5 apps, and
using Phonegap if they want them to be available in app stores.

I think we can satisfy people in category 2 by developing native iOS apps for
sale in the Apple App Store, since from what I can tell, this is the only App
Store that really generates money.

People who want native apps on non iOS devices, for whatever reason, are
probably people we get a subcontractor to handle, or even take a pass
entirely.

------
rodh257
I saw someone post on a show your web app type thread the other day telling
the developer to make his website an iphone app and sell it for 99cents. At
first I was going to comment that it really didn't need to be an iphone app,
and that it was fine as a website but then I thought about it and really thats
the only way you'd get people to pay for the service.

Apple have trained people to pay 1 or 2 dollars for mobile applications, and
thats great - but if you said to someone you need to pay a dollar to use this
website they'd leave straight away.

So now you have the situation where it's in both the developer AND Apple's
best financial interests to make native applications - how is the web on
mobile going to come forward? What incentive does Apple have to make HTML5 run
great on their devices when they earn a chunk of native app sales?
Additionally, if they threw resources at it, they'd probably end up
contributing a bunch of code back to Webkit which would immediately be used by
their biggest competitor.

------
Tichy
At the end of the day, the distinction seems rather stupid. What is "native"
anyway? We are all using frameworks, Cocoa, Android or HTML5. We are not using
assembly code, after all.

So if the capabilities of the "HTML5" framework get better, the distinction
will fade away. WebGL is on it's way, and so are javascript interfaces to the
mobile hardware.

~~~
wvenable
Cocoa and Android _are_ the native APIs of the platform. HTML5 is an
abstraction on top of Cocoa and Android; it should be obvious that it's not at
the same level. HTML is the least common denominator across all platforms and
is a sandbox on top of that. The distinction is a lot stronger than you make
it out to be.

~~~
Tichy
Android is not the native API, at least the Java API is not. What magic
capabilities are there on these devices that are forever beyond the reach of
JavaScript? Does Cocoa expose all possibilities of the phone to the developer
(I don't think so...)?

------
stcredzero
_Native app development is not only difficult, it’s expensive.

These days, if you’re going to do native apps, you at least have to support
iOS and Android. That means at least two developers for each different
language, and preferably more._

Cocos2D may well be shaping up as a good cross-platform environment supporting
both iOS and Android. Add some more GUI libraries, and it would be dandy for
non-game apps. (Javascript)

The Unity 3D engine could be leveraged like this as well.

------
aufreak3
The one thing that _really_ surprised me in this whole "web/native" debate is
the new concept of "installing" web apps (just links?) from the "Chrome web
store" ... while all along hearing things like "installation is a big hurdle
for most people, web is the way".

------
jonpaul
I wrote a popular article about this:
[http://techneur.com/post/3068783134/customers-demand-
native-...](http://techneur.com/post/3068783134/customers-demand-native-for-
mobile-apps)

------
leoc
It's odd not to at least mention Native Client and WebGL in this context.

------
badmash69
OP's analogy could be right but did he consider that You are more likely to be
hit by an oncoming train than by an oncoming rocket !!

HTML5 will rule !!

------
ddkrone
Why does Siegler comment on technology he doesn't understand? The holy grail
of mobile development would be a minimal runtime that would work on all the
mobile platforms which developers could use to factor out the common base of
their applications. Something like a native webkit with some kind of sandboxed
privileges giving the illusion of a native OS. Currently the only thing that
comes close is html/javascript and I know android has a way of bridging Java
and Javascript code and wp7 also has the same capability except with C# and
Javascript. WebOS is all basically javascript so there is nothing to worry
about there and I can't comment on iOS but I'd be surprised if they didn't
offer similar capabilities. I think at this point it's a little too soon to
make comments like Siegler. The space is still young and developers are still
figuring out the proper way to do cross-platform mobile development.

~~~
swix
Yeah there are ways to bridge Javascript and Objective-C, like PhoneGap does,
but it's not "automatic", you'd have to code each method by method etc ...
blegh I hate this, this should be transparent! :P

