HTML5 WebSocket and WebJneering

I want to tell you about HTML5, specifically about the advances in bi-directional, asynchronous communication. But I’m troubled. Consider two propositions that I didn’t come up with: 1) Nothing is new, 2) Everything Sucks. Let these simple truths cast a shadow upon the tale you are about to read…

HTML5 provides a new thing called a WebSocket. I’m pretty sad that its not a TCPSocket, but alas, it was easier to throw in a handshake for security than to set up some out-of-bound security method, such as flash’s cross-domain policy files. We can’t connect to existing TCP servers, so we’ll just have to start over and write new WS/TCP servers. No problem. WebSocket will still be our salvation, leading us towards our stateful future.

I was at first overjoyed at the prospect of the World Wide Web’s new status as a real boy. But such feelings were just a precursor to the greatest technology-driven depression of my life. You see, as recently as twenty years ago the world was brimming with real programmers, who knew how to do such amazing things as write programs that conversed with far-away computers by using bsd sockets. We’ve traded those programmers, by and large, for JavaScript kiddies. Its not that the real programmers all died, retired, or gave up with programming; rather, every new programmer of the past decade is a bright-eyed 22 year old who thinks he’s the best thing since Google, what with his domination of rails (, java, or php) and javascript.

You can probably empathize with my character’s role in this story; I’m just like every other post-apocalyptic protagonist, having spent my whole life questing after futuristic technology of the past, only to discover upon finding it that we’ve fallen so far as to render its usage unobtainable.

The fact of the matter is this. Our civilization already selected “Good Network Application Architecture” and clicked research. Such practice includes simple ideas:
1) Isolate GUI logic to the client
2) Design a protocol (or use an existing one) to transfer application data
3) Use something called state. Have a session. In fact, tie that session to the TCP connection.

But such wisdom can’t help us. We can’t even begin to understand its profoundity because we wholly lack the context. I’ve been trying to re-establish some of that context over the past couple of years, having devoted my life to uncovering the lost art of TCP. And I’ve succeeded in casting a bright spot of hope upon this gloomy era of Web Architecture. My work with Orbited culminated in the development of a TCPSocket api for all browsers. Much like squeezing the oil from olives to fuel the last of our ancestors’ mechanized tractors, this is made possible by employing Comet and Ajax to communicate with a TCP proxy, and thus with actual TCP servers.

But as I said, we’ve lost our context. Realizing my dream doesn’t mean anyone else realizes the next, obvious step. Time to stop dragging the plow yourself and we’ll cover some real ground. But handing a socket to a Web Engineer is the same as handing a tractor to a caveman. You’ve really got to spell out how to use it. And it turns out that the tractor is just too damn complicated to actually use.

So the next leg of my journey was to assemble a codex of knowledge. What does one do with a socket? Thus began the development of a collection of network codecs, js.io. Instead of teaching Webjneers how to use sockets, I can teach them how to use XMPP, IMAP, and STOMP clients, so they don’t have to invent their own shitty wheel when building a proper network application. So enters light into this world.

If only. Really its a small, fragile light that could be snuffed out by a stray bus on Castro street. When the 1 out of 50 web programmers I talk to actually start to get the idea of Orbited.TCPSocket and js.io, I don’t get the satisfaction of wisdom well shared. Instead, I get questions like, “Isn’t building stateful communication on top of stateless communication just a big hack?” All I can say is this: Its kinda like building TCP on top of IP. Or building so-called “HTTP sessions” on top of HTTP. But such comparisons are lost on savages.

Instead of laying down my burden and letting someone else carry on the torch, I noticed a fellow seeker, Hixie, who had tried to put a TCPConnection into the HTML5 Specification.

“Ho, Hixie.”

And with those words I proposed some improvements which led to what we now know as WebSocket, camel casing and all. Let this idea of a WebSocket be a standard ™ in this world.

So what happens now? I suspect that nothing will happen. We will have limited uptake of Orbited.TCPSocket and HTML5 WebSocket. There are too many trillions of dollars invested in the wrong way of doing things to such an extent that doing things the wrong way will be easier for a long, long time to come. Eventually though, we’ll have our salvation.

Though I despair with the present, we should recognize the moral of this tale, that the past iteration of technology led us right to the very brink, and then over. We must never repeat our mistakes. Only Open technology that runs everywhere is acceptable. The modern Web Browser has this characteristic, and it is this that we must keep as we recover our ancestor’s secrets. We must be ever vigilant, for a single slip can and will lead to a second apocalypse from which we may not recover. I am hopeful that a third era will arrive when I can truly say that there is technology in this world that doesn’t suck, and technology that is new; browsers with sockets are a likely candidate for both.

Michael Carter