My previous blog was... ugly. Not only in styling but also in coding. It's a given since it was a project I started on my first year of college. That time, I have almost no experience in building web application that heavily focuses on frontend. I had always been a backend developer, until I realized that my blog was ugly and unoptimized.

I was actually wanting to clean the existing codebase, but it's already "too late". It's already such a mess that I didn't think I had enough the sanity to do. So of course, the best way to fix is to just rebuild everything :D

Let's start with the main component, the base framework itself.

Next.js 13

I started the project back when Next.js 8 just recently released. It had everything that I wanted that time: SSR. It was all because I wanted to pursue "good SEO" practice, and plain CRA didn't suffice. I tried to implement SSR using Express.js but I couldn't. Finding about Next.js was a blessing as it happened to fix my problem in a single night. And ever since, I explored the practices. It come to the point where I had everything I need and all left to do was to style the web app.

I didn't know much aside my part-time experience as React developer, where my senior used styled-components to apply the styles. And I just followed the same method, without knowing the actual purpose of CSS utilities, such as TailwindCSS, or even components like Bootstrap. So in the end, instead of using the classes from Tailwind, I instead wrote every styling in the styled-components component, and it suddenly got very heavy. Looking at it back again, I simply didn't have the sanity to convert everything into proper CSS classes usage, so I just thought to completely rebuild.

Other than that, how I handled the authentication, the upload, and the caching, and SEO, all were off, so it was a no brainer to just rebuild everything. As I looked on how Next.js has been going, I was surprised that it now in the major version 13, and looking at the new features, changelogs, it was the best chance to "update" myself to the current status quo.

So, what did I discover?

`app` directory and React Server Components

This is a beta features as Next.js 13 really wanted to incorporate React 18's Server Components. What is that? I don't know. But it has something to do with how data fetching, caching, and SSR works for web applications that has React as the main frontend framework. Moreover, the new app directory tried to enforce the usage of React Server Components as much as it can, that you'll need "use client"; directive in the beginning of each file to denote that it will be React Client Component.

Another significant difference is the existence of special files, that each has their own purpose on how the layout works, the (suspense) boundaries, and error handling. For example, use layout.{js,jsx,ts,tsx} to build the layout (in which they adopted the "island" concept of Remix.js), use loading.{js,jsx,ts,tsx} to show loading UI, and page.{js,jsx,ts,tsx} for the actual content. There are also lots of configurations, such as caching, metadata generation, and some equivalency of getInitialProps getServerSideProps and other special functions. On personal opinion, although these disambiguate the existing features, it makes it hard as there are now even more granular thing to control and look, rather than "more centralized" configs found in the non-beta version. It took me lots of time to actually "get" how it works, and still doing it even now.

SWC is Fast

So, the other thing is they now have Rust-based compiler, not a Webpack bundler back in Next.js 8, or esbuild in more recent version. Although it's still in beta, I already found myself comfortable of the current performance delivered by SWC. Although my only complain is it still not showing accurate details of the build result for the beta features.

I am very sure that those first load are not zero, and shouldn't be the same. It gives me this weird anxiety on "what if" scenarios, especially on that /post/[id] routes. I hope it will be fixed in near future.

The other thing is it sometimes buggy. Compiling time of below 10ms sounds awesome, but if it repeatedly recompiles where each recompile time takes 1-2ms, then something is definitely wrong. It needs to crash first then recover.

It's weird, but eh, still miles better than the previous DX.

After Thoughts

There are lots of things to explore, not only from the features provided by the framework, but from myself as the "user". Sometimes the SEO failed miserably, sometimes it shows nothing, sometimes the revalidation doesn't work, and cache control. I'd want to see the actual potential of this framework in my hand, but before that I want to properly explore React in it's purity. I believe most of the performance issues come from unnecessary re-render or unwanted re-renders that occasionally happens. The current dashboard implementation and editor for this blog also suffers from how Quill.js operates.

It might gonna take a while until I can actually apply flashy animations to the "visitor" side of this blog. But eh, at least now I have my own space where I can write what I want, with tools that I built by myself. This journey is indeed full of headache, but as it's something that I want to use, then it's a given that I'll have most of fun when doing it.

I'll cover on how I re-implemented the "visitor" side of this blog, and the admin dashboard on later post.

But if you're interested, I already made this blog repository public over Github

Loading...

There will be awesome contents here

Log 0x17: Next.js 13