This is totally up for debate, so I figured I'd ask.
For further actions, you may consider blocking this person and/or reporting abuse
This is totally up for debate, so I figured I'd ask.
For further actions, you may consider blocking this person and/or reporting abuse
Ingo Steinke, web developer -
YUVRAJ SINGH CHOUHAN -
Antonio | CEO at Litlyx.com -
Baltasar García Perez-Schofield -
Top comments (34)
I was inspired to ask based on seeing this on Twitter, which I think is a good take, but could spark further discussion
For me this was never a fact open for debate but simply accepted software engineering knowledge since the Johnson & Foote paper Designing Reusable Classes (1988).
React is a Framework
To be fair, this is only a superficial distinction.
Preact has examples for using WebComponents from within Preact and for using Preact within WebComponents on its docs.
I can use D3 as a framework around React and React as a framework around D3.
Who calls who isn't that important in the end.
It's an important distinction.
There is no rule stating that a framework cannot use the underlying infrastructure - as Web Components are part of "the platform". In fact a framework's role is to abstract away the necessary micro interactions with a lower level API for the user code it invokes.
Of course libraries do that as well but in a call-through manner. The user code calls the library, the library calls the lower level API and then returns (usually) cleanly to the user code without any parts of the library remaining active, on the call stack or otherwise.
Contrast that to a framework which is typically instantiated separately at runtime but then remains independently active calling user code when it deems fit to accomplish some task.
With a library the user code is in charge, with a framework the framework is in charge of the user code (i.e. inversion of control).
That doesn't change that Preact is calling the user code. It simply means that Preact's scope is limited to the scope of the Web Component but Preact itself is still behaving as a framework.
React is the framework for the view components.
D3.js is a library (as far as I can tell) for data-driven DOM manipulation which transforms data to a representation inside the DOM. Now if it has facilities that support real-time data to DOM transformations it may very well have the capability to act as a framework.
The fundamental issue in front-end discussions is imprecise usage of terminology. The term "framework" is used when "application framework" is intended. While application frameworks are frameworks not all frameworks are application frameworks.
Software engineering had already established what framework means before the World Wide Web went live.
Using the term too broadly leads to inaccuracies and contradictions which impedes communication as evidenced by these endlessly recurring "library vs. framework" discussions.
Wow thank you for concisely presenting your thoughts in words. What you have shared is precisely what I had been thinking for the longest time. For the past 5 years in the JS community, it seems like the there are endless discussions of topics that honestly had already long been established with clear, albeit sometimes verbose, explanation.
To me - library is just one of the layers of the framework, like React is a library for building user interfaces, so in order for it to become a framework, it would need a router, data layer management, and "enforce" structure, which frameworks like EmberJS/Angular do. Frameworks are usually opinionated. Libraries are pieced together to make your own framework.
This is exactly the thing I came to say here.
React is a library and as such, it "gives you tools to build your own toolbox".
Rails is a framework and as such, it gives you opinions on how you should do things with its own tools/solutions.
From the same article:
Because "frameworks shape your code" they are imposing their own constraints that shape (, constrain, and impact) your solution architecture—that in my mind is expressing an "opinion", a vision of how things should be done.
So frameworks are inherently opinionated.
Concretely one can move from React, to Preact because Preact deliberately mirrors React (to a point). It's going to be more work to move to something like Inferno or even SolidJS. By the time we get to Svelte we're mostly talking about a rewrite.
To me the whole "React is unopinionated" narrative is mostly marketing because it's less opinionated than other frameworks which by design are more prescriptive—because their community values:
"There should be one-- and preferably only one --obvious way to do it."
PEP 20 – The Zen of Python
I think React has elements of both a library and a framework. But I won't argue about it, I've seen people argue about it and it's a dumb thing to argue about :) In the end, it doesn't really matter which label we slap on it, it is what it is regardless.
I like to think that if a library is a tool, then a framework is platform. You utilise a tool to build upon something, but you build on a platform. A framework is rather self descriptive IMO. It is a scaffolding on which you build your system. A library is a set of tools you use to build your system.
A library is a small toolbox with some code provided to you to achieve small things, like jQuery.
A framework, is a bigger and more structured approach that invites you to follow specific patterns to achieve specific goals.
The difference is not that big of a deal overall IMO.
If you shout in a framework you don't get thrown out?
this ^
It's right there in plain English, already. When you use a framework, you are constrained to work within the frame. When you use a library, you are free to choose whatever books you want, and use them how you want.
That might sound like libraries are preferable to frameworks, but the constraints imposed by a framework can be beneficial whereas a library full of books can easily lead to analysis paralysis.
I have some (quite possibly odd) ideas:
A library does one thing.
But a framework works with many library's or does everything in one task. Basically a toolkit.
So for example:
A framework dictates your code's architecture flow, whereas a library is something you call and can fit in to whatever structure you'd like. An illustrative example for me was learning
egui
, a library for defining UI elements, by usingeframe
, a framework built aroundegui
. I tried just usingegui
on its own, but it would have required a lot more reinventing the wheel, and making design decisions thateframe
dictates for me in a way known to work well with this library.To me a library is plug and play code WHILE a framework is not. If you have a web app you can have a whole lot of libraries but probably only one framework. And libraries you can disable and enable them as you pleases, even replacing one with the other. With frameworks...replacing a framework means rewriting your code base. Hence not a big fan of frameworks at all. Huge proponent of vanilla code.
I agree with your example. A framework is the basis for a project (think create-react-app), a library is bolted on top (e.g. jQuery).
It gets interesting with petite-vue, which provides a bolt-on solution for framework-like features. Not sure how to categorize that.
This starts it effectively making it the "main program"
This is user code that is called by it
therefore it (petite-vue) is a framework.