I spent weeks migrating my site's interactive ASCII portrait from P5.js to React. The result is a 725-line React component with custom GLSL shaders, Three.js instanced meshes, and physics-based particle effects — running inside an Astro static site. The detour taught me more about building for the web than any tutorial could have.
### The P5.js ProblemP5.js is great at drawing. It's terrible at being part of a website.
My interactive ASCII portrait was a self-contained sketch. It fetched a 265KB HTML file of colored spans, parsed them into a grid, and rendered them on canvas with wave effects. Beautiful in isolation. But it existed in its own universe — no awareness of the page layout, no easy way to share state, no lifecycle management beyond `setup()` and `draw()`. When I wanted to add a gallery of homepage concepts — different layouts users could toggle between — P5.js had nothing to offer. I was hand-wiring DOM manipulation alongside canvas rendering, managing state in global variables, and praying that the timing of async fetches wouldn't break the draw loop. It felt like duct-taping a jet engine to a bicycle. ### What React Actually SolvedComponents aren't just reusable UI — they're a way of thinking about state.
The migration started as an experiment. I wrapped my ASCII canvas in a React component, expecting to spend most of my time fighting the framework. Instead, something clicked. React doesn't just give you components. It gives you a **mental model** for how data flows through your application. The ASCII grid becomes state. Wave effects become side effects managed by `useEffect`. User clicks become events that update state, which triggers re-renders, which update the canvas. Every piece has a clear home. Here's what changed concretely:| Capability | Before (P5.js) | After (React) |
|---|---|---|
| State management | Scattered global variables | Wave positions, gradients, dimensions — all in React state with useRef and useState |
| Lifecycle control | Orphaned animation loops when navigating away | useEffect handles setup and teardown cleanly |
| Composition | One monolithic sketch | The portrait became a component I could drop into any layout with a variant prop |
| Visual quality | Canvas 2D at 60fps | WebGL instanced meshes with custom GLSL shaders, bloom postprocessing, additive blending |
React Three Fiber turned what would have been months of raw WebGL into a week of component composition.
Here's where the React ecosystem really showed its value. I didn't just port the P5.js sketch — I rebuilt it on a fundamentally different rendering stack:| Layer | Technology | What It Does |
|---|---|---|
| Rendering | React Three Fiber | Declarative Three.js — the 3D scene is a React component tree |
| Geometry | Three.js InstancedMesh | 6,600+ ASCII characters as GPU-instanced quads — one draw call |
| Shading | Custom GLSL | Vertex shader positions glyphs from a texture atlas; fragment shader handles wave color boosts, shimmer modes, and sparkle effects |
| Postprocessing | @react-three/postprocessing | Bloom filter gives the cyberpunk neon glow |
| Animation | useFrame hook | 60fps animation loop with scatter/reform cycles, shockwaves on click, mouse gravity |
React's learning curve is real, but it's the right kind of hard.
I'm not going to pretend this was frictionless. React's model requires you to think differently about rendering. You can't just mutate a variable and expect the screen to update. The rules around hooks — call order, dependency arrays, stale closures — tripped me up more than once. But here's the thing: every time I hit a wall, the error message or the linter told me *why*. React's constraints aren't arbitrary. They exist because the framework is solving real problems — how to efficiently update the DOM, how to avoid memory leaks, how to keep UI consistent with data. Compare that to debugging a P5.js sketch where the draw loop runs at 60fps and your wave effect glitches because you modified the array while iterating it. No framework to catch that. Just you and `console.log`. ### Why the Site Runs on Astro, Not ReactReact is the right tool for interactive components. Astro is the right tool for a static site.
Here's the twist in the story. After building this React component and falling in love with the mental model, I didn't go all-in on a React framework like Next.js. The site runs on **Astro**. Why? Because a personal website is mostly static content. Blog articles are Markdown files with frontmatter. The about page is HTML with CSS. The project cards are a data file rendered at build time. React would be overkill for 90% of the site — shipping a JavaScript runtime so the browser can render a paragraph of text. Astro's architecture solves this elegantly: **zero JavaScript by default, with opt-in interactivity**. The blog pages, about page, contact page — they ship as pure HTML and CSS. No framework runtime. No hydration overhead. Fast. But when I need interactivity — the ASCII portrait, the prototype gallery — Astro's island architecture lets me drop in a React component with `client:load`:<!-- src/pages/index.astro -->
<ParticleWaves variant="shimmer-cascade" client:load />| Page | JavaScript Shipped | Framework |
|---|---|---|
| Homepage | ~180KB (React + Three.js + shaders) | React island via Astro |
| Blog articles | 0KB | Pure HTML/CSS |
| About, Contact, Projects | 0KB | Pure HTML/CSS |
| Prototype gallery | ~180KB per prototype | React islands |
Claude Code skills turn "I want that pattern" into production CSS in one prompt.
Here's something I didn't expect: AI design tools have become part of my workflow. Specifically, a Claude Code skill called [ui-ux-pro-max](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) that acts like having a design system consultant sitting next to you. The way it works: you find a component you like — say, a card with a grid-ellipsis dot pattern from a shadcn example site — and you feed it to the skill. It hands you back production-ready code with the component, CSS, dependencies, and implementation guidelines. Then you adapt it. I used this workflow to upgrade the article cards on my [/dev-thoughts](/dev-thoughts/) page. The skill generated a `GridPatternCard` component with an SVG dot-grid background, Framer Motion entrance animations, and a gradient overlay. My site doesn't use Tailwind or shadcn — it's Astro with hand-written CSS and a cyberpunk palette. So instead of dropping the component in verbatim, I extracted the pattern:| Step | Action | Detail |
|---|---|---|
| 1 | Took the SVG grid pattern | From the component's Tailwind config (800x800 viewBox, rectangles for grid lines, circles at intersections) |
| 2 | Adapted the colors | Swapped white strokes for cyan (hsla(180,100%,50%,1)) and white dots for magenta (hsla(300,100%,50%,1)) |
| 3 | Encoded as CSS custom property | --grid-pattern-cyber layered under a dark gradient overlay |
| 4 | Applied to existing cards | No new components, no framework changes, just a CSS variable swap |
Learn React. Ship Astro. Use each where it belongs.
If I were rebuilding this site from scratch, I wouldn't skip the React phase. That exploration taught me component thinking, state management patterns, and the value of declarative rendering. Those lessons inform how I build everything now — even the parts that don't use React. But I also wouldn't build the whole site in React. The right answer turned out to be both:| What I Need | Tool | Why |
|---|---|---|
| Interactive 3D portraits | React + Three.js | Component composition, shader management, 60fps animation loops |
| Blog articles | Astro + Markdown | Content collections, zero JS, fast builds |
| Page layouts | Astro components | HTML templates with scoped CSS, no runtime |
| Design patterns | AI-assisted extraction | Borrow from React ecosystem, implement in CSS |