[Go] talk about front-end rendering VS back-end rendering

First, precompilation has no relationship to the front backend, and precompilation can be used for back-end rendering.

Look at the following test time, unit: MS

Template string:

var s = ' {{#datas}}{{name}} ABCDEFG {{type}} {{Date}}{{/datas}} ';

Data object: Put 100000 rows of data

var stack = [];for (var i = 0; i < 100000; i++) {    Stack.push ({        name: ' name-' + I,        type: ' type-' + i,        da TE: (New Date ()). toLocaleString ()    }); var datas = {Datas:stack};

back-End rendering: generating HTML

var start = Date.now (); Require (' Hogan '). Compile (s). Render (datas); var end = Date.now (); Console.log (End-start);  166 MS My machine time

front-End rendering: I've made the simplest setting here, just converting datas into strings.

var start = Date.now (); Json.stringify (datas); var end = Date.now (); Console.log (End-start)  ; Ms My machine time

As a result, you can test the test with other template engines at a glance.

Server for front-end rendering, the time it takes to string an object is much greater than the time it took for the server to render the template HTML directly.

My advice is to use both the front and back end templates.

• The back-end template +bigpipe handles page loading, plus precompilation, which is faster than converting objects to and from a string, and reduces the load on the front-end template files by res.write(require('hogan').compile(s).render(datas)) more than

  res.write(JSON.stringify(datas))快

• Front-end templates, mostly parts that require AJAX loading

• The remaining one of the most difficult to deal with is SEO, for the robot does not support JS, or need an additional set of non-template code.

The focus of this issue is not on "Where to render fast", and if you want to consider this efficiency issue, then you have to think about it at the same time:

• After the backend renders, the volume of network transmission needs to be large, resulting in network loss and network transmission time problems

Many scenes, especially on the mobile side, we usually do not give the rendering work to the backend, on the one hand, the back-end rendering takes time, on the one hand the huge rendering data transmission also has a delay, so there will be white screen problem. Bigpipe can deal with this problem to a certain extent, not enough frame cost is slightly higher, with less people. If the data to the front-end rendering, there are some drawbacks, such as the need to change, the interface needs to be adjusted, the front-end template parsing must follow a change, so separated by a layer of interface development, efficiency is much lower, because we should at least with the development of students to negotiate.

Nodejs the appearance of the template reuse a lot of convenience, many times, let back-end rendering part (such as the first screen part), the back of the work to the front-end asynchronous to deal with. The combination of the two results is the best.

SEO problem, look at the product demand, a lot of products optimized SEO also does not have much effect, if really to consider:

1. Techniques such as Pjax/quickling/hash bang can be used
2. Server-side output content based on UA

Can't be simpler than that, you this test only shows that V8 in your server environment a single time to perform this rendering faster than the PC, but to know that the server but every request to perform rendering, the impact of all users, and front-end rendering only affects the single machine. So "back-end spit first screen + front-end rendering left" is the more appropriate way.

The mobile side, if not webapp, only need to send data on it. Android and iOS clients manage rendering themselves.

For the rendering of the PC-side HTML content, I would rather recommend bigpipe push.

If you are using AJAX pull, then each part of the page will add more client requests. The request-body parsing, in itself, consumes server resources.

For example, a webpage has 3 parts, from 3 database requests:

[User Bill] [User message] [User Article]

If this is bigpipe, the process is:

Client Pull server send layout HTML server send rendered <script> user Bill </script> server send rendered <script> user message </script> server sends rendered <script> User Articles </script> server sends HTML end tags </body>
Server requests only 1 times
In the case of front-end Ajax rendering, the process is this:
Client request send full HTML Layout page client user Bill Ajax request client User message Ajax request client user article AJAX request Server send user billing data server send user message data server send user article data
This process requires 4 client requests. Even if you merge the last 3 Ajax into one Ajax, you need 2 client requests.
Browser-Side Rendering benefits:

 
 

  
  
 
   
Scatter server-side rendering time to browser
 
   
HTTP response size will also be reduced
 
   
Great benefits for maintainability, too 
    
 
     
Easy to build front-end standalone development environment
 
     
Reduced template modification and back-end synchronization issues
 
    
 
  
 
 
The disadvantage is:

 
 

  
  
 
   
Seo
 
   
The first screen will have a white screen
 
   
One of the most vexing problems may be the business logic problem, because it's easy for business logic to run to JS.
 
  
 
 
Front-end rendering of the way I think not necessarily is bigpipe, but also to see the scene;
On the mobile side I think or back-end rendering better, because the mobile side of the CPU is still worse, put on the browser-side rendering may white screen longer
[Go] talk about front-end rendering VS back-end rendering