

Why native development sucks and HTML5 rocks: Porting to Windows 8  - gdamjan
http://gkosev.blogspot.com/2012/08/why-native-development-sucks-and-html5.html

======
chime
I've done non-trivial projects in both HTML5 (with/without PhoneGap,
with/without jQuery Mobile), Native (ObjC, WinMobile), and hybrid mix of
HTML5/Native (views in HTML, model/controller in Native). I've heard all the
pros and cons of both sides but most of them are either non-issues or wrong.

ARGUMENT: Native is ALWAYS faster than HTML5

MY EXPERIENCE: So what? Speed depends on what you're trying to do and how.
Animating a loading icon for UITableView will not spin any faster than a
loading.gif in HTML5 view. Similarly, being able to slide an entire UIView to
the side at 120fps doesn't mean using CSS webkit-transform: translate3d(x,y,z)
at 60fps looks any worse to the user. Speed matters when you're (a) crunching
data and (b) updating graphics. If you're building HTML5 apps that need some
serious data crunching, you can do that part in C and call from your code via
a plugin. And unless you're making 2.5D-3D games, you don't HAVE to go native.
And then you're most likely coding in C/Lua anyway. For most of the apps out
there, raw processor speed isn't a necessity - responsive UI is.

ARGUMENT: HTML5 is ALWAYS easier/faster to code than Native

MY EXPERIENCE: Sometimes yes, sometimes no. It depends on your experience with
all the available technologies. I can code views in HTML5 using
CoffeeScript/Less/Bootstrap/Backbone relatively fast. I can code
models/controllers in ObjC relatively fast. Views in ObjC get complicated and
models/controllers in CoffeeScript/JS get complicated. If you have a UI-heavy
app and you can code UI fast, go with HTML5. If you feel comfortable
validating user data input in ObjC and have tons of forms, go with ObjC. There
is no silver bullet.

ARGUMENT: HTML5 apps ALWAYS look bad/uncanny vs. Native ALWAYS looks boring

MY EXPERIENCE: Poorly designed apps look bad/uncanny/boring. I have to admit
that using jQuery Mobile and similar libraries without doing any
customization/tweaking pushes your HTML5 app into the uncanny valley. And
unless you skin the Native UI, your app will look no different than the
phone's native contacts list. My preference is to (a) Not use libraries that
make fake native-looking-UI when doing HTML5 (b) Adding graphics/skin to
native UI to make it standout from boring address-book UITableView lists.
Ugly/boring apps are a graphic design problem, not a side-effect of platform
choice.

ARGUMENT: HTML5 is ALWAYS easy to port, Native is not

MY EXPERIENCE: Far from the truth. When porting, you're not just porting to a
different software subsystem but also different hardware parameters. Even the
best designed HTML5 apps can't suddenly go from Android phones to iPad or
iPhones to Nexus 7. Moreover, if you code the core functionality of your
Native apps in C, it makes it quite portable. If you make your HTML5 views
fluid/responsive, it makes it quite portable. If you're relying on special
hardware functionality (camera, GPS etc.), it's a case-by-case issue of what's
portable and what's not. If you have a data logging CRUD app that accepts user
input on HTML5 views, posts to a remote server, and displays results, you
might get away with 1-hour port like the author of this article. But more
often than not, you have more issues to consider. In-App purchase? Yeah, can't
port that easily. Facebook-integration? Can't port that easily unless you're
using portable libraries.

Software development is just as complex on mobile devices as it is on servers.
Your choice of platform (HTML5 vs Native) really depends on your specific
app's requirements. There is no way you can make WordLens in HTML5 (today) and
there is nothing wrong with going HTML5 if it saves you time and resources in
the short and long-term. People need to realize that there are no absolute
GOODs or BADs in software development. Pick the best option after you weigh in
the cost of design & architecture, development, legacy support, resources,
training, deployment, and maintenance.

~~~
marknutter
Thanks for the well thought out response to this thread. Often times
conversation around this topic tail-spins into a flamewar between native and
HTML5 proponents. It's a breath of fresh air to have a measured, detailed
account of the pros and cons of using HTML5 to develop mobile applications.

My personal opinion based on my experience having written both native and
html5 mobile apps is that the closest you can get to a "silver bullet" is a
well thought out responsive HTML5 design packed in phonegap/cordova with
native navigation elements. You get the benefit of snappy, native navigation
while being able to go cross platform very easily with one code base.

------
jefflinwood
The problem with HTML5 as an app interface isn't getting something to appear
on the screen on any of the browsers, it's getting the user experience to
match the native platform.

A similar post in 1999 would have been titled: "Why native development sucks
and Java Swing rocks: Porting to Mac OS 9"

~~~
megaman821
Well, I guess to be fair. Windows 8 styling is something that you could do in
CSS (and is done in CSS for some apps), so HTML5 apps will look native (to
Metro).

~~~
themckman
Hell, looking at Safari, I see no reason why you couldn't put together an
interface like this in HTML/CSS. To the grandparent's point about Java Swing,
I don't have much experience with Swing, but I did see a little as I was
entering college in 2003 and it objectively sucked. And that was 4 years after
the hypothetical article title presented. I think the biggest thing hindering
the HTML/CSS thing on certain occasions is performance, and even there,
browser performance is pretty damn good these days.

Edit: My last sentence may or may not have somewhat proved what the grand
parent was trying to say.

~~~
lazyjones
We'll see what happens to browser performance when most apps on the Win8
desktop are HTML/JS/CSS based and when typical displays have 300-400dpi...
We'd probably get better performance if we resurrected NeWS.

~~~
asadotzler
300-400 dpi on desktops is a silly idea. 200 dpi is excessive for a display
that sits a couple feet away from you. Even for laptops which have screens
that are on average closer, 200 dpi is pretty much all you need. Going much
beyond that gets you very little in terms of perceived quality while costing a
lot more to manufacture.

------
jawngee
I like this title better: _Why Our Application Was An Excellent Use Case For
Developing In HTML 5, YMMV_

~~~
herdcall
Right. No real access to contacts, camera, files/database, accelerometer, GPS,
etc. We tried in vain with application cache, offline storage, etc. but not
seeing contacts/camera was a show-stopper. Even location isn't the same as
native GPS because users get a warning on opening the HTML that usually scares
them away.

~~~
xanadohnt
The article is about using one (of the many) methods to develop _native_ apps
for Windows 8. This is not like PhoneGap - you have full access to the
resources available on the device. Don't mistake the composition technologies
(CSS, HTML, JavaScript) as == non-native app.

[http://msdn.microsoft.com/en-
us/library/windows/apps/br21138...](http://msdn.microsoft.com/en-
us/library/windows/apps/br211386.aspx)

------
lubos
HTML5/Javascript/CSS is native to Windows Metro (as is C++ and .NET)... so I
don't know what is this headline about

~~~
Danieru
'Native' in this context is a term that refers to a language that compiles to
machine code. Neither .NET nor HTML5 are ever native. You might be thinking of
'First-class' or 'Supported' which does describe HTML5 under Windows 8.

------
kodablah
"And with efforts such as AppJS, the number of OSes that support mixed
HTML5-native development keeps growing."

I must toss <https://github.com/rogerwang/node-webkit/> into the mix. I have
found it incredibly easy to develop with...and even easier to distribute.

------
Metrop0218
Good to hear that it was easy to do. What this article describes is the vast
majority of why Microsoft made HTML5/JS/CSS a development path in Windows 8.

------
ta12121
<http://catb.org/jargon/html/W/wheel-of-reincarnation.html>

------
strandev
HTML/JS is a native platform for Windows 8 isn't it? This is akin to porting
to IE10.

------
WayneDB
This article failed to debunk any of the claims that it set out to.

