4 ms·
I don't see how this is different than using any of the myriad javascript mvc style frameworks that are out there in tandem with websockets.
by marknutter 15y ago
I don't see how this is different than using any of the myriad javascript mvc style frameworks that are out there in tandem with websockets.
- mafro 15y agoI'm glad to see someone on here doesn't think this is quite so sensational. The only relatively new thing they've done is launching the native game from the browser plugin - and I also wondered if a custom URL scheme would not work instead (and be simpler). In terms of game manufacturers it is light years ahead of what they've done before. I just don't see why the author is quite so blown away by it..
- logn 15y agoI tend to agree with you. XSLT web apps can render on the client and just transmit XML. Same idea. GWT does this too. And I'm sure there are older examples.
- mambodog 15y agoThe point here is that progressive enhancement is baked in all the way through, eg. using the same URLs regardless of whether a page is being requested by the thick JS client, an old dumb browser, or search engine crawl. The realtime stuff works regardless of whether websockets are available (Flash & long polling fallbacks). What this means is that you can actually deploy these new features in the real world without freezing out part of your audience, as happened with Gawker's ill-fated redesign. What's more, you can do this without having to develop everything twice, using abstractions like client/server shared language-agnostic templates and realtime libraries like Socket.IO.