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.
Related
My problem is that I'm unable to understand how server-side rendering single-page application frameworks like Next.js receive prerendered, full HTML on the front end without having to rewrite the entire page. For example, the nextjs website states the following:
By default, Next.js pre-renders every page. This means that Next.js generates HTML for each page in advance, instead of having it all done by client-side JavaScript. Pre-rendering can result in better performance and SEO.
Each generated HTML is associated with minimal JavaScript code necessary for that page. When a page is loaded by the browser, its JavaScript code runs and makes the page fully interactive. (This process is called hydration.)
I understand how this bolsters the responsiveness of an SPA on first page load. But after that first load, what makes server-side rendering compatible with SPAs? I think this arises from a fundamental misunderstanding that I can't catch, so here are some further questions I have that might help you to catch it:
Do SSR SPAs always respond with full prerendered HTML, or only for first page loads?
If the former is true, then on subsequent responses, how does the client efficiently render only the difference rather than rewriting the whole page?
Otherwise, if the latter is true, then how does an SSR SPA backend tell when it's responding to a first request, when the response should be the whole HTML, versus a subsequent request, when the bulk of the page is already there and all that needs to be sent is some relatively minimal information?
What am I misunderstanding about what makes SSR compatible with SPAs?
Many thanks in advance to everyone who tackles this question!
Welcome to Stackoverflow :)
Usually SSR is used for initial rendering of the page, so for the first question - for the first page load
This is necessary, so the SPA will be more SEO-compatible (there also might be some performance improvements with this, but it's usually secondary goal) and Search Engine bots will be able to parse pages without the need for JS
The SSR usually has several important steps:
Server render
Sending of rendered data to browser
Hydration. Hydration - is a ReactJS (since we're talking about next.js here) 'function' that binds the server-rendered HTML to the React on the Frontend. So basically binds server-rendered DOM to virtualDOM
After the hydration step you basically have a fully-functional normal SPA, which has it's own routing and able to fetch data on itself.
Usually you have different endpoint on the BE to fetch the data and to render the page. So basically the rendering process on the BE is somewhat similar to what you have on the FE - your application backend fetches the data from separate endpoints, applies all of the logic and renders the app.
Btw, to ensure that SSR works properly, there is a principle called 'Isomorphic code' - i.e. if you're using a library for data fetching, it has to support both node.js and browser APIs. That's why, for example, you'd have to use Next.js own Router when you have a Next.js application - it just works on both FE and BE unlike react-router, which would require some additional steps to achieve that
I am using React in my project and I have problem with client-side prerendering.
More specifically, it would be necessary to configure SEO
Which is the least painless way to prerender existing reactjs app wiht react-routes
Some examples I have researched:
Gatsby.js - https://www.gatsbyjs.org/docs/porting-from-create-react-app-to-gatsby/
Next.js - https://nextjs.org/docs#custom-document
Netlify - https://dev.to/joelvarty/prerender-your-spa-using-netlify-for-better-seo-3h87
React-snap - https://web.dev/prerender-with-react-snap/
Prerender.io - https://prerender.io/
Keen’s Server Side Rendered - https://medium.com/keen-studio/keens-server-side-rendered-react-wordpress-rest-api-boilerplate-bb58edb7cc0a
Razzle - https://reactresources.com/topics/razzle
React Helmet - https://github.com/nfl/react-helmet
Can anyone suggest what option I should choose that is the least painless.
I have headless wordpress as backend and reactjs client-side as frontend.
Or are there other faster options besides the prerendering?
Thanks.
IMO you really don't need to use a framework to achieve SSR if you want to keep control without turning your codebase into a blackbox and choose your own stack.
I created some boilerplate using Node Express. It supports:
SSR using StaticRouter on the server and BrowserRouter in the client
ES6 webpack transpilation + hot reloading both client and server and auto-updating browser
Redux, data preloading and client store hydration
https://github.com/kimgysen/isomorphic-react-setup
Last time I ran it, I noticed that I hadn't saved the favIcon in the public folder and perhaps there are some minor bugs that I will fix soon (I've fixed them in my projects but didn't update this repo because nobody looks at it anyway (lol!)), but what happens here isn't all that difficult to understand.
I created some basic SSR websites with it in a matter of hours.
I enjoy redux-observable to initiate server ajax calls before rendering the content (using forkJoin), but this is not included in the boilerplate (I haven't actually supported it since I uploaded the first time).
But in terms of setup, I don't really see a point in using a framework for this necessarily, it really isn't that painful / difficult to do yourself.
The benefit that I particularly like is that you don't depend yourself on the scope and dependencies of the framework. You don't get into trouble with things like 'the framework will support this feature or fix that bug in one of the upcoming releases'.
Although ultimately, it comes down to personal choice. So it's not like I want to downgrade these frameworks.
Note: The way Redux achieves pre-rendering is simply by adding Redux store (state) objects to the window object in the html that is sent back to the client.
Then at the client, the it initializes the stores with these objects.
So very simply, this is something that is easy to achieve, even if you decide not to implement any other SSR features.
to create server side applicantion with painless integration you can use my cli to generate a default configuration like create react app cli from facebook, https://github.com/ghondar/crassa
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.
In my web app, I don't want to use hash-based routing, I don't want to see any # appear in my URLs. I want to use RESTful URLs, e.g., http://www.example.com/blog/id.
react-router can deal with client-side routing quite well, but if a user hit enter on the browser address bar or refresh the page, the request will be sent to the web server and then the web server has to understand the URL and handle the routing.
Isomorphic is a good solution to this situation since it can render any page on both client-side and server-side. Actually there are many react starter kit projects on Github which claim to be isomorphic.
In my opinion, isomorphic looks beautiful but it's too expensive to write code: you need to make you react components render successfully both on client-side and server-side, which needs developers to make great efforts.
So here is my question, can I just make the react-router be isomorphic, not the entire code?
Yes. You can use react-router for a purely front-end (non-ismorphic) app with HTML5 history.
The routing is determined client side, so react-router will spit out the expected page.
However, whilst you don't need to write any server side code, you will need to configure the web server to point your routes to the correct place. This usually means pointing every single request - or every single valid request - to the same HTML file or entry point. Exactly how you do this depends on what you're using to serve your pages - Express, Apache etc.
I hope that makes sense.
Pardon my English, it is a second language. The whole point of an isomorphic app, as opposed to a regular client-side SPA is so the client doesn't have to download the whole JS file initially which results in really slow initial load time.
I've been trying to teach myself server-side rendered React, and after watching countless videos around the concept and following countless tutorials on the actual implementation, I still can't get my head around this (at least this is how I understand it):
Despite the server conditionally rendering pages and sending props to the client on url change, the client side still uses a router that includes all the entry points for the app (by requiring all of them, and then loading the file based on the url location). Doesn't that means all the files are included in the main client JS file anyways since it's already been required by the client-side router? Doesn't that defeat the whole purpose of server-rendered React? Or am I thinking about this the wrong way?
In short, how does an isomorphic React app really works with a client-side router that includes (by requiring them) all of the app's entry points?
I'm not sure that "The whole point of an isomorphic app [...] is so the client doesn't have to download the whole JS file initially which results in really slow initial load time" is necessarily true. I think the primary reason people do this is for SEO reasons and to improve perceived load time. You still get the benefit of showing the users the page before they have to load all the JavaScript (e.g. yes, they have to load all the JS, but it's OK because they already have most/all of the content). The app upgrades to an SPA transparently, providing a seamless experience for the user.
That said, you can implement a system where you don't have to load all the JS at once with something like webpack's code splitting. There's even a simple React Router example that does this.