I use tech like HTMX because, as a team of one, I have no other choice.
I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted.
After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with JavaScript sprinkled in.
This year, I've looked at Node again now that frameworks like Next offer a middle ground with server-side rendering, but I'm still put off by the dependency graphs and tooling, which seems to be in a constant state of flux. It seems to offer great benefits for front-end teams that have the time to deal with it, but that's not me.
All this to say pick the right tool for the job. For me, and for teams going fuller stack as shops tighten their belts, that's tech like HTMX, sprinkled JavaScript, and sometimes lightweight frameworks like Alpine.
I use htmx on my current project, and it's like a dream. I'm happy to sacrifice a bit of bandwidth to be able to do all the heavy lifting in python. On top of that, it makes testing much much easier since it turns everything is GET and POST requests.
I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.
I have no love for unnecessarily bloated dependency graphs, but we can't have the cake and eat the cake too.
Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of
single responsability principles set of modules, kind of necessary to build a solve-all needs framework.
And it does that.
A bit like Angular, set to solve everything front-side. With modules not entirely tightly coupled but sort of to get the full solution.
And it did that.
Then we have outliers like React, which stayed away from trying to solve too many things.
But the developers have spoken, and soon enough it became packed in with other frameworks. Gatsby etc. And community "plug-ins" to do that thing that dev think should be part of the framework.
And they did that, solved most problems from authentication to animation, free and open source sir, so that developers can write 12 lines of code and ship 3 features per day in some non innovative way, but it works, deployed in the next 36 seconds, making the manager happy as he was wondering how to justify over 100k in compensation going to a young adult who dressed cool and seemed to type fast.
Oh no! dependency hell. I have to keep things maintained, I have to actually upgrade now, LTS expired,
security audits on my back, got to even change my code that worked perfectly well and deal with "errors", I can't ship 3 features by the end of today.
Django comes with a lot: auth, caching, csrf protection, an orm, the admin, form workflow, templating, migrations, i18n, and yet doesn't come with thousands of deps.
I know of a 15 years django project that runs on 2.7 that is still making money. It got reinstalled this month on brand new Ubuntu servers out of a rubbish requirements.txt, and it worked.
Django can also serve a boatload of concurrent users, way more than one would think. It is a boring, old-fashioned, but stable and very functional framework.
Maybe django is less so a dependency bloat than most other frameworks. Just called out the common consequences of getting more. You get more.
Npm projects are likely the most bloated by far, but also are java based projects, just look at Spring.
Calling out a python framework or some Go lean solution being the exception of the rule is fair enough, my point is developers expect everything and have little to do but rapid painless developement
I would love to hear about those asked to migrate their python 2.7 django ecommerce app to python3 since v2 is totally dead and unmaintained posing serious security risks. But sure if we forgo these things, and don't ever need to touch the code again, some frameworks have no downside. Makes a certain kind of developers finally be right.
Back in the late 90's and early 00's, armed with the experience of C, C++, Bash, and Perl, everybody knew it very clearly that "batteries included" is the correct way to create development tools.
I don't know about the current fashion of minimalism comes from. It doesn't bring simplicity.
While I agree with your comment, lumping these together somehow doesn't seem fair. As for C and C++, it took decades to develop package managers, and we can't still say we have standard ones (but I feel Conan is a de facto standard PM for C++).
Bash, on the other hand, should never have 'batteries included' because in this case the batteries are the rest of the system - coreutils and the rest. An Perl had CPAN quite early on, in the early nineties iirc.
C is completely without batteries, the stdlib for C++ was a great change and a big force towards people adopting it. The same happened with Bash and Perl (and people did migrate a lot of things into the later).
If someone releases a module that depends on nine other modules then their module will likely be promoted by the authors of the other modules, rinse and repeat.
Your story sounds similar to mine, and your choice to use HTMX has me motivated to check it out. The sum total of my software supports 5 families' lifestyles entirely on LAMP MPAs with no frameworks at all. Thanks for posting.
I'm using React, and I feel like I can manage as a team of one. But React has a huge community, which means lots of libraries for just about anything you need.
I previously used HTMX for another project of mine, and it worked fine too. I did, however, feel limited compared to React because of what's available.
Angular is falling off hard in the frontend frameworks race. And I totally agree about how the boilerplate and other things about Angular feels bad to work with. Other frameworks are far easier to build with, to the point where a 1-person team can easily handle them. React is being challenged but still has the biggest community, it's a much better place to start than Angular when evaluating frameworks like this.
All that being said, I'm glad HTMX worked out for you!
Angular 2 works fine out of the box, and already provides a good architecture that noobs struggle to come up with in "freestyle" solutions like React. Angular's bi-directional binding is way superior and simpler to use vs React's mono-directional binding: you can just use bound variables, no need to do complicated setState or use abominations like Redux. Vue also has bi-directional binding. Essentially there are many alternatives that are superior to React, which is where it is mostly because of fame and popularity.
You may of not used React in the past few years, but setState fell out of favor a while ago with the release of the useState hook and Redux (which I agree is an abomination) isn't necessary for 95% (imo) cases, again thanks to hooks.
For bound variables you can use MobX or signals in Preact.
The recommendation for React projects for the past few years has been to write everything using functional components vs the old class-based components. In function-based components, you can only use hooks so useState is that's why the parent comment is referring to.
I've felt the same way and it's good to hear I'm not alone. I feel like log4j should have been enough of a jolt to push back on dependency hell enough that devs would start writing directly against codebases they can trace and understand. Maybe this is just a byproduct of larger teams not having to do their own DevOps.
I really can't recommend Gatsby to anyone at this point. The sale to Netlify was the final nail in the coffin of Gatsby, the entire business was sold off only for the perceived value of Valhalla
I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted.
After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with JavaScript sprinkled in.
This year, I've looked at Node again now that frameworks like Next offer a middle ground with server-side rendering, but I'm still put off by the dependency graphs and tooling, which seems to be in a constant state of flux. It seems to offer great benefits for front-end teams that have the time to deal with it, but that's not me.
All this to say pick the right tool for the job. For me, and for teams going fuller stack as shops tighten their belts, that's tech like HTMX, sprinkled JavaScript, and sometimes lightweight frameworks like Alpine.