HTML5 is not ready
wooga.com
wooga.com
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.
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.
I work on Pocket Island, at wooga.
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.
Once Android starts shipping with Chrome stock things will be different.
Judging the companies by the browser they put in front of users, Apple cares more about HTML5 than anybody else. Like I said, if Google can get mobile Chrome out there I'll revise my assessment.
This just captures features, speed is an order of magnitude.
H.264 support is not an HTML5 feature, by the way.
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.
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.
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.
"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.
Either Native -> HTML5 with things like Mandreel (http://www.mandreel.com/)
or
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
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.
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.
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.
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 ?
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
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.
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.
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.
I strongly agree with that! I feel like it's not been made clear enough.
I work on Pocket Island, at wooga.
I develop using HTML5 or whatever we want to call it, and I most definitely do NOT say that.
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.
I work on Pocket Island, at wooga.
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.
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.
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.
HTML/JS/CSS is a lousy way to code applications. I feel the pain everyday.
Congrats to them to opening up the source and publishing this, html5 gaming is still a pretty new field and everything like this helps.
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.
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
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.
"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.
That being said an interesting article on a interesting html5 game.
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.