Which method is faster, express: server-side rendering and client-side rendering

Question

What would I like to know how you created your web application? I am really confused which method I should use for my project.

Already decided which technologies to choose.

1) Node.js and express as your Structure

2) MongoDB

3) React + Flux

But the problem right now is whether to use method (A) or method (B)

Method (A) - Server Rendering for HTML

app.get('/users/', function(request, respond) { var user = "Jack"; respond.render("user", { user: user }); }); 

Method (B) - rendering with the client for HTML

  app.get('/users/', function(request, respond){ var user = "Jack"; respond.json({ user: user }); }); 

Method A will display the HTML from the server as well as the data.

Method B will simply respond to the data that the client, which is React.js, needs so that it can manipulate the data.

My concern, which method should I use? do most startups use which method?

Thanks.

Answer 1

This is not one or the other sentence.

Reaction is a client environment. You must display on the client side. The question is whether to display on the server side in addition to client-side rendering.

Answer? If you can, YES!

You'll get SEO benefits and initial productivity gains through server-side rendering. But you still have to do the same rendering on the client side.

I suggest googling "isomorphically responsive" and do some reading. Here is one article on this. http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/

Answer 2

Well, it really depends on what vision you have on the modern network, and what you are ready to do.

Do you prefer your users to wait while showing the bootloader while the data is loading asynchronously, or do you prefer your users to be busy for as long as you can?

Here are some articles to help you clear your mind and be aware of the various benefits that may arise when rendering on the server side, on the client side, which has several problems.

You can see this Twitter blog post saying that they improve the initial page load by 1/5 to what they had before, moving the rendering to the server:

https://blog.twitter.com/2012/improving-performance-on-twittercom

Another article, this time from airbnb, describing problems that may occur when rendering on the client side:

http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

There is another interesting article on client-side / server-side rendering, as a result of which we discuss when to use / not use server-side or client-side rendering, and why:

https://ponyfoo.com/articles/stop-breaking-the-web

And to finish, I can give you two more links that are more focused on responsiveness and describe how server-side rendering should be useful for your case:

https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html

http://reactjsnews.com/isomorphic-javascript-with-react-node/

Now about what you SHOULD do, this is a question of what you need to do, in my opinion, but basically you can do it simultaneously (on the client side and on the server side) to get a better user interface.

This concept is called "isomorphic javascript", and today it is becoming increasingly popular.

Answer 3

The simplest architecture is simply dynamic rendering of html on a server without Ajax and with a new HTML page requested for almost any click. This is a “traditional” approach, and there are pros and cons.

The next simplest is to provide fully static html + js + css (your React application) to the client and access XMLHttpRequest web services to retrieve the necessary data (i.e. your method B).

The most complex but ideal approach (in terms of performance and SEO) is to create an “isomorphic” application that supports both approaches. The idea is that the server makes all the necessary WS-calls that the client makes and displays the initial page that the user visited (which may be a deeply connected part of the application), a bit like option A, but using React to render, and then transfer control to the client for future DOM updates. This then allows you to quickly increase page updates through web service calls when the user interacts (for example, like B). Navigating between different pages at this stage involves using the history API to make it look like you are changing a page when in fact you just control the current page using web services. But you, and then updated the browser, your server will send back the full HTML of the current page before transferring control to the React client side again. There are many React + Flux + Node examples of this approach available on the Internet using various Flux options that support server-side rendering.

Whether or not this approach is worth it depends on your situation. It probably makes sense to start using approach B (you can share your HTTP API between mobile apps and websites), but use the Flux architecture, which supports server-side rendering and is aware of this. Thus, if you need to improve the performance of bootstraps, you have the means to do so.