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 tend to ask for alternative approaches for handling reusability like https://bit.dev/ and such, which stores components in a specific way allowing better reusability across a chosen framework.
People more often question if there is a better alternatives to status-quo frameworks. That's why we see new ones pop up like SolidJS and proposals like Signals.
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.
Top comments (8)
I like the way this is framed
Thanks! It is actually very interesting. This is the issue I have been championing to solve for a long time. The lest is bound by a framework the better. Let's take react with libraries like SWR or react-query. You can do that in pure JS and inject into the library (or framework like Next.js) as needed. I made a small plugin as example here. github.com/MattCCC/fetchff (let me butt it in as ad here ha), but the point here is that it is a zero-dependency pure JS solution. It means you can use it with any framework. There are more plugins out there in the ecosystem that do not require a framework to operate nor they ever should.
This is right to the point. All those mess that react environment has created is only valid for react, if react changes anything, it breaks all the tools, which leads to endless maintenance burden.
However, (almost) all the tools for react can be created without react while being much more transparent, understandable and still valid for react with almost no maintenance. They could be final eventually.
This doesn't mean I don't like react - I like it very much, but I'd like to rely on it as a replaceable library.
Yes, we are essentially discussing the same thing. The React is great but it should do one thing and do it well. Right now with things like Next.js or SWR we risk going towards being vendor locked. There are better alternatives in Pure JS.
When I was posting, I couldn't expect that there would be people that shares the same opinion. Moreover, I discovered the links (e.g. puredev) only hours before publishing. It took me years to come to realization of what I described in this short article, so thank you for you feedback!
Thx 4 (pureweb.dev/) such a meaningful site. I was trapped a bit with my React project which lead me to make a step back. So I started working the core idea on a single pure HTML, such a great feelings like my chain are removed.
I think it all boils down to what you want to build. If you need a "rich UI" with complex interactions and components, there is no way around a framework, otherwise you have to re-implement too much of what they deliver. On the opposite, if you just want a "simple" website, with default HTML elements, then sure, go ahead vanilla. The framework would then just be a burden.
My article is not about what frameworks do the best (reconcile, templating, ...), but about the things that all have problems with - dataflow. What I claim is that the data (or state) management should be a problem of a developer, not a framework itself. The state/data should be separated from the code written using framework.
Kind of headless UI.