9 ms·

React famously claims not to be a framework. Many, myself included, would argue that it is very much a framework in every way that matters.

• frosted-flakes 5y ago
  Which ways are those?
  • danappelxx 5y ago
    React forces you to write code a certain way. jQuery does not force you to write your code a certain way. In my experience, that’s the single biggest difference between a library and a framework.
    • hackerfromthefu 5y ago
      If only there was just one way to write react code!
  • acdha 5y ago
    You’re still writing code which is based on React’s view of the world, not standard web APIs. Saying it’s not a framework just means that people are cobbling together their own frameworks using some popular libraries, which gives more flexibility at the cost of the various combinations being less tested and harder for someone else to support. To be clear, this can be a reasonable trade off – but there’s a cost which people often discount until they realize they just spent a week wrestling with abstraction layers.
  • jakelazaroff 5y ago
    The definition I’ve seen is “you call a library’s code; a framework calls your code.” You don’t decide when to run your components — React does.
  • lhorie 5y ago
    - It "calls you" (i.e. you never explicitly call your React components, React does) - It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much) - It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc) - Its direct competitors are frameworks (Angular, Vue, Backbone, Aurelia, Mithril...) - it is composed of multiple libraries (react, react-dom) - Experience in it is considered a primary hiring criteria in many shops (which typically isn't the case for libraries)
    • leeoniya 5y ago
      from the author of Mithril ;)
    • Chris_Newton 5y ago
      Almost everything in your first few points there depends on how you choose to use React, though, rather than being inherent in the library itself. It "calls you" (i.e. you never explicitly call your React components, React does) The starting point for doing anything with React is where you call it to render a certain component at a certain point in your document. There are things built on top of React, such as Next.js, that add more layers and do follow more of a framework design, but even there they are still calling React when they need to rather than the other way around. It’s true that React provides features can automatically trigger a rerender later on. You don’t have to use any of those, though. There are also integrations with many other libraries, such as those for managing state in one way or another, where the library can trigger rerendering of specific React components when relevant state changes. In this case, it’s the library calling React rather than React calling out. Another alternative is the original React “philosophy”, simply rerendering the entire tree whenever you need to and letting the VDOM mechanism and perhaps a few helping hands that avoid unnecessary rerenders in your components keep this reasonably efficient. When to call into React for a rerender is entirely your own choice. I suppose you could argue that React operates somewhat like a framework because it calls the render function for each component, but to me this is more analogous to a generic sorting algorithm that calls a comparison function I pass in when it needs to. It still doesn’t do anything until I call `sort`, and the code I write is still what decides the overall control flow for the program. It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much) It is possible to use React only as a convenient rendering library and keep other responsibilities like state management and communications separate, just like any other software. Some people choose not to do that and instead write React components that manage state and call remote APIs and cook you breakfast in the morning. Whether this strategy is wise is a different question. I’m working on a new front-end using React right now, and even at an early stage when presentation code is a large part of what has been written so far, maybe 1/3 of the code even knows React exists. I’ll be surprised if that figure is even 20% by the time we launch. Even now, we could drop React tomorrow in favour of any other rendering code, and nothing would need to change in the code that handles our data model, diagram layouts, communications with our back-end APIs, etc. It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc) Components are just a way to build a rendering hierarchy: data in, DOM out. Nothing about that forces you to adopt any specific architecture in the rest of your application. Again, some people do choose to put other responsibilities within their components, even using React components to model non-presentational aspects so almost their entire front-end architecture becomes one big tree of React components, but you don’t have to do this and then deal with all the problems it potentially creates that you didn’t otherwise have.
• dbbk 5y ago
  I would define a framework as something that offers a high level abstraction, promotes best practices and takes care of a bunch of boilerplate stuff for you. React doesn't do that at all. Next, Blitz, Redwood etc, do.