

HTML5 Mythbusting - caludio
https://hacks.mozilla.org/2012/11/html5-mythbusting/

======
tptacek
Most of these don't seem like "myths" so much as "uncomfortable realities".
It's not a myth that native apps are faster because they get preferential
access to the hardware, for instance, it's just a fact.

~~~
marknutter
There are "uncomfortable realities" associated with native development as
well, such as the cost of porting to other platforms, forcing users to upgrade
their hardware to stay current, app discoverability issues, etc.

~~~
randomdata
\- _the cost of porting to other platforms_

On the other hand, while it is rapidly getting better, the tooling for HTML5
apps are still generally the wild west. You can hack together an HTML5 app in
no time, but unless you are doing something that is completely bog standard,
by the time you properly engineer your HTML5 app, you probably could have
delivered on two or three native platforms.

\- _forcing users to upgrade their hardware to stay current_

If your app needs something from newer hardware to function properly (more
processing power, new I/O devices, etc.), how does HTML5 alleviate that
problem? If you mean forcing users to upgrade their operating systems (which
is sometimes dictated by the hardware) for new features, I'll note that the
browsers/HTML5 rendering systems are generally part of that upgrade, still
requiring said upgrade to use those features in HTML5.

\- _app discoverability issues_

Given that a native mobile app can use all of the same marketing tools a web
app has, _plus_ the vendor's app marketplace, couldn't it be said that native
apps have better discoverability?

~~~
nwienert
_\- the cost of porting to other platforms_

Where in mobile can you live-debug an application both visually and
functionally like you can with Web Inspector? I mean literally you are coding
and debugging your app at the same time. And with LiveReload you don't even
leave your editor to see your code changes _instantly_.

Not to mention you are coding in JavaScript and CSS so the time it takes to
iterate between various solutions is a fraction of the time of Objective C or
Java. I think you have your first point backwards. There may not be an
equivalent IDE, but we have a runtime inspector/editor baked into our runtime
platform. You can't beat that.

 _\- forcing users to upgrade their hardware to stay current_

On Android you can update your default browser through the app store.

 _\- app discoverability issues_

Perhaps, but then again your app could just be rejected/removed at any time.
Plus the whole 30% cut, time to release, limited sales options, etc. You're
not in control of your app.

~~~
rimantas

      > Where in mobile can you live-debug an application both
      > visually and functionally like you can with Web 
      > Inspector?
    

Visually? Interface builder in Xcode. Functionally? Instrumenta, lldb.

    
    
      > coding in JavaScript and CSS so the time it takes to
      > iterate between various solutions is a fraction of the
      > time of Objective C or Java.
    

You are vastly underestimating the capabilities of Cocoa Touch and UIKit. And
tell me, how many iterations will it take to reimplement something like
reusable cells in UITableView with comparable efficiency in CSS and JS.

    
    
      > Plus the whole 30% cut
    

You get a lot for that: including hosting, payment processing, automatic
notification about upgrades and access to millions people with credit cards a
click away from your app.

~~~
nwienert
No matter, saying HTML5 tools are the "wild-west" was "wildly" inaccurate.

On the UITable thing... the efficiency is the whole point of this article.
Does you UITableView code compile directly to any other platform?

As for implementing, from a quick google search it looks like it would be
trivial. A one day project, if less. How long would it take you to RE-code it
in cocoa from scratch without going off the original code? Also, see Enyo if
you want an easily re-usable kit like that[1]. Not to mention tons of other
ones. If anything that example works in favor of HTML being easy and open.

[1] <http://enyojs.com/sampler/>

~~~
randomdata
I feel you may have completely missed my point about it being the wild west.
Android, iOS, and many other mobile platforms provide a rich set of frameworks
that solve much of the hard engineering challenges for you.

HTML5 gives you a programming language or two and some rough system
interfaces. By the time you are done your HTML5 app, it should be almost
indistinguishable from a native app in terms of code, but you will have had to
build many of those frameworks yourself; or, at best, extend one hundreds of
competing frameworks that get you half way there but never all the way (again,
unless you are doing something _really_ simple).

As mentioned, I do agree that this area does improve each day, and the time
may come where it does meet, or even exceed, what the native platforms offer.
In the meantime, however, you are going to be spending a portion of your
development efforts being part of that improvement cycle instead of moving on
to the next native platform. Six of one, half dozen of the other.

Additionally, the reason I called it the wild west was in reference to the
many HTML5 developers who choose to forego best practices altogether and
program their app close to the "bare metal", doing only the bare minimum to
get their app running. This provides a much shorter learning curve and quicker
time to first product, which many non-native developers even consider a strong
selling point of HTML5, but it sacrifices all of the lessons developers have
learned over the past 30 years or so. Once upon a time, we used to program
native applications that way too. Why sould we consider it a good idea now
when it wasn't deemed a good idea back then?

------
old-gregg
Interesting, when I look at the given "Things HTML5 can do that native Apps
can not", I notice that those things are important to developers, not to the
end users.

End users do not care about "write once deploy everywhere". But they do care
about the responsiveness, battery life, native look and feel, etc

So far HTML5 apps are following the trajectory of "Java on a desktop".

~~~
azakai
> End users do not care about "write once deploy everywhere"

No, end users greatly care about that. They want to access their apps on all
their devices, and to be able to buy a new device and use their apps on it.
Just like they want to access their movies and music on all their devices. To
them, apps and media are content and the computer/tablet/game console should
just let them access it.

~~~
GHFigs
You're implicitly referring to the subset of end users that have chosen or
would like to choose devices from incompatible ecosystems.

I suspect this set of users is relatively small, given that it excludes what
seems like the most common case: people that are satisfied with the platform
they're on. I don't know that there are a lot of Android users (for example)
that are eager to buy iOS devices but hesitate because they won't be able to
use their existing apps.

~~~
nwienert
I think you're wrong. Especially going forward, how about apps that run on
your TV, your tablet, your phone, your computer, etc. Want a chromebook? Runs
there. On a friends phone? Load it there. What happens if a platform dies out?
Or another becomes significantly more attractive to you because they release a
poor maps application? What if you want a cheap tablet for your kids? There's
a ridiculous amount of use cases that _do_ matter to most people. The _reason_
you're happy with your platform is actually because they've locked you into
it. If another closed platform came around with all the new desirable apps,
you'd be unhappy for the same reason you're happy about it now.

~~~
GHFigs
_The reason you're happy with your platform is actually because they've locked
you into it._

I don't agree. Lock-in is when "I want to switch, but can't." Happiness is "I
don't want to switch." Most users on most platforms are happy or at worst
indifferent to the question.

I don't think it makes sense for most developers to target the scenarios you
describe because although they are numerous, each is small. I don't think the
edge cases add up to more than the common case on any major platform.

(Disclosure: I don't regularly use any smartphone, tablet, tv or anything that
could be called a modern web application, so it's not _my_ happiness I'm
talking about.)

------
btipling
This article does not seem to be objective and honest. Yes you can monetize an
HTML5 app, but there is a difference between can monetize and can monetize and
actually make money.

If you are going to criticize app stores, you might want to factor in the
reality that Apple has paid out over 6 billion dollars to app developers. The
article mentions phone gap, that's true, so that's fine, but I'm addressing
the point about monetizing on the web.

This article also is cherry picking news articles. It picks the Financial
Time's article but doesn't mention Facebook's switch to native.

The build once, run everywhere point is flawed as we know that you actually do
have to test and add various fixes here and there and worry about screen size,
poor development environments on mobile and the like. You also do not have to
write the vast majority of your app more than once for multiple platforms. I
know a featured developer with a game that has more than 7 million users who
wrote their game in C++ and were able to port it to both Android and iOS
without writing two different games. And really there are only two mobile
platforms that users have to worry about, iOS and Android.

~~~
jgon
It also does something that always pisses me off when I see it in HTML5
boosterism, which is claim that HTML and Javascript are plenty performant, and
hey look at this demo as proof!

The problem is that the demo is always of a game that would have been
impressive over a decade ago! I mean look at the wipeout clone they show a
video of! The demo consists of a clone of a game that ran on a PS1 with 33mhz
MIPS processor! And the PS1 version appears to have great complexity in its
scenery! The only difference is the increased resolution of the Mozilla demo.
Now all it takes is a quad-core I7 with 8GB of RAM and the latest Nvidia card
to get the exact same experience with a higher-resolution. Take that people
who are unimpressed by HTML5!

<https://www.youtube.com/watch?v=KRSVrkzDyuA>

Javascript and the web are technologies that are popular by virtue of their
incredible reach, and not because of the skill and care that have gone into
their design. I would really like to Mozilla and other concerned parties spend
a lot more time dealing with the glaring deficiencies of the web than trying
to convince me they don't exist.

~~~
pharrington
To be fair, that Wipeout clone demo also runs fine at full quality on a Core 2
E6400+8800GT. That's also before noting that on that old rig the demo never
went above 20% CPU or GPU, which still says nothing about how well optimized
the demo is.

Of course, you're absolutely spot on in that all this is stuff non-web devs
were doing over a decade ago, the real benefit of web technologies not being
that they're as capable as native solutions, but that they benefit from the
web's ubiquity.

------
darkmarmot
So, to demonstrate the awesomeness that is HTML5, they show a video of HTML5
rendered in Flash?

------
frozenport
Internet based HTML5 has an intrinsic latency due to the connection with the
server. Therefore the bottleneck for performance is not cpu but rather network
latency., his makes much of the discussion concerning tailed suite moot,
because the real issue is data delay and not code generation optimization.

Lastly performance comparisons between Java and javascript hint that
portability of code is not the bottleneck: because Java is much faster than
javascript while still being portable.

~~~
azakai
> Internet based HTML5 has an intrinsic latency due to the connection with the
> server.

For first load, sure, just like it takes time to download and install an app.
But you can then access HTML5 sites again quickly if you store data locally
(using IndexedDB for example).

------
tonygrue
Also amusing, WebGL is provided as an example of why perf is good, but is it
really part of HTML5? The assumption that it is appears to be another myth.

<http://www.w3.org/TR/html5/> [http://stackoverflow.com/questions/10185554/is-
webgl-part-of...](http://stackoverflow.com/questions/10185554/is-webgl-part-
of-the-html5-specification)

------
NinjaWarrior
HTML5 means that some elite browser developers enjoy fun and performance
native coding and they allow us to use only crappy HTML/CSS/JavaScript (altjs
languages and Emscripten can't compensate, of course). I suspect Mozilla guys
regard themselves as privileged classes or something.

As a programmer, the freedom of programming languages and APIs is more
important than Apple tax.

I sometimes imagine a catastrophic future. They say all programmers will write
software only on the browsers. Then, all programmers will forget how to write
C++, and no one will be able to maintain browsers eventually :p

IMO, the easiest way to prove HTML5 is a prison rather than open will be
jailbreaking Firefox OS phones.

------
kombine
> HTML5, on the other hand by its very definition is a web technology that
> should run independent of environment, display or technology.

That's a false dichotomy all the way through. Why "web" apps have this
advantage "by definition"? "Web" means network. Nothing more. That has nothing
to do with its independence of environment. Actually, independence is also a
false statement. Web apps are in fact very much dependant on the environment
they run in - the browser. To the point that you can't do anything outside of
what the browser allows you to. Then also this trait is not unique to HTML
apps - Java and .NET are exactly the same, just an order of magnitude more
powerful.

------
pootch
I love the "cost of porting to other platforms" argument. I'd like to replace
it with the "cost of delivering mushy web applications to customers who expect
more". That cost is infinite, and you'll never get it back.

