Hi! @francesco-strazzullo asked me for feedback for this manifesto over at Twitter. Instead of trying to fit it in a tweet, I'll open a discussion issue here. Feel free to close it when you deem the conversation is done.
The difficulty for this manifesto is, generally, that it is hard to define a constructive position when it's formulated in the negative.
Take a hypothetical example of a "meatless manifesto", that states "don't eat meat", and then gives many reasons (ethical, ecological, personal health) for not eating meat. The goal of such a manifesto might be to get people to change their minds and get them to stop eating meat, but it is not very helpful in defining what a healthy meat-free diet looks like, and how to live a ethical, ecologically responsible, and healthy life.
Similarly, the stub document an the open discussion issues here seems to be focused on "don't use frameworks", and raising awareness of why you should not use them. This is a great start, but it's not helpful for developers like myself to discovering a path to writing, scaling and maintaining applications in an effective, responsible way.
What I would like to see is a practical guide to creating a non-trivial frameworkless application.
By non-trivial, I mean an application that:
- is expected to grow large over time
- is expected to change over time as requirements change
- is expected to be worked on by a large, changing team consisting of varying levels of experience
- is expected to have good user experience
- is expected to perform well (as performance is UX)
- contains features of non-trivial technical complexity
By practical guide, I mean:
- How do you get started?
- How do you approach architecture?
- How do you communicate and document the principles, practices and patterns of your application?
- What kinds of architectures do you see emerging, that differ significantly from existing "frameworks"?
- What kind of process do you follow that allows to evolve your architecture consciously as the team evolves?
- When is it ok to take on dependencies?
- How do you do all this with a reasonable amount of effort?
I don't pose these questions because they are hard to answer. I pose them because I would need to see how "frameworkless" can answer these questions.
I absolutely agree with your objectives of "deliver quality software in reasonable time" and "avoiding technical debt". I just don't think that shunning tools and dependencies is necessarily the right way of getting there.
Every non-trivial application will need a framework. Either you buy one off the (open source) shelf, or you will end up writing it yourself. The primary purpose of the framework is to define a structure and shared practices for working of a piece of software. The secondary purpose is to do it in a way that is more efficient (in both development time and runtime) than doing it without.
By writing that framework in-house within your application, you presume that you are taking on less technical debt because you understand the code that you just wrote, and so you feel at peace. This is commonly called the "Not Invented Here" syndrome.
I'm afraid that you are actually taking on more technical debt. The old saying is that "every application without (technology X) contains an ad-hoc, informal, poorly documented, bug-ridden version of (technology X)".
When you, the grand architect(s) of the software leave the company, is the software going to be more or less maintainable than if it were if it was written with a popular framework, even if that framework one days goes out of vogue? What is the difference for the team maintaining code that you wrote in the past, and the code someone else wrote?
The open source community is a fantastic collaboration of incredibly smart people. Libraries like React or Vue and their surrounding ecosystems represent an immense collective effort of creating a common baseline of well-defined, well-documented, well-performing practices. We call the software component of these projects "frameworks", but as much as software, they are frameworks for communication, collaboration and innovation.
By stating that you believe you can do better is a testament to your self-confidence. I certainly don't possess as much faith in myself, and by extrapolation, to the average software developer or software development team.
So, to summarise.
Is it possible to write large scale software without frameworks? Obviously yes.
Is it possible to choose the wrong framework or tool for the job? Absolutely yes.
Is there inherent risk in taking on dependencies at the core of your architecture? Sure.
But how do we actually do better? How do we "deliver quality software in reasonable time" and "avoid technical debt"?
I don't think there's a "right" and a "wrong" here -- it's possible for two people to look at the same evidence and come to two different conclusions.
I am willing to listen to your ideas with an open mind, and I'm interested in having this conversation to learn what I currently don't understand.