Plain React apps are called SPA because they have only one html page which is the index.html. But that is not the case for next.js. So can we call a next.js app a single page application?
Good question.
Normally we don't call an engine SPA or not. For instance, React can do SPA, but it can do non-SPA work as well. The same applies to the NextJS as well.
Just to follow your dictionary. NextJS by default is not SPA based due to its hybrid nature, because it publishes each page as a separate entry point for everything under /pages. Of course if you only have one page index.js, then technically it's a SPA again. I guess it depends on how you structure your pages.
Yes, we can call nextjs a SPA even if you create many pages, but to keep it as such you should use client side transitions (no <a> tag).
First of all, SPA = Single Page Application
I assume the question intend SPA vs MPA (Multi Page Application)
The answer is Nextjs can do both depending if you use next link
https://nextjs.org/docs/api-reference/next/link
That will perform a client side transition without reloading the page from the server, assuming your page is static of coure and does not use getServerSideProps(). You can check that by watching the Network in Chrome debug tools.
How that works ? On first page load, all pages get loaded in js inside the vdom and any page can get injected into your browser dom fromthe client js not from the server.
To give it an MPA behavior, you can also link a relative page with a simple html anchor tag <a>, that will reload the page from the server, as the a tag uses no js for that. What could be the advantage of that ? keeping code clean from next maybe, and if you mess the react vdom (which you shouldn't) you're sure to get a fresh page again. A disadvantage of that is that you loaded all content in js initialy anyway, so reloading with anchors is a waste of resources and load time.
Note using PWA (Progressive Web App) is also an option to optimise the user experience, and it is also supported by nextjs
see
https://nextjs.org/docs/faq
and
https://github.com/vercel/next.js/tree/canary/examples/progressive-web-app
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'm currently working through the next.js tutorial, but I'm struggling to understand the following:
The tutorial is telling me here, that clicking a <Link> element won't trigger a server request, and instead do "Client-side navigation", i.e. adjusting the page content with js:
The Link component enables client-side navigation between two pages in the same Next.js app. Client-side navigation means that the page transition happens using JavaScript
Three questions right away:
This sounds like regular SPA react routing without next.js etc. to me. But it isn't, right?
The <Link> still works if I disable javascript in Chrome dev tools. This shows that the transition is actually not happening with js. Is this a contradiction to their statement?
When I right click the page and click "view source" (in Chrome) I get different HTML before and after clicking the <Link>. (Contratry to the "regular" react behavior). How can this be considered "Client-side navigation"?
Going further in the tutorial, they tell me here:
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
This statement sound like a contradiction to the other one quoted above. Can you help me to clarify this? When I click the <Link> what exactly is happening? Is a new html file loaded? If so, how can this happen "client side". Thank you!
Here is how I understand it:
The approach Next.js takes for client-side navigation is a mixture of SPA-style navigation and traditional navigation
In SPA-style navigation, a "link" is a component with some JS logic. It does not have a <a> element. When you click on it, some JS will run to render the new page. If you disable JS then you can't navigate to a new page;
In traditional navigation, a link is really a <a> element. If you click on it, then the browser will discard the current page and load the new page entirely. If you disable JS then you can still navigate to the new page;
In Next.js navigation, a "link" is a component with some JS logic, but it also has this <a> element under the hood. When you click on it, some JS will run to render the new page and prevent the default <a> navigation. So even if you disable JS, you'll still be able to navigate in a traditional fashion through the <a> element. The pre-rendered page will be fetched and loaded. This is really useful in terms of SEO (as crawlers typically don't have JS enabled), and is the main problem Next.js wants to solve.
In short, when JS is enabled, Next.js navigation behaves just like in SPAs; when JS is disabled, it behaves just like in traditional websites.
Update:
I made a video to further demonstrate the concept: https://www.youtube.com/watch?v=D3wVDE9GGVE
There!
I think the main concept that you should be getting familiar with Next.js framework is Server Side Rendering, which basically means that all contents of a page are pre-processed in the server, that ships to the browser the files already rendered, saving resources from the client-side of an application.
By default, all of your Next.js pages are pre-rendered when you use the build command.
Next.js also has its own <Link /> component which uses the next-router module to navigate between the pages.
By default, every <Link /> component in a page tells Next.js to pre-fetch that page and it's resources ( which will also be rendered by the server on the initial request from the browser ) and be "instantly available" when you click it.
I think the main basic difference than a regular SPA is that in those, when you change pages, it takes longer because they won't be already available to you.
AFAIK:
This sounds like regular SPA react routing without next.js etc. to me. But it isn't, right?
Yes. It's like a regular SPA react routing. When user clicks on Link, it will do it in JS just like CRA.
The still works if I disable javascript in Chrome dev tools. This shows that the transition is actually not happening with js. Is this a contradiction to their statement?
This is happening because, if you disable JS, what you get is a simple <a href="..." />. ie, browser will still count it as a anchor element, click events will work as expected because it's just our old HTML.
When I right click the page and click "view source" (in Chrome) I get different HTML before and after clicking the . (Contratry to the "regular" react behavior). How can this be considered "Client-side navigation"?
Your answer lies in the next statement where:
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
ie, when you "View source" browser will hit the server and show you the HTML. Since Next prerenders, it will be different for different pages. This has nothing to do with client navigation. This behaviour of showing browser response in view source can vary from browser to browser though.
Hello guys i am new to React Js i often hear and see posts regarding react is single page app but never understood what is SPA and many say that it doesn't reload the pages but i didn't understood why so could you guys please explain me with simple examples.
A Single Page Application is a web application or website that interacts with the web browser by dynamically rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages.
This means that the URL of your website will not change completely (page will not reload), instead it will keep getting content and rewriting the DOM with it instead of loading a new page.
The goal is faster transitions that make the website feel more like a native app
Example: Netflix
This is the dashboard, and when we click on any movie, it changes to /watch and the content is rewritten.
In Technical Terms:
When building your react-app, you can see that there is only one
App.js from where your entire web-app is loaded in fragments and
components. This behaviour of rendering components and pages on a single page and changing the DOM( is a single page behaviour and hence the name), instead of loading a new page with new content, this makes it feel like a single application.
As mentioned in Glossary of React Terms:
A single-page application is an application that loads a single HTML page and all the necessary assets (such as JavaScript and CSS) required for the application to run. Any interactions with the page or subsequent pages do not require a round trip to the server which means the page is not reloaded.
And about "Why is React Js called as Single Page Application":
Though you may build a single-page application in React, it is not a requirement. React can also be used for enhancing small parts of existing websites with additional interactivity. Code written in React can coexist peacefully with markup rendered on the server by something like PHP, or with other client-side libraries. In fact, this is exactly how React is being used at Facebook.
A single page application has one single page e.g. www.google.ch. It is exactly one HTML file (with all its required dependencies) loaded into the browser. You'd navigate between paragraphs only using hash-router, but never ever visit another page like www.google.ch/maps (that would then be www.google.ch/#maps, which references / -> index.html) (tho google may not be the best example, it is more about URIs).
ReactJS is an open source JS library for building UI and used for SPA, and it manages the views of web apps. Reactjs can help you to modify your data without reloading of a page. It is a popular library in the market trend because of its scalability & fast performance.
Single Page applications are different from multiple page apps that we see everywhere because the SPA doesn't move into new pages; instead, it will load the pages inline within the same page.
In traditional websites, when we go from one page to another, the whole site is loaded. e.g - if you go from "www.example.com/hi" to "www.example.com/hello" the whole website is reloaded. No matter how much portion of the website is really changed. Let's say, the website has "Sidebar, logo, menu" on both of its pages, then the full reload doesn't make any sense. This takes too much time and decreases the performance.
Single Page Applications, as the name suggests, have only one single page that is loaded the first time you open the website. After this, no matter where you click, it is not gonna refresh the website fully.
browser reload button
The loading icon of the browser doesn't load when we move from one page to another on SPA site, as it does on the traditional websites.
Cons- SPA sites are great for UI UX but they are not the best when it comes to Search Engine Optimisation, it creates problems with rankings.
I am a little bit confused about front end frameworks. I read that if you used ng-route or react-router it would make your app a single page application, so does it mean if I don't use ng-route/react-router and instead used express for server rendering would the app still considered a SPA ?
To answer your final question, if you're serving bits of your site from different Express routes, then by the definition of a Single Page Application it's not a SPA anymore, no.
However, there's nothing explicitly wrong with doing that. ReactJs is a tool and a way of working with components. If you want to work with components, but you're more comfortable with serving your individual views from different server-side routes then just do that. Not everything needs to be a SPA. Once you're comfortable with the core of how React works from a mark-up/component point of view, you can start incorporating partial page renders and client-side routing etc.
I think you are not getting the point about SPA. Please read the following:
https://en.wikipedia.org/wiki/Single-page_application
The Scenario
I'm developing the front-end (CSS only) of an Angular SPA.
I'm not especially familiar with Angular routing.
I'd like to add a standalone page containing Bootstrap components just for development purposes (yes, I know this means it won't be a single page application anymore). This way I have one unified view with all the components so I don't have to switch back and forth while working on the CSS. It also acts as documentation for the Bootstrap for the other devs to refer to.
What I've tried
I originally added a bootstrap.html page to the app folder, alongside the app's index.html This worked at first, but has now stopped working. What would be the best/standard way to achieve something like this?
Update: I've managed to fix some of the JS errors, so the page is up and running again. My question remains though: "is there a way of adding a standalone page that is considered standard/best practise, or is it literally just add a separate HTML page at the app root?"
If you use a target='_self' in your linking anchor tag, this should force a full page reload, and that will avoid the angular routing - which is where I expect your request is getting hijacked (by design).
e.g.
link
Answering your updated question
Not to my knowledge, since (as you correctly pointed out) this mixes the SPA design pattern.