With Web/Local Storage you are limited to 5-10 Megabytes of data.
There will be a shitstorm once graphic drivers get exploited through WebGL.
The game the writer self-promotes is a completely different genre than what id Software does (2D shmup versus a 3D FPS with detailed graphics). It eats a whole CPU core for a seemingly trivial game (might just be missing sleeping in the code, I have no clue).
And never forget that web-based games are kinda non-free unless you can download them and play them locally. You are always at the whim of the developer/hoster/provider. I much prefer games that run natively, disconnected from the internet (attack vector) and whenever I want.
The web platform is rapidly improving for games, on all fronts.
The HTML5 offline (appcache) spec allows you to have resources available when offline (and you don't need to write your own code to stuff things into localstorage...) Besides, localstorage is not considered, by browser hackers, to be the best idea performance-wise. They recommend IndexedDB.
Those specifics aside, my main point is to say that game makers are targeting the browser and browser vendors are very much aware of the pain points they have and are working to correct them. Browsers today evolve much faster than they did a few years ago.
You only need localStorage for saving game or preferences.
Static assets (like models, textures, most of the level) should be, well, static, and can be as huge, as you like them.
Also you can write html5 game as one-page website without server part, and downloading it to play it offline is as simple as file->save complete web page as.. in your browser. You can provide installer for your players that just unpacks the game to directory and places shortcut in start menu (no dll-s, no register settings), you can pack your game into chrome app format for some users and place your game in chrome app store.
One thing I think chrome gets wrong is its security policy that by default prevents local web apps (when you open html file on your disk in browser directly) from doing ajax requests on the same directory. That means you need to wrap static assets in html, and that's stupid, I should be able to load xml from the directory my index.html is stored in. But whatever, there's workaround.
I think most games don't really need super detailed 3d graphic, and simplicity of distribution (nothing to install, just click link and play) is the killer feature of html5 for simple casual games.
There will be a shitstorm once graphic drivers get exploited through WebGL.
The game the writer self-promotes is a completely different genre than what id Software does (2D shmup versus a 3D FPS with detailed graphics). It eats a whole CPU core for a seemingly trivial game (might just be missing sleeping in the code, I have no clue).
If you use a good codebase, you do not need to write 200 lines just to setup your screen, eg http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenG... .
And never forget that web-based games are kinda non-free unless you can download them and play them locally. You are always at the whim of the developer/hoster/provider. I much prefer games that run natively, disconnected from the internet (attack vector) and whenever I want.