Why should you read this article?
- Learn about the framework that I am/will be using
- Pros/cons of Nextjs
Nextjs 13 what’s hot?
Next.js App Directory Playground
Demo, you can open Dev Tool and open the Network tab to see how things like Server Component, streaming, layout work.
Layout
This layout guy was born to solve several problems:
- Dev code layout is quite tired with the previous approach, you have to create the layout component yourself and then attach the corresponding child components according to the url
- There are many nextjs apps used to build Dashboard, but if it is a dashboard, it will often have a nested layout/componnet style. If there’s an approach to doing these, great
In short: Nextjs supports nested layout according to the file structure to make it easier for apps to have nested layouts.
It’s quite similar to how before Nextjs supported routes according to the file structure, instead of having to define it in a file with react-route support like before.
Read more: Routing: Fundamentals | Next.js
Well, well, well-structured code is easier to understand. But there’s something even better
Component-level Data Fetching
Previously, one thing that made Nextjs different was to support some ways of fetching data at the Page level like getServerSideProps , getStaticProps , now if used with the Layout above, I can do it with each component.
Well, is it just fetching the API in the component like before?
No, with the Component-level Data Fetching concept, nextjs supports API calls on the server and the client for each component. As a result, the server can return the component with ready-made HTML code. It’s like the page component is called by the api and rendered to HTML and returned to the client, but this is at the component level.
Why is it better to call the API on the server and at the component level?
- Query directly to source data/database without worrying about leaking key/account
- Less round trip, less dependent on user’s network if query in browser
- Bringing it closer to the component level will make fetching data more efficient. Specifically, someone needs to fetch that guy, instead of before having to fetch all at the page level; or push fetch to client, which component fetches that component
Blue is API call, purple is JS bundle call
Parallel splits into two clear parts, the API for the component, and the JS bundle for that component.
In general, to take advantage of this Parallel call, your API should be completely dependent on URLs and URL params, not on client state.
Read more: Data Fetching: Fundamentals | Next.js
Touching tryming and pense soup (Streaming & Suspense)
Former Flow SSR
Okey, the previous SSR flow would look like:
- Server calls API
- Server uses API and react code, outputs HTML, sends to browser
- Browser downloads the code and renders it
- Hydrating ( Learn more about hydrating here )
SSR will wait for all components to be ready and then send the HTML code down to the browser
Touching tryming
Basically, instead of waiting for all components to finish rendering and then sending it to the browser, run it all the way from the top to the bottom (No need to wait in the whole app for components that haven’t finished rendering), get the HTML and throw it in the browser.
The result will be like this:
What state is the first render, then stream it to the browser. If the component guys get results later, they’ll stream one more time
Suspense is the mechanism by which I can separate those parts to be able to run async as shown in the picture. With streaming will support
- TTFB, FCB, TTI are smaller
- If it’s smaller, users can see/interact with the website faster than before
Read more: Data Fetching: Streaming and Suspense | Next.js
Server components
Simply put, the Server component only runs on the server and returns HTML to the client, not running under the client.
Server components have a few advantages:
- Sometimes I need a lot of code and libraries just to render HTML. So if I just let it run at the server and return the HTML to the browser, I don’t have to ship a bunch of
node_moduledown to the client, and they don’t have to re-run the logic to get the HTML they want. - On the server, it’s easier for me to control. User machines can be “strong and weak every life, but bugs are always there! I’m sorry, so performance fluctuates a lot”. If they all just received HTML from the server, the difference wouldn’t be too big
Read more: Rendering: Server and Client Components | Next.js
That’s basically it, and here are some points that I think are not good or not feasible
Minimum React 18
This to me is called “Excessive pressure”, React 18 does not seem ready to use at the moment. Why?
Bug: validateDOMNesting error produces wrong HTML nodes in SSR · Issue #24519 · facebook/react
The biggest issue was that React added the validateDOMNesting thing. What does this do? It will validate the DOM structure to see if it has the correct HTML syntax.
Like in the p tag, there should be no div tag; in the table must have tbody , not skip through
There’s nothing wrong with it, but it’s extremely annoying. Your code can be edited a little, but the code in the library is extremely painful
For the above error, my experience is 90% can’t use React 18 for SSR, if you want to use nextjs 13, you must bring the code to the client. Then it’s even slower, let’s just use Nextjs 12
Frontend is no longer just frontend
From the moment you start coding with Nextjs, you also have to learn some more concepts about data fetching, page file routing, etc. fix some issues when SSR.
Now you have to know what a Server Component is, how to stream run. Fetching data on server, how to code, how to organize, …
Now in order to make a frontend app and this and that, you have to know how the server runs as well.
The learning curve when Nextjs code started to increase a lot. Although I have to admit that the skill of Dev now is to adapt very well, but what is less fun to spend learning time?
Looks like the loop is starting again. Previously, it was the backend code, did a little more backend, later separated the Frontend and Backend clearly, now the Frontend has to add a little backend to make it better.
It is only suitable for Dashboard-type apps
Actually, the Layout, Nested layout map with most apps is not very necessary. I just need the header/footer and then attach the children and that’s it for most landing pages.
Only dashboard makers have such a deep need to nested, and with my programming experience, most dashboards up to 3 levels are max, deeper is rare and edge case.
Remix.run is also a good framework to build dashboards and solve the same problem as above. Especially it doesn’t even have to deal with React 18 anymore. Next week I will write about this guy
Too dependent on Vercel
Serverless, edge function, streaming, server component, image optimizing, etc.
All good stuff but to run you need Vercel. If you don’t host on vercel, it won’t run well, some features don’t support, or support is also very tiring to make it work, etc.
I completely understand this in terms of biz, if you don’t build nextjs like that, where can you get users to sell Vercel 💁♂️
But in terms of devs or devops, it’s boring.
Therefore, this period is also trending to build open-nextjs
summary
If someone asks me if I should use Nextjs 13? I will answer no, not the time.
In addition, it has some things that sound good, but in reality are quite rarely used. So consider whether the problem you want to solve is suitable for Nextjs 13? The article only gives my personal perspective, if you find it still relevant. Go Ahead!