
Unraveling HTML5 vs. Native - nvk
http://designmind.frogdesign.com/blog/unraveling-html5-vs-native.html
======
brandon_wirtz
We make an app written as HTML5 CSS3. We made this decision because with
limited dev resources it allowed us to write once deploy many. That is
powerful. Our app required more testing than a native app, and less.

With a native app if you write your code for Version X of the OS you can be
99% certain that Version X.1, X+1, and X+1.3 are all going to treat it the
same. With HTML5 "fixes" to the renderer can mean that what was working will
stop working. Or stop looking like it used to.

With an HTML5 app you should be able to write once and deploy many, but Mobile
Safari, and Mobile Chrome, that do the renderings on IOS and Android don't
handle all JS and CSS quite the same. So you may have slight differences. Much
less than you would have with ObjectiveC vs Java, but differences none the
less.

PhoneGap makes much of the stuff you want to do with the hardware easier, but
not perfect. If you want to send a Text, or make a call or access the contacts
you will have to at least touch a plugin, if not write some native code. Most
of the time you can just clip a snippet from someone else, but if you want to
do anything awe inspiring you will have to still get your hands dirty with
native code.

<http://tldrstuff.com> shows what we were able to do with a single UI Core
across Windows Phone 8, Android, and IOS.

We hit all of the platforms, and had less code to change, but our app doesn't
"Feel" native. We don't have a UI that looks integrated with the OS, but we
have concistency across platforms. Was our decision "right"? Hard to say. We
spent less resources which was a major driving factor so I say yes. Did it
keep us from being Wavii or Summly? I hope not. But it is hard to say. I don't
know if we traded dev resources for glory, or if we saved money we will want
and need to be bigger than either.

~~~
SkyMarshal
Thanks for the interesting postmortem. I've been thinking along the same lines
recently - HTML5 + app packager for teams with limited development resources,
multiple parallel native apps for teams that handle it. Or native if you have
some specific requirement that can only be met by native.

Fwiw, the Flat/Tiled/Metro design motiff seems to taking off enough that it's
a satisfactory cross-device substitute for native.

Summly used it too; as such, yours doesn't look significantly different
theirs, other than their use of transparency in places.

Maybe it was their mention of their use of genetic algorithms in their well-
done launch video [1], and having a 15yr old founder, that did it for them. Of
the Three T's they nailed two - team and technology. Attention, interest, and
Traction were sure to follow.

[1]: <http://vimeo.com/52014691>

------
asperous
A few years ago Adobe open sourced flex <http://flex.apache.org/>

This is an "write once, deploy many" that has a bit different offering then
html5, specifically, it deploys natively, allows offline usage, can be set up
to use native ui elements, has a gpu accelerated animated vector engine
available, etc.

~~~
Erwin
I really like Flex. It's supposedly flowed and buggy and abandoned though.

Yet I can easily write a dozen lines of code with my 1990s GUI knowledge that
display 20,000 items in a sortable table and work at full speed in any browser
-- while having endless performance problems/memory leaks when using HTML and
various "data tables" plugins.

Maybe in 10 years we'll have something that will let you build a GUI right in
the browser and will work cross-browser properly.

------
just2n
I don't think there's a good reason such a distinction exists. You have
ChromeOS and FirefoxOS, which prove that web applications given access to
system APIs are just as capable as ObjectiveC and Java. But there's still a
"web" vs "native" distinction. Why can't Android or iOS launch a "web"
application with JS having access to privileged API and HTML/CSS simply
rendering the UI? When did we decide to build worlds where your programming
language dictates whether your application is "real" or not?

~~~
millstone
ChromeOS is a strange choice, because of the box, ChromeOS is not especially
capable. That's why there's interest in tools like Crouton.

What distinguishes native apps is not whether they are rendered with HTML
(many native apps use HTML rendering for parts), or whether they have access
to privileged APIs, but instead whether they conform to the behaviors and
conventions of the platform. Getting that conformance requires using the APIs
the platform gives you - you cannot adequately copy it, as Java Swing has
proven.

For example, Light Table fits your criteria: it's a double clickable .app file
with access to privileged APIs, with HTML and CSS rendering the UI. But it's
obviously not a native app, and will never feel like one.

Note that I didn't say "real". Light Table is certainly a _real_ app. But the
distinction is inescapable: it's impossible to miss the fact that Light Table
is non-native.

------
Zigurd
I think the "functionality" axis doesn't work. One could argue some high-value
enterprise Web apps are more "functional" than Facebook Home, but that does
nothing to capture why it is appropriate for the Web app to be implemented
that way and why it is preposterous to suggest Facebook should be done in
HTML5.

The importance of power consumption, fine-grained interactivity, the need to
fit non-browser concepts in user experience such as AppWidget in Android, the
desirability of sync vs. CRUD-over-IP etc. are among the decision points for
choosing one or more client implementation approaches.

Then there is the fact that most high-value apps do not have a single answer
for implementation approach, and that these high value apps were not born that
way. When Facebook turned away from making mobile Web apps, they did not also
start making native desktop clients.

This is how I would boil it down: Is your app valuable enough to be worth
spending enough on a mobile client implementation than can do things a Web
interface cannot do? That is, for a minimum viable product, you probably need
to do almost everything your Web interface does, but in order to really
justify the effort, you should, at least, have a road map to some place where
the mobile app exceeds what the Web app can do. This might be as simple as
notifications and an AppWidget. But preferably it's something app-specific.

------
maaaats
I have good experiences with writing HTML5 "apps" for phones and tablets. But
the common factor is that they're not very advanced, just a website with some
interactivity. If I were to make something advanced, like Facebook with chat,
tracking, uploading/sharing etc. I'd reconsider my choice, though.

~~~
CmonNoReg
Exactly. Right tool for a right task. No hype.

------
nick32m
From our experience to develop the mobile app with HTML5/Javascript/CSS i.e.
Cordova, not only that the mobile safari in iOS and webkit in Android
sometimes not render js/css the same ( the point brandon_wirtz has raised),
but another difficulty we found very hard is to debug the javasript (js that
resides in the device, not on the server side) .

in iOS it's okay we could connect device/simulator and open the safari
inspector to debug. But in android it's almost impossible to know what & where
the javascript has gone wrong and fix.

The webkit in android 2.3.x version also will render differently on some css
properties compared to 4.x version.

------
shared4you
On a related note: "No, I'm not going to download your bullshit app":
<http://tommorris.org/posts/8070>

------
dottrap
Appcelerator Titanium is not a cross-compiler. In fact, you missed this entire
category of "native" apps. They embed actual Javascript interpreters in your
app to run your Javascript. They provide bindings in Javascript to native APIs
so you can call native code via Javascript.

