This is my experience with all javascript stuff these days. If you leave the codebase even for a few months now you're spending days updating it to all the new breaking library changes. Worse, if your tooling is out of date you're probably spending a week just fighting to fix/change/update the tooling. It's the most brittle tech stack I've ever had to work with.
> These are surprisingly often easy to answer
I agree that maintenance costs are often overlooked/ignored, but I'm curious how you get answers on the costs. I've never found it particularly easy to get reliable information on maintenance costs.
I guess what I was thinking was: even if you can't quantify it, you can squint at the comparative advantages and trade-offs and make a qualitative, yet objective judgement call.
I just write everything from scratch. This seems like a lot of work but it allows me to focus on other things that usually have no deadlines.
Im dense enough to delete things and rewrite if they require babysitting.
Im sorry but I was never able to relate to this problem. All core libraries of javascript are atleast a decade old at this point and that too without any major breaking changes.
Express is almost decade old, react is more than a decade old, redux is almost a decade old, Tailwind is the only new thing but that too is almost half a decade old.
Can you share your package.json?
This is the missing criteria in the technical decision making, IMO. How reliant is the team on the recruiting/retention of the current size and structure of the talent, both on the team and in the wider community?
Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor.
A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!