As a developer at coeno I am often reminded of the year 2005 lately. At that time new web technologies started to revolutionize the internet. From the still static medium, in which few communicate with many, a collaborative platform developed within a few years. Who would have guessed that with AJAX and Co. web-based services would become the norm in all areas of life. And although this development is by no means over yet, web technologies today are once again the starting point for far-reaching changes. We are talking about "Real Time Web". What this is and what the differences to the Internet are that we know today, I want to explain in this post.

Like in grandfather times

The communication between client and web server usually still works like in the early days of the World Wide Web, since the underlying HTTP protocol from 1989 has not changed. It is designed for a short-term connection and basically works like this: The client connects to the server and makes a request. In response, the server sends the message, for example an HTML page, back to the client. Afterwards, all information from this connection is lost. Normally, the client and the server meet again and again as "strangers". The HTTP protocol does not provide for a connection from the server to the client.

According to the waterfall principle

Server-side applications are ubiquitous today. Behind the dynamic content in blogs, online stores and web services are programs. They are executed by the server when corresponding requests are made. And although numerous languages and platforms with different concepts have been developed for this purpose, the rather inefficient, procedural principle of operation has never changed. Like a waterfall, the individual processes are executed one after the other, with blocking I/O operations repeatedly stopping execution. Only when they are completed can the program continue to run. An unanswered database query can therefore quickly lead to a crash of the entire program. The maximum number of simultaneous client connections is also directly dependent on the performance of the server hardware.

The Internet of long update cycles

Our expectations on the web still correspond exactly to the interaction of these functional principles. Learning is finally learning. When we open a web page in the browser, we expect the contents to be displayed. We do not expect content or even parts of it to update itself independently. Instead, we reload the page as a matter of course. So, to stay with the example, the browser always displays only the current state at the time of the request. Updates are always linked to the client triggering this by a new request. Whether 1 second or 1 year has passed in the meantime is irrelevant in this system.

However, if you still want to track data changes automatically, automated requests in fixed time periods are the only option available so far. The user has the choice between countless unnecessary server requests or waiting until changes are synchronized. With the spread of web services, however, the potential update periods are steadily decreasing. In the range of seconds at the latest, we are confronted with unsolvable tasks with classical web technologies, as can be well understood in this Comet Thread.

Everything possible, thanks to new technologies

Fortunately, standardized solutions for real-time communication in client-server systems now exist. The most important innovation is the introduction of WebSockets, which are part of the HTML5 specification. In contrast to the HTTP protocol, WebSocket connections are permanently maintained. The server is thus able to send information to the connected clients independently (push). WebSockets can now be implemented relatively easily on all common platforms (overview). However, it is in the nature of things that the WebSocket principle, which is designed for an extremely long runtime, can present procedural languages and platforms with considerable difficulties. Let us remember that an unanswered database query can crash the entire program.

The solution for the requirements of modern and complex web applications is Node.js. It is based on the Javascript runtime environment "V8" which was originally developed by Google for the Chrome browser. Due to its typical Javascript "non-blocking I/O" principle, Node.js is fundamentally different from the languages and platforms that have been used so far. Since no process leads to a standstill of the application, hardware resources can be used optimally and moreover, many more simultaneous client connections can be realized. Node.js is suitable for the implementation of any web and server application. From a developer's point of view, there is also the advantage that frontend and backend are developed in a common language (Javascript), whereby code can of course be reused. Many current developer tools like npm, Grunt, Yeoman, Jade, Stylus, etc., which make the daily work of developers easier, are also based on Node.js.

And the practical benefit

As with any new technology, the potential of WebSockets is currently not really foreseeable. Nevertheless, three trend lines can already be identified on which the real-time web is likely to begin its triumphant advance. For example, WebSocket applications offer unbeatable advantages when they make information with a very short lifetime available to the user, e.g. stock market data, without unnecessary delay. Based on this, applications for computer-controlled trading, for example, which are currently reserved for large financial service providers, are conceivable. But online multiplayer games also belong in this category for me.

Furthermore, the real-time web will make collaborative work truly location-independent in the future. If several colleagues can work on documents simultaneously, follow all changes in real time and exchange information in parallel via a chat or video channel, long journeys are increasingly rare. Mature applications that enable this form of collaboration are no longer entirely new, at least not in the office environment (Google-Docs, Microsoft Office Web Apps). However, due to their development history, they are not necessarily based on WebSockets. From today's point of view, WebSockets offer the ideal technological basis for comparable new developments. It is therefore to be expected that many new tools for collaborative work will be created in the future and that this form of collaboration will not be limited to Office documents.

In my opinion, the most exciting thing is the development opportunities in the field of so-called Machine-to-Machine communication (M2M). WebSockets radically simplify the necessary information exchange by acting as a universal link. Using standardized APIs, a wide variety of end devices can communicate with each other. The principle can be used to share media content such as TV broadcasts, video or audio files running in local networks between different devices via "PUSH". Or in a "second screen" context to control smart TV devices via tablet or smartphone apps. Not only does this look cool, compared to the classic remote control with countless function and color keys, touchscreens offer a completely new user experience through gesture control and additional screen surface. Coeno has participated in several projects this year in which these scenarios are implemented.

Of course the possibilities are not limited to the home entertainment sector. Whenever different end devices need to exchange information in real time, WebSocket applications offer the appropriate solution. For example, networked on-board computers in vehicles could warn drivers in real time of collisions with other vehicles or ghost drivers and thus provide additional safety.

Conclusion: The above examples show how fundamentally the new technologies of the real-time web differ from previous solutions. WebSocket applications and server-side Javascript will not replace the current Internet, but rather (once again) new areas are emerging where visionary ideas can be developed and realized.