Server-Side Only React with Next, Hacker News

You know that feeling you get sometimes that the web is broken?

You visit a seemingly simple website with little or no interactivity, yet somehow it sends you 2 MB of JavaScript to digest. You’re half way down the article that you’re reading and suddenly: client-side rendering kicks in, resets everything. You try to find your way back but the page is now janking around. Your mobile device is brought to a crawl and behaving like it’s taking its last dying breath. You end up rage quitting and screaming: THE WEB IS BROKEN, as your colleagues look worryingly in your direction.

In spite of all this, when I re-built my personal website (for the n: th time) I made the decision to use React and

Next ! Am I a hypocrite? (you decide for yourself).

Why Next React for a Blog?

Even if I did not intend on using React on the client-side, I still wanted to use it on the server for the following reasons:

I wanted to write blog posts in Markdown, so I needed something to convert Markdown to HTML.

MDX (Markdown JSX) enabled me to transform Markdown into custom React Components.

React aside, I really like organizing code around the component mental model. I was not keen on going back to string based templates and CSS preprocessors (looking back at my old Gulp / Grunt files can trigger nightmares).

There’s a bunch of great JavaScript libraries I want to use server side, for (date-formatting

), code syntax highlighting etc. Having a Node.js compatible application framework allows me to do that.

• Next has a truly great developer experience that allows me to leverage what I already know about React and is highly configurable. Simply drop js and md files into a pages / and you’re ready to go.

Other options considered?

I did try Gatsby

and it’s great, but I felt it was too much of a black box, and I have no idea what’s going on under the hood. I also tried rolling my own minimal setup with MDX and Reacts renderToString , but I found myself simply re-inventing Next. In the past I've also tried Jekyll and Hugo . I found that both work great out of the box, but were hard to customize as I'm not very fluent in either Ruby or Go.

The other option I did consider was the plain vanilla ice-cream flavor. Simple, no build step, no Markdown, only plain HTML, JS and CSS files. This was tempting. I usually opt for this if the project allows it. The downside being that as soon as you want to do anything fancy like component re-use or refactoring it quickly gets messy and hard to maintain.

What's Next?

Next is a multi-purpose React application framework, but for my purposes it's mainly a static site generation tool (comparable to Jekyll or Gatsby). It takes an input (Markdown in my case) and spits out a bunch of HTML files that are later deployed on a CDN. No server-side runtime required.

is great for universal websites

Websites built with Next are isomorphic / universal out of the box. That means that most of the JavaScript you write is run on the server, but also automatically bundled, tree-shaken, split into small modules and shipped to the client. This allows you to seamlessly pre-render your JavaScript application on the server, and add interactivity on the client without any extra configuration.

The Elephant In the Room: kB of JavaScript

So what’s the problem? Ladies and Gentlemen, this is a blog. It’s a one way communication channel with little or no interactivity. Most people read one article and then leave, and that’s OK.

For the tiny amount of interactivity that this site offers there is simply no way I could justify sending you 823 kb of JavaScript that simply “re-renders” the page on the client.

() Part 2: Killing the Elephant

Disclaimer: No animals were harmed during this experiment

What I like about Next is that you can heavily customize it. I’ve done so to an extent that there’s no notion of the Next runtime or traces of it in the statically generated HTML.

What I’ve done here is to remove all client-side JavaScript and extra markup that Next outputs. This is how:

Create a Custom Head Component

One option is to just use a normal HTML element here. However, extending the Next Head component will allow us to inject a from any component or page, this is useful.

}