https://github.com/zeit/next.js/
Next.js is a minimalistic framework for server-rendered React applications.
Background
Next.js was open-sourced 25th October 2016. The company behind Next is called ZEIT.
Next.js is backed by an organization which is stable and is also very active in the open-source world. Next is not going away in a couple months and most likely is here to stay.
So there you go – we’re officially in the age of server side rendered react apps. A lot of questions pop up, for example
- Why should I care? — I already know how to make quality React apps.
Great question — we should always be open to new concepts and learning new things. Remember, being a developer means being a student for life. Next can improve your life as a developer.
Imagine asking “why should I care” each time when a new technology comes out. We would be stuck with 90’s development tooling if that was the case.
When jQuery came out (it was a revolution due it’s ease of use) — you could have asked “why care at all?” and just keep on using vanilla Javascript. But you got to admit it improved almost every code base and made life just a little bit easier for all of us.
At the end, innovation will win — why not be an early adopter? 🤗
How Next can improve your life
- Ease of use. Forget about setting up webpack, react router, react and react-dom. It’s all included right out of the box!
- Code splitting out of the box.
- Performance for first page load.
- Improved SEO.
- Javascript everything! (We’ve all heard this before, ahem MongoDB and Meteor). Meteor is great and all, I even have a production project with Meteor and MongoDB. Next is the next (pun intended) evolution step. Next got a lot of things right (most importantly — it’s simplicity).
Curious about the benefits? Here’s a full in-depth article explaining the details.
What’s the difference between client side rendering and server side rendering?
Client side rendering — Normally when using React, your browser will download a minimal HTML page, and the content will be filled in by JavaScript.
With Server side rendering, the initial content is generated on the server, so your browser can download a page with HTML content already in place. Updates to the content are still handled in the browser.
Cons of server side rendering
- Server-side rendering can improve performance in many situations but worsen it in others.
- SSR is more work for your server, so your HTTP response will take a little longer to return. A lot longer if your servers are under heavy load.
- The size of your HTML will be increased and will take longer to download. For most apps this should be negligible, but could become a factor if your React components contain long lists or tables. SSR will usually increase performance for your app, but not always.
- Using SSR will increase the complexity of your application, which means less time working on other features and improvements.
When is server side rendering good?
- You need SEO on Google, DuckDuckGo, Bing, Yahoo, or Baidu.
- You already have a working React app, need the best possible performance, and are willing to pay for the extra server resources.
When is server side rendering bad?
- Your React app isn’t finished yet: get it working first. This does not apply to Next — It’s perfectly fine to write a Next app from scratch!
- SEO on Google is good enough. (Make sure that Google is crawling your content.)
- Server resources are scarce, perhaps due to a low budget or inability to scale.
What are the alternatives to server side rendering?
- Render client-side as usual. Rely on Googlebot’s JavaScript crawling features for SEO, and focus on other areas of your app for performance improvements. Your SEO will suffer on Baidu, Bing, and Yahoo.
- prerender is a service that will store a cached version of your pages. This helps with both SEO and performance, while keeping your code simple. I haven’t personally tried out this service so I cannot vouch for it’s quality. You might find this minimalist pre-render guide useful!
Very useful article about server side benefits and when to use — when not to use!
Ready to give Next and server side rendering a chance? A bunch of people already have!
Getting started with Next
We start our Next.js project like any other Node project. All you need to do is install Next as a npm module. Paste this command in the terminal.
After successfully starting our node project, installing react, react-dom and next — open the project with your text editor/IDE**.** Add the next script (see line number 7)
Be amazed — Run the dev script!
And that’s it! We successfully installed Next. Notice how ridiculously easy it was to get started?
We have React, webpack, hot module loading, routing, server side rendering, pre-fetching— and many more goodies which are a pain to setup right out of the box!
Okay — You’re probably questioning why is Next showing us a 404 page?
Well.. that’s because we haven’t made a page yet!
Let’s create our first component inside pages/index.js
Notice how we don’t need to import React — and how Next picked up routing? Try adding another paragraph — we also have hot module reloading!
Beautiful.
If you view the source of our app — here’s what we should be seeing.
This is Next doing it’s magic. Our React app is server side rendered.
Cool! This is more a introduction to what is server side rendering — why it can be useful — and how to get the ball rolling with Next.
Go through this great Next tutorial to unleash all of it’s powerful features.
Thanks for reading and I hope you learned as much as I did! ❤