In this blog post we’re going to cover how to use WebSockets to create real-time web applications. Before we dive into learning about the WebSocket protocol and API I first want to spend a little time going through some of problems that face real-time web applications and how the WebSocket spec aims to solve them.

A Brief History of Real-Time Web Applications

The web was built around the idea that a client’s job is to request data from a server, and a server’s job is to fulfill those requests. This paradigm went unchallenged for a number of years but with the introduction of AJAX around 2005 many people started to explore the possibilities of making connections between a client and server bidirectional.

Web applications had grown up a lot and were now consuming more data than ever before. The biggest thing holding them back was the traditional HTTP model of client initiated transactions. To overcome this a number of different strategies were devised to allow servers to push data to the client. One of the most popular of these strategies was long-polling. This involves keeping an HTTP connection open until the server has some data to push down to the client.

The problem with all of these solutions is that they carry the overhead of HTTP. Every time you make an HTTP request a bunch of headers and cookie data are transferred to the server. This can add up to a reasonably large amount of data that needs to be transferred, which in turn increases latency. If you’re building something like a browser-based game, reducing latency is crucial to keeping things running smoothly. The worst part of this is that a lot of these headers and cookies aren’t actually needed to fulfil the client’s request.

What we really need is a way of creating a persistent, low latency connection that can support transactions initiated by either the client or server. This is exactly what WebSockets provide and in this post you are going to learn all about how to use them in your own applications.

How WebSockets Work

WebSockets provide a persistent connection between a client and server that both parties can use to start sending data at any time.

The client establishes a WebSocket connection through a process known as the WebSocket handshake. This process starts with the client sending a regular HTTP request to the server. An Upgrade header is included in this request that informs the server that the client wishes to establish a WebSocket connection.

Here is a simplified example of the initial request headers.

GET ws://websocket.example.com/ HTTP/1.1
    Origin: http://example.com
    Connection: Upgrade
    Host: websocket.example.com
    Upgrade: websocket
    

Note: WebSocket URLs use the ws scheme. There is also wss for secure WebSocket connections which is the equivalent of HTTPS.

If the server supports the WebSocket protocol, it agrees to the upgrade and communicates this through an Upgrade header in the response.

HTTP/1.1 101 WebSocket Protocol Handshake
    Date: Wed, 16 Oct 2013 10:07:34 GMT
    Connection: Upgrade
    Upgrade: WebSocket
    

Now that the handshake is complete the initial HTTP connection is replaced by a WebSocket connection that uses the same underlying TCP/IP connection. At this point either party can starting sending data.

With WebSockets you can transfer as much data as you like without incurring the overhead associated with traditional HTTP requests. Data is transferred through a WebSocket as messages, each of which consists of one or more frames containing the data you are sending (the payload). In order to ensure the message can be properly reconstructed when it reaches the client each frame is prefixed with 4-12 bytes of data about the payload. Using this frame-based messaging system helps to reduce the amount of non-payload data that is transferred, leading to significant reductions in latency.

Note: It’s worth noting that the client will only be notified about a new message once all of the frames have been received and the original message payload has been reconstructed.

Setting up the Demo

Building a WebSockets Demo Application

In true Treehouse style you’re going to be learning about the WebSocket API by creating a simple demo application that communicates with a WebSocket server. Before we dive into the details of the API you first need to set up a few files for your demo.

See the Demo Download The Code View on CodePen

Create an index.html file and populate it with the following markup.

<!DOCTYPE html>
    <html lang="en">
    <head>
      <meta charset="utf-8">
      <title>WebSockets Demo</title>
    
      <link rel="stylesheet" href="style.css">
    </head>
    <body>
      <div id="page-wrapper">
        <h1>WebSockets Demo</h1>
    
        <div id="status">Connecting...</div>
    
        <ul id="messages"></ul>
    
        <form id="message-form" action="#" method="post">
          <textarea id="message" placeholder="Write your message here..." required></textarea>
          <button type="submit">Send Message</button>
          <button type="button" id="close">Close Connection</button>
        </form>
      </div>
    
      <script src="app.js"></script>
    </body>
    </html>
    

Here you have created a few key elements that will be used in your application. These include a <div> for displaying messages about the connection status; a list that will be used to display messages sent to, and received from the server; and a form for inputting messages.

The style.css file referenced here can be found in the code resources download.

Next up create a file called app.js and add the following JavaScript code in it.

window.onload = function() {
    
      // Get references to elements on the page.
      var form = document.getElementById('message-form');
      var messageField = document.getElementById('message');
      var messagesList = document.getElementById('messages');
      var socketStatus = document.getElementById('status');
      var closeBtn = document.getElementById('close');
    
      // The rest of the code in this tutorial will go here...
    };
    

Here you have created a number of variables and initialized them by fetching key elements on the page.

Opening Connections

Okay, so now that you’ve got your demo application set up we can start learning about the WebSocket API. To begin with you are going to learn how to create a new WebSocket connection.

Creating WebSocket connections is really simple. All you have to do is call the WebSocket constructor and pass in the URL of your server.

Copy the following code into your app.js file to create a new WebSocket connection.

// Create a new WebSocket.
    var socket = new WebSocket('ws://echo.websocket.org');
    

Once the connection has been established the open event will be fired on your WebSocket instance.

For your demo application you are going to add an event listener that will update the status <div> with a message to show the user that a connection has been established.

Add the following code to you app.js file.

// Show a connected message when the WebSocket is opened.
    socket.onopen = function(event) {
      socketStatus.innerHTML = 'Connected to: ' + event.currentTarget.URL;
      socketStatus.className = 'open';
    };
    

Here you also add the class open to the status <div>, this is purely for styling purposes.

Handling Errors

You can handle any errors that occur by listening out for the error event.

For your demo application you’re just going to add some code that will log any errors to the console.

// Handle any errors that occur.
    socket.onerror = function(error) {
      console.log('WebSocket Error: ' + error);
    };
    

Sending Messages

To send a message through the WebSocket connection you call the send() method on your WebSocket instance; passing in the data you want to transfer.

socket.send(data);
    

You can send both text and binary data through a WebSocket.

For your demo application you need to send the contents of the textarea to the server when the form is submitted. To do this you first need to set up an event listener on the form.

Add the following code to your app.js file.

// Send a message when the form is submitted.
    form.onsubmit = function(e) {
      e.preventDefault();
    
      // Retrieve the message from the textarea.
      var message = messageField.value;
    
      // Send the message through the WebSocket.
      socket.send(message);
    
      // Add the message to the messages list.
      messagesList.innerHTML += '<li class="sent"><span>Sent:</span>' + message +
                                '</li>';
    
      // Clear out the message field.
      messageField.value = '';
    
      return false;
    };
    

When the form is submitted this code will retrieve the message from the messageField and send it through the WebSocket. The message is then added to the messagesList and displayed on the screen. To finish up, the value of messageField is reset ready for the user to type in a new message.

Receiving Messages

When a message is received the message event is fired. This event includes a property called data that can be used to access the contents of the message.

For the demo application you need to create an event listener that will be fired when a new message is received. Your code should then retrieve the message from the event and display it in the messagesList.

To achieve this, copy the following code into your app.js file.

// Handle messages sent by the server.
    socket.onmessage = function(event) {
      var message = event.data;
      messagesList.innerHTML += '<li class="received"><span>Received:</span>' +
                                 message + '</li>';
    };
    

Closing Connections

Once you’re done with your WebSocket you can terminate the connection using the close() method.

socket.close();
    

After the connection has been closed the browser will fire a close event. Attaching an event listener to the close event allows you to perform any clean up that you might need to do.

For your demo you will want to update the connection status when the connection is closed. Add the following code to your app.js file to do this.

// Show a disconnected message when the WebSocket is closed.
    socket.onclose = function(event) {
      socketStatus.innerHTML = 'Disconnected from WebSocket.';
      socketStatus.className = 'closed';
    };
    

To complete the demo application you need to add an event listener that will be fired when the ‘Close Connection’ button is clicked. This should call close() on the WebSocket.

// Close the WebSocket connection when the close button is clicked.
    closeBtn.onclick = function(e) {
      e.preventDefault();
    
      // Close the WebSocket.
      socket.close();
    
      return false;
    };
    

Your demo application is now complete!

Open index.html in your browser and try sending some messages. You should see that the server echoes your messages back to you.

Monitoring WebSocket Traffic with the Chrome Dev Tools

WebSocket Monitoring in Chrome Dev Tools

The developer tools in Google Chrome include a feature for monitoring traffic through a WebSocket. You can access this tool by following these steps:

• Open up the Developer Tools.
• Switch to the Network tab.
• Click on the entry for your WebSocket connection.
• Switch to the Frames tab.

This tools will show you a summary of all the data sent through the connection. In my testing it didn’t seem to update automatically so you might need to switch in and out of the Frames tab if you’re sending messages with the dev tools open.

WebSockets on the Server

In this article we have mainly focused on how to use WebSockets from a client-side perspective. If you’re looking to build your own WebSocket server there are plenty of libraries out there that can help you out. One of the most popular is socket.io, a Node.JS library that provides cross-browser fallbacks so you can confidently use WebSockets in your applications today.

Some other libraries include:

• C++: libwebsockets
• Errlang: Shirasu.ws
• Java: Jetty
• Node.JS: ws
• Ruby: em-websocket
• Python: Tornado, pywebsocket
• PHP: Ratchet, phpws

Browser Support for WebSockets

WebSockets are supported in almost all modern web browsers. The only exceptions being the Android browser and Opera Mini.

For up-to-date information on browser support check out: Can I use Web Sockets.

Final Thoughts

In this post you’ve learned about the WebSocket protocol and how to use the new API to build real-time web applications.

WebSockets represent a big step in the evolution of the internet. Just as AJAX changed the game in the mid 2000s; having the ability to open bidirectional, low latency connections enables a whole new generation of real-time web applications. Including what I hope will be some pretty awesome games!

If you’re interested in learning more about WebSockets – and browser networking in general – I recommend checking out some of the links below.

Further Reading

• High Performance Browser Networking: WebSocket
• IETF WebSocket Protocol
• WebSocket.org
• WebSockets (MDN)
• WebSocket Specification (WHATWG)
• Can I Use: Web Sockets

The post An Introduction to WebSockets appeared first on Treehouse Blog.

TeslaThemes produce some of the most attractive, and feature-rich WordPress themes available on the Web.

Now, thanks to our sister-site, MightyDeals.com, you can bag 14 of their best themes for the tiny price of $19.

The 14 distinct themes cover the full range of WordPress style sites, from photo journal to corporate website, from personal blog to design studio.

Vitally, all 14 themes are fully responsive, so they’ll run correctly on any device. This is always a key test for a professional WordPress theme and TeslaThemes’ pass with flying colors.

All themes are built with the powerful Tesla Framework; a robust set of configuration settings in the dashboard that allows you to add all sorts of useful plugins and widgets, including custom backgrounds, social media plugins, your own branding and much much more.

Tesla themes are designed so that you don’t need to know a single line of programming, just point and click. The themes come with comprehensive set up guides. You’ll even get access to a dedicated support forum, just in case you do run into any difficulties.

With this mightiest of MightyDeals you get all 14 of these themes:

Electra

MedPark

Hudson

Winterfell

Shape

Vulcano

Revoke

CoolStuff

Wedding Day

MyCountdown

Design Portfolio

Axa

Skywalker

Belle

But don’t just take our word for it, check out what Tesla Themes’ customers have to say:

Tesla guys asked me for a testimonial even though we have never talked to each other. There was no reason for, Tesla framework made my website’s customization so smooth that I had no questions, very clean organized. — Lothar Biebrich

Hi guys! I’m thankful for the new look and feel my website looks today. Since I’m new in WordPress I had patient support from the team. All further customization of my webpage is so easy, very intuitive and simple to use framework. — Samantha Finch

As a newbie in WordPress the guys at TeslaThemes helped me with every single problem I had, including theme installation. A pleasure to work with you guys, fast and prompt. Thank you all. — João Marcos Ernesto

The normal price of these themes is $45, but hop over to MightyDeals.com now, and you can grab them for $19, a saving of 58%!

Have you used a theme from Tesla Themes? Which of these themes is your favorite? Let us know in the comments.

Stride: A Simple Sales Tracking App – only $25!

Every so often, we like to ask our donors why they chose to support UMBC, and what makes their connection the University special. Recently, we spoke with Professor Bimal Sinha, who founded the statistics graduate program at UMBC. Dr. Sinha also created an
endowment fund for both undergraduate and graduate statistics students entitled the Dr. Bimal and Mrs. Suchandra Sinha Endowment for Excellence in Statistics.

There’s a perception that being in developer relations for a browser maker is all glamor and glitz involving lots of jet setting and rockstar-like experiences. So far I haven’t personally found that to be the case but in looking at the life of Opera evangelist Bruce Lawson, I think he may be fitting that description.

Helping fight the good fight for standards, Bruce is constantly on the move either updating his awesome book Introducing HTML5 (which is regarded as one of the best HTML5 books out) or attending developer conferences to read the pulse of the community.

With Opera’s recent shift to the Blink rendering engine, I managed to snag some of Bruce’s time to ask him how the shift will change the Opera browser.

I co-authored the first book on HTML5, "Introducing HTML5" (New Riders). I’m one of the founders of HTML5Doctor.com, and was a member of W3C's Mobile Web Best Practices Working Group. I evangelise open web standards for Opera, the oldest browser manufacturer whose mobile, desktop, TV and embedded browsers are used by 300 million people across the world.

Developers should find that Opera behaves as Chrome does.

Well, it would be nice if it went without saying that web developers should develop for the web and not individual browsers, and these days all browsers have great standards support. However, one of the problems that we had is that developers didn't test on Opera properly – because many devs are in the USA, and our desktop browser has a high market share in countries outside the US. So we've recently changed the rendering engine inside Opera Desktop and Opera Mobile to the Blink rendering engine that Google Chrome uses (we're the first to ship Blink-based browsers). Developers should find that Opera behaves as Chrome does. Because of greater compatibility with mass-market sites, and a more visually appealing UI, and some unique features, we're aiming to grow the user base more in the USA and Western Europe.

We have some unique features in both desktop and Android. One is off-road mode, which saves bandwidth and makes sites render faster. Another is Discover, which is visually appealing, curated content which can be customised to show certain languages and categories. Then, on Desktop, there's Stash – a place where you can save web pages for viewing later with a visual snapshot of the site and its text saved in the browser for later full-text searching.

We've long been known for innovating in browser UI (tabbed browsing, Speed Dial etc) and by using Chromium, we're able to get our developers making new, innovative interfaces rather than solely focussing on making our own rendering engine

When Opera Mobile and Desktop were based on Presto, there were four rendering engines on the market: Presto, WebKit, Gecko and Trident. Now there are four: WebKit, Gecko, Trident and Blink – and the same engineers who developed Presto are actively enhancing web standards support in Blink – enhancements that can be used by anyone.

Moving to Chromium gives Opera Mobile greater compatibility with sites that were coded with only Android and iPhone in mind, so serves our customers better – but working with the Chromium team helps break the incorrect perception that "only WebKit matters".

Our Opera Mini product has traditionally been the market leader on feature phones, as it does the heavy lifting on our servers, so it allows people with very low-powered phones to use the Web. It's used on over 3000 different devices world-wide – many of which we've never heard of – and is often the only way that people can join the Web in some emerging economies. But it's not just a featurephone product: compression and speeding up rendering is just as important on smartphones. We've seen the share of Opera Mini smartphone users in Asia Pacific countries increase from 9% to 32% (see opera.com/smw for monthly insight into worldwide mobile web use).

It's harder for developers to get paid when there isn't an installable product.

I think we need to understand why the web is great. Noone complained that a website didn't match the UI of the Linux box it was being viewed on, or the browser that displayed it. In fact, designers have always been adamant that they should be able to style native UI element such as form fields away from browser defaults. As JavaScript gets closer to native performance, and more and more integrated with device capabilities (File API, WebRTC, Pointer Events, etc) we'll see fewer and fewer reasons for developers to make native apps. The reasons to still make them aren't technological, it's social (apps are curated by App Stores) and economic. It's harder for developers to get paid when there isn't an installable product. I'm confident that we'll plug those gaps, but it will take time; there are many business interests here.

Also, browsers can help make HTML5 sites feel more app-like. Watch Opera for an interesting product that does just this.

I think the web stack is in pretty good shape these days. There’s work to be done making sure that sites can work offline (Appcache-done-right, in whatever guise it comes back) and with web payments. The lack of any useful way for developers to deal with responsive images is a problem, 18 months after it was flagged up.

My biggest worry isn’t the pace of standards development so much as lack of browser choice. Paradoxically, we have the most powerful and interoperable browsers that we’ve ever had, yet many platforms don’t allow the users to choose their browser.

Confusion is the word, indeed. I like the fact that the WHATWG keeps a living standard, that’s always up-to-date. But it means that lots of the stuff in there is really experimental, and not implemented anywhere (or even ready to be implemented, in some cases). It’s also really useful to have just one spec containing all the things.

However, it’s a shame that there are discrepancies between W3C and WHATWG specs. For example, the main element is really well specified in W3C spec, but badly specced in WHATWG. I’d advise developers looking to see what they can use now to look at the W3C version.

It’s a mash-up of memes from 2003, when I first (and last) redesigned my blog. It’s a combo of oolong the rabbit that balanced things on its head (http://en.wikipedia.org/wiki/Oolong_(rabbit)) and goatse, which isn’t a goat. Look it up. Or rather, don’t.

In Conclusion

We’d like to give a big thank you to Bruce for taking part in this interview.

Editor’s Note: Bruce mentioned during the interview that a new, interesting product would be released by Opera. Between the time the interview was conducted and published, Opera released Coast by Opera for iPad, that make HTML5 sites feel more app-like. Be sure to check it out.

There’s a perception that being in developer relations for a browser maker is all glamor and glitz involving lots of jet setting and rockstar-like experiences. So far I haven’t personally found that to be the case but in looking at the life of Opera evangelist Bruce Lawson, I think he may be fitting that description.

Helping fight the good fight for standards, Bruce is constantly on the move either updating his awesome book Introducing HTML5 (which is regarded as one of the best HTML5 books out) or attending developer conferences to read the pulse of the community.

With Opera’s recent shift to the Blink rendering engine, I managed to snag some of Bruce’s time to ask him how the shift will change the Opera browser.

I co-authored the first book on HTML5, “Introducing HTML5” (New Riders). I’m one of the founders of HTML5Doctor.com, and was a member of W3C’s Mobile Web Best Practices Working Group. I evangelise open web standards for Opera, the oldest browser manufacturer whose mobile, desktop, TV and embedded browsers are used by 300 million people across the world.

Developers should find that Opera behaves as Chrome does.

Well, it would be nice if it went without saying that web developers should develop for the web and not individual browsers, and these days all browsers have great standards support. However, one of the problems that we had is that developers didn’t test on Opera properly – because many devs are in the USA, and our desktop browser has a high market share in countries outside the US. So we’ve recently changed the rendering engine inside Opera Desktop and Opera Mobile to the Blink rendering engine that Google Chrome uses (we’re the first to ship Blink-based browsers). Developers should find that Opera behaves as Chrome does. Because of greater compatibility with mass-market sites, and a more visually appealing UI, and some unique features, we’re aiming to grow the user base more in the USA and Western Europe.

We have some unique features in both desktop and Android. One is off-road mode, which saves bandwidth and makes sites render faster. Another is Discover, which is visually appealing, curated content which can be customised to show certain languages and categories. Then, on Desktop, there’s Stash – a place where you can save web pages for viewing later with a visual snapshot of the site and its text saved in the browser for later full-text searching.

We’ve long been known for innovating in browser UI (tabbed browsing, Speed Dial etc) and by using Chromium, we’re able to get our developers making new, innovative interfaces rather than solely focussing on making our own rendering engine

When Opera Mobile and Desktop were based on Presto, there were four rendering engines on the market: Presto, WebKit, Gecko and Trident. Now there are four: WebKit, Gecko, Trident and Blink – and the same engineers who developed Presto are actively enhancing web standards support in Blink – enhancements that can be used by anyone.

Moving to Chromium gives Opera Mobile greater compatibility with sites that were coded with only Android and iPhone in mind, so serves our customers better – but working with the Chromium team helps break the incorrect perception that “only WebKit matters”.

Our Opera Mini product has traditionally been the market leader on feature phones, as it does the heavy lifting on our servers, so it allows people with very low-powered phones to use the Web. It’s used on over 3000 different devices world-wide – many of which we’ve never heard of – and is often the only way that people can join the Web in some emerging economies. But it’s not just a featurephone product: compression and speeding up rendering is just as important on smartphones. We’ve seen the share of Opera Mini smartphone users in Asia Pacific countries increase from 9% to 32% (see opera.com/smw for monthly insight into worldwide mobile web use).

It’s harder for developers to get paid when there isn’t an installable product.

I think we need to understand why the web is great. Noone complained that a website didn’t match the UI of the Linux box it was being viewed on, or the browser that displayed it. In fact, designers have always been adamant that they should be able to style native UI element such as form fields away from browser defaults. As JavaScript gets closer to native performance, and more and more integrated with device capabilities (File API, WebRTC, Pointer Events, etc) we’ll see fewer and fewer reasons for developers to make native apps. The reasons to still make them aren’t technological, it’s social (apps are curated by App Stores) and economic. It’s harder for developers to get paid when there isn’t an installable product. I’m confident that we’ll plug those gaps, but it will take time; there are many business interests here.

Also, browsers can help make HTML5 sites feel more app-like. Watch Opera for an interesting product that does just this.

I think the web stack is in pretty good shape these days. There’s work to be done making sure that sites can work offline (Appcache-done-right, in whatever guise it comes back) and with web payments. The lack of any useful way for developers to deal with responsive images is a problem, 18 months after it was flagged up.

My biggest worry isn’t the pace of standards development so much as lack of browser choice. Paradoxically, we have the most powerful and interoperable browsers that we’ve ever had, yet many platforms don’t allow the users to choose their browser.

Confusion is the word, indeed. I like the fact that the WHATWG keeps a living standard, that’s always up-to-date. But it means that lots of the stuff in there is really experimental, and not implemented anywhere (or even ready to be implemented, in some cases). It’s also really useful to have just one spec containing all the things.

However, it’s a shame that there are discrepancies between W3C and WHATWG specs. For example, the main element is really well specified in W3C spec, but badly specced in WHATWG. I’d advise developers looking to see what they can use now to look at the W3C version.

It’s a mash-up of memes from 2003, when I first (and last) redesigned my blog. It’s a combo of oolong the rabbit that balanced things on its head (http://en.wikipedia.org/wiki/Oolong_(rabbit)) and goatse, which isn’t a goat. Look it up. Or rather, don’t.

In Conclusion

We’d like to give a big thank you to Bruce for taking part in this interview.

Editor’s Note: Bruce mentioned during the interview that a new, interesting product would be released by Opera. Between the time the interview was conducted and published, Opera released Coast by Opera for iPad, that make HTML5 sites feel more app-like. Be sure to check it out.