Half of the point seemed to be to build Flash-like games. That's not a Flash-like game it's a one page tutorial that's probably been written for every language in the last 30 years.
The other half was who needs Flash? Until you can show games comparable to these - http://www.kongregate.com/top-rated-games - with no omissions or compromises or exceptions, the answer is people who are serious about producing casual games need Flash.
JavaScript is improving in a lot of areas but "not Flash" is a horribly weak argument especially when backed by examples such as this. "Not Flash" implies the platform's actually a problem itself ... consumers, developers and an enormous portion of the internet don't share that mindset. If you want to win marketshare against Flash you need to be better in most or all areas, not almost equivalent in some.
He's not though. Proving that you can write a small game in javascript/html5 does not in any way prove that you can write a complex, feature filled game.
I write games for a living (see http://www.rocksolidarcade.com), and the thought of developing them in html5, with the tools and compatibility we have now makes me sick. Eventually an abstraction layer that's fast and powerful enough will come along, once all the browsers support all the features needed.
But writing an abstraction layer, writing a tiny game in it and declaring that "in 2010, games built in JavaScript can be just as shiny, interactive, and fluid as games built in Flash." is ridiculous.
How about instead of giving us 'boys' 'a hint', you drop the condescending bullshit and explain exactly what you mean.
I'm an experienced and successful game developer. Hundreds of millions of plays. Done very well financially. People sometimes recognize my game on the street when I'm wearing a company shirt. I think that entitles me to have an opinion without being treated like an idiot.
Hey, no hard feelings. I think we're all guilty of that from time to time. I'm sorry I hit back so hard (I'd erase it now you've appologized but unfortunately the edit window has lapsed).
If you were using Flash IDE and wrote the game on the timeline, it would take the same amount or fewer lines, since a good third or more of the code is graphics and anim-related stuff that would be done entirely in the tool.
As the other guys are saying, if we're talking about a bigger game, libraries and frameworks can provide substantial savings since they help you build consistent behavior across the whole app. But you can build those for Flash, too. I'm building one. It lets you iterate over the assets while the game runs and then ship a preloader by running a different compile script; it has user setting abstractions for keyboard, mouse, and sound, it has bitmapped font support, an entity model, some limited-but-growing tilemap and spritesheet abilities, pathfinding...in the next few days I'm planning to build out a menu system that I can reuse or customize for every game.
In any case, these things are considerably more game-specific, and they provide an LOC savings that matters even on "weekend projects" - everyone likes to have user settings, everyone likes having a sprite sheet pipeline, etc. But you don't get that from a web framework used as a game platform, which is what this is.
The other half was who needs Flash? Until you can show games comparable to these - http://www.kongregate.com/top-rated-games - with no omissions or compromises or exceptions, the answer is people who are serious about producing casual games need Flash.
JavaScript is improving in a lot of areas but "not Flash" is a horribly weak argument especially when backed by examples such as this. "Not Flash" implies the platform's actually a problem itself ... consumers, developers and an enormous portion of the internet don't share that mindset. If you want to win marketshare against Flash you need to be better in most or all areas, not almost equivalent in some.