With AI, you barely need a frontend framework
The pitch
It has been reported that a web developer, inspired by a Desmos post on Pratt parsers, has sketched a different route: TypeScript + the DOM API + predictable boilerplate, and lean on an AI assistant to write the repetitive stuff. No JSX transforms, no Svelte-like language, no hidden compile-time wizardry. Bold? Sure. Also pragmatic — less build-chain friction, fewer custom tools to make your IDE frown.
How it works
The pattern is simple and surprisingly old-school: render state to an HTML template (a sanitize tagged template for XSS safety), then keep a Binder of small binding functions that mutate the DOM synchronously on state changes. bindText, bindAttr, bindClass, bindChild and a generalized bindSlot cover updates, nested views and conditional mounting; SlotContent describes what should live in a slot and the Binder mounts, syncs, or destroys views accordingly. The cycle is basically Flux/Elm in miniature: DOM event → dispatch → update state → view.sync — all synchronous and inspectable in a single call stack. The author argues — and it has been reported that they argue — that because the boilerplate is predictable, an AI coding assistant can read, summarize and even write it for you.
Why it matters
This is not a manifesto against frameworks so much as a nudge: if AI can shoulder the tedium, do you still need the heavy abstractions? There are clear trade-offs — you lose JSX syntax checking and some ergonomics, and you trade declarative magic for manual bindings — but you also get fewer build-time surprises and more transparent runtime behavior. Allegedly, for many apps the overhead of a full framework might be overkill; for others, it's still the right tool. Either way, the debate has a new wrinkle: frameworks vs. patterns + AI. Who knew the front-end wars would be settled by a good template string and a helpful bot?
Comments