ernee

When we talk about software patterns, we spend most of our time discussing the _technical_ contexts they make sense in. Building an API? Use the gateway pattern! Extracting functionality from a monolith? Use the strangler pattern! Etc etc etc.

In addition to its technical contexts, though, every pattern also has a set of _organizational_ contexts that it makes sense in - and these are usually implicit in our discussions.

But these organizational contexts are what separate use from overuse, when it comes to patterns. Ever work on a project where it felt like the team used the Gang of Four book like a checklist? That’s a team that misunderstood the appropriate organizational context for patterns.

Misjudging the appropriate organizational context for a pattern can be a lot more subtle, though. For example - no startup with all the engineers working together ever needs microservices.

For the same reason, no small company should be using web components. They exist to solve big company organizational problems.

This statemenr doesn't make a lot of sense to me. Web components have many use cases. Maybe you mean small companies shouldn't use them instead of what?

Big companies need isolated contexts around portions of a page because they have dozens or hundreds of teams that each own little bits of UI, & they all need to do their work without breaking other teams.

If you have one team doing all your UI, all those isolation boundaries are unneeded overhead.