Hello

Took some time to set up this blog properly! I first considered just writing my blog posts as normal nextjs page files, but that would probably be a bit cumbersome. So the obvious next answer was Markdown, but I also wanted to be able to use react components to be able to make more interactive blog articles as well, so MDX it would be. At the same time, I wanted to make sure as much as possible is rendered statically. I still keep my .mdx files in my repo and don't mind deploying a new version of my app whenever I want to update or make a new post.

After a bit of banging my head against dynamic imports and getting strange errors, MDXRemote came to the rescue. The wrapper also is very convenient to put on tailwind utility classes on each rendered element. For example, this whole article container is a grid layout in order to do some fancier layouting. I probably want to add support for fancy footnotes in the future too!

Here is an example react component:

Revolutionary, right.

So, what's the deal with Next.js 13?

If you're familliar with how previous versions Next and other server-side react frameworks do their thing, you know there's two steps involved: the actual server side rendering which sends HTML to the client, and then the hydration step, which rerenders the page when all the javascript has been downloaded and parsed. This rerendering is neccesary to make the site interactable and "dynamic" in the React way. This solves the problem of getting a blank page before the js has loaded, but it still needs to send all the javascript needed to render the site, even the parts that doesn't need to be rerendered.

Additionally, fetching data was mostly done client side, so if your page relied on a lot of API calls, even if you didn't show a completely blank page it may not have been far from it until your js had loaded, and your api responded.

Version 13 of Next has worked hard to solve both of these issues. Some of this is bringing in new technical innovations, like integrating react server components. But it's also how the framework now encourages a SSR first approach that I think is one of the bigger changes. Data fetching on the server is trivially easy with serverside async components. Strong cache options for their own fetch-wrapper. The fact that you can use server code directly inside of components is very big for quickly prototyping something without having to write an API-route to fetch the data properly, while still being easy to refactor into actual API routes.

And no more rerendering of non-reactive components. For example, in Next 12, even though most of the content on this page is completely static, next would still send the javascript to hydrate all of it. Now, the only javascript that is sent is the part needed to hydrate the simple increment component up above. Atleast as far as I understand it. And that feels pretty magical to me, to be able to do all of my templating in JSX but still get the benefit of only having isolated islands of fully reactive components.

And as I was writing this, I also tried deploying just to see how it would perform in production mode. Now I have no idea if Vercel is a good host for larger projects, but for small sites like this it's very nice to have such an easy way to deploy. The total size of this page came down to about half a megabyte, with half ot that being JS. Which, may sound like a lot for a simple page like this. But this is not aiming to be a minimalist blog and I plan to put React to good use in other articles.