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.
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?
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.
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.
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.
What are you basing this on? At minimum Chrome and Firefox have better html5 support, as they have near parity with their desktop counterparts. I don't have the numbers but I'd guess Opera Mobile has better html5 compatibility as well.
I'm talking about the browser shipping with the system, which is what 99% of the people using the device are going to use and where web apps are going to live or die.
Once Android starts shipping with Chrome stock things will be different.
I really doubt it has significantly better html5 support than the Android browser, if it's even better at all. But goal posts moving aside, your point was that Safari is somehow evidence that html is important to Apple, when viewed in the context of the entire industry it's above average. Lots of companies are doing good things with html in mobile, even Rim.
Mobile Safari is head & shoulders better than the stock Android browser, which is really a piece of shit. This is abundantly documented all over the web. Just ask the Sencha guys how much fun they've had trying to get acceptable performance out of Android.
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.
> 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.
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.
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
I'm not sure that's true. I think there are some fairly popular mobile apps using a webview. The facebook app? Honestly I don't know if that's true but their mobile website has almost the exact same UX. There's a few subtle differences but maybe those come from some glue around a webview and not all brand new code.
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.
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.
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 ?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
“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.
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.
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 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
"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.
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.
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.