No it's because I have to maintain the frontend stack and it rots faster than raspberries left on the counter. If you write your frontend like it's 2008 it will continue to function unmodified until the heat death of the universe. And you wouldn't believe how many apps fit into that feature-set.

If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux.

Just React << HTMX < React with Friends.

It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.

There you go, claiming another silly choice by frontend for using something built in the last 15 years will rot.

It's just not true in my experience.

It's not a silly choice, it's a trade-off. One which becomes frustrating the moment the code isn't being actively developed anymore. People choose to use unstable technology all the time for various reasons, it's valid for evergreen codebases where you're continuously updating deps. I argue it's bad if you expect your codebase to be "done."

An unmodified frontend will also function the same exact way until the heat death of the universe.

This isn't really much of an argument. The defining characteristic of a non-rotting codebase is one in which you can update your dependencies and language version every six months or on CVEs with only minor changes.

If you think rotting sounds too negative how about "maintenance unfriendly."

Your argument was about unmodified code, not mine.

If you only want minor changes, don’t install new major versions.

How does that work in an ecosystem which is constantly releasing new major versions and not backporting security fixes to old majors?