Practical approaches to creating and scaling frameworkless applications

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.

I can't help feeling that we've been here before and decided to use frameworks as a way of increasing the likelihood that our applications would be consistently architected and performant.

Is it possible to write large scale software without frameworks? Obviously yes.

Zakas' "Maintainable JavaScript" (2012) was a well-written guide to doing exactly this, yet I saw organisations fail hard even while attempting to follow its explicit instructions. My sense is that the reason they did so is because they needed to keep getting decisions right at every step, increasing cognitive load where a framework would have provided a well-understood abstraction.

Hi @jevakallio, for the "naming" part of the issue, we decided to split in a separate one #10 to help to keep this discussion on the practical guide.

I will try to answer your questions:

How do you get started? How do you approach architecture?

For our projects, we try to adopt the Emergent Design Technique. We start with the simplest architecture possible for our first user stories, and for every new story, we decide if we need to adapt our architecture. In many cases, we add a framework at a later time when we feel the need for it.

If you stick to this technique, the team will not write an internal framework. If they strictly follow the YAGNI principle, every feature will just have the code needed.

How do you communicate and document the principles, practices and patterns of your application? What kind of process do you follow that allows to evolve your architecture consciously as the team evolves?

This is a very thorny issue. Because if you don't use a framework you need to document every architectural decision that you make. To solve this issue, we're experimenting with Lightweight Architecture Decision Records, you can find more here. In a nutshell, everytime that we incur in a new pattern we create a Markdown file in the project's repo. This file has a specific format stating the context and the decision that we made. Most importantly every file has a "Consequences" chapter, useful to understand if that decision is a good one or not. Every new member of the team reads these files. In this way, we have a living documentation in the repo and, most importantly, every team member knows why we made that decision.

This approach is very useful also when we decide to use a framework, to help new members of a team to understand why we made that choice.

When is it ok to take on dependencies?

There's actually no real problem in taking dependencies, our point is not to say "No Frameworks is the way". Our point is to make people think about tradeoffs when choosing a dependency. IMHO I think that every time that you take some software from the outside, you are getting something useful. But you're also losing something else, most of the time evolvability, adaptability and longevity.

Sometimes what you get is more of what you lose, and so it's useful to take a new dependency. In that case, it's not technical debt, but a technical investment. On this topic, I suggest reading the posts written by Matteo Vaccari that you can find in issue #9

For example, if you choose a Framework like Angular and then your business changes drastically and so your software needs to adapt very very quickly. If Angular is not suited for the new features of your application it will slow you down.

The main point of this movement is to make aware technical decisions. To make an aware decision a team should not just consider what a software should do, but also the context where this software lives. In our company sometimes we use a Framework Compass Chart to map our non-functional requirements.

As an example, in the project that I talked at the start of my post, we had very high values of evolvability and longevity (talking about a decade). No framework out there could give us this two things. So we decided to go Frameworkless.

What kinds of architectures do you see emerging, that differ significantly from existing "frameworks"?

There's nothing wrong in the architectures behind existing "frameworks". But writing their implementation "from scratch" let a team to quickly adapt implementations to their use case, and not vice-versa. Another important point is that if a team really understand the power behind a new architecture, they can mix things up in a frameworkless application.

For example in one of the application where I'm working we have a declarative approach (aka React-style) in a part of the application; in another part, we're using two-way-data-binding (aka Angular-style).

This question lets me explain my personal position about open source community. I completely agree with you when you say:

"The open source community is a fantastic collaboration of incredibly smart people"

When I decide to reinvent the wheel I'm not saying that I despise the work of the community. And I don't think that my code is better of the code of React, Angular and other frameworks and libraries out there. What I hope is that, sometimes, my code is the right code, for the right team, for the right project.

But I am able to do that only because I learned from the community, and from the frameworks.

How do you do all this with a reasonable amount of effort?

I have to say that in most of the projects where we are not using a framework, our velocity is high enough. But this is possible because during these last years my teams and I studied how frameworks work under the hood.

This is another very important task of this movement. Understand, let other people understand, how frameworks work and how to work effectively without them.

Concluding this movement is about these main topics:

Understand how Frameworks work, in order to be able to work without them when needed
Make aware technical decisions: keeping in mind that every technical decision has a tradeoff.

In response to the original post and mostly relevant in the Javascript world, in my opinion, the many frameworks, libraries and tools that have been created were created to solve specific problems for the apps that were needed by those creators. Since those frameworks elegantly solved those problems they were then evangelized to the rest of the development world that it could also solve their problems. Most of the time those frameworks will solve half of the problems but then for the remaining problems, it's an uphill battle. Also, most people will adopt the framework flavor of the month and start diving into it without much knowledge of how it works underneath the hood or any of it's architectural concepts leading to a bunch of spaghetti code on top of the framework code which results in a maintenance mess and a ton of bloat.

In my opinion and with many years of experience, the use and enforcement of simple and strict coding guidelines and best practices will always lead to well-built, solid, small and maintainable apps without the need for the overhead of complex frameworks.

I'm ready to be fried!

I believe that the javascript frameworks and architectures are amazing, they have shown us new horizons we would never imagine before them, but the overuse of them is what's causing problems inside the community, workplace and the job market. In my opinion when you need to support SEO and slow internet connections you should not think of creating a javascript driven project, because of the size and the hassle to get the SEO work properly, which even if you do, you'll end up with more overhead and complexity than before. There are so many simple ways to start a SPA project without the use of any javascript frameworks and you may be surprised (as I have definitely been) that it's much easier to do it than expected. I recently created a boilerplate called Frameworkless-SPA that does it perfectly and makes it easier for developers to start up a framework-less SPA and wrote an article describing the theory and the implementation. I hope it makes the community think a bit outside the box and see all the options the next time they're thinking of starting a new project.

@jevakallio Back to your final point, I believe every technology whether it's a framework, a library or even a theory is created for a reason and for a need, but the ability to detect the needs and choose the right tool for the job is what makes developers different.

For example, in my opinion, Javascript frameworks are a perfect tool for creating online softwares (e.g. online Photoshop). I've used them for over 6 years now starting with angular 1 and falling in love with React almost 4 years ago but in the end I found myself always being in fear of tackling a project without them, as I'm sure there are tons of developers out there that are feeling the same as me.

So as a result, we always keep ending up with complex projects that are hard to maintain and we keep loosing time on trying to fix the problems that should've never been a problem in the first place, just because of choosing the wrong tool. I've personally seen that happen in at least 5 major projects ending up in failure or at best being a low quality, hard to maintain and costly project.

I personally like to draw the line between using a framework or not, where there's a need for performance, SEO and size (there are definitely more things to consider but these are the red lines for me). If these are not an issue in a project I'd go with the frameworks which by nature

are easier and faster to develop because of their nice APIs
there are more developers that already know the standards and the best practices
there is a lower risks of screw ups as the majority of the common issues are handled within their cores
their gigantic communities are always there to provide solutions

But on the contrary, for the other types of projects I mentioned, the framework-less approach would be tens of times lighter, faster (more performant) and SEO friendlier with much less unnecessary issues and bugs, which saves a lot of time and resource in development, and is more likely to end up as intended without having the maintenance problems.

Hi @Amin52J, I just read your article and it's quite interesting, can you open a PR in this repo https://github.com/frameworkless-movement/awesome-frameworkless to add it to the list? Thank you!

frameworkless-movement / manifesto