makley.com
This portfolio — Astro, TypeScript and layered architecture, with virtually zero client-side JavaScript.
- My role
- Design & Development
- Context
- Personal project
- Category
- Performance & DevOps
Portfolio built from scratch with Astro and TypeScript, using DDD, SOLID principles and Atomic Design. No UI framework ships to the browser: all interactivity is handled by plain TypeScript islands measured in kilobytes.
Results
- 0 KB
- of UI framework No React, Vue or Svelte runtime shipped to the browser
- WCAG AA
- contrast Verified in both light and dark themes
- 100%
- static Pre-rendered at build time, served straight from the CDN
The problem
Most developer portfolios fall into one of two extremes: either they look great and ship hundreds of kilobytes of JavaScript to render static text, or they're fast and convey no design care at all. A portfolio is itself a work sample — if it contradicts what the resume claims about performance and accessibility, it works against its own owner.
The solution
Astro generates static HTML, with interactivity implemented in plain TypeScript islands — no React, no hydration. Content is modeled as the actual domain (entities, value objects and repositories), validated by schemas at build time, with components organized under Atomic Design. Page transitions use the browser's native View Transitions API, with no client-side router.
Key challenges
-
Shipping filters, a command palette, theme switching and scroll animations while keeping the JavaScript sent to the client down to a handful of kilobytes.
-
Applying DDD to a static site without tipping into over-abstraction — every layer has to earn its own existence.
-
Making sure no animation hurts accessibility, respecting prefers-reduced-motion and keeping content readable with JavaScript disabled.
-
Supporting both light and dark themes with WCAG-compliant contrast in each, without duplicating stylesheets.
Technologies used
- Astro
- TypeScript
- Modern CSS
- Atomic Design
- DDD
- Schema.org
- View Transitions API
Architecture decisions
The code is split into four layers, with dependencies always pointing inward: domain
(entities and rules, no framework dependency), application (use cases), infrastructure
(adapters over Astro’s Content Collections) and presentation (components under Atomic
Design).
In practice, that means swapping the content source — from local files to a CMS or an API — takes writing one new adapter and nothing else. No use case, page or component has to change.
Performance as a project constraint
The rule that guided development was simple: no feature justifies shipping a UI framework to the browser. Project filters, the command palette and theme switching are all handled with plain TypeScript, event delegation and CSS — which keeps client-side execution cost close to zero.