Which method is faster, express : Server-side rendering vs client-side rendering

It's not an either/or proposition.

React is a client side framework. You have to render on the client side. The question is whether to render on the server side in addition to rendering on the client side.

The answer? If you can, YES!

You will get SEO benefits and an initial performance boost by rendering on the server side. But you will still have to do the same client side rendering.

I suggestion googling "isomorphic react" and doing some reading. Here is one article on the subject.http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/

Well, it really depends on which vision you have on the modern web, and what you are willing to do.

Will you prefer to let your users wait, displaying a loader while data are loaded asynchronously, or will you prefer to keep your users busy as long as you can ?

Here are different articles that will help you clear your mind and be aware of the different advantages that you can have by doing server-side rendering, client-side rendering having multiple issues.

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

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

An other article, this time from airbnb, describing the issues you can have with client-side rendering itself:

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

There is also an other interesting article talking about client-side/server-side rendering, bringing a debate on when should we 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 link more focused on react, and describing in which way server-side rendering should be helpful 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, it's a matter of what you exactly need to do, to my opinion, but basically, you can do both at the same time (client-side AND server-side), to have the best user experience.

This concept is called "isomorphic javascript" and it is getting more and more popular these days.

The simplest architecture is to just do dynamic html rendering on the server, with no Ajax, and with a new HTML page requested for pretty much any client click. This is the 'traditional' approach, and has pros and cons.

The next simplest is to serve completely static html+js+css (your React app) to the client, and make XMLHttpRequest calls to webservices to fetch the required data (i.e. your method B).

The most complex but ideal approach (from a performance and SEO perspective) is to build an 'isomorphic' app that supports both approaches. The idea is that the server makes all the necessary WS calls that the client would make and renders the initial page that the user has visited (which could be a deep-linked part of the application), a bit like option A but using React to do the rendering, and then passes control to the client for future DOM updates. This then allows fast incremental updates to the page via web-service calls as the user interacts (e.g. just like B). Navigation between different 'pages' at this point involves using the History API to make it look like you're changing page, when actually you are just manipulating the current page using web-services. But you you then did a browser refresh, your server would send back the full HTML of the current page, before passing control to client-side React again. There are lots of React+Flux+Node examples of this approach available online, using the different flavours of Flux that support server-side rendering.

Whether that approach is worthwhile depends on your situation. It probably makes sense to start using approach B (you can share the your HTTP API between mobile apps and websites), but use a Flux architecture that supports server-side rendering and keep it in mind. That way, if you need to improve the performance of initial page loads, you have the means to do it.