Listing impressions of nextjs from my experience with it so far, and how it differs from react from a devs perspective.

How reactjs works:

In case of react, on a prod website, server could be a CDN. Need not be EC2 etc.

CDN is dumb server - which is just a convenient way to say CDN is a server but optimized for file delivery, not for compute.

index.html contains bundle.js

bundle.js contains

  • react runtime
  • JSX and Components
  • Routing info
  • Page Layout info

index.html is almost blank - everything in bundle.js

Client has to execute the JS first, in order to understand what the page is supposed to look like.

Here the server has minimal role in speeding up your app.

The server can only increase or decrease the TTFB (Time to first byte)

TTBF = HTTP Req Time + time to process Req + HTTP resp. time

You can max TTBF here by using a CDN - dont want to use an EC2 instance or a droplet, if using a static website. Better use CDN that is optimized for static file delivery (placed around the world to speed up delivery of your static file).

How NextJS works

Some of the featues of nextjs require you to have a server running (a live server - running).

  • could be serverless, but needs a nodejs process.
  • When using Vercel - that has nextjs-first support - you can put a CDN between Server and client. (You could also you aws with nextjs support - there is a fll blown architecture in aws, aws-serverless-nextjs). But Vercel is more clean.(simple, easy to setup and use)

nextjs-with-vercel

What if nextjs sends the HTML after rendering it on server?

Generate the HTML on server, and send to the client. but HTML

in React you write

  • event handlers
  • functions
  • access window
  • useEffect that runs after component is mounted.

All of this is not available on server! It is too costly to run say puppeteer or some headless browser and render it - so what people do - they wrote a server side renderer for react which is known as reactdom/server

This is a package you can also use to natively export the react DOM into static HTML string, which you can then rehydrate.

re-hydrate

rehydrate means - Magically attach all the eventlisteners again! to the static HTML blob.

This is where nextjs comes in - it abstracts away all these details of rehydrating and Serverside rendering. On top of it, since it is running on a server, it can give you additional superpowers! which are not present with static reactjs bundle.

What nextjs does

As first job, Next JS renders the same page on server that we see in a reactjs app. What’s it does that it creates a HTML blob. This HTML document is up and ready for a person to open in a browser - and also HTML is orders of magnitude faster than JavaScript - Means if browser has to render some HTML versus a browser has to run JavaScript that constructs that HTML from scratch, then always the former will be faster. Browsers are very optimised to display the HTML quickly, compared to executing JS. Because JS is a Programming language - it ~has to~ needs to bootup the whole V8 runtime environment, in order to parse the language syntax and do so much stuff.

HTML on the other hand is just markup lang. - browsers are highly optimized to do this (construct layout) very quickly.

HTML is very fast compared to JS based DOM rendering.

If time delay becomes between kindof 50-100ms. It can impact the user experience.

Even 100-200ms affects UX.

You create HTML on server side. Make CDN store the HTML. CDN can deliver files super quickly.

Nodejs is not CPU friendly.

SSR is slower TTFB because of slow compute of HTML.

With nextjs - it is not just SSR - it can also do SSR + revalidate

Revalidate

You render the page with SSR but then put it on CDN. Then you are regenerating the page in background on the server, every 5 secs or say every 2 secs or every 2 mins.

Why? Because even if your server is slow in regenerating the page completely from scratch, clients dont face the problem because they are served page by fast CDN.

Any app that doesnt require super real time data - can use this.

Even if you need real time data you can seperate your View layer from your real time data: client can connect to a websocket that is connected to say aws that can retrieve data - and the main document that serves the page itself can be from CDN. Performance, SEO friendly

Vercel does need a server running - because of server side revalidation.

If revalidate is on, vercel internally manages update - server regenerates, CDN flushes out old whenever there is new copy of the HTML available.