
HTML5 is not ready - cientifico
http://www.wooga.com/2012/06/woogas-html5-adventure/
======
tomjen3
I beg to differ. The company I work for (cego.dk) has released an HTML5 game
(you can play it here <http://chrome.voodoofriends.com/>) and yeah there is a
ton of small things you have to take care of, and yes IE9 is a pain in the ass
but you can mostly bundle the source code and just ship it on the appstore
([http://itunes.apple.com/us/app/voodoo-
friends/id514562699?mt...](http://itunes.apple.com/us/app/voodoo-
friends/id514562699?mt=8)) and what you can't just bundle are things like in-
app pucharces which will never be crossplatfom and a few issues with sound.

Is it worth it? Well that depends on what your goals are and what your belief
in the future is. If you think IOS is enough, then go for it (and use the
better performance to make a more beautiful game) but if you don't like to
build on somebody else land, HTML5 is the best news in a very long time.

BTW the app is currently free on the app store but I doubt it will be for
long.

~~~
batista
While you "begged to differ", your answer is full of caveats and little
assurances...

------
kunle
One tough thing for HTML5 is that the platforms that the community want to
write for (iOS & Android) have no intrinsic incentive to actually support it
(other than lip service). A world where HTML5 is dominant for the most
profitable tier of games or apps is a world where the best developers dont
have to write in iOS & Android (where Apple and Google respectively make their
money), so given that, what's their incentive to make sure HTML5 reaches
feature/performance parity with their native platforms?

~~~
Peaker
Apple is claiming that the app store is break-even. That it benefits them only
indirectly by making iOS a more attractive choice.

If that is true, and HTML5 worked better with iOS than with Android, that
would work well within that strategy.

I think perhaps there are other reasons for poor HTML5 support on the mobile
platforms.

~~~
cageface
iOS has by far the best support for HTML5 of any mobile platform. If Apple
felt threatened by HTML5 I'd expect to see a lot more evidence of sabotage.

~~~
kunle
Not claiming that iOS support for HTML5 is bad, just that I find it hard to
believe that Apple will ever invest as much in HTMl5 as it does in native, and
by extension, that Apple will ever make sure HTML5 is at feature parity to
native.

At some stage and for some subset of use cases (I think particularly with apps
like news media for example) it will matter less and less, but for anything
that is intensive, I just dont see an argument for why HTML5 will ever
function at parity.

~~~
cageface
To be honest I'm a little puzzled by Apple's efforts with Mobile Safari. It
would seem to be much more in their interests to make it suck.

By best guess is that Apple doesn't _really_ care about the native app market
that much per se and they'll do whatever it takes to sell their hardware.

~~~
DeepDuh
I think you got it exactly right. Of course they want to keep having the best
native App catalogue, but for those devs who DO decide to go the mobile web
app route they don't want to block their users from using it on iOS devices,
since this would lower their satisfaction with iOS.

Conversely, they don't support flash because of the poor / non existant mobile
hardware support which leads to bad performance and -again- unsatisfied users.
With this move they want to force developers to use either html5 or native
apps.

You can say lots of things about their app store policies, but their html5
adoption strategy is pretty rock solid and it's good we have a giant of
Apple's calibre behind this in order to nudge the ecosystem in that direction.

~~~
novalis
With their lack of mobile flash plugin support, Apple just made flash
executable wrapped apps to be profitable through the app store, I wouldn't go
about categorizing Apple's calibre on profit related decisions.

"but for those devs who DO decide to go the mobile web app route they don't
want to block their users from using it on iOS devices, since this would lower
their satisfaction with iOS." Establishing that they did block a plugin on the
browser is a first step. The rest is simply a side effect of js being
supported on the browser combined with the flash cold cut, is there some extra
benevolance we should thank Apple for when their Canvas implementation is
afflicted by the same trouble a flash vm would run into inside a safari mobile
browser ?

Also devs go the web app route way in ways apple has no voice in or control
over, as much as they try. As it should be. Let us not forget such amazing
experiments as the introduction of the quicktime plugin and how that opened
the door for things like flash shockwave itself, and we all know how well that
went.

Revisionisn and a good nanny brand delivered narrative won't make safari
mobile canvas any more apt, sadly. Or a commercial brand any less profit
seeking. As it should.

------
paupino_masano
To be quite honest I find the biggest drawback for HTML5 on mobile devices is
speed. Even simple applications have a noticeable lag that isn't present (or
can be hidden) on Native applications. As an example (as used in the article),
Facebook is one of the worst performing apps on my phone, often taking me to
places I never touched and crashing occasionally. Therefore I would suggest
that the hardware/implementation still needs to catch up first before choosing
a blanket HTML5 architecture (which mind you the hardware is doing gradually).

Now, perhaps it because I am testing on older hardware; however this is for
good reason. I test based on hardware that my clients/target audience use - if
they upgrade and they get a speed increase then that's a bonus - but until
then they need to get the best possible experience given the hardware they
have. I will use HTML5 for applications if I can get a reasonable return on
investment by doing so, but usability is always number one - if it doesn't
perform well then it may as well be thrown out.

~~~
hdragomir
This is also a big problem we have encountered, and I've even summed up most
of the workarounds and hacks you have to employ to gain speed.

<https://speakerdeck.com/u/hdragomir/p/fast-mobile-uis>

It's still a long way to go from there, though.

I work on Pocket Island, at wooga.

~~~
novalis
Thank you for the link. I just don't know how RemoteInspector negates the
existance of a FlashPlayerDebugger, so the "thank you" part of the slides is
exagerated in my modest view. I use Haxe and compile mostly to the c++,
Android and HTML5 targets (and soon to Haxe/Flambe through Wafl, I hope) but
the .swf target is and has been serviced by a localhost debugger for a long
time. The debugger is available for Active X, NSPAPI for the other browsers
and through a standalone version. Also, your caching experiences will vary
from other people using other caching solutions, add to that non blocking
node.js backend or a neko vm threaded server and the "loading js will freeze
the UI" slide turns to something diminute.

But I believe that can only be achieved by not depending only on pure
javascript solutions for all parts of the mobile app. Contrary to your
inference in the slides.

I think your advice is perfect for offline webview implementations but that is
only part of the problem when online service connections come into the
picture, don't you think ?

~~~
hdragomir
You are right. The slides are very vague, I know -- and I'm working on that.

I do talk a lot about loading assets and logic and how hard it is to actually
get stuff across in a nice way.

I never say go pure javascript. What I say is that you don't need mammoth
frameworks on top of javascript. We ended up depending on PhoneGap quite a bit
in the end.

Thank you for the great comment

------
cromwellian
Angry Birds for the Web was developed for HTML5 and it works reasonably well
on desktops and cross-browser (runs on Chrome, Firefox, and IE9+) It runs
offline via HTML5 AppCache, via Chrome app, or online.

Maybe your article should be titled "Writing games in HTML5 for Mobile Devices
is not ready". because I don't think the same reasoning applies to the
desktop.

You won't achieve 100% reach, as you will fail on some combination of
hardware, but perfect is the enemy of the good here.

Also, I think there is a little bit of arrogance in the two articles Wooga
posted. They claim they are one of the most technologically sophisticated
HTML5 games, but that seems dubious. Angry Birds, Field Runners, Bejeweled,
Sonar, and Cut The Rope, are just a few of many of the games out there are
push the limits of HTML5 performance, and are much smoother than Wooga's
offering and do more onscreen. I don't want to bash them, I just want to make
the point that if they are having performance issues, it's not because they
are pushing the limits of what the browser is capable of.

The real lesson is that mobile browser performance sucks, especially Canvas
operations. If and when Mobile Safari and Chrome for Android get WebGL, mobile
HTML5 games might be more plausible. Javascript performance on mobile has been
doubling roughly every generation. The newest WebKit implementations like iOS6
support the Web Audio spec which addresses low latency sound, and File System
APIs for local storage. In another generation, it may be more viable.

Have a look at Quake ported to HTML5 done in 2010 by me and a few others:
[http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=playe...](http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=player_embedded)

Back then, it ran at 45-60fps. Today, it runs at 200+fps on Chrome on the same
machine.

There are options for multiplatform development. Angry Birds was done with
PlayN, in which you write you game in Java, and we compile it to JS (with GWT
targeting CSS3+DOM, Canvas, or WebGL), Android (run direct on dalvik with
OpenGLES), Flash (via GWT->ActionScript compiler), and IOS (via translation to
CLR + Monotouch ahead of time compiler)

hAXe is another similar platform. Write code in ActionScript3-like typed-
Javascript, compile to JS/SWF/C++/Objective-C/etc.

~~~
kombine
> Javascript performance on mobile has been doubling roughly every generation

This is a very strong statement. And even if it was true, there still are
fundamental limitations to Javascript performance, i.e. you wouldn't expect it
to reach the native performance.

~~~
cromwellian
It is true in so far as if you run benchmarks on the Nexus 1, the Nexus S, and
the Galaxy Nexus, the Sun Spider and V8 benchmarks roughly double between each
device. Some of that is improvement in V8, and some of that is faster ARM CPU.

I don't think anyone is claiming JS will reach native performance, or that
you're going to write triple-A title games like Battlefield 3 in it. The
question becomes, when is it good enough?

At a certain threshold, JS performance will be good enough for a good swath of
apps and games on mobile that the deployment benefits and cross-platform
nature will outweigh the downsides for many developers.

Just look at JS on the desktop. Performance has gotten good enough that for
the vast majority of cases, people do a good chunk of their work within the
Web. There's no need to download native apps for reading news paper sites, or
social networks, or even light productivity work on your desktop.

In my opinion, too many apps are being written in native code for mobile that
don't really deserve to be, it's a temporary transient situation for a few
years.

IOS basically is a return the Microsoft era with native apps for everything,
and I think, like with Microsoft, the Web will start to turn around in the
future and start to steal back marketshare from native apps.

------
kripken
> As any HTML5 developer will tell you, coding HTML5 is hard work.

I develop using HTML5 or whatever we want to call it, and I most definitely do
NOT say that.

~~~
lukifer
Agreed. I also found this amusing: "What is a simple task on native apps can
be a decidedly more complex and time consuming task with HTML5." While this is
true for some tasks (web audio still sucks), it's the other way around for
other tasks (last time I tried to dynamically re-flow text in iOS was a
nightmare).

They also assume a gaming context, which is just one of many things that can
be done with HTML5. The way I see it, HTML5 is absolute ready for use, but not
fully matured, similar to web applications in the days of Netscape. Understand
the tradeoffs of the various ecosystems, and pick the best tool for the job.

~~~
hdragomir
Then, in the spirit of your last comment, for making pretty games on mobile
devices, stick to native for now.

I work on Pocket Island, at wooga.

------
azakai
> HTML5 is not ready.

I am guessing there was serious effort behind this game, but... it doesn't
even run on Firefox. One of the basic things in writing HTML5 apps is testing
on multiple browsers, so I guess this was not tested much?. So I am not sure
what to make of the seriousness of this project and how valid its conclusions
("HTML5 is not ready") are.

~~~
georgemcbay
The fact that any project that stresses HTML5 at all often behaves very
differently in different browsers to the point where most HTML5 demos list a
"works on this browser" message is a pretty good argument that HTML5 is not
ready, IMO.

~~~
azakai
I see that point, often there are minor differences between browsers and it's
hard to fix them all, but it isn't _that_ hard to at least get your app to
_load_ in the main ones. This failed at that.

------
huskyr
“Sound on HTML5 has some peculiar limitations. It can only be activated via
user action and there’s a delay of about half a second that can make for a
strange in-game atmosphere.”

Sound on HTML5 audio _on iOS_ has this limitation. It's not at all specific to
HTML5. iOS 6 will get the web audio api which hopefully will solve some of
these problems.

~~~
hdragomir
Please don't get me started on Android. :-)

And as mentioned in a previous comment, this is mostly about Mobile HTML5.

I am also keeping my fingers crossed for iOS6!

I work on Pocket Island, at wooga.

~~~
huskyr
The only way i could get 'HTML5 audio' to work on Android 3.0 was by using
Flash. Which is...pretty ironic.

------
pjmlp
Native apps are the way to go to fully take advantage of the target platform,
specially when doing games.

HTML/JS/CSS is a lousy way to code applications. I feel the pain everyday.

~~~
david927
I feel your pain, but HTML5 can get rid of that stack, especially when doing
games. It goes from HTML/CSS/JS to just JS.

------
daleharvey
really confused by the description of their issues, yes you need to be online
to access and download the game the first time, no you shouldnt need to be
online to play it, yes an app packaged for offline still has access to a
server.

Congrats to them to opening up the source and publishing this, html5 gaming is
still a pretty new field and everything like this helps.

~~~
hdragomir
The problem was getting fresh content (missions, better assets, what have you)
to the user. If you go with long autonomy, you get a fairly static game which
you can update in big jumps. If you go with fast updates, you sometimes delay
the startup of the app.

Either way, getting your application across initially can take some time.
Originally, the game was meant to run within the Facebook app -- for which you
would always need internet so we had to optimize for fast delivery.

I work on Pocket Island, at wooga.

~~~
daleharvey
I dont see where there is any conflict between how it works natively and how
it can/should work with an offline web app though.

The assets shouldnt take any significantly different time to transfer between
native / html, and you have the same choices of when you want to transfer them

------
laserDinosaur
"The promise of HTML5 is still an exciting one and while the time for mass
market implementation may not be in 2012, we’re confident its time will come."

Considering the specs are not even projected to be completed until around
2015, I think they might be stating the obvious here. Of course HTML5 is not
ready yet, it's not ready yet.

~~~
tudorizer
I wonder how the browsers will be in 2015...

~~~
robmcm
I wonder how the hardware will be in 2015...

------
bhalden89
HTML5 is not ready? HTML5 games may not be ready for mobile browsers, but
check out what CocoonJS can do: [http://blog.ludei.com/html5-fails-to-deliver-
for-mobile-game...](http://blog.ludei.com/html5-fails-to-deliver-for-mobile-
games-cocoonjs-begs-to-differ/)

------
marknutter
It's ready when people start using it, and people have started using it.

------
posabsolute
What a bad choice of title (on HN). It's totally not what the article is
saying, it only focus on gaming, and specially on mobile.

That being said an interesting article on a interesting html5 game.

------
drivebyacct2
Sounds like they were not using offline caching (correctly?) at all and had
very obvious side effects as a result.

~~~
hdragomir
We did use offline caching aggressively when we launched with Facebook.

Most of that logic has been removed, though, when we went the PhoneGap route.

Also, [https://speakerdeck.com/u/jaffathecake/p/application-
cache-d...](https://speakerdeck.com/u/jaffathecake/p/application-cache-
douchebag)

I work on Pocket Island, at wooga.

