-2

When deciding for a new web project I have two design choices.

First, I can go for traditional web application design. In this case, pages are rendered on server side.

Second, I can go for an API server over HTTP. In this case, I have to develop a separate front-end client which will consume the API.

I think the second approach is obviously superior, the concerns are separated very well, independent teams can work on them, one can take advantage of the plethora of packages on npm and friends. Client doesn't need to know anything about the server except the API. Many clients can be developed to use the same API and etc.

My question is, whether there is any reason at all not to choose the second approach over the first one.

I appreciate any insight.

Update: If something is wrong with the question, please let me know. I'll do better next time then! I can't understand the reason of the negative vote.

closed as too broad by Laiv, JeffO, TheCatWhisperer, kevin cline, Thomas Junk Apr 5 '18 at 15:14

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    It's a matter of adequacy. Not everybody needs a super architecture with all its components, SLDCs and such things decoupled and distributed. Not everybody needs a couple of clients consuming a REST API. #1 (IMO) is fairly simpler and cheaper than #2. In all the senses. – Laiv Mar 7 '18 at 8:07
1

Front-end frameworks are mature and reasonable choices – but you this comes at a cost of crawlability, and at a cost of performance. This may or may not be relevant, depending purely on the nature of your project.

For a website, being able to directly serve HTML content matters. Sure, Google can also crawl client-side rendered websites. But other search engines don't. More importantly, client-side rendering makes your content inaccessible to crawlers from social networks or similar services. When visitors share your site on Facebook, Twitter, or Slack, their crawlers are looking for specific meta tags in order to render more than just a plain link. When users want to read your page on a read-it-later service such as Pocket or Instapaper, their crawlers need to fetch the HTML. Not supporting these use cases will limit the reach of your content.

For a web app that has no content for non-authenticated users, crawlability doesn't matter for the URLs of your app. It still matters for the publicly visible, static parts.

When you render everything client-side, you don't just have to transmit your page and wait for the Browser's rendering engine to do its thing. You need to transmit a HTML scaffold, all your JS, the data to be rendered, and any templates, then create the HTML and then actually let the browser render everything. Admittedly, if you can use HTTP/2 having to load multiple resources doesn't necessarily lead to latency issues. But the client will still have to do more processing. That can delay the perceived load time for the initial page load. If this is a web application that users are somehow invested in, this doesn't matter. They will wait. For casual users, users on mobile phones, or for websites the initial load time matters very much. Visitors might simply lose interest in your offering if it doesn't display anything useful after a few seconds. I regularly encounter fancy client-side rendered websites that simply don't display anything because they make bad assumptions.

Note that it's possible to have perceived-fast subsequent load times even without using client-side rendering. First, serve a server-side rendered page. Then do a tiny bit of progressive enhancement: when the user performs any action, don't let the browser navigate directly to that new URL. Instead, fire of a background request for the URL, display an unobtrusive progress indicator, wait until the response has finished downloading, then replace the DOM with the received HTML and update the browser history. E.g. Github does something like this. Or you can just replace parts of the page with a new HTML fragment, jQuery-style! The point is not that this is the best way to do web development, just that it's a perfectly fine, very fast, and highly compatible approach.

Note that server-side rendering does not cut you off from many of the client-side rendering benefits. A server-side frontend can still connect to an API (possibly on localhost, super fast!), can still be developed by a separate team, can still make use of NPM and so on.

The only really good reason to create a client side rendered web app is that the user interaction doesn't fit easily into a state transfer model. State transfer makes it easy to model a form-based workflow with a clear “save changes” button, or user interactions that only consist of viewing/consuming content. So client-side rendering is only a must if you have client side state that would be pointless to transfer for each user interaction, e.g. in an editor or a game.

  • Thanks for your thorough answer. I will consider these issues from know on. – Mehdi Sadeghi Mar 3 '18 at 22:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.