I have accumulated some information about possible methods of templating, but I still could not find anything where it would be clearly explained what and in what cases it is better to use. So I decided to write out some pros and cons of each type as I understand them, and discuss them with you ... because I need to discuss this with someone :)

1. Client templateization with json rest api

We get data from the database => we transfer them to the client in json / xml => we parse the data on the client, creating objects by client models => we add each obtained model to the DOM.

pros:

  • the user is waiting only for the data he needs
  • in the process of loading data, we can show a beautiful preloader

minuses:

  • duplicate models
  • once again straining the client browser with templating

2. Also rest api, only template making, as a whole, server

We get the data out of the database => create the html code from them => give it to the client html => on the client, just shove the resulting html into the DOM without thinking.
This method seems to me the most practical, but for some reason practically no one writes about it. Am I just reading something wrong, or are there any serious flaws that I just don’t see?

pros:

  • first two of paragraph above
  • do not duplicate models

minuses:

  • it looks like there are none

3. Classic server templateization ... only server

Selecting data from the database => on the server, we do this whole thing in html, but not a piece of the page, but the whole page entirely => reload the entire page to the client.

pros:

  • do not duplicate models

minuses:

  • we redraw everything that the user already had and all the resulting lack of preloaders, a blank white page, and so on

Questions

  1. What other variations are there?
  2. Who uses what in their projects (personal, workers, how do large companies ...)?
  3. Why?
  4. What are the pros and cons I missed / misunderstood?
  5. In which case what is better to use?
  • Close to point 2, you can google according to pjax and turbolinks, I am actively using it on my websites (I consider point 1 as heresy, and point 3 is too slow, but this is just my personal opinion) - andreymal
  • @andreymal tell me why the first point you consider heresy? Are you against angularjs, ember, knokout ? At the expense of 2 ways - minus: it is difficult to make reused components. - Stepan Kasyanenko
  • @Stepan yes, against :) And what prevents to reuse components on the server? - andreymal
  • @andreymal and what if you do not use turbolinks, and immediately develop the application so that the server gives out the html chunks, and some backbone.js caught clicking on the links, changed the page headers / url and inserted the resulting html into the right place? - fobedep
  • A bunch of unpleasant trifles such as browser Back / Forward buttons or scrolling problems with either css or scripts for freshly loaded data will come up (however, it will pop up in any case, but it seems a little easier with pjax) - andreymal

2 answers 2

Who uses what in their projects (personal, workers, how do large companies ...)?

A large company, more than 20 developers on the project happens.

Either a full server-side, or a completely client-side, mixing only in very specific cases (perhaps there are such, I have not met).

Server-side for projects where you can provide a full-stack of developers so that you can create a request for the trivia, and write a JS script and query the database, etc. Mobile applications are not required, providing APIs for third parties, too. Most often there are no projects where the web interface is minimal.

Client-side if the team is large, it can be divided into front-end, backend, mobblers. Cons - the cost of supporting the API line. Most often, this approach is used, with the API first (we have RAML).

There were a couple of projects in practice where responsibility for mapping was shared between a server and a client, very unpleasant impressions: constant questions about who should be responsible for what, consistency questions (for example, a dynamically generated form on the client and its refilling in case of an erroneous submission). Requirements for developers are very high, you need to know both client-side and server-side technologies.

    In the second case there are actually a lot of minuses (by the way, the words "REST API" are not applicable to it - because it is not REST and not API).

    • firstly, the possibility of markup in this mode turns out to be "cut off" - in particular, many ways to insert HTML-code into the document do not run scripts;

    • secondly, a page made of a heap of nadgrennyh pieces is usually the layout designer’s nightmare - it’s not at all clear in which file to look for the necessary piece of typesetting;

    • thirdly, the constant jerkiness of innerHTML negatively affects performance;

    • fourth, such a solution usually requires more traffic than both alternatives.

    Of the advantages he has - support by most server frameworks.

    According to the first option - if you do not write anything complicated, then the client browser does not bother to "template". Especially if you use not template engines, but libraries for bidirectional data binding.

    Duplication of models is also not a feature of the first option - often the client model, the server model and the transfer model are completely different - and this is completely normal. In fact, during the transition from the third variant to the first one, the model is not duplicated, but divided into two.

    • The first point can be easily corrected, the second point is solved by the competent organization of templates (I haven't had any problems in the four years), the third for the same four years has never been observed, the fourth is not true and there is a small traffic saving compared to the third method - andreymal
    • @andreymal in its draft problems and the truth does not arise. But when an individual layout designer is invited to the project to unload the main developer - the fun begins :) - Pavel Mayorov