Shaun Rashid: UI Engineer and Architect

My Introduction to Next.js

I recently tried out Next.js React framework.

I started by going through the basic tutorial on their website. It is a well-written, easy to follow tutorial that enabled me to get the basics figured out quickly.

Once I completed the tutorial, I decided to migrate a side project of mine from an Eleventy-based static site to one using Next and its app router paradigm.

Below are some of my thoughts on my limited time using Next:

Routing

I really enjoyed how easy it was to set up pages. You can structure your project any way you like and use a page.js file in a folder to make a publicly-accessible route.

Components

Creating components was straight-forward but I did stumble with the return statements when I started to nest components, especially when I wanted to loop through multiple instances.

The fact that you can only return a single root node in a component made me feel like I was nesting components deeper than I should need to. However, I may just need to explore more examples to set up better patterns in my code.

I ended scribbling various component patterns on paper to work within the framework in addition to the overall HTML structure. That's not a bad thing, but when I compare it to working with web components and being able to add the custom element tag in my markup, it felt like added overhead.

Styling

I'm a "purist" when it comes to CSS.

When we got CSS custom properties, I felt like the only need I had for using a CSS pre-processor like Sass or LESS was so that I could nest my selectors. I love writing CSS the way it was intended, cascade and all.

As I went through the Next tutorial and it got to styling using CSS modules, I knew I wasn't going to like it.

The jury is still out for me when it comes to styling in Next or other frameworks. Styling in frameworks isn't as bad as I feel it is but I have a difficult time working with it as I have differences in opinion with regards to the approach.

At least with Next, I am still able to include external CSS files and write my CSS as I so choose.

Static Site Generation

One of the preconceived notions that I had about React-based frameworks is that they all did client-side rendering by default. It's one of the reasons I've avoided them for so long.

I was pleasantly surprised that Next did server-side rendering by default and that you can choose to render pages either way.

I also like the fact that you can produce a static website and deploy that to a web server. For the Tracken Kraken site, I generated the static site and deployed it to an Amazon S3 bucket that is connected to a Cloudfront instance.

The major drawback for me so far is all of the extra scripts being loaded on the page even though my static site had no client-side Javascript.

While not an apples-to-apples comparison, the static site generated by Next was 80kb heavier in size and took 400ms longer to load than the site generated through Eleventy.

I'm sure there are ways to optimize/eliminate this but it was a disappointing out-of-the-box experience for me.

Final Thoughts

In general, I really enjoyed building the site using Next. It is a very powerful tool for building web applications and the developer workflow feels pretty good.

I still haven't gotten used to writing HTML within Javascript (using className instead of class in my markup drives me nuts) but that issue is not limited to Next.

With the current state of my side project, I think it's way more advanced than what I need but I'm curious to see if that might change as I start pulling more data or adding features that might require lazy-loading content or the number of static pages I need to generate would lead me to dynamically render some parts of the site.

I would recommend considering Next if you need a framework to build a web application and I'm looking forward to playing around with it some more.

Return to Homepage