WebSockets and RTC: No more REST for Web Programmers?

Unless you've been living under a rock for the last decade or so, you might have noticed that the world wide web has been producing more and more elaborate websites. And it's really not going to end there - or even at all - until we can telepathically host and browse websites. While waiting for formal specs for a Telepathy Markup Language by the W3C, sparing you a complete history of web design from <table /> until JSON, here's what's going to be hot for web programming from now onwards:

 

JavaScript

Thankfully some geeks thought it would be a nice idea to add a client-side programming language to web pages. That turned out to be a ridiculously delightful idea. However JavaScript was initially discarded as a "not-so-serious" programming language. Of course. At the time it was being abused by clueless web designers. Made to perform gimmicks, serve alert boxes, animate cursors... and at best used for drop-down menus, it just wasn't something one would consider for serious development. And on top of it all, it was interpreted.

Fast forward to the early 00's. Web 2.0 was born, thanks to the AJAX call, that could asynchronously call and receive data from a service, without a full-page refresh. 

All of a sudden JavaScript became more than just a tool for manipulating the DOM and showing alerts. Web pages were not just dead-end documents with links to other documents. AJAX (and JavaScript in general) truly allowed developers to create web pages that could behave like apps. 

With Web 2.0 JavaScript shot to stardom, and more and more programmers started acknowledging its importance. JavaScript has not stopped gaining momentum since then. Some of the notable technologies that work with JS are Node.js, a server-side JS engine emancipated from the browser, and a wide variety of HTML5 Mobile App development frameworks. There is also the much awaited ASM.js, which I personally think was secretly bestowed upon us by the Gods of client-side obfuscation.

 

So Many Years of Existence, So Many Types of Browsers

 

Since the HTML, CSS and JavaScript triumvirate had been around for quite some time, different types of browsers came about at different periods of time. JavaScript too was evolving - slowly but steadily - and although the language now has its specifications formally penned down, massive amounts of web surfers still wander around the thick forest of WWW with that old crappy browser that you thought had already been wiped off the surface of the e-planet.

Logically one would attempt to detect the User-Agent name and version (read: browser name & version) to ascertain what will work and what won't. That technique, called UA Sniffing or Browser Sniffing, is limited to the programmer's knowledge of current browsers, and will likely not work well for new or unknown UA's. To circumvent this problem the W3C recommends y'all to write standard HTML code. 

Still, that doesn't really solve the problem as many old browsers are still lurking out there and it's just a pain to marry historical data with actual coding.

 

Modernizr.js

Enter Modernizr.js. Modernizr.js completely eliminates the need for scanning the client's UA and instead provides for a more practical alternative: detecting browser features. Give it a try to see what your browser can and cannot do.

Not content with detecting browser features, Modernizr also allows for polyfills. Simply put, a polyfill saves the day when your old browser should've eaten dirt. A polyfill augments the capabilities of your browser by downloading code that will fill in the missing gaps, completely eliminating the need for a window.alert('Sorry your browser is not supported.');.

 

WebSockets & WebRTC

And if all of that wasn't cool enough, you would be surprised to learn that modern web standards define a new means to communicate with a server: through WebSockets. In a nutshell, web sockets allow for a direct line of communication between a browser and a server. In this architecture, the server can send data directly to the client without the client side having triggered any mechanism requiring the server to do so. 

In other words, instead of refreshing your inbox every now and then, the server can actually send you a notification immediately when an email is received.

Welcome to WebRTC. Real-time communication within web pages.

For any of you who ever implemented an AJAX-based chat system, you must by now have realized that WebSockets deprecate the need for long polling or iframe fiddling. Through the simple ability of a server to communicate with connected clients, massive paradigm shifts are occurring within web programming.

If you have any doubts about whether WebRTC will be of any relevance in the future, check out the WebRTC.org page or see some of its awesome demos, including a video chat client.

 

Server-Side Coding vs SOA

Here's a simple way to explain what a server-side web programming language does: At the end of any page or service request, it generates HTML, CSS, JavaScript, JSON or XML code to be sent and consumed by a browser. And that's all. That's what all of them do - generate some HTML.

The process of generating client-side code complicates the process of web programming on so many levels, especially if it's a web app. 

A service oriented architecture not only exposes your functionality to other types of applications (there's no need to re-write the same server-side logic), but also simplifies the development process by returning the web's client-server architecture to its simplest form: separating the development of interfaces with that of functionality.