Last Updated:

Ajax css style for HTML

Ajax is slowly starting to smear as a technology, and various patterns, approaches, schools are already being formed in it (and with them there are mandatory sacred wars). In particular, I have already read from several people (for example, a note by Frank Sommers, which prompted me to write this one) that two fundamentally different approaches to writing ajax applications have taken shape:

  • creation of ready-made HTML on the server with automatic embedding of it in the right place of the page
  • transferring only structured data to the page and modifying HTML on it with a script on the client

Even though Frank writes that these two approaches are incompatible, I found that I'm mixing them myself, and I think it's good :-).

Learn more about approaches

HTML Transfer

The HTML approach is ideal for pages that change little when interacting with the server. For example, a certain form that, after submitting to the server, again appears on the screen, and with it either a picture is drawn that everything is fine, or a list of errors is drawn. In this case, ajax allows you to reduce the amount of data transmitted over the network, taking from the server not the entire form with the indication, but only the indication itself.

The undoubted advantages of this approach include the exceptional simplicity of the idea, from which it directly follows that almost everything can be automated on the client side:

  • replacing the submit of the form with a javascript handler
  • the generation of forms by this scripting data processor into a form suitable for submitting to the server (name1=value1&name2=value2)
  • receive a response and embed it in a page

In fact, all that remains for the programmer to do is:

  • poke his finger at which button he wants to "make ajax", and in which block on the page then write the result
  • on the server to explain to the framework exactly which part of the response should be cut for ajax requests

To the disadvantages of the approach, I would include the fact that it works much worse for "highly dynamic" pages, where different parts change from one action. For example, a long comment thread, where a new comment should come from the server by submitting a form with text and, say, update the line "N comments", which is located in a completely different place on the page. Here, if you follow the automatic model, you need to pass to the page that part of it that includes all the necessary pieces, even if there is data between them that was not supposed to change. In practice, this can lead to the fact that rather large amounts of data are driven around the network, comparable to the size of the page itself, and the whole point of ajax degenerates in the absence of the effect of an animation of the browser icon in the upper right corner.

And my emphasized "maybe", unfortunately, turns out to be true more often than I would like, because such a fully automatic approach attracts a lot of developers who do not have the time and / or desire to deal with scripting, but rely on the fact that the framework will help them do it with little blood. Therefore, they will not be able to notice in time or correctly correct the problems of a lower level.

Transfer of structural data

The transmission of structured data was the essence of ajax even when it was called "". That is, it was invented in order to turn to the server and get a description of some part of the state of the system, expressed in XML - a language that is designed for convenient machine processing. I will say right away that despite the fact that this was intended, the wedge light did not converge on the XML responses, and the structure can be transmitted in another way, which will be discussed a little later.XmlHttpRequest

The advantage of this approach is maximum flexibility. You can come up with absolutely any format and set of data that is requested from the server, in which there will be exactly the information that is missing on the client, and nothing superfluous. On the client, with the help of Javascript, you can change the page completely and in any way.

Take the same example with comments: a comment is sent to the server, and the response returns something like this:

<comment status="ok" quantity="12"/>

Which means that the comment has been validated, and now there are 12 of them on page 12. Everything else can be made a script: draw a new block of comment, copy the text of the mold there, delete the fomochka, update the number with a new digit.

The most obvious disadvantage in the transfer of the structure is a much larger volume and complexity of programming. And it consists of several things.

The first difficulty is the use of XML. Despite the fact that the format is clear and wonderful, in Javascript you can only work with it using DOM methods. And it's tedious to write and very difficult to read: too much text to produce simple things. Fortunately, this particular drawback has recently been solved using the JSON format: the data is returned from the server not in the form of XML, but in the form of a piece of Javascript code that creates the object of the structure you need:

response = {
status: 'ok',
quantity: 12

It is immediately executed in the script by 'ohm and you get an object that has and . Very convenient and without any .evalresponseresponse.statusresponse.quantitygetElementsByTagName('response')[0]

In addition to removing the complexity of parsing the XML response, the second difficulty remains: building HTML completely manually by DOM methods, which, again, is difficult and tedious.

But the worst thing is that this very thing in the system appears two completely different places in which the appearance of the page is set: an HTML template and Javascript code. So, the changes will have to be carefully duplicated here and there. And it also means that to write HTML, you now need a person who can write both HTML and heavy Javascript. "Maintenance hell", in other words.

In general, when I started playing with 'om, this approach seemed to me the most natural: since the thing knows how to parse XML, then this is the right way to use it. The result of those exercises was a rather cool client ajax-interface to the chat with a lot of all sorts of baubles. Then, in 2003, it was terribly advanced technologically, but we never managed to promote it into something famous. I'm even surprised now that it's still working. Let the link to the story now be here :-)XmlHttpRequest

Combining the best features

The incompatibility that Frank Sommers talks about is present only from the point of view of a programmer who chooses to transmit HTML, and does not want to dive into scripting at all. However, if the programmer is not against this in principle, then the transfer of the structure can be combined with the transfer of HTML. The principle is actually very simple:

  • the response from the server is sent as a JSON object
  • things not related to HTML generation (for example, move something somewhere, hide/open, etc.) are executed by the script, using data from the object
  • if you need to change some non-trivial chunks of HTML, they are passed in lines in the same object and inserted where necessary
  • modifiable parts of HTML on the server are designed as small included templates, and are used both in the initial formation of the page and in ajax-responses

In other words, the whole "great idea" is to abandon the dogma of "use only XML" and use what is convenient.

The only thing I don't like about this approach yet is that there's a slight increase in the amount of work on the server side. If without ajax, the code serving the form gives only two responses - either the same form with errors, or a redirect, when everything is fine - then with ajax, another option is added to each response with the issuance of JSON objects. Not particularly difficult, but it looks too cluttered. Although over time I hope to come up with or spy some automation of this process.POST