
Go native, HTML5 is going to lag for a while - raganwald
http://blog.suthakamal.com/2012/08/go-native-html5-is-going-to-lag-for.html
======
ender7
Sadly, Apple and/or Google have the power to retard the adoption of HTML5 as
long as they like.

"But ender7," you say, "both Mobile Safari and Chrome have great support for
HTML5."

Yes, they do. Sort of. Except for the crippling bugs in many of their
implementations. Some of these bugs render the APIs in question essentially
useless on mobile. Or just a giant pain in the ass to work around. Or have
performance issues so large that they are impractical for non-toy purposes.

How quickly these bugs (and perfomance issues) get fixed will have a huge
effect on HTML5 vs. native adoption. So far, this seems to be happening at a
rate of "meh". For example, iOS 6 _finally_ fixed the bugs in its HTML5
History API that prevented anyone from using it in a real product. But they
did fix it. It only took...a few years.

~~~
akldfgj
Which browser is the shining beacon of light for HTML5?

~~~
knitatoms
The new version of Firefox on Android is fantastic.

~~~
solnyshok
but it keeps crashing on my dual core 1.2GHz, 512Mb RAM phone

------
simonsarris
"Early birds get the worm, early adopters get the shaft" to paraphrase my
brother.

But we all need early adopters.

Sure HTML5 isn't ideal yet. Writing multiple apps for separate platforms to do
the same damn thing on different devices isn't ideal either, though. Unless
you want to take one on principle I think its almost too context dependent to
bother wage a conversation over it.

I think that the conclusion of this blog post is all too broad and so
circumstantial that the title seems a tad silly. It amounts to something that
everyone already knows. He gives an NB in the middle of the article that
amounts to "of course if your app works well with HTML5 then you should use
HTML5," and before that he mentions that native apps have more functionality
(sensors/webcam/etc).

If you like the idea of a native web and you can make your app practical today
in HTML5 then I think you should. On the principle of it I agree with the
actually-pretty-butchered[1] Gandhi quote, "Be the change you want to see in
the world."

~~~

For more talk on the topic see Paul Irish's post from the other day. It's not
a rebuttal, more of a plea for HTML5 instead of native, but I found it and the
comments interesting:

[https://plus.google.com/u/0/113127438179392830442/posts/fR3i...](https://plus.google.com/u/0/113127438179392830442/posts/fR3iiuN4kEF)

~~~

[1] From a NYT article: The closest verifiable remark we have from Gandhi is
this: "If we could change ourselves, the tendencies in the world would also
change. As a man changes his own nature, so does the attitude of the world
change towards him. ... We need not wait to see what others do."
<http://goo.gl/S29tx>

------
DigitalSea
Lets get this straight, the limitations in performance on Mobile Safari are
very much deliberate limitations. Do you seriously think a company like Apple
who gets a pretty large chunk of app store sales is going to let something
like HTML5, CSS3 and Javascript steal it's profits away? Fat chance.

Although it even rings true for desktop browsers not being able to perform as
optimally in regards to some HTML5 features work, Apple can and could do more
to improve HTML5 support but won't for the foreseeable future until it works
out how it can control and monetise HTML5 (which it can't and never will).

People are quick to point out Facebook ditched web and went native because of
HTML5 limitations which I believe is a lie. It's been rumoured that Facebook
is going to be deeply embedded into iOS 6 like Twitter got in iOS 5 and one of
the requirements would obviously be to have a native application.

The Facebook app I believe was slow because of one key issue: 37 requests,
491kb. That was the problem, of course that many requests and large size is
going to be slow for users on congested 3G networks.

Case in point of just how well a web app can run is LinkedIn's iOS app. It
works the same way as the Facebook app used too. It has a Node.JS backend and
uses a web wrapper to load it in, they even wrote up a blog post about how
they squeezed every ounce of performance out of the web UIView and I think it
works well.

I'm not one to believe in conspiracy theories without solid facts, but in my
opinion the move to native by Facebook was a strategic one on Apple's end.
Apple knew Facebook were the poster-child for HTML5 web applications that
could run without relying on the almighty iPhone operating system, so throw
them an integration bone and ask them to go native in hopes that others do the
same and ditch HTML5 as their first choice for an app and many people will
follow.

~~~
needle0
"It has a Node.JS backend and uses a web wrapper to load it in, they even
wrote up a blog post about how they squeezed every ounce of performance out of
the web UIView and I think it works well."

Can you give a link to that blog post? I took a quick look at LinkedIn's
corporate and developer blogs but couldn't come across it.

~~~
modernerd
Related HN discussion here: <http://news.ycombinator.com/item?id=4153599>

This presentation from LinkedIn's Director of Engineering is worth watching
too: <http://www.youtube.com/watch?v=hMd45Ij2DYQ>

Also see this piece from Venturebeat:
<http://venturebeat.com/2011/08/16/linkedin-node/>

------
confluence
HTML5 isn't ideal yet - but it is getting there (see link):

[http://arstechnica.com/science/2012/09/pong-gets-a-
physics-b...](http://arstechnica.com/science/2012/09/pong-gets-a-physics-
boost-by-way-of-html5/)

Everything is set up for HTML5 to take off. Google doesn't really care about
"app markets" so they are strongly incentivised to disintermediate the app
stores via a triple threat of native speed JS (V8/Native Client) in Chrome,
the Chrome Web store (listing of websites really) and the relatively free and
open Android market (this is Microsoft's 80-90s strategy against Apple all
over again).

Microsoft wants people to get off Obj-C Apple native app programming and onto
HTML5 with Windows 8 - and they, along with Mozilla, have aggressively been
pushing into native mobile HTML5.

Apple doesn't want HTML5 to win (flash wars aside). They need to keep apps
locked and native since anything else will erode their competitive advantage
(which neither Mozilla/Google/Microsoft care much for - since they don't do
hardware).

HTML5 will come.

Question is will OnLive-esque video streaming win out in the end. I'll bet
it'll be a mixture - with streaming for really hard core things and HTML5 for
basic casual games/CRUD apps/low latency stuff. We might even go all video - I
don't really know.

But it's gonna be awesome!

------
jorangreef
One way to help is to ask for lower level OS apis to be exposed by browsers,
so that the open source community can do the rest:

1\. Ask for UDP to be exposed to trusted web apps installed by the user. This
will let the P2P community race ahead without having to wait for WebRTC to get
released and then fixed.

2\. Ask for TCP to be exposed to trusted web apps installed by the user. This
will instantly enable things like SMTP clients running in the browser without
the need for WebSocket proxies/proprietary gateway servers.

3\. Ask for POSIX to be exposed to trusted web apps installed by the user.
This will lead to an explosion of database innovation in the browser.
IndexedDB is design-by-committee. Insist on proper POSIX not the FileSystem
API. Borrow from the Node API. Impedance mismatch is crippling browser
storage.

4\. Low-hanging fruit: ask for LevelDB to be exposed directly
(<http://code.google.com/p/chromium/issues/detail?id=128865>). Most of the
browser vendors are using LevelDB underneath IndexedDB, and just exposing
LevelDB directly would already be a huge leap forward. No need to wait for the
many IndexedDB bugs to get fixed by browser vendors.

Browser vendors are trying to do too much. Innovation needs to move from top-
down to bottom-up. Browser vendors need to provide just basic access to bare
metal and let OSS do the rest. UDP, TCP, POSIX would be a great start.

------
ricardobeat

        A smartphone today can talk to all sorts of other devices:
        TV remotes over WiFi, watches and headphones over Bluetooth,
        health-sensors and car stereos through dock connectors, and 
        TVs over AirPlay. All this is beyond the reach of HTML apps.
    

That's almost the entire point of PhoneGap and similar frameworks, exposing
these via APIs. He's confusing using HTML/CSS/JS for UI in a "native" app with
making a _web_ app.

~~~
tjogin
Did you notice the _enormous_ performance improvement in Facebook's app when
they moved away from that type of solution to a native one?

~~~
SunboX
That´s really wrong! Facebook still uses a lot of HTML5 in their new App! But
they fixed a lot of bugs, mainly removed a lot of concurrent UIWebViews. For
more information, take a look at:

[http://www.vasantkumar.ca/2012/08/native-vs-html5-why-
facebo...](http://www.vasantkumar.ca/2012/08/native-vs-html5-why-facebooks-
newest-app-should-not-be-viewed-as-a-reason-to-go-native/)

But simply saying "They removed HTML5 and all works a lot better" is very
wrong.

~~~
tjogin
Nobody's said that though. Facebook has, in fact, replaced some web views with
native code, and that has sped up the app tremendously.

------
jmitcheson
Saying HTML5 won't be 'production ready' for a while, and saying that HTML5
will _never_ be production ready are two very different things, but I feel
people conflate the arguments all the time.

If you do believe that HTML5 will eventually be production ready, even if not
for another 2 years, ask yourself this: when that time comes, do you want to
be the guy with 2 years experience or the guy with none? When the industry is
ready, 'HTML5 developers' are going to be all anybody wants and they'll want
them all right now. If you want to jump on a moving train carriage then you
have to start running towards it very early...

~~~
rimantas
I am guy with more than 10 years experience, I am on WHATWG list since
prehistoric times, when HTML5 was still called "Web Applications 1.0" and I
will gladly use it for web content, but for mobile applications I choose
native.

------
batgaijin
I can't wait until unlocked bootloaders are the norm and the drivers are open
source. The level of artificial stagnation on phones is disgusting and a joke
to our profession.

------
epic9x
Regardless of whether or not HTML5 is going to "lag", I think this article
white-washes the evolution of the web as an open platform vis-a-vis the
desktop/OS. Open platforms and protocols are the result of hard work and
people taking risks and building value, not a result of stability in the
platform.

The Web and technologies have operated in a disruptive manner with respect to
an established platform, and the mobile revolution was about the platform
moving to serve modern, networked users. The is counter to silo'd interests
attempt to constrain and integrate the web into proprietary formats and
platforms (See: everything from active-X/flash to the current mobile platform
wars).

~~~
suthakamal
(I wrote the original article.)

You're absolutely right about open platforms and protocols being about lots of
people taking risks and building hugely valuable things. My point was that
when the core OS is innovating like mad, you need to be close to those OS's to
build the best apps... The innovation on the desktop slowed to a crawl years
ago, and the majority of innovation has moved to the browser and web-app
layer. In mobile, however, there's a LOT of innovation still happening right
at the OS level w/ Android and iOS, and so all the frameworks that exist above
the native SDK's are going to lag, and not take best advantage of the
innovations being released at the OS layer.

The speed of mobile OS innovation will invariably slow (like it did on the
desktop), but until then, philosophy about open platforms aside, iOS and
Android show no signs of being displaced as the real mobile OS / platform
drivers... and so, native's going to lead HTML5 / other "open" platforms for a
while.

------
chj
Let's face the reality. THe HTML5+CSS3+JS is over complicated. It's not going
to stop lagging for the same jobs that native apps can handle well. Not even
your computer is sped up 2x. Because native apps will always make it look bad.

However it should be fast enough for ebook production, if the typography is
done right.

~~~
sil3ntmac
Don't generalize. The reality is that for _certain_ apps (esp. simple, data-
driven ones a la ebooks), web is certainly not overcomplicated, and in many
times can be nearly indistinguishable from a native app. And it is -- albeit
slowly -- getting better.

------
azakai
> WebGL is cool, but [..] the kind of graphics performance a developer can get
> by writing straight OpenGL (taking advantage of sophisticated shader models
> on more recent devices) is astonishing

Why can't you get the same performance with WebGL shaders? Yes, WebGL GLSL
adds some security checks, but apparently they only add about 5%. The article
here seems to assume there is a huge difference - I'd be curious to know what
that is based on.

Is it new shader models not present in WebGL GLSL? If so, specific examples
would be appreciated.

edit: expand the question

~~~
daeken
In current implementations, the shaders running through WebGL are identical to
those that are not (outside of ES vs desktop changes). However, there are a
couple problems:

1) There's definite overhead on the API itself, e.g. the slow shader
compilation times due to the verification, translation, etc. That'll get
better over time, but it'll never match the desktop; I personally think a
caching approach will be a big win here, but no one has done it yet.

2) You don't have geometry shaders, hardware tessellation, hardware
instancing, and a number of other features you get on the desktop with modern
hardware. You also don't get the ability to render to multiple targets at once
(critical for performant deferred shading).

3) There's significant 'extension lag' as it isn't as simple as just
implementing an extension on one chip and coding for that; it has to hit a
certain level of penetration before it'll be ratified for inclusion in WebGL,
then it has to be made safe and implemented.

Those are the core things holding WebGL performance back (IMO), excluding
other browser bits that may get in the way, which aren't relevant to this
discussion directly. A lot of this will go away over time, but I honestly have
no idea how any of that will happen.

(Disclaimer: I work on graphics stuff for Mozilla, but don't work much on the
WebGL side of things; mainly write demo code there)

~~~
khuey
I'm slightly amused by one Mozilla employee responding to a question posed by
another Mozilla employee with a disclaimer that they work for Mozilla.

------
sbooks
Couldn't agree more. We have seen this recently with the Facebook app
switching to native. I think as time goes on, and as phones get more powerful,
it will mean less of a difference, but for now it is better to stick with
native. We decided this for our iPhone/Droid apps at <http://trackmydrive.com>
and couldn't be happier!

------
olouv
The author is wrong, you can build up a HTML5 app and use everything that a
native app does (using PhoneGap/Cordova & custom native bridges), so that is
not the point at all in the HTML5 vs. native debate.

To me the real issue is will Apple & Google keep holding their browser perf
because hybrid mobile dev could hurt their profit & often breaks UI
guidelines.

------
Zigurd
I do not believe this debate will ever be fully resolved one way or the other.
That is, there will always be things Web sites/apps are better for: Delivering
free-form, multimedia information, especially when frequently updated. Or for
relatively simple apps that benefit from pervasive access.

There are also things that OS-specific apps are likely to be better at for
many years to come: Apps that operate in the background without using a lot of
battery power, and interactive apps that manipulate and organize information
and benefit from the richest and most responsive user experience that is
integrated with OS features for information and device resource sharing.

OS innovation hasn't stopped. App development for iOS, Android, and Windows 8
hasn't even fully probed what those OSs can do for app developers in creating
apps that work together. And the OS developers have not stopped improving
their app APIs. They all have different approaches to interaction and
application architecture, especially inter-app communication and cooperation.

So not only will we see a continuation of platform-specific apps, we will see
a lot of innovation in what those apps can do on different platforms, and a
richer expression of the differences between platforms.

"Write-once run everywhere" has zero value to the end user. They want the best
Facebook/g+/Twitter/whatever experience possible on the platform they use.

~~~
kybernetikos
> "Write-once run everywhere" has zero value to the end user. They want the
> best Facebook/g+/Twitter/whatever experience possible on the platform they
> use.

Exactly, and if Mr Enduser X can get it on his weird platform because it runs
HTML, that's a massive piece of value to him.

Also, while he wants a good experience, he wants it to be free too and the
cost in building and maintaining multiple codebases for client libraries would
certainly get passed on to him one way or another.

~~~
Zigurd
That argument is a little circular. If a platform has significant market
share, apps get ported to that platform. If not, it doesn't matter.

Before there were Web apps, all software makers wrote apps for multiple
platforms. Porting to a platform has a cost, but, for a successful software
company, not a relatively large cost. Even unprofitable platforms are likely
to be supported by some software makers as a way of erecting barriers to
entry, or to speculate on the future success of that platform.

Users will expect all the features of their platform to be well-supported in
their apps.

~~~
erichocean
_Before there were Web apps, all software makers wrote apps for multiple
platforms._

I think you meant: Before there were web apps, most software makers wrote apps
for Windows.

Because that's what actually happened.

------
Thomaschaaf
If companies like apple would not restrict non-native apps to only use the
slower JS engine I think a lot of performance issues would go away. HTML5
should almost always be enough for most usecases such as chats, shopping apps,
award apps etc. If an app is restricted speedwise to an IE 6 type of
Javascript engine and HTML5 Apps heavily use Javascript. The problem aren't
the Apps but the JS engine powering these apps.

------
darkstalker
I would say _Go native, HTML5 is going to lag forever_ , since even on a
modern desktops, the performance of HTML5 is way behind native apps. Besides
that, HTML5 is an amalgamation of technologies that feels awkward to use for
someone who has wrote native apps. I would like to see something like XUL
added to HTML5, so you can write web interfaces in a more sane way.

~~~
marknutter
Are we all forgetting why people build web apps in the first place? It's not
about performance.

------
equark
A lot of comments suggest that Apple and maybe even Google are deliberately
keeping HTML5 performance subpar. I think this misses a key fact: Google has
struggled for years to make native Android apps match iOS performance, even
for simple things like scrolling a list. The fact is Apple set a standard with
iOS that is incredibly hard to meet regardless of the technology.

The conclusion is sound though. Companies that build mobile apps using HTML5
in 2012 will almost certainly face the fate of companies that built web apps
using Java applets in 1998.

------
erichocean
_Go native, HTML5 is going to lag for a while_

This is true _for most developers_. I don't think it's true on the leading
edge of HTML 5 development, but it's true that the existing MVC libraries
really aren't there yet, and if anything, are asking the wrong questions.

It'll be awhile before HTML5 application development is a viable option for
your average dev team just wanting to get a product out the door.

------
D_Guidi
the author doesn't think about the fact that small companies simply can't "go
native". there isn't only facebook and google, out there.

------
ericxtang
What about things like Titanium or RubyMotion? They compile to native and
allow you to have a "unified" code base.

~~~
suthakamal
(I wrote the original article.)

These frameworks typically just allow you to wrap native methods with
JavaScript... so you're not really writing to a single cross-platform code
base. Morever, if you can build your app entirely in the HTML/JS/CSS side of
things, you're golden... as soon as you start to bridge between the Native and
JS layers, things get messy (and often very slow).

~~~
prpatel
What? You make no sense. In your original article you advocate going native
for now and eschewing Web tech. Now you say that "you're golden" if you use
Web tech? Then you top it off by saying bridging down to native is slow.....

Are you just talking out of your ass? Have you actually built an application
using Ansca Corona, Ruby Motion, or Appcelerator Titanium? Have you built a
published native and Phonegap app to the Android or iOS store? Well, I have
done all of these - and I even speak about it at conferences[1][2]. I can
safely say you have no idea what you're talking about or you are pushing a
hidden agenda.

[1] <http://lanyrd.com/2012/lone-star-symposium-austin/stbht/> [2]
<http://lanyrd.com/2012/uberconf/stcdt/>

~~~
CJefferson
Could you please either link to a copy of your talk, or some material? Or
alternatively (if possible), just give the 3 sentence version of your talk?
I'm just about to decide what to system to build a new project on, and I'm
interested in your opinion.

~~~
prpatel
...or go watch this video. It's a pretty decent (and balanced) overview of the
dev options out there: <http://www.infoq.com/presentations/Cross-Platform-
Mobile>

------
mikecane
I've read all the Comments and at the time I'm writing this, I'm scratching my
head because I don't see a single mention of Open webOS. Have all of you
written it off or is it just too early to be on anyone's radar?

~~~
prpatel
IMO there's too much uncertainty over WebOS. There's no real deployment of
these devices (dwarfed by even Windows Phone at this point), the helter-
skelter handling of killing it and bringing it back has scared people (thanks
Apotheker for coming in an destroying WebOS and HP in general!), and a roadmap
that hasn't unfolded yet.

------
deepGem
I really hope Firefox Mobile addresses most of the HTML5 pain points and go
live on Android and iOS. We badly need a neutral, open browser on mobile.

------
sonnenkiste
Why is Apple's App-Store App build with HTML? I really don't get it. Why did
Apple favour HTML instead of Objective-C?

------
EGreg
The biggest obstacle to using HTML, in my opinion, is horrible scrolling
support on Android mobile websites. In general, Android's scrolling is ehh
(not sure why they don't make it as good as on the iPhone), but on MOBILE
SITES it's just really bad.

And for overflow: scroll areas, even using iScroll or your own implementation
runs into simple bugs, such as: quick swipes make the document scroll no
matter what you do!

------
trollforce
Thought it was about golang at first, got my hopes up for something that
actually matters to me.

------
natmaster
Or use Firefox.

------
goggles99
Overrated they call it in sports, overhyped they call it in economics,
overgeeked I call it in the hacker world.

Those of you surprised that HTML5 may not soon (if ever) be the holy grail
have been drinking too much cool-aid.

------
ucee054
Mobile apps will be preferred over web apps until mobile internet bandwidth is
cheap and abundant.

------
its_so_on
going native is like going skinny-dipping. a lot of freedom and exquisite
possibilities, but with it comes responsibility - and you can easily get
yourself into trouble.

