But if a project starts out with minimal JS and it grows complex, then it has a hard problem. If it was previously templates, there are going to be a lot of APIs that need to be made to convert from form posts and ajax. Some sort of framework is important to help provide guide rails for the team to avoid the mess, and they expect to update the page and don't play well with whatever was progressively enhancing the site before.
The other problem is that if it was just templates and a minimum of JS, then there probably isn't a frontend team in place. Most of them want to work in $fancyFramework and not on HTML templates. They don't get paid well for HTML and won't come to work for a company slinging template code. The backend devs don't want to do HTML, either. So it becomes a people problem. At some point in the complexity growth, a hard gulp is made to higher some frontend folks who are immediately unhappy. I've seen this play out several times and it results in big rewrites and stalled company growth.
So yeah, a lot of times we just start with React. Because there's not a great path from minimal JS into additional complexity. And you can hire people for it who'll be productive immediately. And at least there's no gotcha down the line when complexity grows. To do otherwise seems to always end up with rewrites that are so long that the team who finishes it isn't the same team that started it.
In Django, I love a good monolith. I try not to split them up and even ran a top 100 site for years using a Django project, as have others. It's generally a good time to break up a Django project into smaller Django projects when the team size is big enough to support dedicated people for features. Around then it starts to get frustrating to manage deploys and CI and testing and all of the peripheral stuff. But disciplined coding in a monolith can take a team a long way.
