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 small static marketing site: a homepage plus same-domain case-study and notes pages that all work as plain files on GitHub Pages. There is no shared state between components, no data fetching, and no editorial content that needs templating. The product applications themselves live 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
The case studies already moved onto this domain, and static pages handled that without needing a framework. I would move this site to React + Vite when that stops being true — when content is templated from a CMS, when pages need shared client state, or when more than one person is editing the site. Until then, the simpler stack is the honest choice.