1. Early web
Back in the mid-2000s, when the web was still in its infancy and growing, developers started moving from static HTML pages to dynamic ones. It was the golden age of object-oriented programming languages like PHP (Server render HTML).
Then came the JavaScript era. People are starting to realize that this language is supported for the web and can be used a lot.
You can submit dynamic forms, HTTP requests, create beautiful scrolling effects, and even create web pages quickly.
The proliferation of JavaScript and libraries like jQuery allow web developers to create beautiful interfaces that are fully customizable using JavaScript.
Before long, every web developer started pushing more and more JavaScript down to the web client . Sure, technology evolved, mobile phones, and PCs got better with more RAM and cores, but JavaScript started to evolve faster.
More functionality, more features and more frameworks mean a better user experience and the ability to create an app-like feel on the web.
But this also means pushing more and more JavaScript down to mobile devices, and those devices are unable to keep up with the growing limits of JavaScript.
2.The Web was made for HTML
With frameworks like React and Angular, you’re basically pushing giant JavaScript packages to the client that first has to download small HTML pages.
Old, slow mobile devices start to give up – increasingly high load times, more latency, less powerful JS tools
Web developers who have moved from PHP (server- render HTML) to JavaScript (client-rendered HTML) have begun to realize that they spend a lot of time loading the page.
A simple About Us page, maybe a very simple static HTML / CSS page, now a giant JS package page. First, the browser (client) has to download, then parse, then execute and then change the DOM to render the content.
People love React and similar tools. But they also understand the meaning of running too much client-side JS.
On the other hand, they like the way PHP works (server render HTML), but they don’t like its architecture. So what is the solution?
3. Server-Side Rendering (SSR) – the best of both worlds
Web developers realize, after all, when the React code is executed, all you really have is an HTML document to display.
So they did it. Server-Side Rendering (SSR) for React is born.
Now, with SSR, you can write React code, somehow run it on a server (more powerful than your regular client device – like a mobile phone), and then send the HTML document to the client.
As a developer, you can code in React – the technology you love. And the client visiting the website will get a pure HTML document, which will get a huge performance boost.
Win-win, who wouldn’t like that
4. But it was too difficult
Server-side rendering is definitely the solution to this problem. But the problem? It’s too difficult to set up correctly.
Proper caching and blocking? Can you create static HTML file for unchanged pages? How should you build a seamless navigation experience on your website even if you have server-side rendering HTML? How should you offload the load on your server or create on-demand content?
And most of all, how do you set up this whole architecture? Sure, React and the web provide all of the APIs for these, but they’re quite wordy and usually a one-time setup.
And Next.js was born in that situation
5. Introducing Next.js
Github: https://github.com/vercel/next.js
The nearly 60k stars on github have seen Next.js much Next.js is interested in. Next.js is getting updates, you can check in the tags on next’s github: https://github.com/vercel /next.js/tags
Next.js has the following solutions:
- Good for website SEO
- Integrated automatic caching and static optimization
- The pages are entirely server-rendered
- 100% React supports
- Tweak your webpack / babel configuration if needed
- And more!
It abstracts all the performance and development setup you need with a typical React application and allows you to focus on just what matters – your business logic.
Next.js 9.5 was released this year with a lot of new features. And I think it’s safe to say it’s one of the most powerful tools out there in the web development ecosystem, especially if you’re already a React developer.
If you’re a React developer in 2020, one of the best skills you can learn is Next.js. Here are some of the benefits it offers you as a developer:
- An emerging technology – more employment opportunities and possibilities
- Pages are rendered by the server, which means better performance – more customers coming to your website
- SEO for your websites – search engines will love you too
- All the benefits of having a server – API router, dynamic content fetching
- A great technical skill on your CV
6. Some Next.js features I’m excited about
Next.js is evolving very fast. They don’t use old functionality and are always introducing new and quality stuff.
Up until today, I’m really interested in the whole framework, but this is the feature that I like the most
6.1 Stable Incremental Static Regeneration
Simply put, this feature allows you to dynamically create static content.
Let’s say you have a blog website with lots of articles. When someone visits /news/[link] (where [link] is anything), you want to give them the static page as quickly as possible.
But you may not want to create all your static pages at build time as it will take you a lot of time. In some cases this is completely not possible at build time.
Also, sometimes your content can change, such as a quick blog edit – so you don’t really want a page that is completely static forever. So what’s the solution?
Using Next.js 9.5+, you can now dynamically generate static pages in dynamic paths and refresh them.
This means that when Next fetches that particular URL, it saves it as a static page and serves it statically whenever someone hits the path. At the same time, it will be ready to accept the new paths flexibly.
6.2 Webpack 5 Support
Next.js is also moving towards Webpack 5. support. This is interesting as Webpack 5 brings some great bundle optimizations and performance, and removes support for the deprecated stuff in webpack 4, make the core lighter.
That means your Next.js apps will be faster than ever and more powerful.
6.3 Dropping of getInitialProps
Personally, I don’t like the concept of having a single function that executes on both environments (client request and server request) – getInitialProps .
Thankfully, Next.js discovered that there was a much better solution and they included getServerSideProps and getStaticProps as two great methods with nice names.
getServerSideProps , as the name suggests, allows you to submit props to your Next.js page from the server itself. And getStaticProps allows Next.js to still generate static output at build time.
getStaticProps in combination with a static regeneration is an excellent feature. You get many benefits of a dynamic backend without the need for a dynamic backend .
6.4 Persistent Caching for Page Bundles
Next.js now also supports persistent caching for immutable pages. Previously, when you released a new Next.js app, Next.js would remove the entire app and the user had to re-download all CSS / JS, even if those packages didn’t change.
In the latest Next.js release released last week, our friends at Vercel introduced Persistent Caching ( learn more ), which is once again an absolutely great thing for performance.
6.5 Out of the box support for Sass Modules and TypeScript
If there’s one thing I love more than JavaScript, it’s TypeScript. And Sass is also very sweet. Most people I know use Sass to power their CSS, and it provides a great experience for develop.
Next.js has long provided great support for TypeScript. But they also recently added module-based support for Sass.
This means styles can now be written in Sass , locally for your modules, with caching and validation – all managed internally by Next.js.
It seems that Vercel really wants you to develop the best products focusing solely on logic.
7. Conclusion
Above is my understanding of Next.js
Hopefully the above article helps people get an overview of Next.js , a language that is gaining much love from developers