Web Sockets in HTML 5 might solve the http pull problem once and for all
The truth be told, us ActionScript programmers have always had it easy when it came to creating real-time, multi-user applications. We might not have had much processing power back then, but as early as Flash 5 introduced back in 2000, we got the XMLSocket object, which enabled a whole series of multi-user-applications like isometric chat worlds etc. This leaves us JavaScript programmers a bit stranded. We do have Comet and similar technologies, but true persistent connections, we have never had – unless we used a Flash object in the document somewhere, but who wants to use Flash anyway?
But with the dawn of HTML 5, this worry is irrelevant, because with HTML 5 and the greatly improved JavaScript API, we also get a brand new Web Sockets API. This will have the same basic low-level access to bi-directional communication as ActionScript got with the XMLSocket API – it wasn’t XML only, it was just the (widely used) default transport method, but it could easily be circumvented.
Quite stunning though, how such a simple mechanism arrives in JavaScript 10 years later than it did in ActionScript!
When this becomes standard in new browsers across vendors, we will see it implemented in so many popular applications, that currently use all sorts of tricks to achieve the same results – like Facebook, who uses Comet to “push” JavaScript notifications. With this API, doing stuff like that becomes much easier and much cleaner. Or Google Docs, who use Comet as well as HTTP pulling. Or NFL live match view, who use a Flash object in the document to receive events about the match being watched.
And this of course also increase the opportunity for creating new multi-user applications – and games – in HTML and JavaScript. And given the extra computational strengths, that most JavaScript engines are being equipped with currently (Chrome started the race and IE8 perform surprisingly well), and given some of the other fun things in HTML 5 like canvas, things will really start to get interesting.
Go HTML 5 – get yourself final as soon as possible! Give us JavaScript programmers the same tools that we ActionScript programmers have had for a decade.
Related posts:
Category: Flash Platform, HTML 5, Trends 9 comments »
August 20th, 2009 at 13:19
I just hope that it won’t involve the same amount of oddities between browsers, as for example XmlHttpRequest does.
You just gotta love jQuery and friends for hiding all that scary stuff.
August 20th, 2009 at 13:39
XmlHttpRequest came in through the backdoor as you know. IE5.0 invented it (necessary to do Outlook Web Access), but via ActiveX and a strange instantiation method. The other browsers adopted something similar eventhough still non-standard and only after that it actually became a draft for a standard, that is still only in Final Call Working Draft since 2008.
Microsoft invented something good for once ;)
Given that no browser started inventing their own socket client API, the specification will probably be implemented correctly first time by all parties – even Microsoft.
August 20th, 2009 at 17:40
But what about server support? I have been looking at putting together something like this with long-standing HTTP requests and the browser / Javascript side is easy but it needs a server which can comfortably support paused / waiting requests and a means of communicating between requests so I am going to build one using Twisted.
Anyway, I am sure that there are multiple alternatives but they all need server support – HTML 5 support in the browser is not sufficient by itself. Are you assuming that custom servers are the easy part (from a deployment point of view)?
August 20th, 2009 at 18:03
Facebook does Comet for their millions of simultaneous users. Maybe they built the server software from scratch, but it sure proves, that it can be done and in large scale. Oh, and GMail and GDocs does it as well, be Google for sure built it from scratch even if the software existed.
Twisted is a good choice for implementing this kind of serverside technology. Previously I’ve built such applications using Python or Java, but only for Flash clients.
I am sure, that when the ball starts rolling, you will see dozens of serverside frameworks popping up for this kind of architecture – both commercial and open-source and there will be a lot of crap and only a handful gems in-between.
If you build it [client-side socket API's -ed], they [server-side architectures -ed] will come.
August 20th, 2009 at 19:09
Facebook has indeed built it from scratch. They have very interesting blog posts on the subject: http://www.facebook.com/note.php?note_id=51412338919
Getting COMET to work properly isn’t technically difficult, but involves a lot of corner cases specific to each browser that make it prohibitively expensive to cover unless you are a Google or Facebook-sized company. A common API as specified in HTML5 will make this sort of application much easier to develop
August 20th, 2009 at 19:44
I’d much rather use a pure environment with _good_ programming tools such as Silverlight. HTML/Javascript is the absolute lowest common denominator as far as application platforms go and frankly, it kinda sucks.
August 20th, 2009 at 22:50
I don’t know about Wayne B, but I tend to think of ‘pure environments’ as client agents that don’t require plugins. Naturally, unless you’re coding for a client specifically with IE8, this precludes the use of Silverlight. I also tend to think of _good_ programming tools as the ones which support open standards, even if not as their primary format.
August 21st, 2009 at 02:25
It’s cool with me if we disagree about the _value_ that we each get from the platform. I surmise that to you, the web is valuable as an applications platform because of the fact that it _is_ the lowest common denominator; you can reach everybody and everybody’s equal and the barrier to entry is zero.
To me, that’s less valuable than the ease with which I can transform the thoughts in my head into a product that works for most people. Silverlight and Flash are indeed much more pure than HTML. They certainly have more of a capacity to be so, since they’re maintained by one company which is better than a committee. As a matter of fact, if you can get one smart a**hole in that company to run the show, you’ll be better off for it.
I think of good programming tools as the ones that let me think the least about things that don’t matter and help me accomplish the things that do without a lot of fuss. There’s already enough fuss…too much in fact depending on the industry you’re in. As a matter of fact, imho software development as a whole could stand to get an order of magnitude easier.
Besides the tools though, I really wish that they would just drop HTML5 and come up with a completely new standard that is focused on application development, not this mix between “documents” and “applications”.
See my reddit comments for more thoughts on the issue:
http://www.reddit.com/r/programming/comments/9cefn/web_sockets_in_html_5_might_solve_the_http_pull/c0c94wn
Sorry for hijacking your thread. We all have to deal with it sometimes:
http://stackoverflow.com/questions/1148591/recording-audio-from-users-microphone-in-silverlight-3/1176392#1176392
August 21st, 2009 at 09:50
As for what kind of software to use to build such a socket server, there are endless possibilities. As Morten says, twisted is a good way to go (perfect for prototyping), because it’s all about doing thing asynchronously.
If you *really* want to reach a million simultaneous users, you’ll probably want to build something on top of erlang otp or libevent for c.