HTML5 is not ready

http://www.wooga.com/2012/06/woogas-html5-adventure/

by cientifico • 14 years ago

76 58 14 years ago

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.

hdragomir9• 14 years ago

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.

novalis2• 14 years ago

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 ?

tomjen3• 14 years ago

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...) 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• 14 years ago

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

laserDinosaur• 14 years ago

"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.

daleharvey3• 14 years ago

You arent stating the obvious, just a misunderstanding of the standardisation process

"HTML5" is not a single thing, and it wont suddenly be released in 2015, there is a lot to it and a lot of people are using various parts now and have been for a long time.

tudorizer• 14 years ago

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

robmcm• 14 years ago

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

marknutter• 14 years ago

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

daleharvey3• 14 years ago

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.

hdragomir9• 14 years ago

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.

daleharvey3• 14 years ago

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

zanny• 14 years ago

Web workers!

kripken• 14 years ago

> 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• 14 years ago

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.

hdragomir9• 14 years ago

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.

jcromartie2• 14 years ago

When I want to dynamically re-flow text on iOS, I use HTML in a UIWebView. Otherwise, native is easier for presenting a navigable and interactive UI. Using the right tool for the job is always the way to go.

kunle2• 14 years ago

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• 14 years ago

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.

ThomPete• 14 years ago

Apple don't want the app store to be anything but break even. They have it because it's a way to make money where it really matters which is the hardware.

hdragomir9• 14 years ago

wooga chose to focus on iOS because of the less fragmentation.

I work on Pocket Island, at wooga.

zmmmmm• 14 years ago

> it benefits them only indirectly by making iOS a more attractive choice

Since you agree it benefits them - and your use of the word "only" is deceptive here; having the best app catalog is no marginal thing, it is an enormous benefit, often cited as the primary reason Android tablets have struggled and why WP7 failed - why don't you think that benefit - which exists primarily because HTML5 still sucks for mobile apps - incentivises them not to improve browsers?

It would be trivial for both Google and Apple to remove a large number of the barriers to HTML5 apps replacing native apps. But they don't, and it's been long enough that time is not an excuse.

cageface4• 14 years ago

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.

MatthewPhillips4• 14 years ago

A similar, but less conspiracy-y explanation is that there is essentially no browser competition in mobile so there is no motivation to improve like on desktop. Hence, the two major OS vendors update their browsers yearly.

greggman2• 14 years ago

You can cross develop though

Either Native -> HTML5 with things like Mandreel (http://www.mandreel.com/)

HTML5 to Native with things like cocoon.js (http://ludei.com/tech/cocoonjs)

Even many "native" apps just embed the native browser as a widget. Development is often much faster that way and they can fall back to native APIs for those few features HTML5 doesn't give them access too

flatline3• 14 years ago

> Even many "native" apps just embed the native browser as a widget.

They sacrifice UX doing so.

> Development is often much faster that way ...

It's faster for their existing web team, which is what this is really about.

josephcooney• 14 years ago

How much do google really make from Android?

hdragomir9• 14 years ago

A fraction of what AppStore revenue is -- even though they have more market share. :-(

drivebyacct2• 14 years ago

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

jcromartie2• 14 years ago

Last time I experimented with this, it was not a viable option for my use case for several reasons.

hdragomir9• 14 years ago

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...

I work on Pocket Island, at wooga.

posabsolute• 14 years ago

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.

azakai2• 14 years ago

> 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• 14 years ago

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.

azakai2• 14 years ago

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.

bhalden89• 14 years ago

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...

pjmlp• 14 years ago

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• 14 years ago

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.

huskyr2• 14 years ago

“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.

hdragomir9• 14 years ago

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.

huskyr2• 14 years ago

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

cromwellian2• 14 years ago

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...

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• 14 years ago

> 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.

cromwellian2• 14 years ago

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.

hdragomir9• 14 years ago

> Maybe your article should be titled "Writing games in HTML5 for Mobile Devices is not ready".

I strongly agree with that! I feel like it's not been made clear enough.

I work on Pocket Island, at wooga.

HTML5 is not ready

Related Stories