I disagree with that. They are fine for regular forms, tables (as in grids), etc. I usually have a few views using plain old Django templates (with a couple of template tags for additional functionality), and then maybe one view with a full blown SPA in it. No need to build your login page etc in React.
I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)
To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished.
Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites.
I'll take react and typescript any day over even one tenth of that.
Well, It is more of a design problem than a Django template problem. If you add more and more logic in the template itself instead of dealing with it in the views context or templatetags, you are bound to find yourself in such position that you have very hard to test code.
The tooling is fine and almost always lets you know where you are breaking stuff. Also, comparing react tooling with it is not fair, it is a much modern ecosystem that has pitfalls of its own.
I have been writing Django professionally for 10 years and React + Django together for 4+ years, so I really know what I am talking about here.
I basically agree. Templates are basically strings, while jsx is in the end a full programming language (js).
It has the downsides you mention (the error reporting is okayish I think). On the other side, you can write html directly (no classname, etc), and there is no transpiling/build tools/server-side rendering to add.
String templates are also side-effect free.
For spa I would prefer React (with Typescript): for a request/response old-fashioned app, or something like htmx/hotwire text templates can be very productive. I see your point though.
Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it?
Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified.
It's less about static checking than it is runtime debugging. When you have a syntax error in a template, Django's error reporting is super opaque about the problem, usually just raising a TemplateSyntaxError with a vague description. This just gives you the python error stack with little information of the actual context of the actual problem in the template itself.
By contrast, if you have a problem in the python code, the exception stacktrace will point you to exactly where the problem originates. If you add a `breakpoint()` call in the source before the exception point and run the request again, you'll get dropped into a live debugging repl
Just the one if you're using CRA. None if you're embedding react as is.
The answer depends on how you're using react, and what advantages you want to get from it. "How many tools" is not a real question to ask. If you're concerned about ease of development and learning curves, then that gives you an actual goal to optimize for, and it won't coincide with the amount of tools (react is harder to use embedded than with tooling, hence why the latter is more popular).
For each and every tool that is added to my project, it needs to be installed by every developer, it needs to be understood at least on some level by every developer, and it needs to be maintained by someone.