4 ms·

I think the key difference is that frameworks usually hijack your control flow, while library are not. But is framework necessarily bad or inferior to library?

I think the key difference is that frameworks usually hijack your control flow, while library are not. But is framework necessarily bad or inferior to library? I would like to present React as an example. React heavily regulates the control flow for its developer, leaving several specific hooks to allow you control the timing when your code would trigger. But React is an excellent piece of software. And assuming in a perfect world, if everything we interact are more or less functional or self-containing, then timing doesn't really matter, and uncertainty is thus controlled. In the end, the lesson here seems to me is, making good frameworks are much harder than making good libraries. For libraries, you need to make sure the building blocks are solid, but for frameworks you are defining a whole world for people to visit.

khant2021 6y ago
You are absolutely right sir 100% every one of starts doing like this he will be more successful
lhorie 6y ago
I would argue React is actually a great example why the article title is on point. Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year. Now consider tools like Redis or Postgresql. You can interface with them from just about any language and you can go years without your usage of them ever becoming unidiomatic.
- tanilama 6y ago
  DBs, IMO, are neither library or frameworks. They have their own DSL after all, which is close to programming languages. Programming languages are hard to categorize as either library or framework. They are libraries with full set of control flow primitives or framework that doesn't assume a particular flow at all.
  - lhorie 6y ago
    I don't consider Redis to have a DSL, and similarly, I was thinking about Postgres in the context of its client APIs rather than the SQL language. FWIW, there's another good example there: a client API centered around connections, queries, etc tends to be far more usable in terms of expressiveness and transparency than an overarching ORM framework.
- hesarenu 6y ago
  Could you point out which reactjs code has completely changed? I believe reactjs has remained the same, there are deprecations, hooks etc but basic premise is same.
  - tanilama 6y ago
    Yep. React went from React.createClass -> class xxx extends Component -> Hooks. But I don't think that means...change? The fundamental concept of react, that UI is a derivative from the state, stays the same. Class based or Hook (or just a really nice way to write Functional Component), stays the same.
    - mewpmewp2 6y ago
      Fc and hooks force you to think in an entirely different manner though. I would say it is an entirely different paradigm. And it is a much higher learning curve. For instance I see a lot of developers and engineers with 6 months and more experience with functional components and still misunderstanding the point of all of this. And these are smart people at high tier companies. The main thing being the meaning of having dependencies for useEffect and other hooks.
      - loquor 6y ago
        You're right. But this is the natural progression for React. React emphasizes stateful behavior in components. UseEffects with specific dependencies are actions which depend on the specified variable-set alone, while all the other infinite variables can change however they like. This concept already exists when we talk about state machines. That said, it isn't a smooth transition going from explicit lifecycle methods in class based components to useEffect hooks in functional components. But it refines the quality of the thinking, and the quality of the code overall, imo.
      - sfvisser 6y ago
        > The main thing being the meaning of having dependencies for useEffect and other hooks. This is 100% a result of how react (ab)uses the host language semantics to implement their DSL to describe components and has nothing to do with the conceptual nature of functional components themselves. It relatively easy to imagine a design that doesn’t require the dependency lists when capturing a callback closing over props or state. Not saying that design would be better or worse, just that it could exist and still leverage concepts like FCs, hooks, effects etc.
- strogonoff 6y ago
  This thread is peculiar. Framework <-> library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library. The reverse, bringing a single Angular component into an otherwise React-based webapp, is basically an oxymoron. Angular will generate e2e test scaffolding for your entire project, prescribe where to query data, expect you to follow a particular file layout in your codebase, and pull in enough machinery to rule out any auxiliary uses.
  - lhorie 6y ago
    Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form. FWIW, it _is_ also possible to render Angular code inside of React [1] (but again, this falls well into non-idiomatic territory for both Angular and React) Idiomatically, React is the only thing dealing w/ DOM in an app, and the way it's used is rather frameworky ("don't call us, we'll call you"). And when it's used that way - which is the vast majority of the time - the used idioms do vary heavily depending on when the code was written. Tying this back to what I mentioned about postgres: _within_ a React codebase, you need to be aware of the _semantics_ of the system: performance is achieved through reasoning about the semantics of things like shouldComponentUpdate/memo and even object identity, one needs to understand the semantics of stale closures and useCallback, etc. This is similar to having to understand the semantics of how various ORM idioms translate to underlying SQL queries. By comparison, the cost of any given jQuery idiom tends to correlate more directly with the underlying semantics, just as the cost of a raw SQL query does - i.e. it's pretty obvious without context how expensive `$('html').html(html)` is, just as it's more obvious what is the performance profile of a CTE vs a subquery, in comparison to whatever the high-level ORM idiom is (assuming, of course, that you know SQL) [1] https://medium.com/@balramchavan/integrate-import-angular-v6-component-s-inside-react-js-applications-da5cc03107b4 https://medium.com/@balramchavan/integrate-import-angular-v6...
- tchaffee 6y ago
  With Postgres that's because SQL has been a standard for decades now. And with idiomatic React the changes were largely not because of what you claim: not anticipating needs well enough. The changes in what is idiomatic were largely around discovering better ways of doing things, along with JavaScript itself changing. You can still write a React component using idioms from five years ago and it's still easy to read the code. React is very focused, and very simple. The main motivation for moving to the newer idioms is that you can make the code even shorter and more readable. It seems to me that they anticipated the need to keep up with the JavaScript language evolving quite well.
Frost1x 6y ago
>I think the key difference is that frameworks usually hijack your control flow, while library are not. Which is what should be expected. The point of a framework is to not only provide higher level abstractions to rapidly put together a certain type of application but to also provide a certain approach or set of approaches (a "framework") to follow as a guide during the process. This means some generalization should exist but if a framework is too abstract its really no longer a framework... it's a library. A library is supposed to simply provide useful utilities/lego blocks to assemble however you want and not necessarily give specific guidance or patterns. Certain common patterns of usage may arrive as a sort of emergent property based on fundamental library choices/structure but it's overall pretty flexible.
einpoklum 6y ago
> But is framework necessarily bad or inferior to library? The point is that more people, projects and even frameworks can use the library you write. If you write a framework, people have to drop whatever it is they're using and go with your framework. That's bad, unless your framework is the one to trump them all, which it probably isn't.
skohan 6y ago
I think React is somewhat of a special case, because a lot of what makes React good is that it mitigates a lot of the issues which make web painful to deal with: "the browser" is this highly inconsistent target, and Javascript doesn't have built-in facilities for modularizing code, and React gives you a sensible way to get consisten behavior and implement reusable components in this type of environment. Another way to put it is that for web you're already pretty heavily invested in the "framework" of HTML/CSS/JS wheather you like it or not. React is essentially just choosing another baseline framework to replace it, not adding a framework where none exists.

khant2021 6y ago

You are absolutely right sir 100% every one of starts doing like this he will be more successful

lhorie 6y ago

I would argue React is actually a great example why the article title is on point. Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year. Now consider tools like Redis or Postgresql. You can interface with them from just about any language and you can go years without your usage of them ever becoming unidiomatic.

tanilama 6y ago
DBs, IMO, are neither library or frameworks. They have their own DSL after all, which is close to programming languages. Programming languages are hard to categorize as either library or framework. They are libraries with full set of control flow primitives or framework that doesn't assume a particular flow at all.
- lhorie 6y ago
  I don't consider Redis to have a DSL, and similarly, I was thinking about Postgres in the context of its client APIs rather than the SQL language. FWIW, there's another good example there: a client API centered around connections, queries, etc tends to be far more usable in terms of expressiveness and transparency than an overarching ORM framework.
hesarenu 6y ago
Could you point out which reactjs code has completely changed? I believe reactjs has remained the same, there are deprecations, hooks etc but basic premise is same.
- tanilama 6y ago
  Yep. React went from React.createClass -> class xxx extends Component -> Hooks. But I don't think that means...change? The fundamental concept of react, that UI is a derivative from the state, stays the same. Class based or Hook (or just a really nice way to write Functional Component), stays the same.
  - mewpmewp2 6y ago
    Fc and hooks force you to think in an entirely different manner though. I would say it is an entirely different paradigm. And it is a much higher learning curve. For instance I see a lot of developers and engineers with 6 months and more experience with functional components and still misunderstanding the point of all of this. And these are smart people at high tier companies. The main thing being the meaning of having dependencies for useEffect and other hooks.
    - loquor 6y ago
      You're right. But this is the natural progression for React. React emphasizes stateful behavior in components. UseEffects with specific dependencies are actions which depend on the specified variable-set alone, while all the other infinite variables can change however they like. This concept already exists when we talk about state machines. That said, it isn't a smooth transition going from explicit lifecycle methods in class based components to useEffect hooks in functional components. But it refines the quality of the thinking, and the quality of the code overall, imo.
    - sfvisser 6y ago
      > The main thing being the meaning of having dependencies for useEffect and other hooks. This is 100% a result of how react (ab)uses the host language semantics to implement their DSL to describe components and has nothing to do with the conceptual nature of functional components themselves. It relatively easy to imagine a design that doesn’t require the dependency lists when capturing a callback closing over props or state. Not saying that design would be better or worse, just that it could exist and still leverage concepts like FCs, hooks, effects etc.
strogonoff 6y ago
This thread is peculiar. Framework <-> library is a spectrum, of course, but as an obvious indicator of React’s location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it’s a library. The reverse, bringing a single Angular component into an otherwise React-based webapp, is basically an oxymoron. Angular will generate e2e test scaffolding for your entire project, prescribe where to query data, expect you to follow a particular file layout in your codebase, and pull in enough machinery to rule out any auxiliary uses.
- lhorie 6y ago
  Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form. FWIW, it _is_ also possible to render Angular code inside of React [1] (but again, this falls well into non-idiomatic territory for both Angular and React) Idiomatically, React is the only thing dealing w/ DOM in an app, and the way it's used is rather frameworky ("don't call us, we'll call you"). And when it's used that way - which is the vast majority of the time - the used idioms do vary heavily depending on when the code was written. Tying this back to what I mentioned about postgres: _within_ a React codebase, you need to be aware of the _semantics_ of the system: performance is achieved through reasoning about the semantics of things like shouldComponentUpdate/memo and even object identity, one needs to understand the semantics of stale closures and useCallback, etc. This is similar to having to understand the semantics of how various ORM idioms translate to underlying SQL queries. By comparison, the cost of any given jQuery idiom tends to correlate more directly with the underlying semantics, just as the cost of a raw SQL query does - i.e. it's pretty obvious without context how expensive `$('html').html(html)` is, just as it's more obvious what is the performance profile of a CTE vs a subquery, in comparison to whatever the high-level ORM idiom is (assuming, of course, that you know SQL) [1] https://medium.com/@balramchavan/integrate-import-angular-v6-component-s-inside-react-js-applications-da5cc03107b4 https://medium.com/@balramchavan/integrate-import-angular-v6...
tchaffee 6y ago
With Postgres that's because SQL has been a standard for decades now. And with idiomatic React the changes were largely not because of what you claim: not anticipating needs well enough. The changes in what is idiomatic were largely around discovering better ways of doing things, along with JavaScript itself changing. You can still write a React component using idioms from five years ago and it's still easy to read the code. React is very focused, and very simple. The main motivation for moving to the newer idioms is that you can make the code even shorter and more readable. It seems to me that they anticipated the need to keep up with the JavaScript language evolving quite well.

Frost1x 6y ago

>I think the key difference is that frameworks usually hijack your control flow, while library are not. Which is what should be expected. The point of a framework is to not only provide higher level abstractions to rapidly put together a certain type of application but to also provide a certain approach or set of approaches (a "framework") to follow as a guide during the process. This means some generalization should exist but if a framework is too abstract its really no longer a framework... it's a library. A library is supposed to simply provide useful utilities/lego blocks to assemble however you want and not necessarily give specific guidance or patterns. Certain common patterns of usage may arrive as a sort of emergent property based on fundamental library choices/structure but it's overall pretty flexible.

einpoklum 6y ago

> But is framework necessarily bad or inferior to library? The point is that more people, projects and even frameworks can use the library you write. If you write a framework, people have to drop whatever it is they're using and go with your framework. That's bad, unless your framework is the one to trump them all, which it probably isn't.

skohan 6y ago

I think React is somewhat of a special case, because a lot of what makes React good is that it mitigates a lot of the issues which make web painful to deal with: "the browser" is this highly inconsistent target, and Javascript doesn't have built-in facilities for modularizing code, and React gives you a sensible way to get consisten behavior and implement reusable components in this type of environment. Another way to put it is that for web you're already pretty heavily invested in the "framework" of HTML/CSS/JS wheather you like it or not. React is essentially just choosing another baseline framework to replace it, not adding a framework where none exists.