Engineering note
Why this portfolio is vanilla JavaScript.
My production work uses React, and the platforms I link to from this site are React applications. So a fair question for any reviewer is: why is the portfolio itself written in plain HTML, CSS, and JavaScript, with no build step?
What this site actually is
It is a one-page marketing site that links to the real product work. There is no routing beyond hash anchors, no shared state between components, no data fetching, and no editorial content that needs templating. The work itself lives on other deployments.
What I would gain from React here
- Component ergonomics — JSX is nicer than imperative DOM building.
- Better authoring for the project card list (currently in
js/projects.js). - A familiar build pipeline (Vite, ESLint, type-checking).
What I would lose
- A build step, a node_modules directory, and a framework runtime shipped to every visitor for a page that does not need any of that.
- The ability to read the entire site in five minutes by opening three files.
- A clearer demonstration that the stack matches the job the page needs to do.
The tradeoff I am still paying
The project-card renderer in js/projects.js is the main
vanilla-JS tradeoff. React would make that list nicer to author, but
the current renderer keeps the page framework-free and still lets each
card expose ownership, product value, and proof points consistently.
When I would migrate
I would move this site to React + Vite the moment it stops being a one-page marketing surface — when case studies live on the same domain, when content is templated from a CMS, or when more than one person is editing it. Until then, the simpler stack is the honest choice.