Storage-Facilities Architecture is an attempt to delineate a general solution for typical problems appertain to web software development. If you browsed the source code of any open-source web application, fully developed using JavaScript in particular, you would probably find that its architecture is brutally shaped by a framework or, even worse, by a library (there are tools proclaimed as libraries, but they are usually used as frameworks in the sense that they specify at least one part of the architecture). Developing a large software project bounded to a specific framework is a pernicious decision which is significantly what led to the wide range of irrelevant, to the art of software development, titles: React Developer, VueJS Developer, ExpressJS Developer, ...etc (“Software Developer” or even “JavaScript Developer” should be sufficient). This article prescribes a general architecture, perceived as a receptacle box in which various frameworks can be plugged, that web developers can implement regardless of what technology will be used in the future.
This article is a plea for mature industry!
Read the full article on Substack:
https://open.substack.com/pub/moehab/p/storage-facilities-architecture
Top comments (3)
Sorry to say so, but it really seems like you have no idea of the constraints in which these paradigms exist. This reads like the reply of a LLM. Why are there frontend frameworks? Because they serve a purpose: to provide an abstraction over plain DOM access that is scalable and helps code reuse.
That there's a lock-in with some of the frameworks is because they have each their own set of compromises and rules, same as in the back-end world. The lock-in to certain frameworks is mostly due to management. A react developer will take a few days to learn Angular, Vue, Svelte, or Solid.js.
No doubt they serve a purpose, they provide an abstraction over plain DOM access...etc. But is that all what they do or being used for?
In most cases, they are used beyond that purpose... they literally shapes the architecture (solution) of the software problem in hand (managing the state for instance).
And so my proposal, so to speak, is to use frameworks as plug-ins in our own architecture rather than letting the architecture evolves and grows in according to a specific framework. Noone said that we should completely abandon frameworks!
If we did design a well-thought-out architecture, and used frameworks only as plug-ins, using certain framework in the project would require only a few hours reading the documentation (and so it's a decision that should be taken late in the project). However, I'm just guessing; I have not tried it yet.
You should have a look at mitosis: github.com/BuilderIO/mitosis
However, even that requires more than a few hours. You can't abstract development away, you'll only outsource it.