Comment by cwizou
4 years ago
The pragmatic answer is that, for the the large companies usually behind those frameworks, they can have many independent teams that are working on split components, without marching on each other's toes.
But to me, there's a parallel to be made between both the newer trends of components and micro-services, and the old idea of Object Oriented Programming. In all cases, you get sold on the idea that everything should be cut down into tiny pieces.
Theoretically the separation of concerns has tons of merits, but in practice there are a lot of rough edges when those separate pieces have to interact with each others.
And the tradeoffs may not always be worth it when your project isn't on the scale of those large companies (it very rarely is).
I agree. The real difficulty in software engineering is at the seams where systems or components have to interact with other systems/components. The more seams, the more difficulty.
The key though is that componentization is useful when you find yourself writing the same code over and over again. That's where DRY steps in and says yeah this should be its own component.
This is one reason monoliths are great as an app structure, because they let you be as DRY as possible and have as few seams as possible (making a component within a monolith doesn't create an external dependency, no seam). Additionally, there are options nowadays (ruby on jets for example) that let you have a monolith repo structure but each controller endpoint gets deployed as a separate lambda. So you get to have your cake and eat it too.
The analogy really does work fairly well at every level of software engineering, from frontend components to backend services.
Yep, the way I see it is, how much abstraction are you willing to accept.
Intuitively you may not want too much, until you find out that maybe you could have needed a bit more because of the repetitiveness. So frameworks that give you the option to gradually increase it when you need are the best. And when the documentation follows those patterns it's really great (I'd put Vue in that category).
Usually the thinking was, while it may not make sense, it will someday when my project grows, so let's adopt it right away. And for years I would have said that was a decent advice. Nowadays I think that with some of the more extreme scales behind some of those trends though, it's not always as clear cut.