To be fair, this is only a superficial distinction.
It's an important distinction.
Preact has examples for using Web Components from within Preact
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).
using Preact within WebComponents
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.
I can use D3 as a framework around React and React as a framework around D3.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.