One cannot deny that the IT domain evolves not only towards a higher sophistication, but sometimes needs to make some steps back to right the wrongs of the past. The scope of this work was to spotlight the problems of modern networking and provide the results of comparison of two web applications executing similar task, but having different implementation: one based on HTTP and another one – on WebSockets. Nowadays HTTP is still the most commonly used protocol for network communication. It was designed as a means of communication between nodes in the client-server computing model. By design, the HTTP server can understand request messages from clients in isolation, so it does not know how many different users communicate with it, and does not remember their previous actions. These limitations made developers to invent some tricks to evade them. For instance, we use cookies (pieces of information kept at client-side) to tell the server who it is talking to in every single request, this way imitating a multiple requests duration communication. Today, in time of powerful machines and even more demanding applications, the HTTP limitations begin to throw sand in the wheels of developers work. When some events happen on server very fast, the clients cannot get this information in time, because the server cannot alert clients by itself, only clients can ask the server for information. This was the purpose for creating an alternative standard of network communication – the WebSocket protocol. Although this protocol was standardized in 2011, it has not become widely spread yet. To initiate a WebSocket-driven communication, a web browser needs to send a single HTTP GET request with special headers, which mean that browser wants to switch protocol [1]. Since then, server and client become equal in rights, any of them can initiate communication. Moreover, server can also broadcast information (send it to all connected clients). To compare these two paradigms of network communication there were created two web services within the scope of this work. Since we need them to be in equal conditions, it was decided to use pure Java EE code and Apache TomEE+ application server. Both of the web services implement similar functionality: when user asks to start the work process, the web services create a new thread which initializes a counter variable with zero and increments this counter in a loop with a pause set by user. Furthermore, the user can request not only the counter value, but also an image, changing from one counter value to another. The WebSocket-driven service broadcasts information on every counter change from that separate thread. Since the HTTP-driven service has no such possibility, it only implements a method processing GET requests for the counter value in the main application thread. The difference in backend architectures makes the frontend different too. The JavaScript interacting with WebSocket-driven service can only ask it to start or stop the work process, but the HTTPdriven service must be able in addition to request data from service. To prevent the web page from freezing, this work is done through “chained” AJAX requests; the script makes a new GET request on any response arrival. The results of comparing the work of the two web services are definitely amazing. On slow speeds (0.1 ms pause), the clients of both services get every new message, inspite of the JavaScript for HTTPdriven service makes many useless requests for it (since the counter changes slower than the requests come, many requests receive the same response). But on fast speeds (0.001-0.005 ms pause) the HTTPdriven web application loses up to 78% of data, while the WebSocketdriven application processes it all. When the client requests to get images also, the HTTP-driven application’s work starts deteriorating already on moderate speeds (0.01 ms pause, 60% data loss), and WebSocket-driven application still gets everything, although the client starts to suffer of browser overloading: the browser becomes unresponsive because it cannot process the data that fast. To draw the conclusion, one can say that WebSockets are the future of network communication. Our example applications have shown that the WebSockets offer a much greater performance, even though they demand the client’s hardware to be powerful as well. In cases when the data is changing not very fast and clients need the browser work good more than get information in time, the HTTPdriven applications are also acceptable, but in contrary cases the WebSockets are surely indispensable.