frameworkless-movement / manifesto

The Frameworkless Movement Manifesto

Frameworkless Movement Webiste

https://www.frameworklessmovement.org/

Setup

npm start

manifesto's Issues

Mindful Decision

With the PR #32 we changed the principle The choice of a framework is a technical choice and thus should be made by technical people, but to make mindful decisions business needs should be kept in consideration. into the more concise (and better) The choice of a framework is a technical one and should be made by technical people, taking business needs into account.

While I really like the new version, we lost the concept of mindful decision. What do you think? Should we try to rewrite the principle again or is it good enough?

Why GPLv3 License.

I think that GPLv3 license does not fit with these kind of projects since is mostly related to software artifacts and not generic publications.

What about picking a Creative Commons one?

https://creativecommons.org/

Pinpoint the problems of excessive relying on a framework

this is one the questions created by @apiraino in issue #1.

Quoting @apiraino...

maybe examples of bad framework usage (and why) and provide an alternate approach (based on your experience)

Visual Identity

Hi everyone,

any plans for visual identity of manifesto?

what does "frameworkless" means for a designer?

The technological choices on the code of a software produce a big impact on the user experience as they promote or make specific uses more difficult.
These choices impact on important aspects for those who contribute to the project with experience design activities. For example:

• how the user can send or receive data
• how the user will be able to use the data
• how easy it will be to change the design in the future
• how easy it will be to update the project with the possibilities offered by emerging technologies and web APIs
• how the user interface can be designed
• on the rhythm and pace of the activity

Vice versa, design activities are those that more clarify these elements.

So, in our effort to create awareness about frameworks and their impact, we think it's important to put the other experts who make decisions about the software in our discussion.

We are against a model where "everyone protects his own point of view" and acts in separate ways and times. Instead, we are in favor of making shared decisions, thinking about the good of the whole project.

I invite everyone, therefore, to contribute to this thread in order to improve the assumptions of the movement suggesting changes to the current text.

Ui-editor - a tool that generates framework code

Hi,

My name is Vetrivel. I am building a concept tool to build components. The tool generates code for a targeted framework and currently generates code for reactjs.

Saw your post and I though I'll share my work hereas the vision seems to be the same.

Here is the link to my project. https://github.com/imvetri/ui-editor

Here is the video for code generation demo https://vimeo.com/386239546

I recently removed some features from the tool which wasn't needed for the direction I'm going forward. But if you need help / questions / build POCs feel free to let me know.

Link to Awesome Frameworkless?

Given that this manifesto is our main way to communicate outside, I would like to add a link to our Awesome Frameworkless list. https://github.com/frameworkless-movement/awesome-frameworkless

I'm not sure that is a good idea, because I would like to keep this manifesto "free" of links. What do you think?

Define scope of the proposal

this is one the questions created by @apiraino in issue #1.

Should I use raw web components?

I got informations about the new Web Components standard and I'm thinking to use them in building the front end of a web application but I'm worried about a thing: in many places I read that they aren't meant to be created manually and used "raw" but more as plumbing to use in the making of front end libraries and frameworks that needs a way to specify reusable and encapsulated interface components.

What's your stance on that? In the context of a small project (in short it's a single page application with 3-6 views) should I ignore these warning and manually build Web Components in order to have a frameworkless application (I plan to include just some lightweight libraries) or it's better to find a good front end framework?

When do guidelines for a frameworkless approach become a framework?

When you start forming guidelines and practical approaches for a frameworkless application, aren't you actually creating a framework?

What's the definition of a framework and when does a set of guidelines become a framework?

English translations for Quest

At present the Quest documents are all in Italian, might require the same in English

How to sign the manifesto?

Manifestoless Manifesto

Where is the manifesto? Is it manifestoless? :D

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.

Better name?

Hi @jevakallio. This issue is related to your issue #8. But I would like to concentrate on the first part of your statement on this specific issue. When you talk about the name of the movement and how is difficult to create a constructive position when it's formulated in the negative.

You made our team think about it. The point is, you're absolutely right.

The purpose of this movement is not just to make people write code without frameworks. But it's also, and perhaps more importantly, on how we as developers make context-aware techinical decisions about frameworks. And to make people understand why it's important to consider a frameworkless approach as a solution.

So a better name could be "Good Context-aware Techincal Decisions about Frameworks" Movement. 😄

But as you can understand "Frameworkless Movement" has more impact, even if it's not exactly what we mean. Now the I hope that I explained better our purpose, I hope that someone can come up with a better name.

In the meantime, we will change our README in order to make this message clear enough.

Thank you very much to help us making our point as clearest as possible.

"abuse of the use of frameworks"

Taking a look here https://dictionary.cambridge.org/dictionary/english/abuse, it seems that abuse it's a too strong word.

The main meaning of abuse is

to use something for the wrong purpose in a way that is harmful or morally wrong

I don't think that this is the meaning that we want to pass, what do you think?

about `lack of knowledge regarding technical debt`

Is in the purpose of this movement suggest some libraries or component? If yes, ... could be present here at least name of good patterns to use? Or libraries? Or part of frameworks.

What Frameworkless is not?

this is one the questions created by @apiraino in issue #1.

Quoting @apiraino

perhaps clarify a bit more what frameworkless is not (build your own library? reinvent the wheel? NIH? etc.)

Frameworks as "tools" to learn

this is one the questions created by @apiraino in issue #1.

Quoting @apiraino

from the manifesto: [frameworks] are the most powerful tool to learn how to code without them not sure about the meaning of this.

Frameworks increase technical debt the more they try to impose on your design

I think it should be pointed out that where there is a particular dependency it's be to look for a lighter alternative that still accomplishes the same goal but without imposing particular design patterns on the developer, so that the developer is more empowered to make changes in future. For example: Nancy over ASP.NET, Sinatra over Rails, Kemal over Amber.
What's meant by 'framework' here should also be more clearly defined, it's not clear how large the scope of what you're referring to is but I generally define frameworks as being libraries that carry design baggage.

"make deliberate tech decisions."

I'm thinking about the word deliberate when talking about tech decisions. Taking a look at the dictionary the word deliberate means:

(often of something bad) intentional or planned

or

A deliberate movement, action, or thought is done carefully without hurrying

I think that in this case, it's better to use aware or conscious. The point is to make decisions considering the natural tradeoff of every decision.

What do you think?

The meaning is not so clear in these passages

1. "They are the most powerful tools to learn how to code without them."
2. "Having clear opportunities and constraints of each framework it will be easier make the right choice, also it will be clear when you don't need a framework"
3. "Frameworkless means, however, don't assume that in the software I'm writing I can afford to delegate this responsibility and depends on other (library for example) to solve a specific problem. Or worse: don't reinvent the wheel and bind hand and foot to a whole framework even if I don't really need"
4. "But it means taking a conscious decision about if we want to get help to do our own job from tools already exist and in what way"

The syntax above does not convey a clear message. I cannot understand exactly what you are saying.

Lastly, in the section What Frameworkless Movement IS NOT, the last two arguments are about what it DOES mean, so it is kinda confusing too. Maybe they should move to the purpose section??

:)

Best Practice Guidelines for Javascript Applications?

This movement will likely not fly without the guidelines someone suspected of being a framework in themselves once they are written. Guidelines help to understand what good components are and why they are good. A software framework (merely) tries to enforce getting out good components even without understanding why they are good.

The guidelines should assume that one does not use a framework with some reasonable definition of 'framework' as you did with the simplistic, but, I think effective: 'a framework calls your code' (in contrast your code calls a library)'.

The guidelines should describe what to do and what to avoid to get reusable software, in particular UI elements/components, with plain Javascript. I wouldn't expect to find, for example, a suggestion to use web components or not, but rather abstract recommendations what to watch out for regarding the non-exhaustive list

• creating, changing and removing DOM structures
• maintaining state
• attaching, removing and handling events in a non-intrusive way to facilitate reuse
• defining CSS rules for the component with reasonable prevention of littering the global namespace
• ...(you name it)...

These guideline could even be used as a checklist for libraries to include in a project, assuming that if too many guidelines are not followed by the library it may need extra thought before being depended on.

A lot of 'best practice javascript' sites are out there, so maybe some have good guidelines already, but the ones I looked at so far have 'coding best practice' and not much about 'design of reusable components'.