BrowserQuest– a massively multiplayer HTML5 (WebSocket + Canvas) game experiment
hacks.mozilla.org
hacks.mozilla.org
1) security 2) computational performance 3) flexibility
WebSockets for example are just a bad rehash of existing APIs. Woopty-doo.
this is a great DEMONSTRATION. leave it at that. if you are really that annoyed by the points you mentioned, why, it's open source!
Simple like DF?
The potential is awesome and Im sure some hackers out there will do something amazing with the source code.
A game like this was feasible 20 years ago in a native environment or 10 years ago in Flash. I can only see disadvantages in developing games in JavaScript + HTML.
Write up something explaining your views, the post it as a comment/Ask HN/blog post and submit.
Also you seem to be saying this sucks in comparison to some amazing product that doesn't actually exist... the big feature of html5 is that it's already widely deployed.
The other is a maze to a rickroll, and then there's a fox potion that turns you into a firefox that makes you invincible for a short time.
1) Zero-pain installation (no steps, no wait to download)
2) Zero-friction sharing (paste a url to any resource within the app/game)
3) Zero-friction upgrading (happens automatically. depending on architecture, no need to even reload the app)
4) Largest install base of any platform
It's a classic disruptive technology. Yeah the graphics suck. Yeah it's slow. But those things are improving, and will get to the point where they're "good enough" for a big swath of uses. Whereas the four properties above are much more challenging to fit into an Xbox or iOS architecture.
Web links are cool. Just about the only redeeming feature of the web. They have absolutely no connection to JavaScript, HTML5 or any of the other hideous complexity you see in the browser.
Browsers are not "zero friction" upgrading. Behaviour changes from version to version. Using Firefox on Linux I have experienced continued breakages. Again, if you had a simple virtual machine it would be simple to port anywhere, and you wouldn't need constant bug fixes.
Your last point has nothing to do with technology. It is simply the result of vendors successfully selling the technology to people. By doing so they've locked other better approaches out of the market due to network effects.
The remainder of your post is the good old "it'll be good enough" attitude. Except it won't ever be as good as it was because people are reliant on benchmarks that make "freight train" style systems look "fast" for through-put code.