> Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do.

I don't know your job, your coworkers or your context. You may be right… probably not, though. React is a powerhouse in terms of developer productivity.

I have 17 years of software engineering behind me, and while I dabbled in a lot of things, most of these years have been spent using Python (and Django). And the current typescript+react ecosystem is several orders of magnitude more productive than anything else I've ever used, be it in Python or any other language.

You say "overcomplication", but React is far, far simpler than Django's template system. You're basically throwing away a LOT of overly complex shit that is simply there to generate HTML in non-html. React generates HTML with actual HTML -- well, okay, JSX/TSX is not technically HTML, but it maps perfectly where it needs to, and still gives you that added layer of typing for extra safety. React can't generate invalid HTML, and if your app compiles, you won't ever have a client-side syntax error.

I can't stress how bad a tool Django templates are for the job of generating HTML.

Oh and JS without React? I mean, sure, if you're literally just adding a couple of dynamic elements on a mostly static site. If you're actually going to have JS-driven UI elements in a dynamic interface, just use React. Not saying you have to, but it's probably the correct choice.

There's a lot of purists out there who will cry foul at 50kb more of some gzipped code, but do you want to spend your time tweaking and manually testing imperative UI behaviour for all your little widgets and how they interact with each other, or do you want to be productive?

Feel free to email me more context on your situation and I can give you a more specific assessement … but my €.02 here is, spend some time learning react & typescript, and playing with the more useful bits of it (NextJS+Typescript). It's not time that will be wasted either way. Give it a week and re-assess.

yeah i’m inclined to agree. i’ve had no complaints with the react/django combo.

Not the OP but this approach is great if you're starting a new project that is intended to grow.

Django has lots of stuff besides the template system, in particular the admin, authentication, and ORM which allow rapid iteration and getting your product into production.

After some growth though, you may find yourself constrained by the framework: a mixture of difficulty implementing functionalities, performance problems, and organizational/deployment problems (i.e. several teams wanting to deploy simultaneously).

Around that time you'll probably start looking at taking your (obviously well-designed) monolith apart and peeling off the business domains out into separate services. Maybe rewrite some parts Go or Rust? Anyway if you use the template system, you'll have a much harder time doing this than if you're only slinging JSON around.

Another advantage is that you get right from the start is having the ability to modify purely display parts of the UI without having to touch the back-end, it doesn't sound like much but is incredibly useful when prototyping/testing new ideas.

For an SSG though, for me that's the wrong use case. For that I would use Zola which is incredibly fast and uses a template system that's basically a Rust port of Jinja, so a Django developer is right at home.

https://www.getzola.org/

How does "several teams wanting to deploy simultaneously" cause problems in a monolith? Do you mean "merge code changes simultaneously"?

> my case against react when plain whole JS would do.

IME (not a senior dev) it's easier to turn the entire front-end over to React. I don't want to rebuild the wheel and write custom CSS every time I need a new component. I want to be able to plug in common components, with unsurprising and predictable props. If I'm already using React for dialog boxes, it may well as handle my click handlers as well. Then it can also grab data.

I agree with the spirit of avoiding more dependencies though and for this reason I try to avoid Redux. I find React absolutely invaluable for styling and reusable components however.

> I don't want to rebuild the wheel and write custom CSS every time I need a new component.

You are telling me it is worth migrating to a new architecture/build with all the overhead just so we can have less time writing custom css? Surely you jest. Devs should not define their jobs as cookie cutters. We use common stuff as a base to start work on the customized business facing solution yo.

I've seen some custom PHP production codebases with plain css and jquery doing its thing with 1x10^6 plus weekly traffic. It was a pleasure to read and figure out. I could throw an intern at it and he would figure it out. Verbose as hell too.

> I've seen some custom PHP production codebases with plain css and jquery doing its thing with 1x10^6 plus weekly traffic.

I've worked on plenty of those. I've handled more traffic with uglier shit, too. This isn't a performance thing, nor is it a premature optimization thing. It's about developer productivity.

Refactors are faster. Components are easier to break down. Bugs are easier to catch at compile time. Some classes of bugs are entirely avoided. A LOT of UI logic makes a ton more sense when written declaratively (as React forces you to), than imperatively. And none of that is even getting into the realm of how much easier it is to find devs who will work on a ReactJS codebase (and even more so, will be happy to do so).

My field Python experience surpasses my Typescript/React experience easily 50x. And yet, I'll be much faster at picking up a new client's React/TS codebase than their equivalent Python one. The productivity gains are real.

Absolutely. He’s talking about custom CSS which has already been written for the organization. You don’t want to have someone waste time duplicating the style. They may be against a deadline or have higher priority tasks.

Plus, you may have gotten lucky with that app, but that’s very often not the case.