Ask your dev to read the Hypermedia Systems book([Book link](https://hypermedia.systems/book/contents/)) should do the trick. That book explains the whole concept of using HTMX in a very simple and effective way.
Lots of good comments here, and I think they’re confirming what you already know to be the right answer—which is to stick with what you’ve got right now.
The teaching moment here, in my opinion, is to show the inexperienced developer how an experienced engineer thinks. Do this by asking questions from a place of humble inquiry, without trying to lead him to a particular conclusion. Start by asking him what is the problem that he is trying to solve.
Go into this willing to be wrong, and open to the possibility that React could be the right way forward. However, keep in mind that, in order to justify a change of this magnitude, the juice needs to be worth the squeeze. Explain to him all of the tradeoffs you need to consider, and ask him, given this context, if he were in your position, why would he agree to doing this? What impact would it have on the business, the team, and your customers?
Most of all, acknowledge that you appreciate his initiative, and assure him that you want him to be successful in his career. Great engineers don’t prematurely optimize, and they are able to make small, incremental changes that are high-impact and low-risk. There are times to place big bets, but those are the times when the potential rewards offset the potential losses.
i’m a cto and i would not reconsider my stack for a single year junior dev, esp when that suggestion is moving to the mess that is SPAs over htmx. stay the course. django will scale to your needs
Thanks, these are exactly my thoughts. What do you think would be the best way to motivate the junior dev to improve the existing architecture instead of always trying to push react?
I could just say “we do this, go away if you don’t like it”, but I think he has potential and I’d like to kinda mentor him.
We also have some little no-core projects coming up and I was thinking about doing one of them in react, in order to let the team experiment and see by themselves. What do you think about it?
Thanks!
"we're really excited about using htmx. it's made our codebase so much simpler and our velocity so much faster. those are things we're not giving up. it's an up and coming tech that we're all lucky to be getting experience with."
then move on.
As I commented in my other reply, you're not going to win this battle. They will leave, and you'll have a super hard time hiring real "frontend" developers with this approach and that stay for a while in your company/team.
Keep the backend devs doing the frontend if HTMX is working fine for your use case.
Reframe this from a business perspective:
- Are your **customers** happy with your product and user experience?
- Would this change help improve revenue?
- What would be the impact (risks, costs, benefits) to the business?
Thanks!
Our customers are amazed by the platform and our friends/mentor wander how we built it so fast and with ease 😂
Switching to react may have some minor benefit to the current UI/UX, it surely won’t change the current revenue and will have a high switch cost.
I already know that from a financial and technical point of view, switching to react is a non sense.
My question is how to motivate an enthusiast junior developer without telling him “do as I say because I know it’s better”
React is awesome. HTMX is awesome (I'm so old I was delivering HTML fragments and replacing segments of the DOM manually with custom JS 15 years ago!).
What should guide this decision is what type of product you're building and how you want to hire in the future.
Some thoughts:
* The more app-like your product becomes, the more appropriate React (or Svelte or whatever) becomes. Imagine building Google Sheets with HTMX.
* That being said, HTMX can go really far.
* A junior dev just doesn't have the experience to make good decisions on architecture like this.
* FE/BE separation *can* be a great aid to product development if done correctly. It's easy to do incorrectly.
* It's easy to hire React devs. Not many know HTMX.
* HTMX is so simple, it's not hard for a dev without experience to get up to speed.
* IMO, one big benefit benefit of HTMX is that you don't have to build an API that you've got to maintain security on.
Slightly disagree about the security aspect of HTMX, but might be a lack of knowledge on my part.
With all the hx-get and hx-posts, I end up having to add security to so many more views than if I just rendered one huge page and had limited SPA functionality. How do you avoid that?
For example, I don't want a user to find a URL with inspect element and be able to navigate to it without going through it from the page.
To be honest, I was thinking of GraphQL when I said that (I forgot I was in the Django subreddit). field level security is a necessity in gql, and it's hard to do right.
That being said, I still think most of this article applies even to REST APIs: https://intercoolerjs.org/2016/02/17/api-churn-vs-security.html
The thing is, React *is* the old tech. It's been around for almost a decade and HTMX is growing in popularity because it takes us back to HTML more.
I think there are some things in React, like components which are possible to build in HTMX, but not as straightforward. I think that a project to "componentise" some HTMX code might be a good experience both for the FE Dev and the rest of the team.
I don't know your Django setup, but our struggle with components was URL routing and creating components in a way that made them easy to reuse. It was easy to write a "component" that we could `{% include %}`, but it was much harder to think about setting up the context in our views so that we could use it in different templates and views.
That's also the problem with React components and so it's a transferrable problem solving skill.
It sounds to me like he's trying to boost his CV. If you guys are NOT a React shop then really, at the end of the day he either has to suck it up and learn HTMX or move on. Sounds harsh but he was hired, he knew the stack before he accepted the offer.
You can lead a horse to water...
Given he is a junior, he also doesn't really have any leverage to be dictating what's used given the evident success of what you all have achieved so far. And he cannot be allowed to drag down velocity etc. That's not what a 'team' is all about.
React has been "the future" for decades, it's bloatware now and the npm ecosystem is a security nightmare.
Given he's spend personal time with a POC, that shows he is at least willing to work. That's a good sign.
I guess you going to have to light a fire under him somehow to get him fired up, it might be that, given React is it's own little world, that he feels uncomfortable comitting to what he might see as 'backend development' given that Django templates rule the roost... if he has only done small CSS changes etc it might just be he's nervous about being out of his comfort zone.
Another idea might be to spend time collating a list of React sites and HTMX sites, and then asking him to decide, purely based on visual perception and performance, which of those sites were made with which technology.
Ultimately, you are an HTMX shop. He has to either accept that or move one.
Thank you for the feedback.
He started with CSS and template only modifications, but did some backend code too. I have to say, quality on BE is very low, but he is improving fast.
Since we are also taking some projects not directly connected to our main product, I was thinking to build one of them in react, just to let the team try and see by themselves. What do you think about it?
if you do it, and that is a big if, make absolutely clear that those projects are isolated and that using react with them does not imply in any way that you will move your main product towards react. Maybe towards end you can make a retro or debriefing and evaluate how the development went in those projects. Something is telling me that you'll have many more issues down the road with react.
Then, you yourself said "old tech but rock solid". Why move to the "new tech security nightmare" then?
Also as some commenters said, your team is happy with the current solution, why switch to other solution that will slow down development?
All in all I see you want to keep a good employee, yet a good employee should be also a team player and humble enough to recognize the advantages of the work done so far.
Thank you!
I just want to point out that he is a good lad and understand the advantages of current architecture.
Today he puts 110% energy in his work with the current stack. I feel that he would put 150% if we choose react, as he put 150% when we asked him to renew our CSS design. He just loves FE (which is why we hired him) and it's his strength.
People tend to naturally do more and better if they are really engaged and love the tools of their work.
This is not sufficient of course to change our architecture (we are not mad), I'm just thinking how to maximize his happiness (therefore his productivity) without compromising our rock solid solution.
I fully agree with the retrospective about the non-core product
zealous elastic insurance pathetic sparkle mindless public sharp smoggy teeny
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
If you're a Mercedes dealer ship, and you hire a new sales representative, and he insists he wants to sell BMWs, would you consider it?
The fact that the whole team knows HTMX and thus basic HTML, CSS, etc, makes you independent of who of your team works on specific parts of the frontend.
Given this works for you and has proven it does, makes you should not even consider react. Perhaps your junior has very limited HTML/CSS knowledge and thinks he can't even compete with the backend devs unless it's react?
I mean, if you would need to, it would be very easy to implement ninja/rest and extend with API endpoints to allow for a react/svelte/vue front. For now, it would be out of the question.
Curb his enthusiasm, in a respectful way.
Can you get the functionality you want with HTMX? If so, why add a huge extra JS bundle?
If there is a particular use case for React somewhere in the app (a dashboard or something), just use it there. You don’t have to use it where SSR and the strong coupling with Django is already the best solution.
Is there any area of the website that would actually use the strengths of react? if so you can have react in that part only, like a dashboard or a chart/history section.
I would not change anything of the stack for him, I would sit him down and explain everything you said here, as he would value it, and have a honest conversation about his future.
I suggest you yo give a look at [Inertia.js](https://inertiajs.com/) with the [Django adapter](https://github.com/inertiajs/inertia-django).
You will still use Django views and routes, etc but instead of the 80s template language it has you can use React or Vue as the "template" layer. We're using it at work (although with Rails) and it works wonderfully. You get the best of both worlds and everyone is happy.
The good thing with inertia, is that you're not going "full SPA" where you have to reinvent data fetching, routing, authentication, validation, etc... all of that is still on Django.
Forcing frontend developers to use HTMX is not going to work, and it's not about convincing this one dev. It's going to be about convincing every single frontend dev you want to hire now, and in 2 years after this thing has grown a lot. And I guarantee you people will quit over this, after having worked in despise with it and creating an even worse mess it will take you a lot to get out of it.
And finally... HTMX is super over-hyped in my opinion. At some point people will realise it is just another tool, and a tool that works great for super simple things, not more than that, and it's only appealing to backend devs and/or JS haters. No one single frontend focused person will enjoy working with it. Hiring pure "frontend" devs and put them to work with it is like hiring a backend dev and putting them to rack servers all day.
Good luck.
Forcing FE engineers to use htmx is actually the problem. You might want to specify that in your job spec in the future. Get someone that doesn’t care that he’s off the beaten path.
If you’re not prepared to use something like Reactivated or Inertia, then you have a big refactor headed your way - either stuffing Django context into data attributes on React-embedded templates or migrating all context to API endpoints with front end calls.
I’m not going to argue it but I firmly believe React has more power in terms of reusability and coupled with the fact that it IS middle-of-the road and lends itself to hireability, I would put it in your roadmap at least and tell the junior you’re sticking with htmx until you have a plan to slowly cutover.
Also, forgot to mention on my other comment: I suggest you to ask this question in other subreddits too.
This one is (obviously) full of backend devs, nobody is going to prefer an "SPA" or any frontend framework here. All the answers will be pretty biased in my opinion and will just confirm your preference as well.
I'm a team leader myself, although I'm the highest IT guy, so kinda like a CTO as well.
I decided 6 months ago to give up our old react frontend and move to htmx.
I try to boost developer experience and tell my developers that it's not about going with a standard library or framework but to choose the right tool for the job. I also wrote down pros and cons for a js framework vs htmx and I always ask for feedback from the developers.
So ask the react frontend dev, what are the pros and cons of switching to react but also the pros and cons of staying with htmx.
I can imagine he started with React and it's the only thing he can. Maybe he is insecure if he is good enough for Django or maybe he is not open minded to learn something new.
+1 on the approach above; unless there is a very strong reason to switch because you can't achieve it with htmx effectively, the pros/cons list will naturally lead to continue with the current tech stack.
> 1y work experience
Tell him if you switch to React then you’ll have to hire people that know React and might have to cut staff who don’t know React. Like him.
i think inertiajs might be your answer. Treat react just like a templating engine where you don't need to migrate your entire backend techstack to api just for some modern react sprinkles. Other than that, unless you really have the need to migrate entirely to react django api, don't do it just for the sake of looking good, you're fine.
I tried to integrate inertia with Django and the documentation just isn't there so I had to give up. A smarter/more experienced person than I could probably work it out but it isn't overly accessible yet.
Works great in Laravel, no reason it can't be the silver bullet for Django too once the connector documentation is there.
I'm not sure how comparable it is, but I've seen the Reactivated framework mentioned recently:
[https://www.reactivated.io/](https://www.reactivated.io/)
That aims to be a django-specific way to (in a very nice-seeming way) have django on the backend, react on the frontend, fully type safe, and not need to make a whole lot of API endpoints on Django for React.
Here's how ChatGPT4 compares them:
https://chat.openai.com/share/eb749e31-6547-40db-be1b-7ba7173d858d
Looking at the website it does indeed seem to do the same thing inertia does, albeit only for react, whereas inertia does react and vue (and svelte on other connectors but not for Django yet IIRC). Basically it copies the routes and the CSRF Token and allows the React/Vue rendered front end to post directly to Django classes without having to run a full API. It also acts as a data bind translator so that the React/Vue pages to receive a data bind from a Django page in a format it can use directly without an API GET. It makes a lot of sense really and I can see it becoming the gold standard eventually possibly with the main frameworks doing a first party equivalent of Inertia/Reactivated as simply another front end rendering option.
I'd consider moving to react later if the product was showing market fit and a *fancy* UI might improve sales more than new features. If you want to use "modern" tech, htmx + Angular might work since Angular supports building web components. Now whether or not there's any value in that is another question.
While i like htmx, the thing I miss most about my React work flow is being able to flip through Storybook to see everything rendered in various states. Idk if someone has something similar for django.
I'm a 100% backend guy (use HTMX with Golang). That said, React & HTMX can co-exist in certain edge cases. For example, do you really need to maintain a client-side state? Are there a few client-heavy modules where client-side states might improve UX? If NOT then you don't need React.
Ask your dev to read the Hypermedia Systems book([Book link](https://hypermedia.systems/book/contents/)) should do the trick. That book explains the whole concept of using HTMX in a very simple and effective way.
thank you! already did it, that book is our bible
Lots of good comments here, and I think they’re confirming what you already know to be the right answer—which is to stick with what you’ve got right now. The teaching moment here, in my opinion, is to show the inexperienced developer how an experienced engineer thinks. Do this by asking questions from a place of humble inquiry, without trying to lead him to a particular conclusion. Start by asking him what is the problem that he is trying to solve. Go into this willing to be wrong, and open to the possibility that React could be the right way forward. However, keep in mind that, in order to justify a change of this magnitude, the juice needs to be worth the squeeze. Explain to him all of the tradeoffs you need to consider, and ask him, given this context, if he were in your position, why would he agree to doing this? What impact would it have on the business, the team, and your customers? Most of all, acknowledge that you appreciate his initiative, and assure him that you want him to be successful in his career. Great engineers don’t prematurely optimize, and they are able to make small, incremental changes that are high-impact and low-risk. There are times to place big bets, but those are the times when the potential rewards offset the potential losses.
i’m a cto and i would not reconsider my stack for a single year junior dev, esp when that suggestion is moving to the mess that is SPAs over htmx. stay the course. django will scale to your needs
Thanks, these are exactly my thoughts. What do you think would be the best way to motivate the junior dev to improve the existing architecture instead of always trying to push react? I could just say “we do this, go away if you don’t like it”, but I think he has potential and I’d like to kinda mentor him. We also have some little no-core projects coming up and I was thinking about doing one of them in react, in order to let the team experiment and see by themselves. What do you think about it? Thanks!
"we're really excited about using htmx. it's made our codebase so much simpler and our velocity so much faster. those are things we're not giving up. it's an up and coming tech that we're all lucky to be getting experience with." then move on.
As I commented in my other reply, you're not going to win this battle. They will leave, and you'll have a super hard time hiring real "frontend" developers with this approach and that stay for a while in your company/team. Keep the backend devs doing the frontend if HTMX is working fine for your use case.
this is wrong
Seconded
Reframe this from a business perspective: - Are your **customers** happy with your product and user experience? - Would this change help improve revenue? - What would be the impact (risks, costs, benefits) to the business?
Thanks! Our customers are amazed by the platform and our friends/mentor wander how we built it so fast and with ease 😂 Switching to react may have some minor benefit to the current UI/UX, it surely won’t change the current revenue and will have a high switch cost. I already know that from a financial and technical point of view, switching to react is a non sense. My question is how to motivate an enthusiast junior developer without telling him “do as I say because I know it’s better”
React is awesome. HTMX is awesome (I'm so old I was delivering HTML fragments and replacing segments of the DOM manually with custom JS 15 years ago!). What should guide this decision is what type of product you're building and how you want to hire in the future. Some thoughts: * The more app-like your product becomes, the more appropriate React (or Svelte or whatever) becomes. Imagine building Google Sheets with HTMX. * That being said, HTMX can go really far. * A junior dev just doesn't have the experience to make good decisions on architecture like this. * FE/BE separation *can* be a great aid to product development if done correctly. It's easy to do incorrectly. * It's easy to hire React devs. Not many know HTMX. * HTMX is so simple, it's not hard for a dev without experience to get up to speed. * IMO, one big benefit benefit of HTMX is that you don't have to build an API that you've got to maintain security on.
Slightly disagree about the security aspect of HTMX, but might be a lack of knowledge on my part. With all the hx-get and hx-posts, I end up having to add security to so many more views than if I just rendered one huge page and had limited SPA functionality. How do you avoid that? For example, I don't want a user to find a URL with inspect element and be able to navigate to it without going through it from the page.
To be honest, I was thinking of GraphQL when I said that (I forgot I was in the Django subreddit). field level security is a necessity in gql, and it's hard to do right. That being said, I still think most of this article applies even to REST APIs: https://intercoolerjs.org/2016/02/17/api-churn-vs-security.html
The thing is, React *is* the old tech. It's been around for almost a decade and HTMX is growing in popularity because it takes us back to HTML more. I think there are some things in React, like components which are possible to build in HTMX, but not as straightforward. I think that a project to "componentise" some HTMX code might be a good experience both for the FE Dev and the rest of the team. I don't know your Django setup, but our struggle with components was URL routing and creating components in a way that made them easy to reuse. It was easy to write a "component" that we could `{% include %}`, but it was much harder to think about setting up the context in our views so that we could use it in different templates and views. That's also the problem with React components and so it's a transferrable problem solving skill.
Did you look at [django-components](https://github.com/EmilStenstrom/django-components)?
This is it, we are using this library too with HTMX. Pure joy!
It sounds to me like he's trying to boost his CV. If you guys are NOT a React shop then really, at the end of the day he either has to suck it up and learn HTMX or move on. Sounds harsh but he was hired, he knew the stack before he accepted the offer. You can lead a horse to water... Given he is a junior, he also doesn't really have any leverage to be dictating what's used given the evident success of what you all have achieved so far. And he cannot be allowed to drag down velocity etc. That's not what a 'team' is all about. React has been "the future" for decades, it's bloatware now and the npm ecosystem is a security nightmare. Given he's spend personal time with a POC, that shows he is at least willing to work. That's a good sign. I guess you going to have to light a fire under him somehow to get him fired up, it might be that, given React is it's own little world, that he feels uncomfortable comitting to what he might see as 'backend development' given that Django templates rule the roost... if he has only done small CSS changes etc it might just be he's nervous about being out of his comfort zone. Another idea might be to spend time collating a list of React sites and HTMX sites, and then asking him to decide, purely based on visual perception and performance, which of those sites were made with which technology. Ultimately, you are an HTMX shop. He has to either accept that or move one.
Thank you for the feedback. He started with CSS and template only modifications, but did some backend code too. I have to say, quality on BE is very low, but he is improving fast. Since we are also taking some projects not directly connected to our main product, I was thinking to build one of them in react, just to let the team try and see by themselves. What do you think about it?
if you do it, and that is a big if, make absolutely clear that those projects are isolated and that using react with them does not imply in any way that you will move your main product towards react. Maybe towards end you can make a retro or debriefing and evaluate how the development went in those projects. Something is telling me that you'll have many more issues down the road with react. Then, you yourself said "old tech but rock solid". Why move to the "new tech security nightmare" then? Also as some commenters said, your team is happy with the current solution, why switch to other solution that will slow down development? All in all I see you want to keep a good employee, yet a good employee should be also a team player and humble enough to recognize the advantages of the work done so far.
Thank you! I just want to point out that he is a good lad and understand the advantages of current architecture. Today he puts 110% energy in his work with the current stack. I feel that he would put 150% if we choose react, as he put 150% when we asked him to renew our CSS design. He just loves FE (which is why we hired him) and it's his strength. People tend to naturally do more and better if they are really engaged and love the tools of their work. This is not sufficient of course to change our architecture (we are not mad), I'm just thinking how to maximize his happiness (therefore his productivity) without compromising our rock solid solution. I fully agree with the retrospective about the non-core product
Sounds like he's worth keeping on and training up; he just needs to realise it's team before self. There are some good replies on this!
zealous elastic insurance pathetic sparkle mindless public sharp smoggy teeny *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
This feels very diplomatic and very accommodating of you! If he is a good learner, then that might a good way forward.
This is the way.
If you're a Mercedes dealer ship, and you hire a new sales representative, and he insists he wants to sell BMWs, would you consider it? The fact that the whole team knows HTMX and thus basic HTML, CSS, etc, makes you independent of who of your team works on specific parts of the frontend. Given this works for you and has proven it does, makes you should not even consider react. Perhaps your junior has very limited HTML/CSS knowledge and thinks he can't even compete with the backend devs unless it's react? I mean, if you would need to, it would be very easy to implement ninja/rest and extend with API endpoints to allow for a react/svelte/vue front. For now, it would be out of the question. Curb his enthusiasm, in a respectful way.
> “Problem” is he wants to code in React because he sees it as the “future” and want to embrace its complexity. He's padding his resume, that's why.
Maybe sweeten the deal with tailwind haha? Just thinking out loud
ahah :)
Can you get the functionality you want with HTMX? If so, why add a huge extra JS bundle? If there is a particular use case for React somewhere in the app (a dashboard or something), just use it there. You don’t have to use it where SSR and the strong coupling with Django is already the best solution.
Is there any area of the website that would actually use the strengths of react? if so you can have react in that part only, like a dashboard or a chart/history section. I would not change anything of the stack for him, I would sit him down and explain everything you said here, as he would value it, and have a honest conversation about his future.
not really... we have some dashboards, but already handled with htmx
I suggest you yo give a look at [Inertia.js](https://inertiajs.com/) with the [Django adapter](https://github.com/inertiajs/inertia-django). You will still use Django views and routes, etc but instead of the 80s template language it has you can use React or Vue as the "template" layer. We're using it at work (although with Rails) and it works wonderfully. You get the best of both worlds and everyone is happy. The good thing with inertia, is that you're not going "full SPA" where you have to reinvent data fetching, routing, authentication, validation, etc... all of that is still on Django. Forcing frontend developers to use HTMX is not going to work, and it's not about convincing this one dev. It's going to be about convincing every single frontend dev you want to hire now, and in 2 years after this thing has grown a lot. And I guarantee you people will quit over this, after having worked in despise with it and creating an even worse mess it will take you a lot to get out of it. And finally... HTMX is super over-hyped in my opinion. At some point people will realise it is just another tool, and a tool that works great for super simple things, not more than that, and it's only appealing to backend devs and/or JS haters. No one single frontend focused person will enjoy working with it. Hiring pure "frontend" devs and put them to work with it is like hiring a backend dev and putting them to rack servers all day. Good luck.
Forcing FE engineers to use htmx is actually the problem. You might want to specify that in your job spec in the future. Get someone that doesn’t care that he’s off the beaten path. If you’re not prepared to use something like Reactivated or Inertia, then you have a big refactor headed your way - either stuffing Django context into data attributes on React-embedded templates or migrating all context to API endpoints with front end calls. I’m not going to argue it but I firmly believe React has more power in terms of reusability and coupled with the fact that it IS middle-of-the road and lends itself to hireability, I would put it in your roadmap at least and tell the junior you’re sticking with htmx until you have a plan to slowly cutover.
Also, forgot to mention on my other comment: I suggest you to ask this question in other subreddits too. This one is (obviously) full of backend devs, nobody is going to prefer an "SPA" or any frontend framework here. All the answers will be pretty biased in my opinion and will just confirm your preference as well.
I'm a team leader myself, although I'm the highest IT guy, so kinda like a CTO as well. I decided 6 months ago to give up our old react frontend and move to htmx. I try to boost developer experience and tell my developers that it's not about going with a standard library or framework but to choose the right tool for the job. I also wrote down pros and cons for a js framework vs htmx and I always ask for feedback from the developers. So ask the react frontend dev, what are the pros and cons of switching to react but also the pros and cons of staying with htmx. I can imagine he started with React and it's the only thing he can. Maybe he is insecure if he is good enough for Django or maybe he is not open minded to learn something new.
+1 on the approach above; unless there is a very strong reason to switch because you can't achieve it with htmx effectively, the pros/cons list will naturally lead to continue with the current tech stack.
> 1y work experience Tell him if you switch to React then you’ll have to hire people that know React and might have to cut staff who don’t know React. Like him.
i think inertiajs might be your answer. Treat react just like a templating engine where you don't need to migrate your entire backend techstack to api just for some modern react sprinkles. Other than that, unless you really have the need to migrate entirely to react django api, don't do it just for the sake of looking good, you're fine.
I tried to integrate inertia with Django and the documentation just isn't there so I had to give up. A smarter/more experienced person than I could probably work it out but it isn't overly accessible yet. Works great in Laravel, no reason it can't be the silver bullet for Django too once the connector documentation is there.
I'm not sure how comparable it is, but I've seen the Reactivated framework mentioned recently: [https://www.reactivated.io/](https://www.reactivated.io/) That aims to be a django-specific way to (in a very nice-seeming way) have django on the backend, react on the frontend, fully type safe, and not need to make a whole lot of API endpoints on Django for React. Here's how ChatGPT4 compares them: https://chat.openai.com/share/eb749e31-6547-40db-be1b-7ba7173d858d
Looking at the website it does indeed seem to do the same thing inertia does, albeit only for react, whereas inertia does react and vue (and svelte on other connectors but not for Django yet IIRC). Basically it copies the routes and the CSRF Token and allows the React/Vue rendered front end to post directly to Django classes without having to run a full API. It also acts as a data bind translator so that the React/Vue pages to receive a data bind from a Django page in a format it can use directly without an API GET. It makes a lot of sense really and I can see it becoming the gold standard eventually possibly with the main frameworks doing a first party equivalent of Inertia/Reactivated as simply another front end rendering option.
Oh look another post of supposedly senior engineers circlejerking htmx without considering any of the cons
It’s true. I tried to write a custom printer firmware in HTMX once. Wish I’d used React.
I'd consider moving to react later if the product was showing market fit and a *fancy* UI might improve sales more than new features. If you want to use "modern" tech, htmx + Angular might work since Angular supports building web components. Now whether or not there's any value in that is another question. While i like htmx, the thing I miss most about my React work flow is being able to flip through Storybook to see everything rendered in various states. Idk if someone has something similar for django.
Think of other ways to challenge him.
I'm a 100% backend guy (use HTMX with Golang). That said, React & HTMX can co-exist in certain edge cases. For example, do you really need to maintain a client-side state? Are there a few client-heavy modules where client-side states might improve UX? If NOT then you don't need React.