You've done this a hundred times. Clone a template. npm install. Wait. Maybe a peer dependency fight. Fix the node version. Install again. Start the dev server. Wait for the first compile. Now you can finally look at the thing.
Nobody complains about this anymore. We just accept it as the cost of looking at code. But if all you wanted was to glance at a component or tweak one prop, that whole ritual is wildly out of proportion to the task.
So — why does "look at this code" require an entire toolchain as a prerequisite?
That whole ritual was invented, not required
Browsers have been able to run JS forever. Running was never the hard part. Compiling is the hard part — JSX isn't valid JS, TypeScript annotations aren't valid JS, both need translating first.
The standard answer puts that translation on your machine, in your terminal, through a bundler running on Node, and it hands the browser a finished file afterward. That's a historical accident, not a law of nature. Browser-side compilers just weren't mature when this pattern got set. Node was there first.
If the compiling itself moves into the browser, the whole chain in between just goes away.
Putting a compiler in the browser is harder than it sounds
Parsing TSX isn't free. A real template is hundreds of files. Full type-checking on the main thread would lock up the UI. You have to decide what's actually needed to render — mostly that means syntax transforms and type erasure, not a full type-check on every keystroke.
There's no filesystem to resolve against. Node's module resolution assumes a real disk, a real node_modules, package.json exports fields. In a browser you're simulating all of that in memory — path aliases, workspace protocols, conditional exports, the works.
Where do the packages even come from? A template depends on real npm packages — MUI, shadcn, whatever. You can't ask the user to install first. Either resolve real package versions off a CDN, or pre-bundle the common ones — and match whatever's actually pinned in that template's package.json, or the render won't match the real project.
Some plugins assume they're running in Node. Build-time babel plugins, emotion's compile-time optimizations — a fair number of templates lean on these. You either reimplement the effect in the browser or find a runtime equivalent. Neither is free.
Recompiling everything on every keystroke would be miserable. You need module-level caching and invalidation — only the file that changed, and whatever depends on it, gets rebuilt.
Source maps have to survive the whole trip. Errors, breakpoints, and any node-level mapping have to point back to your actual source line, not some transformed mess. That has to hold end to end, not just at one stage of the pipeline.
None of this is exotic. It's just what a real React template looks like once you actually try to run it without Node standing in the middle.
What we gave up to get here
Being upfront about the tradeoffs, because a piece claiming none is a little suspect.
Not every build-time plugin gets covered — projects leaning heavily on custom webpack/vite codegen plugins are only partially supported right now. Big monorepos have a real compile cost on first load, incremental after that, but not instant the very first time. And this isn't a replacement for a production build — production still needs a real build tuned for tree-shaking and performance. This is a tool for looking and editing, not a deploy pipeline.
Why this is the floor the other two pieces stand on
SCD(Symmetric Collaborative Development) selection needs position info injected at compile time, and a live index kept in sync with it. If compiling happens in some black-box bundler on your machine, there's no place to slot that in. Owning the compiler means owning every step of it, so the index can live inside the pipeline instead of bolted on after.
The dependency graph needs imports resolved live, as you edit — not from some static analysis script run once, offline, drifting out of sync the moment you touch a file. A browser-side compiler means the graph updates incrementally, with you, instead of "run the script again."
Neither of the other two pillars gets to be real-time without this one underneath it. It's the least visible of the three, and the one everything else depends on.
What this actually looks like, side by side
Old way: clone, npm install (thirty seconds to several minutes depending on the day, longer if peer deps fight you), sort out the node version, start the dev server, wait for the first compile.
New way: open the file.
The gap isn't "faster." It's a different category of thing. One is running a project. The other is opening a file. Your brain never has to switch into "this is an engineering task" mode just to look at a card component.
We've already shown this holding up on real templates — Material Kit React, shadcn-admin — where "open it and it renders" isn't a demo trick, it's just what happens.
What this means for teaching React
Environment setup is where most tutorials lose people. A lot of beginners hit an npm install error before they've written a single line of real React, and they walk away — and that has nothing to do with whether they could've learned the material.
Zero-infrastructure flattens the gap between "open a real template" and "open a CodePen." A student can touch actual production-shaped code in the first session instead of waiting out a whole week of environment setup first.
For instructors it kills a specific nightmare: half the room stuck on a different Node version, a different OS quirk, a different peer dependency error, each one eating fifteen minutes of class time that had nothing to do with React.
What this means for pairing with AI
The part of AI pairing nobody talks about is the loop after the generation — you get a diff, and now you have to actually run it to see if it's right. The old loop: switch to a terminal, maybe install something new the AI just pulled in, wait for the build, wait for the dev server, then look. Call it two or three minutes per round trip, easily.
Cut the compile step out and that loop collapses. The AI finishes, you open it, it's already rendered — no waiting stage in between. That turns human-AI back-and-forth into something closer to real-time instead of something metered out in build-times. If the AI keeps getting faster and the human verification step doesn't, all that generation speed just evaporates into the wait.
There's a second-order effect too — an AI agent itself can look at a render in this environment and self-check (screenshot, check for errors) without spinning up a whole build chain inside its own sandbox first. This isn't just saving a human's coffee break. It's infrastructure for the "AI writes code, then checks its own screenshot" loop that's already how a lot of people work now.
Three questions for any tool claiming to skip the build
Open a template you've never seen. Do you have to run a single command line command before you see it rendered?
Change one file, one line. Does that mean waiting for a full recompile, or does it just... update?
When something breaks, does the stack trace point at your actual line, or at some scrambled, transformed mess three layers removed from what you wrote?
Top comments (0)