4 ms·

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, a

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework. It's not a complete Application Framework, sure, and you may mix it with other stuff. In fact, you will generally mix it with other stuff. But I don't think that the difference library vs framework lies in providing for all of the aspects of the application or just for some parts of it. In this particular case, the author seems to have overstepped that somewhat, saying "With a framework, you’re essentially given all the materials to build that house, and it’s up to you in what arrangement you put them in." And in there lies the problem. That is not a framework. That's Home Depot. A framework does indeed tell you in what arrangement you're supposed to put the materials. It's in fact this that makes it a framework. It gives you structure. Or at least, the basis for the structure. You put your materials into the arrangement the framework suggests. React is only concerned with UI, sure. But then again it does give you quite a bit of structure. It does tell you how you're supposed to arrange and build your UI. You extend this class with these methods, or you create this kind of function using these functions in this way. You put your rendering here, and return it in this way... and then the framework will run it. What is correct is that React is for UI. So, sure, it will not tell you how you should do your API calls. But not because it's not a framework, but because API calls are not a UI concern.

capableweb 6y ago
I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize. If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.
- genezeta 6y ago
  Yes. That's the other way of expressing the distinction between frameworks and libraries. And I think most people do use React as a framework. (But I could be underestimating those who use it in the second way, of course).
  - yazaddaruvala 6y ago
    I can give a production example of migrating to React. We needed to do it incrementally from a server side rendered Java application, with jQuery and a lot of custom spaghetti code. At first we migrated the server side templates to JSX and started to use React as a library by calling ReactDOM.renderToString. The first thing our JavaScript did was render the React templates similar to using Handlebars. Then the rest of our code kicked in using jQuery bindings and it’s events logic. Now that our templates were all JSX. It was simple that start converting leaf “components” with simple state into ReactDOM.render instead. Often needing ReactDOM.unmountComponent to “refresh” the state And rerender everything like the jQuery based code needed. Finally, we worked our way up the stack of components so that more and more were “just normal react components without calls to ReactDOM. The last thing we did was migrate the top level to use ReactDOM.render and we were fully React based. FWIW, we thought about Redux but didn’t use it. We used the patterns from Redux, but felt we didn’t need a library to manage our data. This was also pre-Hooks. All in all took 1 dev on a team of 9, that all kept working on the codebase, about 4 months working on it off and on 50% time focused on the migration. There were no issues caused along the way, the automated tests didn’t need to be changed (except for the new features - which were orthogonal to the React migration), and customers had a (unnoticeable) latency improvement comparing the metrics at the start and end of the migration. The incremental use was a huge reason we picked React. Not only to migrate to React but also because we can do the inverse process when we want to migrate away. P.S. We finished this migration Jan 2019. Since then the productivity of the team has noticeably increased. Even new hire “ramp up” has been reduced with them producing production code faster, on average, than pre-React. I’m sure these successes would be true for a migration to any modern UI tool e.g. Angular or Vue.
- marcus_holmes 6y ago
  Excellent description. I'm going to borrow this when talking to new gophers about the difference in attitude between Go and $other_language_that_emphasises_frameworks.
Vinnl 6y ago
Hmm, did the React team themselves sell it as a library specifically as in "not a framework"? I do remember them specifically calling it responsible for "just" the view layer, but I also seem to recall someone on the React team (I might be wrong there) distinguishing the two as "a framework calls your code, whereas your code calls a library", where React is squarely the former. (Other than `React.render()`, I guess.)
nicoburns 6y ago
I think the sense which the original article talks about is an important one: You can generally use vanilla libraries for non-UI stuff. You don't generally need to use anything React specific. This is in contrast to frameworks like Angular which try to reinvent to entire ecosystem in an "Angular style". Which is a massive pain if the Angular version has a bug, doesn't implement the feature you need, or is simply far too complicated because it's trying to be everything to everyone. In React, there are usually 2 or 3 options for everything with different trade-offs. And this is amazing, because you can pick the library that works for your project.
protonimitate 6y ago
I think the "library" vs "framework" argument irt react is pretty silly. At the end of the day, what difference does it make? React may not be as opinionated as other application frameworks, but it's also non completely un-opionionated. If you write a full ui in React, whats the level of effort involved to port it back to vanilla js, or even another framework? It's certainly not trivial. IMO that's the only qualifier needed. But I agree, it's all about marketing. I do think the "win" that React has here is that it's easy to introduce React into an existing project with minimal overhead. In that sense I think its closer to library than framework, but after enough time you will inevitably end up with a "React app" and not a "web app with some React".
cloverich 6y ago
The library argument makes much more sense if you've been around the block in web UI. There are many precursor and concurrent web frameworks that do much more than just the UI: They control data management, dependency injection, etc. For some, the UI is nearly an after thought of the model layer. So maybe its not completely accurate but contextually it rang very true to someone like myself, who had used 4-5 other frameworks before using React, and was absolutely one way it stood out to me.

capableweb 6y ago

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize. If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.

genezeta 6y ago
Yes. That's the other way of expressing the distinction between frameworks and libraries. And I think most people do use React as a framework. (But I could be underestimating those who use it in the second way, of course).
- yazaddaruvala 6y ago
  I can give a production example of migrating to React. We needed to do it incrementally from a server side rendered Java application, with jQuery and a lot of custom spaghetti code. At first we migrated the server side templates to JSX and started to use React as a library by calling ReactDOM.renderToString. The first thing our JavaScript did was render the React templates similar to using Handlebars. Then the rest of our code kicked in using jQuery bindings and it’s events logic. Now that our templates were all JSX. It was simple that start converting leaf “components” with simple state into ReactDOM.render instead. Often needing ReactDOM.unmountComponent to “refresh” the state And rerender everything like the jQuery based code needed. Finally, we worked our way up the stack of components so that more and more were “just normal react components without calls to ReactDOM. The last thing we did was migrate the top level to use ReactDOM.render and we were fully React based. FWIW, we thought about Redux but didn’t use it. We used the patterns from Redux, but felt we didn’t need a library to manage our data. This was also pre-Hooks. All in all took 1 dev on a team of 9, that all kept working on the codebase, about 4 months working on it off and on 50% time focused on the migration. There were no issues caused along the way, the automated tests didn’t need to be changed (except for the new features - which were orthogonal to the React migration), and customers had a (unnoticeable) latency improvement comparing the metrics at the start and end of the migration. The incremental use was a huge reason we picked React. Not only to migrate to React but also because we can do the inverse process when we want to migrate away. P.S. We finished this migration Jan 2019. Since then the productivity of the team has noticeably increased. Even new hire “ramp up” has been reduced with them producing production code faster, on average, than pre-React. I’m sure these successes would be true for a migration to any modern UI tool e.g. Angular or Vue.
marcus_holmes 6y ago
Excellent description. I'm going to borrow this when talking to new gophers about the difference in attitude between Go and $other_language_that_emphasises_frameworks.

Vinnl 6y ago

Hmm, did the React team themselves sell it as a library specifically as in "not a framework"? I do remember them specifically calling it responsible for "just" the view layer, but I also seem to recall someone on the React team (I might be wrong there) distinguishing the two as "a framework calls your code, whereas your code calls a library", where React is squarely the former. (Other than `React.render()`, I guess.)

nicoburns 6y ago

I think the sense which the original article talks about is an important one: You can generally use vanilla libraries for non-UI stuff. You don't generally need to use anything React specific. This is in contrast to frameworks like Angular which try to reinvent to entire ecosystem in an "Angular style". Which is a massive pain if the Angular version has a bug, doesn't implement the feature you need, or is simply far too complicated because it's trying to be everything to everyone. In React, there are usually 2 or 3 options for everything with different trade-offs. And this is amazing, because you can pick the library that works for your project.

protonimitate 6y ago

I think the "library" vs "framework" argument irt react is pretty silly. At the end of the day, what difference does it make? React may not be as opinionated as other application frameworks, but it's also non completely un-opionionated. If you write a full ui in React, whats the level of effort involved to port it back to vanilla js, or even another framework? It's certainly not trivial. IMO that's the only qualifier needed. But I agree, it's all about marketing. I do think the "win" that React has here is that it's easy to introduce React into an existing project with minimal overhead. In that sense I think its closer to library than framework, but after enough time you will inevitably end up with a "React app" and not a "web app with some React".

cloverich 6y ago

The library argument makes much more sense if you've been around the block in web UI. There are many precursor and concurrent web frameworks that do much more than just the UI: They control data management, dependency injection, etc. For some, the UI is nearly an after thought of the model layer. So maybe its not completely accurate but contextually it rang very true to someone like myself, who had used 4-5 other frameworks before using React, and was absolutely one way it stood out to me.