So I get the difference between next build && next export and next build && next start from here.
In short, next build && next export generates a fully static app which does not require a server to host, whereas next build && next start starts a server which renders and serves content.
My question is then, how is next build && next export different from just using React? Seems both approaches generate static files (html, css, js). If I want to optimize SEO, is next export better than using react?
There are many ways to create a React web app. And there are many types of them as well.
Client-Side Rendering
Noticeable toolchain: Create React App
Everything is done on the client side. You send a blank HTML file and various JS bundles to the browser. And the browser parses the bundle and renders contents on the HTML and presents it to the users.
It takes less effort to set up so it best suits small projects.
This is properly what you were referring to when you said: "just using React".
Server-Side Rendering
Noticeable Toolchain: Next.js
Most of the works is done on the server-side. When a user requests to view a page, the server generates the need HTML file dynamically with static contents in it. Then, it sends the file to the user together with JS bundles for interactive content. The browser then attaches those JS to the HTML and present it to the users.
It requires far more effort to set up compared to Create React App. It best suits mid to large projects.
Static Site Generator (Prerender)
Noticeable Toolchain: Gatsby
Similar to Next.js, but instead of generating the HTML dynamically. It generates ALL OF THEM at build time and just sends it to users upon being requested.
This property has the best performance overall. But it can become a nightmare when the site is growing bigger and have hundreds of pages. Building a large, static Gatsby site takes ages to complete.
p.s. Next.js is also capable of generating static sites, but why don't you pick the right tool which is designed and optimized for generating a static site in the first place?
Answering my own question after I tried the following:
Launch a create-next-app then do next build && next export
Launch a create-react-app then do yarn build
Compare out/index.html in the next app and build/index.html in the react app
I found out that out/index.html actually contains all the static contents, whereas build/index.html contains nothing but <script> elements in its <body>. Everything including paragraphs (<p> elements) are later generated (or hydrated) when opened in the browser.
So in conclusion, even though both Next and React can be used to generate static site (SSG), Next is still better for SEO purposes since the contents are already in the html file.
Next.js can be used as static side builder (in the case you are referencing) which means it will generate all of you html at the time of build and along provide some performance features.
React(if not used on server) will always just have 1 HTML page which then loads of all your App(or chunks if you are code splitting) when the client requests it.
If you are not familiar about the concept read more on Static side building.
For SEO purposes using Next.js with either static or server side rendering would be the best approach since everything is prebuilt and easily accessible by robots(Although Google bot should already read javascript apps as well).
Related
I have a huge project using asp.net and jquery. I want to start migrating to react page by page (it might take a lot of time).
I would like to know what is the best practice to do it.
Can I move pages to react partially (for example half of page), and is it good approach?
Lets say I have main page A with with links to page B and C. Can I move page B and C to react, using routing, without moving page A right now?
I think I will use Vite to create and manager react project. In the production vite generates static files so I will simply host new files next to old ones in my backend server.
The problem is with development, because in this mode vite creates new server with functions like hotreload and in the result I have two diffrent servers hosting frontend asp.net and vite.
I would prefer to have just one server also for development. Is it possible to build development version with vite and copy it to server the same way like in production? Is this good approach?
I know that it would be the best to have backend and frontend server separated, but project is so huge that it is not possible in the foreseeable future
I am new to Next.js and I was looking at the Next.js deployment options https://nextjs.org/docs/deployment and I run into the following (and I guess most commonly used) options:
deployment using a Node.js server: https://nextjs.org/docs/deployment#nodejs-server
deployment using Static HTML Export: https://nextjs.org/docs/advanced-features/static-html-export#how-to-use-it
I am wondering, what is the actual difference there and how to better detect which approach should be used?
I believe Next.js' official documentation covers this properly: Advanced Features: Static HTML Export
Still some of the points that I feel should be highlighted:
Statically exporting a Next.js application via next export disables API routes (because they can't be prerendered to HTML).
next export is intended for scenarios where none of your pages have server-side data requirements (you will have to fetch all data client side or during build).
next export causes features like Incremental Static Generation/Regeneration to be disabled.
I18n routing is not supported (in static HTML export) as it requires Next.js' server-side routing.
what is the actual difference there
As the name suggests, when you are statically exporting your app, you are simply building it into a bunch of HTML, CSS, JS files, which can be hosted with ease anywhere.
On the other hand, when you are deploying on a Node.js server, you can use some more features (as mentioned above). Although ultimately HTML, CSS, JS will be sent to the browser, but before sending you can specify your logic.
You can define your APIs without a need to write the backend of your app separately. You can server-side render your page, you can fetch data, and add it to your page so that the requests are not made from client side (a necessity if you don't want to share where are you getting data from).
Also when your code is running on a Node.js server you can use the default next/image loader, it optimizes the images that you serve. In static export you need to use third party libraries [or (generally paid) loaders], or maybe manually optimize them.
which approach should be used
This is something that you need to figure out yourself. If your hosting provider restricts you to use only static assets, then you are forced to deploy site by statically exporting the HTML.
If your provider has option to deploy Node.js apps, then you need to check various parameters, like if you actually need a server to run your app, do you have some code that cannot/should not be executed on client side, ...
Are there any examples out there of injecting new ReactJS components at Runtime, e.g:
A build is deployed on production is stable and running.
We need to add a component or a new route without running through an entire deploy process.
An additional usecase : the application ships with all the components ( e.g: A CMS Module library) - Only certain components were enabled in layout at build time but need more to be added later via a config.
Approaches I have considered.
Using next getStaticPaths and then using a override in the front-end to inject client side components. This will most probably be seen at runtim
Use a more faster deploy system - This is more obvious but imagine lots of changes within a day and multiple deploys.
Any similar problems or approaches people would have tried would be great.
Update Nov 2022
If you are searching on the internet and this comes up, Zack Jackson's Module Federation supposedly achieves this and is called live code sharing via Module federation - https://module-federation.github.io/ There is a NextJS Paid plugin https://app.privjs.com/buy/packageDetail?pkg=#module-federation/nextjs-mf (supports only CSR currently)
I think you would lose out on a lot of built-in build optimizations from Next by trying to circumvent the standard build process, e.g. automatic code-splitting as described here.
However, you might find the fallback feature solves your problem entirely - the fallback feature was meant for large ecommerce sites like it sounds like you're working with. As stated at the fallback true docs:
useful if your app has a very large number of static pages that depend on data (think: a very large e-commerce site). You want to pre-render all product pages, but then your builds would take forever.
When creating an app with create-react-app,there is only one index.html,does that means React can only handle one SPA at a time? What if I want to develop multiple pages? Should I create another SPA with create-react-app and then put them together after building each of them?
Update:
Parceljs can do that. here is docs.
You can use Parcel instead of Webpack (which being used in create-react-app) and it provide you zero config environment to develop web apps (using react or anything else).
Having multiple pages (instead of SPA) is not what most React environments had in mind [before - see update above].
You can have different page URL's using react-router or similar client side routing solutions.
If the concern is bundle size, there are solutions using webpack or parcel to lazy load each bundle whenever they needed or cache bundle (using service workers) and so on (Tree shaking, ...). (check Code Splitting in React Docs)
Other concern I might have in my brain is SEO, in this case you may find Isomorphic app (react server side rendering) useful which initialize first view of requested URL HTML and sends it to client, then client will load react and react will take control of UI. This will help Google (or other search engines) find your URLs fast and user experience in transitions between pages will remain seamless.
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.