On the use of front-end template engine in Web

back-end MVC

Speaking of template rendering, the landlord first contact is not the front-end template engine, but the backend. In the back-end MVC pattern, the data is generally read from the model layer and then transmitted to the view layer rendering (rendered as an HTML file), and the view layer generally uses the template engine, such as the PHP smarty template engine used in the landlord project. Just take a look at the code.

<div>
  <ul class= "Well nav nav-list" style= "height:95%;" >
    {{foreach from= $pageArray. Result item=leftmenu key=key Name=leftmenu}}
      <li class= "Nav-header" >{{ $key}}</li>
      {{foreach from= $leftMenu key=key2 item=item2}}
        <li><a target= "main" href= ' {{$ ITEM2}} ' >{{$key 2}}</a></li>
      {{/foreach}}
    {{/foreach}}
  </ul>
</div>

The incoming View layer is actually a JSON data called a $pageArray. The MVC pattern is also very easy to understand, and then take a look at the following picture.

Most of the previous WEB projects used this background MVC pattern, which is good for SEO, and the way the front-end request interface, less HTTP request, theoretically loading speed may be a little faster. But the shortcomings are very obvious, the front end to write static pages, to let the background to "set template", each front-end a slight change, the background corresponding template page also need to change, very troublesome. If there is a complex JS in the page, the front-end write or back-end write. Front-end write words, not a lot of data, debugging inconvenient, back-end write words ... Therefore, the landlord sees the phper usually will JS. Front-end templates

The advent of AJAX makes it possible to detach from front to back. The backend focuses on the business logic, providing an interface to the front end, while the front end uses AJAX to pull data back and then render the page dynamically.

We assume that the interface data is as follows:

[{name: "Apple"}, {name: "Orange"}, {name: "Peach"}]

Assume the following rendered page:

<div>
  <ul class= "list" >
    <li>apple</li>
    <li>orange</li>
    < Li class= "last-item" >peach</li>
  </ul>
</div>

We typically do this before the front-end template engine appears:

<div></div>
<script>
//hypothetical interface data
var = [{name: ' Apple '}, {name: ' Orange '}, {name: ' Peach "}];

var str = "";
str + = ' <ul class= ' list > ';

for (var i = 0, len = data.length; i < Len; i++) {
  if (i!== len-1)
    str + = "<li>" + data[i].name + "< ;/li> ";
  else
    str + = ' <li class= "Last-item" > '  + data[i].name + "</li>";
}

str + = "</ul>";
Document.queryselector ("div"). InnerHTML = str;
</script>

In fact, the landlord personally often do so, it seems simple and convenient, but this is obviously a disadvantage, the HTML code (View layer) and JS code (Controller layer) mixed together, the UI and logic code mixed together, reading will be very laborious. Once the business is complicated, or if multiple people maintain it, it will almost get out of control. And if there is a lot of quotes in the HTML code that needs to be spliced (such as a large number of href attributes, the src attribute), then it is very easy to make a mistake (this should be done with deep experience).

At this point, the front-end template engine appears, and underscore's _.template is probably the simplest front-end template engine (which may not rise to the height of the engine, or a front-end template function). Let's not talk about the implementation of _.template, and rewrite the above code with it.

<div></div>
<script src= "//cdn.bootcss.com/underscore.js/1.8.3/underscore.js" ></script >
<script type= "text/template" id= "TPL" >
  <ul class= "list" >
    <%_.each (obj, function (E, I, a) {%>
      <% if (i = = = a.length-1)%>
        <li class= "Last-item" ><%=e.name%></li>
      <% else%>
        <li><%=e.name%></li>
    <%})%>
  </ul>
</script >

<script>
//Analog data
var = [{name: "Apple"}, {name: "Orange"}, {name: "Peach"}];

var compiled = _.template (document.getElementById ("TPL"). InnerHTML);
var str = compiled (data);
Document.queryselector ("div"). InnerHTML = str;
</script>

This way, if the front end needs to change the HTML code, only need to change the template. The advantages are obvious, the front-end UI and logic code are no longer mixed, the reading experience is good, and the changes are much easier.

The biggest drawback of the front and back end is that the SEO is weak, after all, the crawler will crawl only HTML code, not to render JS. (PS: Now the Google crawler can already crawl Ajax Making AJAX Applications Crawlable, concrete effect unknown) Node Middle layer

The simple back-end templating engine (back-end MVC) and the front-end template engine approach have some limitations, and the advent of node gives us a third option to make node the middle tier.

How it is done. In short, let's get a background language like Java. Php. Simply provide the interface needed to render the page, and the Node middle layer uses a template engine to render the page, making the page go straight out. In this way, the background provides the interface, not only the Web side can be used, the APP, the browser can also be called, while the page Node straight out will not affect the SEO, and the front and back end is also separated, it is a more perfect solution.