React is neither good nor bad, it is just another framework. Usually developers are keen to rewrite things in their current flavor where they are comfortable. You need to be detailed with them and understand what react is going to solve, because while it might solve some things it will bring with it a lot of baggage and complexity too which may or may not be good for your current app.

My general rule is newly hired team members can't rewrite systems or major components within their first few months on the team. Of course it isn't an unbreakable rule, but the goal is to make them fully understand the product and clients. A lot of times people want to rewrite things cause they don't understand the problem you are solving and by rewriting the code base they can dig into the problem more. When in reality if you force them to live with the existing codebase for a bit it can help them and you feel more comfortable with a rewrite if that becomes necessary and usually it goes better too.

I've seen devs use react for landing sites that are 3-5 pages and maybe a couple of forms etc all because they didn't know how to interact with forms through javascript. Or one I loved is a new dev saw jquery in a project we had that was still operational and doing great but he freaked out wanting to rewrite a stable cash cow of a codebase cause jquery is "bad". I doubt/hope that isn't your case here, but just make sure you feel confident in the reasoning and it isn't just cause they know react and it is the hammer they use regardless.

Thanks. That is great advice. This is no cash cow, but it is useful to my little company and a small group of users.

This is not an exact answer to your question, but if you run a "simple" website or web application and really want to move to react, choose an easy to use and maintain popular framework like Next.js and host it on a platform like Vercel or Netlify

Yeah, see, my concern is that I am constantly going to be porting the site over to the developer’s framework du jour. Maybe I am overestimating what a rewrite requires.

I already know what I need the web application to do. It uses Flask, which I understand to be akin to driving a Dodge Caravan, but it gets me place to place. Updating it to Next.js or similar only feels necessary to me when the Dodge needs to be abandoned by the side of the road. For the developer, I am sure it feels like working on a useless piece of junk, but the developer is not the one that has to drive it place to place.

It depends on a whole lot of things. Is your app generating revenue. Is the developer a full time employee. Are the changes you want the developer to do simple cosmetic changes. Is the largest part of the value in the front-end or is there some complex orchestration in the backend? I.e: has the product never existed for lack of good front-end and the value is precisely in the UI?

React is amazing. Throw in ESLint, typescript, and copilot and you will be shocked at how fast and beautifully things come together.

It doesn't sound like you know what React is. Let the developer do the job you hired them to do.

I do not know what it is in detail. That is part of my concern. Framed another way, should I continue to use this developer that is pushing for React, or should I hire one that wants to use plain Javascript? Would all developers push for React?

No, all developers would not push for React, and anyone coming into a web project for the first time suggesting a rewrite in React smacks of bootcamp-era ignorance. There are legit apps where React is indeed the best-suited tool for the task, but that number is surprisingly low. React has become the new "nobody got fired for choosing IBM" and has become just as problematic in our industry. Many projects would be better off with other tools/frameworks or actually just vanilla JavaScript.

Thanks. This is the feeling I have as well.

The web community has had another revolution and SPAs are now on the way out.

Good to know, thanks.

React can be used for non-SPA sites. Next.js has added features for this recently.

react will net you some marginal ada compliance ootb. youll get more complex ui components. depending on your current deployment process, you may also incur a significant new maintenance overhead

Hm, I am concerned about overhead in the abstract. More complex ui components could be good at a later stage of development, but they seem unnecessary at present. The basic functionality, i.e. the functionality that I am actually finding useful, is already realized in JavaScript. It is merely ugly. Thanks for the reply.

React made me 10 times faster, and I'm not exaggerating.

tbh how can one NOT use react? it’s insanely simple. is this not the way?

https://reagent-project.github.io/

api basically unchanged since 2013 btw.

> The goal of Reagent is to make it possible to define arbitrarily complex UIs using just a couple of basic concepts

The counting component example is way too complex for me. js/setTimeout? r/atom? What is this wizardly? Is there a reason why this would be preferable, ever?

the basics are:

- atom is a compare and swap data structure, its lets you mutate state

- in your atom you hold a hashmap, deeply nested, that contains ALL state describing your app

- your react components reference that state with: (:some-hashmap-key @state)

- every time you update that state, any components depending on it rerender

- thats it. it’s literally the best!