An interesting read on web architectures that discusses the cost of abstraction:
Some quotes:
Things that help us, can effectively tie our hands. We must tread carefully when standardizing any higher-level mechanism because it assumes a lot.
As a framework author, I understand this too well. I often say that in this field things are discovered as much as they are invented. What I mean by that is there is a certain truth/physics, if you will, to design decisions that when followed lead us all to similar places. It isn’t that these tools copy each other blatantly. They fall into the grooves.
The resonates. I’ve had the same experience working on Simple IoT – the useful patterns that emerged were definitely a discovery process. They emerged over time, not from some brilliant up-front vision.
The isolation or portability afforded by Web Components means that one could have multiple different components on the page from different sources. Now like the others prudence is in order. Similar to not wanting to write all your Microservices in different languages you might not want to author all your components in different frameworks.
But frontend is a much more restrictive space. The cost of each kilobyte of JS is not insignificant. It isn’t only maintenance why you wouldn’t want to mix and match but to reduce payload. And this is where the wheels start coming off.
This really gets to the heart of the matter. In the end simplicity and maintainability is what matters. And often that means using one framework, one build system, and keeping everything up to date. On the backend, this means monorepos and monoliths where possible.
Being able to mix and match loads of different languages and technologies is neat and necessary in some cases, but does not always lead to the best result.
Examples of not doing this is the Go and Elm languages. They both made it hard to integrate with legacy languages (C/C++ and Javascript). As a result, a thriving pure ecosystem has emerged which makes projects easy to maintain and reliable.