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, ...
Related
I wonder if I don't use server side rendering in next.js, do I have to I have to run dynamic website with node server? I mean, nextjs doesn't create an index.html file like react. Therefore, I can't run the project without node server. I hope I could express the situation
You can still have a dynamic website even without the Node.js server (i.e., static HTML export). You'll need to use client-side data fetching:
Client-side data fetching is useful when your page doesn't require SEO indexing, when you don't need to pre-render your data, or when the content of your pages needs to update frequently. Unlike the server-side rendering APIs, you can use client-side data fetching at the component level.
A Node.js server will be required if you want to use Next's own API routes in the same project or if you change your mind and want to use SSR features (e.g., getSeverSideProps) afterall. In my own experience, for example, I've paired a static generated frontend from Next (served by Caddy) with a REST API written in Go and had no issues fetching new data from a Postgres DB.
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).
Why would someone doing SSR with Next.js use Express (or other server) instead of building and initializing with the built in next start?
The Next.js team is always working on ways to eliminate the need to use a custom server.
For example: in the past, it was required for:
static asset routing (such as robots.txt)
internationalization middleware
relay modern server
dynamic routing
Now it's just sometimes needed for middleware. Just note you could be in an old project that made that decision based on a historical need, not necessarily one that's present anymore.
Zeit themselves advertise multiple custom server examples (just search for "express").
If building a react app produces only static files how can dynamic websites be created with react?
Or can react build dynamic content too?
I have only made statics websites with react.
The short answer is yes - React can provide dynamic content.. You can also configure React to be a "dynamic" site (aka server side rendered) by using something like Next.js
Rather useful article..
To elaborate...
The relationship between a dynamic site and dynamic content is not mutually exclusive. A static site can most definitely provide dynamic content..
When you boil it down, a NON-static, or dynamic, website essentially refers to a website (or certain pages within a website) that are rendered server side. A static site refers to a website (or certain pages within a website) that are pre-built and then served to the client..
In the case of 'dynamic' websites, dynamic data is gathered server side and injected into html via some sort of a templating engine.. (Razor on ASP, Handlebars on Node, Jinja on Flask, to list some examples) ... As for 'static' sites, dynamic data is usually retrieved from a backend API that resides in a separate location than the web server that served the 'static' content - the requests, etc are all performed FROM THE CLIENT SIDE..
Basically, take the terms "dynamic site" and "static site" with a grain of salt.. Dynamic content is not mutually exclusive to either paradigm, and can exist using either paradigm.. You can have a dynamic site that doesn't have dynamic data..
Dynamic sites inject dynamic data into html server side, then send it to the client for viewing. Static sites gather dynamic data from a server somewhere (could be an API you control, or some 3rd party API), and then inject that data into the markup - difference is this is ALL done client side. If you wanted to retrieve data from a third party API using a dynamic/server side rendered site, the client would request a page from your web server, then your web server would query the 3rd party API, and inject that into HTML, then send the HTML back to you..(at a high level).. With that being said - you can still call 3rd party APIs client side, manipulate data, and manipulate the DOM client side, when using server side rendering..
Static sites basically send the entire website to the client (at a high level) upon the initial request - even if it contains multiple "pages".
React can be inter-mixed with dynamic server-side code such as PHP, ASP.Net, etc. In the case of ASP.Net, you can just use the React templates for ASP.Net, rather than using pure React-only templates such as CRA, or NEXT, or you can install React manually into your ASP.Net project.
If you want to build a React App that strictly produces static files for some reason, and still want some dynamic behaviour (e.g. loading from database), then you might want to look at JAMStack. The main idea is for dynamic operations, you either:
Get the dynamic data from an API on the run-time of your static pages
Get the dynamic data from an API on build/compile time using Static Site Generators (SSG)
Ok so I have looked around and cannot find the exact answer I am looking for. When developing a Sails app (which I am new to) it appears that by default it creates its own frontend using EJS.
Is this correct?
If this is correct then why is there an npm for sails generate frontend
If I want to use an Angular frontend is sails-generate-frontend-angular the best route to go?
Thanks!
First you need to separate server templating (EJS) from angular.
Just because sails defaults to an EJS template engine does not mean that you can not still put angular is your asset library and create and angular app. EJS is (the default but not the only option) what sails uses as a programming language for building its templates on the server that then get delivered to the client. Angular templates are used once delivered to the client to display information and perform tasks specifically already in the client machine.
1.) See above
2.) Sails-generate-frontend helps to setup your asset pipeline. It creates grunt tasks to copy image files and setup your javascript libraries such as ANGULAR.js, jQuery ect for use in your front-end.
3.) It could be. It depends, what a lot of people do is setup 2 projects. They use Sails as their API and then setup a second project for their Angular app (especially if its a SPA).
If instead your just using angular is specific places in your app (think jQuery style), then you would use a something like generate-front-end to take the angular library from someplace (like bower_compenents) and place it in your assets when you lift your app. It also makes it avaiable so that it can be placed in your html to be included in your app.
I on the other hand, use sails templates (I use Jade instead of EJS) to create and modify my angular templates on the server before they reach the client. This is a slightly advanced practice and can get confusing if you don't understand the difference between generating html on the server vs client.
An alternate method of thinking about this would be creating your index page on the server. This page would include your css and scripts. It would possibly be the only page on your server and everything else would be angular templates rendered on the client asking for JSON calls. In this scenario you would be using SAILS (ejs, or jade or whatever) to render only a single page INDEX.js and that might be the only server template you have.
However, this being said. Sails ships with this stuff already. You don't need sails-generate-frontend. Its is already inside a standard sails app.