5 ms·

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, th

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 7y 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 7y 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 7y 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.
nsonha 7y ago
Nah im sure if you look close into, say angular's docs, you'll eventually find out how to bootstrap their app container manually. It's usually the fact that a framework comes with some conventions that you "must" (not should) follow in order for things to work. Like having an IoC container in angular, you can't opt out that.
snarfy 7y ago
> I've always found the best distinction between a framework and the library lies in who-calls-who? I've heard this referred as the 'Hollywood principle', as in 'Don't call us, we'll call you'.
- capableweb 7y ago
  Hm, I'd say in a framework you usually work with the Hollywood principle, but when using something like a library, you're not. So you're 50% correct :)
lhorie 7y ago
> If you call `ReactDOM.render` in multiple places Nobody uses React that way. Besides, React is still very much the one calling you when you're dealing w/ lifecycle methods, useEffect/useCallback, suspense, etc.
- Silhouette 7y ago
  Nobody uses React that way. Hi. I make complicated web UIs. I call React that way sometimes, because sometimes you don't want your entire UI to be one big React component.

genezeta 7y 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 7y 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 7y 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.

nsonha 7y ago

Nah im sure if you look close into, say angular's docs, you'll eventually find out how to bootstrap their app container manually. It's usually the fact that a framework comes with some conventions that you "must" (not should) follow in order for things to work. Like having an IoC container in angular, you can't opt out that.

snarfy 7y ago

> I've always found the best distinction between a framework and the library lies in who-calls-who? I've heard this referred as the 'Hollywood principle', as in 'Don't call us, we'll call you'.

capableweb 7y ago
Hm, I'd say in a framework you usually work with the Hollywood principle, but when using something like a library, you're not. So you're 50% correct :)

lhorie 7y ago

> If you call `ReactDOM.render` in multiple places Nobody uses React that way. Besides, React is still very much the one calling you when you're dealing w/ lifecycle methods, useEffect/useCallback, suspense, etc.

Silhouette 7y ago
Nobody uses React that way. Hi. I make complicated web UIs. I call React that way sometimes, because sometimes you don't want your entire UI to be one big React component.