All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?

If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?

Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.

sounds like someone has a bad case of not-invented-here

Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.

I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked.

Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.

Do you work alone though? Do all people in your team agree with your technical decisions? If you left the team, would someone be able to maintain and improve your hand-rolled framework?

This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.

so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time.

as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect.

beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it.

you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth.

in the end, frameworks aide results beyond the ability of a single coder to implement on their own.