After working for a few years in DevOps, I had some ideas that I wanted to put in code and try it out. I could have built just a library or a backend api and played around with it. But I wanted to experience a full development cycle from an idea to production.
I wanted to be able to build my custom sites for my projects, design something decent-looking, and document the journey.
Now the next thing that every engineer gets too excited for but then becomes a victim of decision fatigue and eventually starts losing motivation: Tech Stack selection!
Every language or framework has some pros and cons. There is always a trade-off. Since I am new to frontend development, I stuck to one rule:
“Pick one that's most established.”
After quick research, I picked the framework which had the most learning resources, tutorials and references: React! Pure JS/HTML/CSS would have been fun too, but honestly looking at the current landscape of frontend, React was an easy choice. That led me to the Next.js framework (especially after I enjoyed Vercel's UI), another framework built on top of React (how fun!), but slightly more opinionated for good reasons.
I had read about Svelte (another web development framework) too but — as I said earlier — didn't want to fall into decision fatigue. So I just picked one. Maybe I will try Svelte in the future in another project to understand the pros and cons of different frameworks.
Now where and how do I start? Learning a new tech stack usually has a steep learning curve. In my opinion, tutorials and courses can be a boring slog, but turns out the official Next.js guides were a good entry point.
- Quick intro to React
- React Foundations
- Entry project to learn Next.js
- App Router
Once these foundational courses were done, I started building this portfolio site from scratch. It is simple, keeps me focused on learning frontend fundamentals.
During development I noticed I was mostly focused on 3 concepts:
App Router and reusable components
I was pleasantly surprised by the app router feature. It was so intuitive and great for organizing my pages. Then creating reusable components (not just the UI elements) was fun! It helped me a lot with customizing and reusing my style with ease. If I find myself repeating something more than 3 times, I was leaning towards making it a reusable component. It also helped me ensure the consistency is kept in all places.
Typography and spacing
I was amazed by how just simple typography and spacing makes a huge difference in how a page feels. If you notice this site itself, it doesn't use any fancy UI or animations library. With just one accent color and solid typography, I could build a decent-looking site. Although I have to admit, setting up the styling conventions was the most difficult part of designing the site. A lot of trial and error to see how it looks and feels. I built a typography reference for myself to keep it consistent. And I still keep tweaking as I keep developing.
Styling with globals.css and Tailwind
It was crucial to define the basic color theme utilities. Just simple variations around black and white with one accent color for a bit of flair.
/* globals.css */
:root {
--background: #f7f6f3; /* the background of this page */
--foreground: #18181b; /* text color on top */
--muted: #71717a; /* for extra variant of text */
--accent: #d97706; /* for key highlights and links */
--surface: #efede9; /* the background of this code block */
}I was a bit intimidated by Tailwind v4 utilities at the beginning but then as I kept using it more, it started to make sense. I still can't style an element from memory, but now I know where to look and what to reach for.
Key takeaways, especially coming from DevOps background:
- Writing the CSS utilities independently in all elements.
- I was always worried if I missed some utilities for some elements. And there is no proper validator for checking this for the site except to check it yourself visually on the rendered site.
- Not a big fan of this blindsided approach. In DevOps, I could test everything before deployment, that builds confidence in your deployment, no matter the size of the project.
- I suppose you could always use components for every little thing to keep it consistent and clean. But it makes sense if you have a large project. For this scale, not able to have a framework for this was strange. Maybe there is something, if I come across this I would update my view.
- Not able to write (unit-)tests.
- For library functions in TypScript, I could write tests but for the UI pages, it is difficult.
- There are ways to write the tests with Playwright and other tools, but they are slow, and expensive on resources.
- I miss being able to write unit tests.
Keeping it simple — building only what the site actually needed — is what got me here. I learned a new stack, hit the rough edges that come with frontend, and ended up with a working site of my own design. That's enough for the intro; whatever comes next will be its own post.