Of course, when it comes to web apps, like Google Docs or similar, SPAs all the way, but that's a tiny minority of the web.
I hate having to use what is basically a simple static page but is effectively a large app that is being downloaded and executed client side- it makes it unresponsive.
I'm wary though, because lots of things start nicely but fail to manage complexity of even a moderately sized app, and everything grows over time. I feel like a lot of people are going to rediscover why we started making everything a SPA.
There have been a lot of approaches on the frontend over the years and it's been my job too many times to clean up where that approach eventually collapsed as the app grew larger or ran into limitations. I am looking for the upgrade path -- I want to start simple but not risk an entire rewrite when the complexity exceeds that pattern. To date, very few of these things work well enough together to consider it seriously. (htmx+react would work fine but you'd pay a large cost for upgrading a single component, like rewriting it and a chunk of new runtime code. And if everything eventually gets more complex, somebody starts asking "why we have two ways of doing things?? We should consolidate!" And the rewrite cycle continues...)
It's a balance between hard-won experience and becoming too wary of new things. It's hard to see new frameworks completely based on events, for example, and not cry does nobody remember that we tried it already? Having a glob of untyped context in Angular v1 was always bad, and I refused it even when it made me look like a dinosaur back then. But React was a great pattern for complex code, and I immediately switched to that. I would switch to something tomorrow if it kept those good parts, like handling complex apps, but didn't have to render everything a minimum of two times server and client. Maybe a new winner will emerge.
Experience is still good to have. It doesn't === dinosaur. Instead, it has saved me a lot of misadventures.
Is it size, do you think? To me it's more about how much interactivity you want the app to have. If I'm making an online shop, I don't think I'll need tons of interactivity, so I don't see the codebase ever outgrowing simple SSR views. If I'm making something much more dynamic, then I probably would go with an SPA from the beginning.
What kinds of things have you seen that made sense to start with Django but then had to be split up, and why did they need to?
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.
There’s a lot of “slack” in the industry that we get away with. Ridiculous incidental complexity, far-out frameworks, architectural astronautics etc.
But if you care about “adding value” or your business succeeding, tools like Rails/Django are way to go. (And btw, use a RDBMS ffs)
I agree; at some point someone said that I'm "like the anti-vaxxer of frontend development", because "I'm not listening to the experts". Hmkay.
Maybe I'm old and stuck in my ways. But telling people they're like anti-vaxxers because they disagree with them (with caveats: "SPA is nice for some things, but for many template-driven apps are better") means you're just as much "stuck in your ways".
