Statement

No-Framework Principle in Frontend Development states that Developer should not rely on framework utils/tools/methods to build dataflow or data structures.

Instead, Developer should rely on a language and well-known libraries to build and maintain them.

Developer should go for a codebase that splits into two branches: Framework-Based and Framework-Free and provide another integration between. Shortly: good and isolated APIs.

The framework should take care of initiating, storing and reacting to updates of external data. On other hand, a Developer should choose right tools to better support the integration of the external data.

Though there are cases when a part of the flow could only be implemented in a way that is well-supported by framework. Or local object environments where data is not going beyond itself and has no side-effects.

Problem

Writing components often involves establishing data flow/structures locally or between other components. This usually done by abusing framework (e.g. using React Hooks), which to accomplish correctly requires learning the framework deeply that leads to a learning curve just to support a data flow/structure.

Moreover, this tightly couples a data flow/structure to a framework, which kills reusability across other frameworks and puts additional burden to always stick to latest updates of the particular framework for maintenance.

Afterward

There is a noticeable movement to a similar paradigm, like this one: https://pureweb.dev/.

And people are tend to ask for alternative approaches for handling reusability like bit.dev and such, which stores components in a specific way allowing better reusability across FrameWorks.

The web itself is striving to provide much better support for native Web Components

Though I don't think we should just quit the FrameWorks, but rather they should be better optimized and adapted to handling, reusing and declaring the data-flow independently of their own code.

The original "zero framework manifesto"