Practical approaches to creating and scaling frameworkless applications about manifesto

[francesco-strazzullo]

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:

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

[oliverturner]

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.

[c62eu19]

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!

[Amin52J]

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.

[francesco-strazzullo]

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!

[Amin52J]

@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.