Philosophy

Almost everyone shows components in a single framework. Here every piece lives in both: React and Vue 3, both with TypeScript. It isn't duplicated work for its own sake, it's to separate what matters from what changes with the tool.

A component is, deep down, an API with props coming in, events going out and an accessible behavior to honor. That belongs to no framework. React and Vue are two ways of expressing the same idea, and seeing them side by side makes clear what's essence and what's syntax. That's why each piece takes only what its props table lists, in React and in Vue.

Along the way it shows I can move between stacks and migrate from one to the other without getting lost, because the component design leads and the tool is secondary.

Showing components in two frameworks at once needs a place where React and Vue can live on the same page. That's exactly what Astro does with its islands architecture.

Each interactive component is an island that hydrates on its own. The rest of the page is static HTML, so the JavaScript only loads where it's needed and the content stays fast and good for SEO.

Astro here is the minimum glue: routing, the HTML skeleton and the global CSS. It doesn't impose its way of doing things, it lets each island belong to whichever framework fits.

I come from markup and styling, and CSS is where I move most comfortably. That's why there's no Tailwind or SCSS here, native CSS only, which now covers everything that used to need an extra tool.

Nesting, has(), container queries, color-mix(), light-dark(), scroll-driven animations. The platform has caught up, and mastering it properly is worth more than hiding it behind a layer of utilities.

The entire theming of this portfolio comes out of custom properties and light-dark(), without a single line of JavaScript for the colors. It's the proof that I understand the platform, not just a framework sitting on top of it.

Building everything from scratch isn't a fixed rule. In a real product, the right call is often to use a headless library and focus on the business.

The decision depends on the context, on the time available, on whether the team wants to invest in custom and on how much control you need over the detail. More than a single answer, there's judgment.

What doesn't change is that knowing how to use a library is a commodity. Understanding what it solves inside (focus, keyboard, accessibility) is how you decide with a clear head. Here I build that part myself so it shows.

Building a complex component used to cost a lot of time. With AI-assisted development that cost drops fast, and what used to take hours now takes a fraction of that.

The nuance matters. AI generates code, not judgment. If you don't know the DOM, accessibility or how a focus-trap works, you can't tell whether what it gives you is right or whether it breaks keyboard navigation without anyone noticing. The fundamentals are what let you guide it and check its work.

That's why the fundamentals are worth more now, not less. The value has moved from writing the code to knowing what's correct. This playground is just that, the foundation put to work.