I've had many attempts in creating a blog, starting from using the old school BlogSpot, into writing my own simple blog using Express.js + EJS (which still available on aniharuka.herokuapp.com), and several attempts on using React.js

I'm astounded by how cool Virtual DOM is, and while people said React is hard for beginners, I've been deeply hooked into it and just continuing my journey here. I am hugely interested in Vue.js though, but that would be on another day, or another subdomain of this website.

The thing that's hard about React.js is the fact that it's Client-side rendered. And everything happened inside the <body> tag. You can't tinker with anything outside, like the <head> tag.

And so there comes the Server-Side Rendering (SSR) terminology. Which basically enables React app to have the <head> tag all the necessary information, like <title> and <meta> tags. But with the common configuration around the internet which uses Express.js as the back-end, things don't get any simpler.

Then there comes Next.js. Basically the solution of SSR the easy way.

Why SSR?

Most React developers focuses on building slick and cool user interface at the beginning, then extending capabilities into asynchronous data fetching, state management, and many else.

But once they feel happy with how things looks, it's time to actually turn from 'develop' into 'production'. Talking about React web application, we want our app to be readable, accessible, and also shareable.

Shareable is one important aspect to make our app looks interesting. And sometimes it includes the searchability (yes, it's a word).

One of the most important aspect is how you applied Search Engine Optimization (SEO) for your content. Nowadays, anything in the internet that can be opened by browser is called document, and search engine crawlers (like Googlebot) often looks at the meta information that lies on the <head> tags, like <meta>, <link>, and <title> tags.

The title of your document, and all the necessary information for good representation on social medias are defined by the stuffs inside <head> tag. And this is beyond the reach of the classic React app.

To gain control over it, one must directly inject data into the <head> tag on every request, then serve the React app on the <body>. This is what we often call as 'Server-side Rendering', as we render the data on the server side.

There is also another method which is to generate static pages, but it's outside this post main topic.

Next.js mainly known for it's simplicity on creating SSR React App, while also able to serve statically generated pages. Which is why that this could be the savior for any React developer who need quick setup for the ability of tinkering with the <head>, or even more!

Next.js for blogs

The ability to actually define the appropriate meta tags for each documents,or pages is the main attraction for Next.js. But it's also able to define routes for RESTful API, so with proper configuration, you only need Next.js as the only framework for both back end and front end.

Your routes are defined as a .tsx | .jsx file inside the /pages directory of your root source app. Adding a folder means adding route, and static routes are defined just like how you name your file.

Dynamic routes are supported through giving square brackets on your file name, like [link].tsx. This will define that the route is a dynamic route that accepts any valid string and will produce query string (as dictionary) with "link" as the key.

The rest are stuffs like dealing with data fetching, which can affect how your pages treated as. For example, adding a function 'getServerSideProps' will turn your page into SSR page, while 'getStaticProps' and 'getStaticPaths' will turn your page into statically generated page on build.

The functions with 'props' in it acts as the function that will return the props for your React component, while 'getStaticPaths' will tell the available paths that can be generated statically on build. The data that returned by 'getStaticPaths' also used by 'getStaticProps' to fetch the corresponding data on each available path. This usually used together with database (SQL or NoSQL) as the main source of data.

Where to go?

For the basic quick setup, the official documentation is already good enough for starting. As for myself, it was a collective experience from visiting many Medium posts, stackoverflow, and GitHub issues.

I'm planning to cover what I did on setting this blog, but let that rest for the future posts.

That's it. See ya!

Migration to Next.js