Comments on: Web Sockets in HTML 5 might solve the http pull problem once and for all

By: Mads Sülau Jørgensen

Mads Sülau Jørgensen — Fri, 21 Aug 2009 07:50:28 +0000

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.

By: Wayne B

Wayne B — Fri, 21 Aug 2009 00:25:57 +0000

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

By: Tarik

Tarik — Thu, 20 Aug 2009 20:50:09 +0000

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.

By: Wayne B

Wayne B — Thu, 20 Aug 2009 17:44:07 +0000

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.

By: Ryan Petrich

Ryan Petrich — Thu, 20 Aug 2009 17:09:55 +0000

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

By: Barklund

Barklund — Thu, 20 Aug 2009 16:03:19 +0000

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.

By: Ian McDowall

Ian McDowall — Thu, 20 Aug 2009 15:40:17 +0000

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)?

By: Barklund

Barklund — Thu, 20 Aug 2009 11:39:20 +0000

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.

By: Mads Sülau Jørgensen

Mads Sülau Jørgensen — Thu, 20 Aug 2009 11:19:43 +0000

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.