Write Libraries, Not Frameworks

Yeah. I prefer Rails, but I'm fluent in python too, and the lack of explicit module importing was a mistake in my opinion.

Strapi. I just want the CMS/admin panel. I don’t want the... well everything else

I agree with what you say here to a large degree. We were able to reuse things like external service connections, accounts, contracts, some of the requirements documentation and some of the already provisioned hardware, VMs and so on. Those things are not trivial to put together and easily saved us several months of work.

Where I think I part ways with you is with this "they did as well as they could using the choices and resources they stuck with and I happened upon the project with 20/20 hindsight". One of the big lessons we've learned as an industry involved in software development is to start small, iterate often, get feedback from users. What I see time and again with these types of overblown space elevator projects is a kind of fundamental...immaturity -- the people who run these don't seem to understand how to achieve results with the minimum required to do it.

They've never started small and iterated to large. The projects they've worked on have all been so enormous, and have taken so long, that they have very few data points to draw lessons from. Each iteration and growth cycle in a mature project creates lots of information that can be reapplied elsewhere. But for people who've only ever grown up in large enterprise software projects, that's the only approach they know, and there's only a handful of lessons they've learned.

It's not only architecture astronauts, but the entire ecosystem that supports "enterprise" software engineering: vendors, consultants, scaled agile experts, design tools -- even university programs that churn out enterprise ready engineers. The appearance of these things, and how widespread they are in certain circles, demonstrates how those circles have regressed and tossed into the rubbish bin the lessons that we've learned. The penalty that's being paid is that these same lessons have to be continuously relearned again and again, but instead of pushing against outside models of how to do things (e.g. trying to adopt physical engineering approaches to software), we have to push against our own industry.

When you go against billion dollar enterprise software industries, you end up sounding like a heretic. It's really only when you get a long portfolio of success stories can you succeed. But that's very hard to get in today's climate where people spend their entire careers trying to kill ants with nuclear weapons dropped from the orbit of Mars.

>Libraries aren't everything, but they should be preferred.

The story is much much more complicated than this. Every single one of you is using a framework everyday, that is unless you program in assembly language.

All Programming languages are highly opinionated frameworks on top of assembly languages.

When you know this, then you know that you can't just say something simplistic like libraries are "preferred."

If all programming languages are frameworks on top of assembly language then frameworks are not only preferred they are Required for humans to make sense of complexity.

When you write a framework like django within the framework of python you are putting a framework within a framework. It's similar to writing a compiler that compiles some PL into python. You are building layers and layers of interfaces between your logic.

For every extra layer you add, two things, in general, happen:

     1. Complexity decreases
     2. Restriction increases

So when someone writes an article like this, what they are actually saying is this:

    "The complexity and restriction balance in the current framework/programming language 
     strikes the right balance so in my opinion (keyword)
     writing another framework on top of the current framework will
     increase the restriction to the point where the trade off is not worth it."

When writing a library as opposed to a framework, what people are essentially doing is augmenting the capabilities of the current framework without creating an extra layer of abstraction. Another good way to think about it is that frameworks are equivalent to extra layers of abstraction and therefore the benefits and downsides of adding more layers of abstraction are equivalent to adding more frameworks. So it's really not as simple to say that "Libraries are preferred."

The story actually gets even more complicated then this. I spoke previously as if there is a trade off between Complexity and Restriction. While a decrease in complexity is always good, an increase in restriction is not always bad.

Take for example ELM. ELM is a language (or framework) that compiles to javascript and HTML. It is more restrictive then javascript due to type checking. Yes type checking is a framework that decreases freedom and increases restriction. But people think type checking is a good thing. Why? Well, the ELM type checker/framework is so powerful that it restricts you from ever writing a run time error. You absolutely do not have the freedom to write code that has certain bugs in ELM while in javascript you absolutely have the freedom to pollute your code with thousands of obscure bugs.

Restriction can be good, really good. In fact restriction outside of testing is our greatest tool and weapon for combating the problem of bugs occurring as a result of too much complexity.

In short, I don't like this article because it doesn't illustrate the full story. It kind of biases against frameworks. The author did not think deeply enough, he thinks of frameworks in terms of things like rails or django, but he does not think of what a framework is from a more general perspective.

Keep in mind, react or how react is used is basically a framework as well. Nobody uses it as a library, they prefer the component abstraction to take over the entire notion of the DOM.