Dynamic webpage update

Introduction

No one will be surprised by the concept of dynamic HTML, almost all sites have long been to some extent using javascript to make the pages interactive. And with the advent of AJAX technology, it became possible to asynchronously generate requests to the server in order to modify old data on the server or receive new ones. But how to update the structure of the page? Who should generate a new html server or javascript? Or maybe all together?

Let's see how you can answer these questions.

To begin with, I will describe the page life cycle. I must say at once that I am not going to describe this process in detail, here only an understanding of the basic logic of the process is required.

Any web application can be logically divided into two components - the client side and the server side . The client part includes the browser itself and the scripts it executes, and the server part — a set of scripts that generate the answer to any user request.
')
The life of any page begins with a request from the client to the server. The answer will be the code of the page containing, in addition to the structure and styles, the logic of the client part.

After receiving the page from the server, the browser displays it and runs the scripts attached to it from the server.
The client side responds to various events — for example, by clicking on an element, moving the mouse, or when the timer expires. In order to get some data from the server (or send something to it), additional, usually asynchronous, requests are used.

Spice begins when it is necessary at some point to redraw some components on the page. In order to update the page structure, the client’s script needs to know what needs to be removed, what needs to be added and what needs to be replaced. This is where different options appear on how to organize such updates.

Closer to the point

For convenience of explanation, consider the option of updating a simple page with a news feed and, say, a subscriber count. We want the browser to regularly check for updates of the feed, adding news as they appear. And we want every visitor to see the dynamics of the growth of our site’s popularity - let the subscriber’s counter be regularly updated as well.

The body of our page might look like this:

<span id="subscr_cnt">: 42</span> <ul id="news"> <li><a href="/australia">        </a></li> <li><a href="/wonderwoman">-      </a></li> <li><a href="/romeo_madness">«  »    «300 »</a></li> </ul> 

Option 1 - duplication

The main idea is that the display logic is known by both the client and the server side. In this case, the answers to regular requests from the client may contain only data - changes in the model, and look, for example, like this:

 { subscr_cnt: 44, news:[ { href: "/wiskey", name: "      2015 " }, { href: "/kindergarden", name: " -     " } ] } 

When such a response is received, the client side “wraps” the data in html-tags, adds the necessary texts and updates the page structure.

The server, however, knowledge about the display is needed only to generate the initial version of the page.

Advantages of the approach:

• Low traffic - only necessary data is transmitted;

Cons of the approach:

• It is required to duplicate the code - it will be in the client part and in the server part;
• The client part needs to know exactly how to deal with each piece of data from the server - sometimes you need to replace the element's html, sometimes add new data to the already existing code;

Option 2 - omnipotent server and "fat" answers

The main idea is that only the server knows the logic of the display, the client part receives the ready html-code of the elements. Here, the server response looks like this:

 { subscr_cnt: ": 44", news: "<li><a href=\"/australia\">        </a></li> \n <li><a href=\"/wonderwoman\">-      </a></li> <li><a href=\"/romeo_madness\">«  »    «300 »</a></li> <li><a href=\"/wiskey\">      2015 </a></li> <li><a href=\"/kindergarden\"> -     </a></li>" } 

I note that all the html of each component on the page is sent here. This method is implemented simply - the server generates a page piece by piece, the client replaces the bodies of individual elements when a response is received.

Advantages of the approach:

• Ease of implementation;
• No duplication of code;

Cons of the approach:

• Repeated generation of the same code is especially inefficient with small changes;
• A huge amount of traffic, especially on large pages;

Option 2a - omnipotent server and “thin” answers

You can try to fix the main drawback of the previous version. The server may not send the entire html component, but send only the “delta” - the changes that need to be made. Our answer could then be:

 { subscr_cnt: { html: ": 44", mode: "replace" }, news: { html: "<li><a href=\"/wiskey\">      2015 </a></li> <li><a href=\"/kindergarden\"> -     </a></li>", mode: "append" } } 

Now the client determines the element that will change, and how it will change it, directly from the server's response.

Advantages of the approach:

• No duplication of code;

Cons of the approach:

• There is still quite a large amount of network traffic;
• The client must send the server the current state of each component, encoded in some way, so that the server understands what to consider the delta;
• The complexity of the calculation and recording of the delta in the case of non-trivial changes;
• General complication of both client and server parts;

Option 3 - Almighty javascript

You can transfer all responsibility for generating html to the client. In this case, the server will only provide the data necessary for display. Answers, as in the first variant, will contain only data:

 { subscr_cnt: 44, news:[ { href: "/wiskey", name: "      2015 " }, { href: "/kindergarden", name: " -     " } ] } 

So what is the significant difference from the first option? And it lies in the fact that the server does not perform the initial generation of the page, it is already being assembled by the client’s browser. This option only looks strange, it can be useful if you need to reduce the load on the server.

Advantages of the approach:

• Low traffic - only necessary data is transmitted;
• Reducing server load;

Cons of the approach:

• High load on the user's computer;
• Redundancy is possible - a part of the client’s knowledge about the display may remain unclaimed, if some events do not occur;

Conclusion

Each of the considered methods has the right to life, and can be used in projects of different complexity. Personally, I have often seen the first option in the projects I met, despite his violation of my favorite principle DRY - Don`t repeat yourself.

And what principles do you use when developing dynamic pages?