4 ms·
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
by guilherme-puida 4y ago
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?
- tgflynn 4y agoOnly 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.
- wonnage 4y agosounds like someone has a bad case of not-invented-here
- spoils19 4y agoSounds 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.
- phist_mcgee 4y agoI'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.
- wonnage 4y agoThis from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.
- guilherme-puida 4y agoDo 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?