After HTML5 Web Storage, I'm gonna show a use case of HTML5 Websockets. It's quickly becoming a hype solution for bidirectional communication between client and server (think TCP for browsers). Hype but not really usable in production because of the compatibility with the browsers.

Compatibility of Websockets (as of January 2010) : nightly builds of WebKit and Chrome.

We just have to start the server and test with client.html to see the tweets.

Conclusion

If you read the code you'll see that Websockets make more sense to a developer than Comet. And it's the same for a lot of HTML5 features. Having more logical things and less hacks will may finally be a reality soon. You can see the whole code of this example in my fork of the original one.

After HTML5 Web Storage, I’m gonna show a use case of HTML5 Websockets. It’s quickly becoming a hype solution for bidirectional communication between client and server (think TCP for browsers). Hype but not really usable in production because of the compatibility with the browsers.

Compatibility of Websockets (as of January 2010) : nightly builds of WebKit and Chrome.

Cramp for Websockets

Lifo introduced it on his blog. A few lines later we have the application configured for Cramp instead of EventMachine in socket.rb:

on_start

Now we want to convert the open event to Cramp. For that, Cramp has a on_start method to call the method executed for this event. So the open event will be like that:

To send a message to the user, Cramp has a render method.

on_finish

When the user ends the execution of the socket, there’s a close event. When this event is fired, the method passed to on_finish will be executed.

We just have to start the server and test with client.html to see the tweets.

Conclusion

If you read the code you’ll see that Websockets make more sense to a developer than Comet. And it’s the same for a lot of HTML5 features. Having more logical things and less hacks will may finally be a reality soon. You can see the whole code of this example in my fork of the original one.

I'm beginning a series of articles about the modern features of Web browsers. This article will be about HTML5 Web Storage and particularly localStorage. And because I like it, another twitter example folks!

What is localStorage?

Basically it's like cookies but restricted to the client (the server cannot get data from localStorage), it can store more data (the limit depends of the browser but it's generally 5MB) and it doesn't have a time expiration. It's time for the example!

WARNING: You must test the above example with a real URL (not file://). Otherwise it won't work in IE and Firefox (but seems to be fine in Safari and Chrome)

The slow way

First we get the tweets and display them. It is slow because each time we access the page the Javascript will request Twitter. And it's ugly because we have a loading message before displaying the tweets.

localStorage.setItem(key, value) take a key for the first argument ("tweets" here) and the value for the second argument (the Twitter JSON response here). WARNING: The value must be a string so if we want to store an object, we stringify it with JSON.stringify(data).

To get the data it's localStorage.getItem(key). If there's something in it we display them. The first time we access the page there won't be anything in localStorage so the process will be the same as "The slow way". The other times the tweets will be displayed instantly. The Twitter request is running too, so it will refresh the list a little bit after the first display in case there's any new tweets. The rendering will be way prettier than the loading message! You can see the example here.

If we want to clear the localStorage it's as simple as localStorage.clear().

Old browsers compatibility (progressive enhancement)

If you do that in production, the Javascript will fail for the users who have old browsers. To be safe, we will download Modernizr (I will write an article about Modernizr soon) and check if the browser has a localStorage: