When AJAX came around a few years ago, the technique started to bring more dynamic interactivity to web. But still, all communication was imitated by user interaction (or periodic polling) to load new data from the server. Usually server initiated connections is a hack created to give the illusion of interactivity or responsiveness is leaving the connection open for longer and “hanging”. It’s possible for a request to time-out, and a new connection will be needed anyway. Other techniques involve Flash, XHR multipart requests. However, all of these work-arounds share one problem: They carry the traffic overhead of HTTP, which doesn’t make them well suited for low latency applications.
Technologies that enable the server to send data to the client in the very moment when it knows that new data is available have been around for quite some time. The umbrella term often used to describe this is ”Push” or sometimes ”Comet”.

One of the cool new features of HTML5 is WebSockets, and they are a bit different are different though. WebSockets is a type of push technology basically. The technique makes it possible to open an interactive communication session between the user’s browser and a server. With this it let us talk to the server without using AJAX requests. The WebSockets specification defines an API (Application Programing Interface) establishing ”socket” connections between a web browser and a server. In plain words: There is an open connection between the client and the server and both parties can start sending data at any time. This has its benefits: decreased latency being one of them, as a connection that has already been opened does not require a new connection to be established.

Examples? There are many cross platform APIs developed by third party developers that aims to make real-time apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. Most build upon using JavaScript in real-time. At the moment, the use of these APIs, is still being standardized by the W3C; however, the latest versions of Chrome and Safari have support for WebSockets.

We hope to se more great usage of WebSockets and continue to make the web a happier place.

It may be functional, but from a branding perspective it’s a disaster. Typography is an important part of todays branding tools and when used right can be very powerful. For too long the attention to detail that typographic styling means have been overlooked as a whole. Let’s not forget that typographical design was a considered a sacred art back in a day and some might say that it was lost on a generation but I think we are seeing a rebuild into the typo getting back its former glory.

Sure, there are workarounds and a few alternatives developed in recent years that enables more advance styling options, but between all the formats like OFT, EOT, WOFF, SVG, CSS @font-face, SIFR, Cufon etc, they all seem to have flaws rending them more or less useless in the big picture. For one, even is the style is correct doesn’t often load instantly and flashes of non-styled content can be hugely annoying and generally we are still missing ways to kern, style, transform, and scale our web type.

The web is beginning to catch up surely, but much of these are still not implemented across all browsers etc. Modern browser have much improved text rending and the resolutions on screens a getting higher, all making for a better viewing of content and therefore fonts.

Things are brewing out there though and its about to change the myths surrounding the limitations of typography on the web. Perhaps the most interesting version of fonts is the Google web fonts released last year, enable free font for the masses.

The type nerd in all of smiles when thinking of the new possibilities and the beautiful web designs ahead of us. Hell, I even hear it turns some people on.