Why Vanilla JavaScript
guseyn.com
guseyn.com
Those problems aren't 'solved'. The author has an implementation of a solution. It's one that they think is good, which is ace and I'm happy for him, but if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is the code so verbose?'
The massive advantage of a framework is that the people who choose it have agreed to share a solution to the common problems. This cannot be overstated - as soon as your team grows to more than one developer you move from 'solve the problem' to 'solve the problem in a way that people agree on', and that is far more complicated than just solving a problem. Sometimes you get lucky and work with people who think the same way as you, or with people who are willing to compromise on their ideal solution and accept yours, and then things still work, but if they're 'passionate' about being right then it's horrible, slow, and results in bad code.
A framework is an upfront agreement about how to build something. That has no practical advantage for a dev working alone. It's incredibly useful for two or more devs working together. Which framework doesn't really matter, except the ones with more devs behind them make it a lot easier to find people who've already accepted that way of working. That's helpful.
I agree with the problems you list, but I don't think a framework solves them. The same complaints can be made by the second developer because the first developer chose the "wrong" framework. Solved the wrong way, not covering the edge cases of your domain, too verbose etc.
Additionally a framework will likely be bloated and inefficient because they try to solve every problem for everyone, and you introduce a random breaking point where any framework update could in theory break your system.
Exactly this. There's so much fragmentation within the browser ecosystem that there is no guarantee your second developer will be comfortable/familiar with what the first developer chose. Even if you went with React you could be using state management they don't understand, a styling system they don't understand, etc... Even if you choose the most popular everything at the start of the project there is a lot of churn where things eventually fall out of favour.
I'd also be skeptical of web developers who work with React but aren't familiar with vanilla JavaScript. It's probably a good indicator that they aren't the best candidate but we can't all be picky.
Because you think whatever you want to pretend your web software isn't MVC isn't solved doesn't mean it's true. Oh brother, MVVM, Model-template-view (no offense, Simon), come on.
You define resources on an HTML page, the browser loads them, renders a page, loads scripts, and makes AJAX calls.
You don't need build scripts for this. More over, these frameworks and build scripts DON'T SOLVE PROBLEMS. They move them. They want you to become a React developer. Not a software engineer who writes web software.
They don't solve routing, because you rewrite it every year. They don't solve bundling, because you change bundlers every year. They don't solve event handling, because they just move the chain of calls where you define the listener.
It's all a lie.
yes it's still a framework, duh. it's just less abstraction than react etc.
Other people make different choices. That doesn't mean they're wrong.
People keep touting react etc but I swear every mobile ordering app I use lags like hell, just from recent example, and these can easily be built and maintained without a huge framework to "manage state" or "connect state to the view".
I don't doubt it. People make terrible websites with React.
However ... what might be happening is that you go to some websites, and some of them are great and others are terrible laggy garbage. When it's a bad one you open up devtools and see React, and that leads you to conclude that React is bad. But reality is that the good ones also use React, because most big websites use it.
Your reaction to the good ones is to assume they're well-built using whatever tech you happen to think is great (Rails, Vanilla JS, Vue, Svelte... whatever) but you're not actually looking. Hell, a great website isn't even a website, it's the experience of interacting with the business behind it. You don't even think about the tech when the website is actually usable.
Your reaction to the bad websites is to look under the hood, and you often find React.
That either means React websites are bad, or that React websites are good or bad, and it's not really React that's the issue. It's the team who built the site (and often not even the tech team; there's often some Product or commercial pressure that's driving the team to release something that's not really ready yet.)
I did an experiment recently, I actually wanted to launch a dashboard and picked React because I knew I could throw React + Tailwind + popular_component_and_charts_frameworks at Opus and get a decent result. But actually, I realized a lot of fairly simple button clicks had like a 100ms-200ms delay, and I just did not like it. I ported it to Java/Javalin with J2HTML and kept tailwind, and it's very snappy and works great. It's currently 96k lines of java ^_^
We shipped it like that. Turns out the computer's not fast and it does matter.
The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI.
Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" eventually gets patched in using a rube-goldberg-machine approach to architecture.
This can be solved later, but is a lot harder when you have an entire application that needs to bee kept working, and almost trivial if you started with some reactivity built in.
In that case, the backend will likely have a class instancr representing it, with the first field being a discriminator on the class and the remaining fields being the details. And regardless of what the frontend does, the backend will revalidate always because you can never trust data sent from a frontend.
All that to say, maybe the form could be server side rendered, with an adaptor to convert a class definition into an html form fragment, and either embedding the js "rules" into the html itself, or making it a web component for containered usage.
Doing it this way is a big deviation from the current status quo, but I've found it to work very well and cut out a whole range of bugs. Plus it makes me think about what is truly client side state (no chance of staleness) vs server state cached in client to avoid repeat server calls (could be stale, leads to bugs).
React was invented because jQuery style state management collapsed into unmanageable code past a certain size
function initWidget(root){
// Or a bunch of calls to document.createElement, whatever you want.
const inp = root.querySelector('.input');
const check = root.querySelector('.check');
function update(){
inp.style.display = check.checked ? 'none' : 'block';
}
check.onchange = update;
}
function initWidget(root){
// Or a bunch of calls to document.createElement, whatever you want.
const inp = root.querySelector('.input');
const check = root.querySelector('.check');
const check2 = root.querySelector('.check2');
function update(){
inp.style.display = check.checked && !check2.checked ? 'none' : 'block';
}
check.onchange = update;
check2.onchange = update;
}
function Widget(){
const [check1, setCheck1] = useState(false);
const [check2, setCheck2] = useState(false);
return <>
<input type="checkbox"
checked={check1} onChange={e => setCheck1(e.target.checked)}/>
<input type="checkbox"
checked={check2} onChange={e => setCheck2(e.target.checked)}/>
{check1 && !check2 && <input type="text" />}
</>;
}
<script>
let check1 = $state(false);
let check2 = $state(false);
</script>
<input type="checkbox" bind:checked={check1}>
<input type="checkbox" bind:checked={check2}>
{#if check1 && !check2}
<input type="text">
{/if}
You don't need to remember how to properly line up useState/useEffect/useCallback and all.
You could just insert any simple state object and be ok with it, or insert a well-known state management library and it still works the same way.
For UI libraries they almost always have a vanilla option, and even better, if you are not working with google sheet level of stuff, vanilla element management is much much easier to work with.
And no need to talk about the style frameworks, they always work the vanilla way.
With some default vite configuration, nothing you need to worry anymore and the framework level stuff are simple and easy to understand and is totally manageable.
<e-toast
data-type="success"
data-position="top-right"
data-hide-after-n-seconds="5"
data-close-icon="/images/close.svg"></e-toast>
React’s complexity isn’t just components — it’s effects, state‑management conventions, data‑loading patterns, and the surrounding build ecosystem. If your UI doesn’t need those abstractions, adopting them early is pure overhead.
For these kinds of projects, React usually carries a much larger total cost than vanilla HTML + JS.
The “vanilla becomes a bespoke framework” claim assumes the UI will inevitably grow until it needs framework‑level abstractions. Most UIs don’t. React front‑loads complexity even when the UI is small, while vanilla only adds what the actual requirements demand.
A few helpers aren’t “reinventing React” — they’re choosing a simpler design avoiding numerous unnecessary abstractions, and with lower costs & complexity for the moderate apps they're building. It's a very valid architectural choice.
Vue is just a huge convenience over raw JavaScript for large, complex view. Sure, I don't get to do direct DOM manipulation, but when I write C code I also don't get to pick which variable goes in which CPU register. I accept giving up control that ASM would give me, for all the improvements that C brings on top of it, even if C just compiles to ASM and is an abstraction on top of it.
No, spreadsheets popularized reactivity. And the general point is incredibly weak.
Don't use frameworks and make your own? Sure, have your fun. But then try teaching your framework to your company of 1000 and see how quickly you realize your view of the "problems" are only a slice of the pie.
Do they need 1000 frontend developers?
Aside from the Giants maybe some consultancies or hire-firms have that many? But they use whatever the client uses. If you're not in the business of selling frontend development services then a big part of your competitive advantage is _being able_ to make technology choices that are more-optimal than the labor market's lowest-common-denominator slurry.
Between JS/ECMAscript being abandonware for a decade and CSS' historical immaturity (cross-browser layout, custom properties, more pseudoclasses, etc) the Web was more of a wild west "whatever you we can cobble together" place. So of course we built an entire toolchain ecosystem for all the cool new tools we would reinvent from scratch.
but Things Are Pretty Good these days. We even have the world's only fully system portable assembly language: WASM! And the browser's Web APIs are becoming something like the missing Standard Library (shoutout to Deno).
The author's point seems to be that we are past a tipping point where we need all that additional complexity. You don't _need_ a separate system of reactivity these days, you can write a (closer to pre-hooks React, even!) React-style component library with Web Components now.
Personally I would need for Type Annotations to be a fully supported part of the spec before I made the point to "use the platform" professionally. Until some market force causes the core web technologies to truly fork my skills are useful for life. It's like a pale shadow of how UNIX users must feel :')
I don't want to think of memory management in most projects, I want to focus on business logic, so I use Node.js instead of Rust, even if the latter gives me more control.
Similarly, I don't want to think of DOM management in most projects, I want to focus on data dependencies, so I use React instead of Web Components, even if the latter gives me more control.
The author frames this as artificial complexity, and that's the best framing I've seen. The browser has a particular presentation philosophy and the more you try to cover it up, the more awkward your code becomes at the edges.
The killer application of LLMs is their ability to inform and adapt to a particular API, and analyze the code that you write. They are garbage at producing functionality for which they don't have a thousand examples, but provide documentation and intent and they will help you fill in the gaps. This is the real 10x opportunity, and the best part is that you can still write all the code yourself.
I'm certain this doesn't just apply to javascript and the web. I predict that the need for frameworks will slowly go away.
A bit tired to see this...
No it's not. We do this all the time. It's as simple as using proper HTTP headers for your css/js/pictures/whatever. You can even have smooth page transitions now.
Multi-page applications are slow if you load in 20 libraries from 10 different CDNs, a page tracking system, a click tracking system, a "performance metrics" system, a chat bot overlay, an advertising platform, all the crap loaded by the ad intermediate, all the crap loaded by the ad itself, an ad "traffic quality" montor, a Stripe.com thing (even though this isn't a payment page), something from Facebook, something else from fbcdn...
The author is reinforcing the false dichotomy between using front end frameworks and hand-rolled JS, as if rendering data from JSON APIs is the only way to display information from the server.
Almost as an aside, he says
> Server Side Rendering is also no better, because while they can do certain things in more straightforward way, they break browser behaviour [...]
but he provides no examples or supporting evidence, so it's difficult to know what browser behaviour he's referencing. "SSR" is just how the web has worked since the beginning and it works very well. Maybe he's specifically talking about SSR as provided by Next? I've never used it, so I'm not sure what browser behaviour it might be breaking.
But yes the web has evolved since then and the HTTP protocol has newer versions and most apps don't serve as many users as Facebook.
If that means you have to make a small thing that is designed to do just the task at hand but to do it well, I am all for it.
I think the only frameworks that I have encountered that I felt were worth using were server side things like express where they had a very specific task to do and could isolate areas of behaviour.
Author then elaborates in the absence of using a common-knowledge framework you can create some tighter solution that achieves just the part you need. This is "fun" programming, and the author is suitably impressed with themselves for solving problems they created just by convincing themself not to use a framework. Sometimes that's fine, although I don't think there's much appetite for this anymore.
Article doesn't really elaborate on what "scaling" and "providing structure" means, I think it downplays the benefits because when you use <framework> you are really establishing ground rules for how all future developers are going to work on that software. You don't know exactly what they'll write, but you know they'll always gravitate towards the top 2 or 3 solutions for that framework at any given time.
When you bust out a bespoke solution that carves out that one thing you needed and does it oh so elegantly and perfectly, you're creating art but most of the canvas is left blank for future developers and they're effectively going to scribble on it with crayons.
Also - sometimes it is actually useful to make a mini-thing instead of bringing in enterprise messes.
Among the most critical realities to consider exist outside the product definition entirely, and have to do with the environment in which it will exist during and after development. These are things like plausible scaling curves and limits, code lifetime, team size, deployment options and preferences, etc. Others are things like available runway, team fluency and talent, available tools and licenses, etc.
One of the big eyeroll moments of the last 15 years or so was when folks started blindly cargo culting global-scale 10,000-engineer enterprise practices on projects that would obviously only ever be touched by 1-2 technicians and deployed on a far far far more modest scale. Instead of actively considering any of those environmental requirements above, "engineers" would try to treat every project as though it would someday service 10,000,000 DAU under the hand of dozens or hundreds of churning technicians.
Akin to the joke about some Americans who see themselves as "temporarily embarassed millionares", making foolish choices at their own obvious expense, many engineers during this era would seem to see themselves as "temporarily embarassed Facebooks".
In countless cases, this was simply very dumb and very wasteful and at best amounted to inadvertent (or perhaps intentional) resume-padding for the people involved, while their projects bloated and sagged and lurched under unwarranted complexity.
Sometimes (in fact: often), just doing the thing well with simple, clear, stable tools -- and nothing more -- is the right choice.
Not too mention how damaging it all is to environment in exacerbating the climate catastrophe.
Some engineers learned it works fine and are quietly maintaining a stable system well under capacity. Or building the most insane distributed systems ever conceived.
Stronger: that should be standard operating procedure. Unless there's a pressing need (if not absolute necessity) to do otherwise.
Web Components and vanilla JS scale just as well. Been doing this for ages.
While I’m not the biggest fan of Nextjs for my own solo projects, I really enjoy using it at work. Leaning into the opinionation it provides/encourages keeps my team from bickering too much about how to structure things.
It’s really nice to say “this is the idiomatic way of doing it according to the docs” and for everyone to nod their head. Whereas pages in our legacy PHP codebase look completely different depending on who implemented them.
Front ends works like this - main app split into few smaller ones callable from a menu. Each sub-app is dynamically imported module (no need for building, code mutilation, direct dependency etc). Sub-apps in turn can consist from the other sub apps. Each can be worked on completely independently by different team member with virtually no interaction needed. Apps can share some approved libraries (like for graphics etc) and HTML components responsible for particular bits and pieces. Components and libs go into common pool. Once component is in a pool modifying behavior is punishable by death. Only internals. If change is breaking then simply new version is developed and deployed.
The whole thing is super scalable organization wise (nearly everything is decoupled) and resource wise as well since everything is loaded strictly on on need basis.
Folks learn about how to use modules and libraries?
I don’t like react very much and dislike the other ones even more. Yet, it’d be stupid to say you can’t make them work. They come with a large community and pckages and solve a ton of problems that a homebrewed framework doesn’t even conceive of. And you can just start writing the stuff you need right away.
On the other hand, a homemade framework doesn’t require the extra overhead of knowing the framework, and maintaining it overtime. You don’t need to track down why the code gets run a gazillion times more than it needs to, you can debug through your events, etc.
They’re just different ways of doing things.
But mainly: react is a pain in the butt but if time is your constrain, it should get you to where you want to be faster than if you’re not using it.
It could be attributed also to typescript dominance of course, since people don't use plain js anymore.
As for the blog post, I agree, I also implemented my own js framework when I code in vanilla js and it works fine.
The problem is not inventing frameworks, the problem is that everyone invents frameworks, so people all know different things and they are hard to hire.
Of course, if you use old syntax you still deal with weird scoping and casting, but you don't have to any more.
Also, I think the framework churn has slowed considerably in the last 5 years.
This person re-invented form handlers, frameworks, ui helpers just to be able to do some basic things.
All power to you if you like it, its just funny.
Well played. You got me to visit your version of the thing you complained about. :clapping-emoji:
window.i = 0; // initialize all my for loops in one go!
Especially nowadays with LLMs, the team would benefit more from the LLM innately knowing a widely used library/framework than having to spend context each session teaching the agent your custom setup through context files and skills.
Plain JS is also a lot better with AI. I don't recall Claude ever making any mistakes in terms of getting the type wrong with plain JS since I started using it. It's just not the kind of mistake that AI makes.
I feel somewhat vindicated by this. I've been saying for years that coding isn't the hard part, type correctness isn't the hard part. I also made a point that complex interfaces are a greater danger and that Typescript tends to encourage people to design complex interfaces... And look, this certainly seems to be reflected in the training data because my AI token usage at work (Typescript) is far greater than on my side projects for the same task complexity.
This is kind of proving my point that plain JS code is better architeted overall than Typescript code... It makes sense to me, any complex plain JS code MUST be well architecture because JS is unforgiving. The spaghetti doesn't go very far in JS.
And sure, there is a build step. I have never felt like this was a problem with Svelte, but then I don't have experience working on a colossal Svelte app. Does it become one?
Just use server side template rendering with HTMX. LLM can see server side request flow better anyway.
As for offline, yeah, my Internet web page doesn't work offline. Shocker.
That's really too bad honestly. What about your users who want to use your site when they're offline? Sympathy with those users is why I made sure that my site works well when offline.
Web apps that are valuable to use offline also tend to be the kind that really do warrant client-side logic and rendering (a spreadsheet web app is a classic example).
If the site's focus is providing information (e.g. Wikipedia), then working offline really just means loading all the backing data into the browser, which quickly becomes impossible.
I'm sure there are cases where offline availability is a huge plus (your site might be a good example), I just don't think it's universally applicable.
1. Browser requests /js/foo.js
2. Server middleware checks if /js/foo.ts exists
3. If yes, server middleware strips types from the file before returning it
In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly. The middleware looks like this:
``` return esbuild.Transform(string(fileBytes), esbuild.TransformOptions{ Loader: esbuild.LoaderTS, Format: esbuild.FormatESModule, }) ```
It only takes a few microseconds and I don't need any bundlers or tsc or anything like that. Everything on my frontend is 100% vanilla TS; I make changes directly to TS and then hit refresh in my browser and the changes are reflected instantly without needing a bundler or even node/npm for that matter. Note: for this setup to work, your front end TS has to use ES modules import/export which browsers natively support. If you try to use CommonJS or something like that, you would start needing a bundler again because browsers can't resolve "require" statements.
In node it should be even easier than Go because Node added native type stripping starting with v22[2]
But even on older versions of Node, a type stripping middleware would still be very easy to implement[3][4].
[1] https://pkg.go.dev/github.com/evanw/esbuild
[2] https://nodejs.org/api/module.html#modulestriptypescripttype...
And yet you're using one. Esbuild is one of the most popular bundlers in the js ecosystem, your workflow is functionally identical to any other bundler workflow except that the example you provided is worse than the typical workflow because it builds the ts file on every request rather than just once when the source code changes.
I'm using a TS type stripper API from a go package inside the server. I'm not actually doing any "bundling" which implies resolving imports, tree shaking, combining multiple files into one, minification, uglification, etc. I'm strictly stripping out types and serving what's left directly to the browser. This costs less than 1ms of cpu time on a cold load (and usually costs nothing because of front-end caching/etags)
Look, I don't want to argue with you. Just sharing my setup. I develop medical device software which means dependencies are very expensive because they incur regulatory burden. SBOMs and associated CVEs have to be tracked and reported to the FDA. My TS/golang stack means:
- My docker images can be from scratch or from busybox with a statically linked go binary
- My frontend can be vanilla TS with zero dependencies (npm or otherwise)
- Debugging is dead simple: set breakpoints directly in dev tools and it's WYSIWYG (no map files needed, etc)
- Feedback is instantaneous. If I change a file in TS and hit refresh, the change is reflected instantly (compare to bloated Vue/React shops I've seen where every change requires a 10 second frontend compile pipeline to run before you can get feedback in the browser)
So what exactly are you referring to here?
You run node with the TS support - great.
That doesn't explain how your front-end TS code is transformed into JS. You seem to be suggesting that node does it automatically, but it doesn't. The explanation of your setup isn't adding up.
Node will do that at run time. Its automatic. Functions do not have to execute to receive this benefit. They just have to be imported. Ensure you are using a very recent version of Node.
Since I am not handcuffed by some giant framework I have maximum flexibility to do what makes sense.
So in other words, you created your own bundler?
Node isn't actually doing the work for you on the front-end.
> I just write my code and then point node at the main file, and this even includes front-end code for the browser.
It sounds like you're just making stuff up.
> I just write my code and then point node at the main file, and this even includes front-end code for the browser.
Then you said:
> I never said Node is did anything for the front end.
So which is it?
Yes, I push all my TS code through Node for type stripping. No, Node is not executing browser code. No, I am not suggesting Node is running in the browser.
For extra extra extra clarity importing functions in JavaScript does not execute them. They still have to be called for them to execute.
I am still willing to fix your code for a consultation fee.
You do have a build step, you just think that doing that using node script is the same as not having one, I guess.
I recommend you stop making stuff up online. We're 10 layers deep into this thread and you still can't explain how any of this works in a coherent way.
If any of this is real, why don't you attach a link from the node documention or an article that explains this technique that allows node to serve type stripped imports over http.
I'm not asking for a link to the http stack, I'm asking you to explain how you run a node app that consumes your typescript source code and serves it over http without a bundler.
But in the last post he kinda explained that he uses a node script to convert TS to JS. He is just confused.
zero build on complex front ends is disrespectful to your users. when you dont minify and code split you are basically saying "got a slow connection? tough luck, go wait for 10 seconds while this page loads 1.5mb of code that could be 5x smaller but i dont care enough to spend a couple minutes on a basic vite setup."
you might get away with it when its a mostly static page with a couple lines of script but when its a bigger app users will notice. "just write less code" is not an option most of the time. and tsc is also a build tool so if you take it strictly you either get no type safety or get stuck with awful looking jsdoc comments that take up space in your final script file.
Also with the developer disruption of agentic coding AI, the arguments for using vanilla JS is even stronger. Code reviews of code/solutions is much easier. Scoping of code paths for each server-side render templates is easier. The AI does all the boilerplate coding, while keeping it readable and debugable. Implementing design patterns is just common computer science stuff, and the coding agent is pretty good at it.
I also what to mention, as a business owner, and boss of a startup. All developers here work with vanilla javascript. They were first surprised, but today they prefer it by a huge margin because of the simplicity and zero dependency and non existing build steps. The web browser is the framework, you need another abstraction over the web browser.
https://cdn.guseyn.com(/mp4/desktop.mp4)
Instead of
Works fine.
It is very interesting watching the Web cycles, and found it curious how many people here were sad that typescript was not mentioned. There are some fun (though I suppose dangerous) things you can do without it, and I've found it has had very many instances not helped me where expected like a fully matured typed language has. And I've worked with a lot of people who just went I added types and don't know how to use generics.
I guess if you have it poorly implemented, then it's best to leave as JavaScript. And, web components you can keep things very simple... Which helps keep many errors down.
Since React's invention, it has gotten more bloated, browsers have made living DOM changes a lot faster, and the vast majority of websites still only change one or two DOM objects in response to events. Those could easily be handled much faster with plain old AJAX. The latency overhead React adds to a website is quite noticeable and unnecessary. Airbnb.com for example would be a great deal more pleasant to use if they would ditch React.
The fact that React had to reinvent server-side rendering is all you need to know to see that React has jumped the shark.
You don't need React: creating a minimal UI library:
TypeScript benefits can be had without a build step by leveraging JsDoc.
But in response to the article: no, vanilla JS is a nightmare to keep your code organized, and battle tested frameworks do quite a good job at that. It's otherwise mostly a waste of time, or an intellectual exercise at most, to build an app with vanilla JS
In vanilla JS even small SPA projects can end up tangled or you are hand compiling what React would do for you for free.
Nit: in React events are events useEffect reacts to abstract state changes.
I know posts like this get a lot of whinging, but you are 100% right. The browser is in itself a platform; frameworks are not like some kind of hyper abstracted Web Scrinting Language for people too important to deal with "raw" CSS/DOM. They're a an awkward, alternate abstraction, slow as molasses, and they leak like a sieve.
As for frameworks, we are not progressing towards AI-driven frameworks.
IMHO knowledge of C++, Python, or pretty much everything that's not a lisp variant, doesn't translate well to JavaScript.
There's such a nice language with its own silly warts, readily available to pretty much anyone with a computer regardless of form factor, being misunderstood by the vast majority of programmers.
Do we hand-code every UI field with the code that updates the local model and then transmits it to the backend?
Or is there a way to make the boilerplate as small as possible, relying on one bit of code to handle synchronization between UI, local model, and server?
“Using WebSockets” doesn’t bind an interface element to its source of truth; it’s just the chosen transport to move the data. I’ll be sticking with a RESTy interface. But that doesn’t matter because the question is how is the binding implemented so that fewer mistakes are made synchronizing the data?
Hand coding every field’s binding logic is going to be error-prone.
It is as simple as I am suggesting, but only if you have actually done it yourself more than once. Whether or not your application is error prone is entirely on how you execute regardless of the tools in your toolbox.
And these days, LLM agent will just re-use existing patterns if prompted correctly, regardless of who in the team is using it or whether or not there's a public well known framework in place or not. So consistency should not really be an issue anymore even in a team.
The issue is that much of the time, people seem to choose tools based on convenience/past experience, not whether it's actually the right solution to their current issue.
ask Codex to make you a website and maybe it will use React.
maybe you didn't need really need build steps, but whatever it works?