milku.dev
Published at: 2025-08-21
Last Modified: 2025-08-23
Introduction
A sleek, performance-focused personal portfolio website designed to showcase my projects and technical skills. Built with Astro for exceptional speed and TailwindCSS for pixel-perfect styling, this site combines coding aesthetics with elegant design. The architecture leverages Astro’s content collections for managing project portfolios. With features like dynamic project cards, markdown rendering with syntax highlighting, and animated UI elements, milku.dev serves as both a professional portfolio and a practical demonstration of modern web development techniques.
Technologies used
milku.dev is a static website consisting of modern web technologies.
Frontend
- Astro
- Markdown
- TailwindCSS
- Astro Icon & Iconify
- Day.js
Backend / Server
Core Inspiration
This project was developed to showcase my works in the past and serves as my professional portfolio. It took me a year to start this project since I bought the domain milku.dev.
While planning for this website, two ideas has been in my mind ever since I bought the domain. I want the website to showcase me and what I do, and showcase my projects, but in an unusual way. I’ve seen blogs as a common way for personal developer porfolios so I thought, why not make my own blogs, but featuring my works as a way to showcase them deeper.
Technical Concepts
It is similar to other portfolio webpages but this time I chose to use Astro, A JavaScript framework for content-driven websites. Behind the Astro curtain, the articles are done in Markdown while the styling are done with Tailwind.
Through this project, I managed to fully understand the differences between CSR, SSR, and SSG.
Developer, What do these three letters mean?
Essentially, these are how your web applications are rendered/compiled.
CSR or Client Side Rendering is where your content is being rendered on the client/browser through DOM Manipulation. What happens is your browser fetches the site and it would get a blank index.html and a large JS file that would manipulate the DOM through the HTML interfaces and build the website from there.
This approach is very common in Single Page Applications (SPAs) and libraries like React. This approach also affects the page’s SEO as crawlers don’t have static content they could work with.
SSR or Server-side Rendering is where the content is being rendered on demand. Basically, the page requested by the browser will be rendered only as the request hits the server. This would return HTML with the requested content leading to better client performance since there’s no Client Side processing unlike CSR. This approach is very common to PHP.
SSG or Server-side Generation on the other hand is where the content is already rendered beforehand before it hits your browser. Just like this website, this page has been already rendered long ago before your browser requested it. Pair it with a CDN cache and it would defeat SSR in terms of performance.
Okay, so should I always go SSG then?
Not Quite. Those three have use cases based on the website you are creating. CSR is useful when you need JavaScript to populate the information, SSR is useful when you have to have up-to-date information like CSR but with server handling most of the work, and SSG is useful if the information does not update that much.
In the case of this website, I went with Server-side Generation since most of the content here are words, and it won’t be updated in a while. The site would be low maintenance too since it is just a static webpage and lastly, easier deployment to like Github Pages.
The First Commit
The first commit has been committed to main branch at 2025-08-09
- Commit 9f3ad07 -
bootstrap project
This commit consists of .vscode files for Dockerized Bun Dev Container environment, as well as a minimal starter files for Astro.
Beyond that, I also have several tabs of Astro opened learning how this platform works. I was also quite intrigued by how simple routing works here. It is similar to the way Next.js does it.
The root folder will be defined starting from /src/pages all the way down. There’s also some special file names like [id].astro in cases of dynamic routes like this very page you are right now.
Developer’s Design Intention
Just like with my other projects, I’ve initially did my mockup in Excalidraw, then to Figma.
This website design is quite simple, with a beige like color and a near-black grayish secondary color. One highlight of this design is the URL-like website title in the navigation bar. Every page present in the website has a guarantee to have this navigation bar because of its BasePageLayout that an Astro website can have.
The way the whole website is plotted is there is a Base layout that contains the <head> tags, Navigation Bar, as well as the footer. This file, BasePageLayout.astro, has required props on top of its initial design it come with.
// BasePageLayout.astro
interface Props {
navSlug: string;
pageTitle: string;
hasPathError?: boolean;
}
navSlug refers to the actual text you can see in the Navigation bar. It is passed into a <Header> custom component that forms that black bar on it. pageTitle is passed into the title tag in the <head> of the HTML. hasPathError is an optional boolean that is passed again into the <Header> component that turns the text into strikethrough and colored into red.
Moving on to the Markdown pages, These pages are using strong yellow-like colors that contrasts against the beige background. It also has an elevated-like shadow that is similar to the ProjectCard component.
The Markdown pages are styled using Tailwind and the code blocks are styled using the plugin rehype-prism with the theme prism-duotone-space. This theme matches the yellow-orangey look here in the markdown page.
Personally, the whole look of the design might be too simple but I am satisfied with it. It is soft to your eyes, not as too bright as a pure light-mode page, not as too dark as a pure dark-mode page.
The Development Process
From the first commit until the latest commit, the process has been smooth. However, every projects has its hiccups and features planned but never shipped.
Though these features might be implemented in the future, here is the list of features I’ve cut out (as of 2025-08-21) for the website’s initial deployment:
- Vue-based Image Carousel of the Project
- Markdown Pages Table of Contents
- Github Stars counter
ProjectPreviewthat contains the Image Carousel- Full Page scrolling for
/indexpage - Search and sort for
/projects
In case I managed to implement them in the future, I will update the article and strikethrough them down and a short section explaining how and why I implemented it again.
As for the reasoning why I cut those out, some of them (targeting design) don’t really have a purposeful purpose or is difficult to implement at the moment. Good luck, future me 🫡
Afterword(?)
At the time of writing this article, the latest commit (Commit 83bf213 - added published date to projectCard) has been committed to main at 2025-08-20. As of 2025-08-21, I haven’t finished this website and this entire article might be updated too as I finish this website. Though its been weeks since I’ve started this project and finally by domain is getting its intended use.
I am quite satisfied with the website’s current development progress. I hope that this website will help me land a job.
Which would result in progress? Day One or One Day?