This blog is part of a series that I am writing to document my journey of creating a portfolio website from scratch. I highly recommend that you start with the first one which walks you through the whole process of how I managed to convince myself to create a portfolio website.
This particular blog might be a bit longer than the others since I would be getting into the actual nitty-gritties of my development process, the problems that I faced and the thought process behind solving said problems. So I suggest you grab your cup of coffee, sit down and lets get into the meaty stuff (pause).
🌐 Deciding on a framework
While there are a lot of ways to go about developing a website in 2024, I mostly tend towards solutions that are battle-tested and robust. I’ve worked with React, Svelte and Angular in the past, and out of those three I personally prefer working with Svelte and React more. In my opinion, they are easier to work with and more intuitive compared to Angular, but that’s just me.
So, deciding between Svelte and React was tough, mainly because both of them are so good in their own ways. Both of them have amazing DX, good library support and offer out of the box meta-frameworks supporting them. Now, since the current project that I am working on in my company uses SvelteKit, I have had a fair bit of time on my hands to tinker around with it. One thing I wasn’t able to play around with was Next.js 13. I remember hearing its announcement and thinking to myself, “Wow, they are finally getting folder based routing” (while sitting on my high horse since SvelteKit already had that 😌). Anyway, coming back to the task at hand, I was using SvelteKit in my day to day development tasks already, so I thought why not build the portfolio using Next.js 13 that would literally kill two birds with one stone (I don’t condone violence), I would be building my portfolio and simultaneously learn all the cool stuff about this new release. For anyone who is trying to decide which stack/framework you should use for your site, I would highly recommend using the tech you already know, especially, if the work you plan on doing is time bounded. Once you are comfortable with a stack that helps you get things done, you can explore out into the wilderness of the internet and choose any library/or a next-gen framework to build your next project. Or, you could use something that you aren’t familiar with but do keep in mind that it might take longer for you to get things working, so don’t be too harsh on yourself and lose your motivation. Coming back to the task at had, I decided that my weapon of choice was going to be "The React Framework for the Web" a.k.a Next.js.
🏗️ Folder Structure
I followed all the steps that were necessary to get the boiler plate for Next.js up and running. After setting that up the first thing that I wanted to do was to devise a folder structure that would help me organise files and iterate on them quickly once I start developing the site. Believe me when I say, a messy folder structure can really put a dent in your productivity. So, I did just that, a couple of DDG searches (yes, I don’t use google) later I found a structure that aligned with my workflow.
├── ./app
│ ├── (routes)
│ │ ├── blog
│ │ │ ├── not-found.tsx
│ │ │ └── page.tsx
│ │ ├── globals.css
│ │ ├── layout.tsx
│ │ └── page.tsx
│ ├── _components
│ ├── _sections
│ ├── _utilities
│ └── favicon.ico
└── blogs
├── never.md
├── gonna.md
├── give.md
├── you.md
└── up.md
Next.js uses file based routing, if you want to read about it you can check out their docs
So, there are 2 things that you might see in the above structure and be like wtf is that, lets address them.
- Private folders (folders with “_” prefix), essentially do two things, firstly, they help in organising files having similar context, and, secondly, they tell the routing system that the folder along with its contents should not be considered as a part of routing.
- Route groups (folder surrounded with parenthesis”()”), also tell the routing system to remove that folder as part of the route, but allows its contents to still be a part of the routing system.
This seemed really intuitive to me since I liked the idea of my routes being separated from other files, and generally I have a lot of files, so I like to organise stuff w.r.t what they help me achieve.
🛠️ Getting all the tools and libraries
Now, although I had the basic Next.js project running and the folder structure organised, I still had to gather a bunch of tools that would help me be more productive and focus on the key aspects of my site rather than reinventing the wheel. There are a couple of things that I like to setup in a frontend project that help me write bug-free (and by free, I mean fewer tha usual amount of bugs 😛) code.
Following are the things that made my life easier particularly while developing this project:
-
A css framework or a library helps me write css in a better manner than its native implementation, for bigger projects which are timebound I usually would opt for component frameworks like shadcn/ui or Radix which are prebuilt component libraries, but since I wanted this site to be truly mine I went with a minimalist approach and just chose tailwind as my weapon.
-
A linter, for those of you who don’t know, is a program that checks your code and tells you about obvious bugs upfront rather than having to go in the “Test>Find a bug>Fix>Test” loop. It doesn’t guarantee you a bug-free codebase but really helps you identify common mistakes that can be checked via static code analysis and save you a bunch of time. Bugs like using a variable which is not declared (and believe me, this happens more often than you might think) is something a linter can easily catch. So, I used ESLint for this project, which is kind of an industry standard linter for JS/TS based projects.
-
A code formatter, not much to explain here, a code formatter just keeps the code neat and clean (as best as it can, ofc). I chose Prettier for this, which is another industry standard formatter for many languages (don’t quote me on this btw).
-
Since I planned on writing my blogs in markdown files I needed way to parse and show them as HTML inside my blog. I found out that Next.js has an official package which helps in parsing
.mdfiles as markup. So I went ahead and used that, but I needed something more. You know how there is some metadata which is related with each blog, such as the date it was written on, the tags associated with it, the blog description and much more. Now when I was checking about how to work with.mdfiles I got to know that this metadata actually resides inside the.mdfile itself (generally) and is called Front Matter. Okay quick detour, this is how front matter looks like inside a.mdfile.--- title: A blog about how I conquered Russia, JK just JS rants date: 2024-05-18 --- # Your blog headingThe “—-” marks the start and end of the Front matter.
Okay, back to the point, so I found this amazing library called gray-matter which helped me solve this issue of parsing front matter of my markdown files and use it at my convenience.
-
The last thing but definitely not the least, was that I needed a way to animate stuff on my website, because of course its 2024, it needed some ✨Pizzaz✨. There were a couple of options for this too, since the JS ecosystem is vast, but I went ahead with framer motion. I had always wanted to try my hands on it but never got the time to, and this seemed like the perfect opportunity to give it a go.
Setting up the project did take some time, and it would take you some time too, especially if you’re doing it for the first time, but eventually it makes your life wayyyy easier, if done correctly.
👨🏽💻 Time to code
With all these things set-up, it was time to code, and so I did. It won’t make sense for me to go over each and every line of code, explaining why I did, what I did. Instead, if you are really interested, you can check this very project on my github and maybe shoot me an email if you have any specific questions. I’d be glad to answer. In the next blog, we’ll go over the details of how I managed to host this site, so that all the wonderful people on the internet can access it. From buying the domain, to setting up the hosting and finally getting the first version up and running, we’ll cover all the bases. Until then stay motivated, stay curious and keep building! ❤️