I've done a lot of microchip pic programming but for equally simple(read beginners) and cheaper avr development I would recommend a teensy. Besides using a standard pinout spacing you can also program it with the arduino ide if you feel so inclined. Of course if you want to use the arduino shields, it's more convoluted, but if you just want to light a few leds, read some sensors, it should be enough.
Anyway, it's quite nice to have all these possibilities; some years ago the barrier to entry was much higher, now with 10 minutes of tutorial reading you can light a led or control a servo through your browser from the other side of the world, which is fantastic.
The spacing of the Arduino pins (between 7 and 8) is a strange decision. But a big advantage of the Arduino is it's popularity. There are a lot of Arduino shields on the market.
Another great thing about the Teensy++ is that it has a AT90USB1286 which offers 128 KB of flash and 8 KB of RAM. That is a big improvement over the Arduino Uno's ATmega328 that offers 32 KB of flash and 2 KB of RAM.
This is one of the two things that got me to order one last night. Being able to build with it on a breadboard makes a huge difference compared to the arduino. I've got a number of fun projects to do that the breadboard makes more fun to start. (Particularly things with model trains and monitoring window sensors).
There are two components to web sockets. The WebSocket API under development by the W3C/HTML5 groups (http://dev.w3.org/html5/websockets/) which defines the javascript/browser API and the WebSocket Protocol under development by the HyBi working group at the IETF (http://datatracker.ietf.org/wg/hybi/charter/) which defines the actual wire protocol.
The WebSocket API has been relatively stable for awhile, most of the changes recently have been hashing out how to handle binary messages in javascript.
The WebSocket wire protocol has been undergoing more substantial development in the past year and is presently in the Last Call phase of IETF standardization. The final wire protocol has not been fixed yet.
Protocol version numbers were added sometime last year and each version stands for which draft version of the protocol the user agent is implementing. Not all drafts change the wire protocol so some version numbers aren't used. The purpose of the version numbers was to help folks who were writing test implementations of websocket to keep track of which implementations should work together for interoperability testing.
The draft/version number primarily indicates that the client can only talk to servers that speak the same version. Clients typically support only one draft, servers often support multiple drafts. The current draft (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...) uses protocol version 13. FireFox 6 ships with a prefixed (MozWebSocket) websocket object that implements draft 7. FireFox 7 and 8 and Chrome 14 and 15 (beta and dev channels respectively) currently implement draft 8, though this may change before they are shipped. Safari 5.0.1+ and Chrome 7-13 implement draft 0, an obsolete version from 2010.
Draft 7,8, and 13 are nearly identical, a server supporting one will likely support all three. Draft 0 is significantly different. There is a list on wikipedia of the major websocket implementations and which protocol versions they presently support (http://en.wikipedia.org/wiki/Comparison_of_WebSocket_impleme...).
The OP appears to be using a simplified version of a pre-draft 0 that Pusher implemented. I am not actually sure why it is using websocket at all since it doesn't appear to actually use the browser as the source of the connection. It just happens to be using an early draft of the websocket protocol as it's message framing mechanism.
http://caniuse.com/#search=web+sockets makes the answer to that question more clear, although you'd probably need to go to each browser's documentation to find out what "partial" means in its case.
In some senses this will be harder on the raspberry pi. Certainly more complex. You'd have to worry about the whole stack from the kernel upwards. On arduino, you handcraft your protocol right on top of the TCP/IP lib and just squirt it straight into the bootloader. Done.
If everyone in tech took the attitude of "let's not bother now, <next big advance> is coming soon" then noone would ever build anything.
Yes, Raspberry Pi is cool and you will probably be able to do this with it some day. In fact, there are a billion platform alternatives available right now (or soon) at various price points. Albeit not with the internet-punter coverage that the Pi has (deservedly) gotten.
However, krohling is doing this with an Arduino right now and it looks to work just fine.
The subject of the post was more the software not the hardware. The Arduino in the post is using the WiFly shield: http://www.sparkfun.com/products/9954
Anyway, it's quite nice to have all these possibilities; some years ago the barrier to entry was much higher, now with 10 minutes of tutorial reading you can light a led or control a servo through your browser from the other side of the world, which is fantastic.