an intern asked how familiar i was with react. harmless question, except i heard it as a dare. could i actually port this site to react? could i hook it up to the kind of spatial ai editing where you point at a layout and change it visually instead of hunting through a text file? the site already worked fine on template literals. nothing was broken. this was not a fix. i just wanted to know if a future i actually want is reachable.
template literals in all honestly were a ceiling and not a wound. they could render the site... they just couldn't be the target of a write-back from a visual editor. react components can. so the migration wasn't really about getting a nicer editor. it was about making a future buildable that the old stack locked out: authoring my design system in a spatial ai editor, changes flowing editor >> repo >> build >> live. repo always the source of truth.
why not make the editor the source of truth? because then the visual tool owns my markup, and i lose room to move on the stuff that actually keeps the site fast and reliable. i'll take a sync problem i never used to have. keeping control of what ships matters more than having one surface for everything.
react never reaches the user. at build time each component becomes plain html, same static pages the template-literal stack always produced. the browser never downloads react, never runs it, never pays for it. components and ai-editability are an authoring convenience on my side. the visitor gets what they always got.
it's already paying off in componentization and editor sync. and it opens a future i can actually picture now: changes flowing down from the editor into the live site, not just pushed up to it.
an intern's question turned into a self-set challenge. a ceiling worth breaking turned into control over the fundamentals. free-at-runtime abstraction turns into a future that's now reachable. i am having fun.