Intro

As I've mentioned in some other places around this site, this place is my first attempt at a usable NextJS website. It has a home page, it has a blog, and the fact either work is a testament to my commitment to yell at TypeScript until my errors make sense.

Most people might write a blog post how-to guide on how they made their site, this is more of a developer trauma dump.

NextJS and the /app folder conundrum

For me, the best way to learn is to tinker, and to start tinkering you first need to install what you'll be tinkering with. Installing NextJS is pretty simple, the first hurdle however are the installation options:

• Would you like to use the experimental /app folder?
• Would you like to use TypeScript?

So we run our install command:

npx create-next-app@latest

And we get our options:

What is your project named? my-app
Would you like to use TypeScript with this project? No / Yes
Would you like to use ESLint with this project? No / Yes
Would you like to use Tailwind CSS with this project? No / Yes
Would you like to use `src/` directory with this project? No / Yes
Would you like to use experimental app/ directory with this project? No / Yes
What import alias would you like configured? @/*

Now I primarily use Laravel, an app folder sounds lovely! But how experimental are we talking? Am I going to learn a system that might not make it to the stable branch or should I learn their current Page Router? (It turns out now that app/ was a good call, of course, and has now become the default when installing). And then we come to TypeScript, I've used type safe languages before, so I presumed it wouldn't be so bad and endeavoured to continue. Upon installation I was presented with a pre-created folder structure and a demo page, let the tinkering commence!

Blogging with MDX

As I knew I would rarely be adding new posts, I wanted to prioritise speed of viewing over speed of editing, so I decided to go with markdown files that could be interpreted into HTML through MDX. I'd heard of frontmatter before to allow adding useful metadata to my files, and thus thought this a good direction to go in.

After cobbling together a home page using some guides I moved onto the blog system. Some guides covered the basics well, some had far too many features, so I learned from both and decided to go from scratch with a couple of code samples.

The majority of these samples came from this guide by Max Leiter to build the slug-powered part to ensure the static pages were generated properly as well as their suggestion to use Bright for code highlighting, a brilliant solution! If you're looking for a guide on setting up a blog I would wholeheartedly recommend as I'd rather you get the code from the source than me just copy-paste it here, I'm not a monster!

Much like theirs, each post would be an individual .md file which would be loaded into the system with frontmatter and its slug pulled out to be the URL of it's dedicated static page, seemed simple enough! Which of course meant it was time for my first pitfall..

TypeScript, the multifarious multi-headed demonic form of my displeasure

Ok maybe the title is a TAD melodramatic, but I can explain. In php if I want to loop through elements in an array where I know the layout of each element and access a wildcard attribute that's fine, it's simple, just a quick

// Merely an example, this isn't floating round in production don't worry
foreach($elements as $element) {
    echo $element->$wildcardAttr;
}

Easy, now if I want to do this in TypeScript? Well that's the kicker isn't it? Of course it complains because if you're thinking typesafe you really should have refactored your code in a way you can ensure the integrity of your data, and you can't really argue with it because of course, it's right. TypeScript does a good job in making you code in a much more structured, reliable way, but it also makes every job feel like it takes 3 times as long. It's like TypeScript is your pair programmer, making you rethink how you're coding as you're coding it. But after fighting with learning the types your functions need to take in, building the structs for your arguments to work and resisting using the "any" keyword everywhere, you end up with a system that should hopefully stand the tests of time.

Learning a new system is one thing, but learning a new system while also rewiring how your brain approaches code is another beast entirely.

Conclusion

I know this blog post comes off as a rant (don't even get me started on completely forgetting about the virtual DOM), merely voicing the frustrations I felt along this journey. There were many plus sides too, NextJS is very intuitive, the pages load incredibly fast, NextJS's Image component makes optimising images a doddle and the same can be said for Tailwind. Overall it was well worth doing and I can't wait to delve into it again and see what I can make!