The Frameworkless Movement

by Francesco Strazzullo

Some years ago, my friend Lorenzo Massacci during a coffee break at the office asked me “What does it take to make a software to last forever?”. Thanks to that question Lorenzo and I, helped by our colleagues Antonio Dell’Ava and Alessandro Violini, started to think about how various factors can impact the lifespan of a project like teams, technologies and the market situation. At some point, we started talking about frameworks and how they impact the development of a product in the long run.

Analyzing the projects of our clients and talking with other companies as well, we noticed quite an obvious fact, in the long run, frameworks tend to become a roadblock rather than a help for the teams. This happens for a number of causes. The most frequent one is that the framework becomes obsolete way before the actual code of the application. When this situation occurs usually the team start hating the framework and the codebase altogether, and usually, it ends with some people leaving the company or with the team proposing the big rewrite (that is almost never a good idea).

• While we acknowledged the advantages of frameworks, we started to help other people to understand how to work effectively without frameworks, and how frameworks may be considered a risk and not just an opportunity. At the time we were a company focused on front-end, but we found other people interested in the topic in the Java and PHP communities: the Frameworkless Movement was born.

The Manifesto 
 

The people gathered around the Movement started to write posts, preparing talks and workshops about a bunch of topics related to frameworks. Some of these topics included how to replace specific part of frameworks (Rendering engine, IOC containers, State Managements) with custom code, or the relationship between Frameworks and technical debt. I started to gather examples and material for my book. But it wasn’t enough. We realized that helping people to understand the risks of frameworks and to mitigate them is just one side of the problem. After a team learned that frameworks are a kind of risk and how to manage them a new problem arose: how to choose if the frameworkless approach is the right one for your product. We discovered that is wasn’t just a technical problem. It was something more complex, something related to people, market and other decision-making factors.We decided to gather together in one of the Flowing offices in Ancona, to try to write down a list of inspiring principles that we would use as a compass every time that we have to make a decision related to frameworks or, more generally, technical stack. We prepared a dedicated workshop helped by Emanuele Rapisarda. It was a success. At the end of the day, we had defined our principles and after a couple of weeks, we published the Frameworkless Manifesto on Github. 


The Principles

These are the four principles of the Frameworkless Movement, with some explanations on how to use them in the day-by-day job.

 1. The value of a software is not the code itself but in the reasons behind the existence of that code

The first principle is a technical version of the “Start With Why” rule. Before making any kind of decision you should know why the product exists in the first place. If in your company this is not clear, One of the thing that you can do is to ask your managers to build a Business Model Canvas and a Value Proposition Canvas.

2. Every decision should be made considering the context. A good choice in a given context could be a bad choice in another one.

This principle may seem a bit obvious: every senior software engineer knows that a silver bullet for software development cannot exist. The real problem here is to define and visualize the context. A good way to do that is to use Non-functional requirements (NFR). Quoting Wikipedia, an NFR is “a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours”. A tool that I developed to help a team to define and visualize the most important NFRs and the relationship between them is the Framework Compass Chart.

3. The mindful choice of a framework is a technical one and should be made by technical people, taking business needs into account.

This is a very important point. Choosing a framework is a technical decision and so is a responsibility of a technical team. But to make a mindful decision the only way is to consider also business needs into account. This is no easy task, but getting this kind of information from managers is an essential part of the decision-making process. 
 

4. The decision-making criteria that led to the choice of a framework should be known to all the members of the team.

It’s very hard to judge the outcome of a technical decision without knowing the reasons that made a team decide for a specific solution. This is the problem that this principle tries to address. A tool that I usually use to keep track of the decisions made during the lifespan of a project is Lightweight Architecture Decision Records. It’s a very simple way to track decisions and, most importantly, the context and the consequences of every decision. 

How to get involved 

As stated on the Manifesto, there is no way to sign it, “Sharing is how we would like people to sign this document”. We will use GitHub as a virtual meeting place and you can propose a Pull request or open a discussion with an Issue. Every discussion is welcome.Another way to help the Frameworkless Movement is to add material to the Frameworkless awesome list, a collection of posts or videos about working without frameworks.

About the Author

Francesco Strazzullo is an experienced front-end engineer, JavaScript trainer and co-founder of the Marca User Group (MUG). He has presented at tech conferences and meet-ups around Europe, is a technical reviewer for multiple tech publishers, and writes technical articles on his blog. He is always enthusiastic about trying out new APIs, and he is a firm believer that the best way to learn something new is to explain and teach it to somebody else. With a group of friends and fellow developers, he has founded the Frameworkless Movement, a group interested in developing software without using frameworks and spreading knowledge about making informed decisions about the choice and use of frameworks in front-end software development.

This article was contributed by Francesco Strazzullo, author of Frameworkless Front-End Development.