What is the point of server side rendering in React/Redux?
It would seem to me that another level of complexity is being added to the software, but I don't really see the benefit of it.
What are some common use cases for server side rendering?
React's SSR (Server Side Rendering) offers some benefits over CSR (Client Side Rendering):
1. Improved (Perceived) performance at the client side
Obviously, rendered components are shown to the user right away without the need to wait for browser to render. The website won't be interactive until all React code are loaded and executed, but the perceived performance is improved by showing content to users ASAP.
2. Better SEO
Since content are rendered at the server side, search engine crawlers can see the rendered content instead of just a blank page with JS tags.
Note: Google crawler supports JavaScript rendering, not sure about other Search Engines though.
Interms of complexity - yes, SSR introduced extra complexity but there's always a tradeoff for each technical decision.
The whole point of so called Universal apps or "Isomorphic JavaScript" is its "write once, run everywhere" kind of motto. Meaning that you wouldn't need to maintain a specific backend project and a specific frontend project differing in techniques and instead consolidate a whole JavaScript project into one.
It's not quite as dandy as you'd think because you still need to maintain a backend specific part that handles the initial GET request.
Furthermore you also leverage the Single Page nature of an application whilst getting the server side first page load making your website 100% crawlable by the Googs, even though Google now crawls SPAs quite competently currently.
As for complexity - it could be as complex or as simple as you would want to, I guess. Not everything is solved by doing a "Universal app" nor is everything solved by doing a standard web app either.
Related
I have read multiple articles trying to explain server-side rendering vs client-side rendering and I simply cannot seem to get a grasp of the concept. To me, when someone says "render" something, I think of the computer parsing the HTML file and presenting this to the computer screen, therefore the idea of server-side rendering makes no sense to me at first, as the idea would be for the server to parse and present it on it's own monitor.
I have seen articles mention that SSR is better for SEO, but my additional confusion comes from the fact that Create React App is a SPA, meaning to be a SPA it must load the entire page at once, and not make requests to the server when changing pages. Should this mean that since the page is loaded all at once that it is SEO friendly?
My question is, could somebody please explain what the key differences are between CSR (React app) vs SSR (Next.js) and what is meant by "rendering" and "compiling" in this context.
Using a client side routing server side doesn't forge entire page to serve a client, but datas are downloaded from webapp "on demand".
So, in this scenario, if you see html code you could see something like this below:
<body>
<div class="blah">{{content}}</div>
</body>
I know that prerender strategy can be used and i think that probably google crawler is very smarty and can see contents anyway, but the question is:
is it good this approach on seo side?
Using prerender strategy server needs to generate page with content. Could be that a penalty in page speed factor?
Thank you in advance to everyone.
As you've mentioned google is pretty smart and from a recent experience, is able to fetch some of your site's static content even when using client-side rendering. However when it comes to client-side routing it's not quite there yet so if you need to have SEO, server side rendering frameworks like nuxt.js should be your go-to.
but datas are downloaded from webapp "on demand"
The same thing applies when you do asynchronous fetches (download on demand as you've described it), imagine the data inside your {{ content }} was coming from an external API, as far as I'm concerned no crawler at this time is able to deal with this, so your content area would just be empty. So generally speaking, when SEO is an requirement, so is server-side rendering.
Using prerender strategy server needs to generate page with content.
Could be that a penalty in page speed factor?
Yes and no. Load times will certainly go up a little, but when using client-side rendering, the client needs to render the page after loading it, so this time just gets shifted to your server. This applies again to asynchronous data fetching. The delivery of the site will take longer, but the data it has to fetch will already be there, so the client wont have to do it (SSR frameworks allow you to fetch data and render it before sending the site to the client). If you accumulate everything, there shouldn't be a huge difference in time from sending the request to actually seeing the rendered page in your browser.
We have a website that's running AngularJS 1.*
but one of our main clients are military personnel and they frequently attempt to use the site via Department of Defense computers. These, of course, have javascript disabled.
I've heard of doing server side rendering, but the majority of the examples and research just mention using it for the initial load. We would need the entire site to run off that principle. Essentially acting like an old MVC site. Is this even possible? And I don't mean with just angularJS. Angular 2(5, whatever version we're on now), or react. I just really don't want to back track to .net MVC
Edit: I realize this is, for all intents, a silly question. I was just hoping there was some awesome new tech that had solved the issues that would be present in even attempting this (as stated below, data-binding. I realize this concept completely defeats the purpose of SPAs)
Thanks anyways. I may just delete this question. Didn't have too many expectations to begin with.
This is very possible! Don't let the rest of the people here fool you.
We have a few websites that work just fine with or without JavaScript enabled. My company website https://bitgenics.io is a React app. If you disable your JavaScript the only thing that won't work is the client-side video player.
Now I have no experience with Angular 1 (and I have heard SSR is hard there), but support should be better in the later versions of it.
Getting the GETs to work is the first challenge. But the next one is that you have to have a fallback for your HTTP POSTs. SPAs often use straight REST calls to do any state changes, but you can't do that because it requires JS on the client.
So your forms have to a fallback of a regular FORM post. So you might need some server-side logic to receive these POSTs and respond with a Server-Side Rendered page again.
I am starting a new project and one of the requirements is potentially for the app to work when javascript is turned off.
I have been using reactjs for a while but solely as a SPA javascript app that runs in the browser.
I don't think I quite understand how a react SSR application works.
next.js is intriguing. Will a SSR application work without javascript?
If not can someone explain how an SSR application works or what problem it is solving.
SSR means the server will render the initial state of the application before sending it to the client on the initial run. This makes it so that:
Crawlers see actual content and can index your site based on it.
In most cases it speeds up your application since it puts the responsibility of the initial request on the server which is usually faster than most commercial computers
An SSR cannot work without javascript. It'll render initially but then subsequent executions and state changes will not be possible.
I suppose if your application doesn't require any subsequent state changes or provide further functionalities after the first load then it wouldn't need javascript.
The actual loading time of a web page and the user impression of that loading time can be quite different. For example, here are three different experiences a user can have while a page loads:
Waiting for a blank page to completely render at once
Parts of the page immediately render (e.g. top navigation) but components load
individually
The entire page is made of components that load individually
These different UI experiences become more common as JavaScript frameworks become more common, such as React or Angular.
The user's UI experience can also change if individual components use loading markers to indicate something is happening, such as Loading... or a spinning wheel.
What are some guidelines for improving the user impression of a fast loading page? If there are not any, how do you approach this problem?
There is always going to be an initial hit whilst the javascript gets parsed and executed. However, if you are after very fast initial loads you could try a few techniques such as:
Delivering a "critical" payload first which will quickly load the "essentials" of your webpage to make it feel much more responsive. Webpack has a code splitting feature that you could use for this effect.
Making use of Server Side Rendering (i.e. universal style applications) which will execute the javascript server side and embed the output in the HTML payload. This probably renders the best results for what you are after as you don't getting the "flashing" parts as much you would otherwise. It's a pretty cool technique but is probably presents more technical challenges so you will have to decide on your own tradeoffs.
If you are after an example of SSR you could look at a boilerplate I recently put together for React: https://github.com/ctrlplusb/react-universally
In that boilerplate I actually also make use of Webpack's code splitting feature based on the Routes defined within the application. Checkout webpack's docs on this: https://webpack.github.io/docs/code-splitting.html
If webpack is completely new to you I highly recommend the survive js series: https://survivejs.com/