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"
Top comments (22)
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!
The vendor lock in is very true and something that I genuinely dislike but also understand from a business perspective. Never been fond of React but do like Svelte but still I have been writing pure JavaScript for years now. But you do some very repetitive tasks and that is what a framework should solve. But every framework starts with a good ideology but at the moment it grows it becomes influenced by the possibility of becoming a cash cow and after a while those frameworks will try to sell you the silver bullet and look like all the other frameworks.
My approach is simple.. less dependencies is more...
As for the article, I like it but would also suggest to add a reference to the Web API's because a lot can be done without any external code.
Can you elaborate as for references?
developer.mozilla.org/en-US/docs/W...
Mmm, I think that would be too abstract, I reference something, this is because I mentioning it. Don't really want to just throw links so they to figure it on their own.
And my article is to tell that there are ways to make a relying on framework loose, not that you should forget about it because HTML, CSS and JS maintainers have an intention to allow people building apps using just built-in instruments.
However, that's still a good point, but I'm just saying it's not relevant here IMHO.
React coding leads to a lot of technical debt; to avoid it, the code needs to be constantly refactored. It dropped classes in favor of hooks, introduced suspense, and is now moving towards server components. I’m avoiding the topic of CSS-in-JS, the build stage, to keep the comment brief.
At each stage, a new refactor comes with its associated cost. React is not the only framework with this issue.
That said, you are completely right in your point. Of course, there will be others with different opinions, and each programmer should follow what they prefer.
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.
Modern vanilla can cover an amazing amount of ground with ES6 modules and a basic yarn/vite build/pack combination.
Two classic resources reflecting my own sentiments on these issues include:
The original "zero framework manifesto": bitworking.org/news/2014/05/zero_f...
A closely-associated "you have ruined javascript" rant: codeofrob.com/entries/you-have-rui...
I've used both of them (among other resources) as required reading in our onboarding process.
I've read these posts, that was refreshing 😀
But you know what I say? Why I need a random guy to come to share the precious information? I'm so tired of those "articles" about "what console.log can do" or "what diff between var, let, const" 😩
The more I go up webdev knowledge stairs, the more it gets harder, because only so few people are striving there...
Pretty depressing actually, each time I feel less wanting to keep working in Web, but I'm still giving it chances 😔
I like these ideas. I think tools like HTMX are helping "bridge" the gap between development without any framework and development solely with a framework. But also, as you said, it's not necessary to completely ditch frameworks. I've written a ~400 line JS script that could've been accomplished in ~40 lines with something like React. It's just about choosing the right tool for the right job :p
Mostly that the thing about managing html elements and setting attributes.
What I realized is that dataflow always stays the same, so it can be extracted out of the framework.
And usually the data-flow that is established using the framework takes even more lines of code (if we count it this way).
That's why we should use frameworks for what they do the best and keep away from they don't.
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.
I don't quite get it. IMHO the 3 big frameworks help exactly with that: straightforward data-binding. Facilitating the data flow is where they shine. I'd give the same tip, for interactive data-driven UIs, pick a framework, for something almost static, go vanilla.
Ok, thanks for the feedback anyway
No-Framework Principle in Frontend Development...
Says who?
Marko!
I go by the principle: Don't like it? Don't use it. 😉