11 ms·

Lessons from migrating a large codebase to React 16

164 points by sidcool 9y ago

orliesaurus 9y ago
how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?
- baddox 9y ago
  The author hints that there probably aren’t significant performance improvements yet, but I’ve seen a spattering of tweets claiming to see fairly significantly real-world performance boosts. https://mobile.twitter.com/winkler1/status/911580798024912897?lang=en https://mobile.twitter.com/winkler1/status/91158079802491289...
  - orliesaurus 9y ago
    thanks, nicely spotted tweet!
  - nikcub 9y ago
    That benchmark needs more context because were I to guess i'd say they're using stream rendering[0][1] in React 16 I also agree with one of the comments in reply who linked to "How to win in web framework benchmarks"[2] Unlike, say, benchmarks for performing hash functions on graphics cards or frame rates on certain hardware the units of work being tested on web benchmarks very rarely reflect the units of work used in your own systems In performance and security critical components we write benchmark-*.{ts,js} tests and track performance of real-world components. At the moment in the mocha world there is no good way to keep a history of results, so we tend to copy+paste them as code comments (noticed this in a lot of projects) - but it wouldn't be difficult to write a storage backend here in sqlite or similar and store it in the same way coverage reports are If you're doing comparisons on modules you use - you can include them as devDependancies. This also forces you to abstract away your dependancies which is often a good thing. [0] https://reactjs.org/docs/react-dom-server.html#rendertonodestream https://reactjs.org/docs/react-dom-server.html#rendertonodes... [1] https://github.com/facebook/react/issues/6420 https://github.com/facebook/react/issues/6420 [2] https://medium.com/@localvoid/how-to-win-in-web-framework-benchmarks-8bc31af76ce7 https://medium.com/@localvoid/how-to-win-in-web-framework-be...
    - baddox 9y ago
      Indeed, it’s not easy to come up with a repeatable benchmark from which broad meaningful conclusions can be made. But if a real-world React application gets faster when upgrading, I’m all for sharing that, and it can be a useful estimate if that application is somewhat similar to my own codebase.
- sergiotapia 9y ago
  I can speak to _significant_ performance improvements when upgrading to React 16. Like night and day performance with minimal code tweaking. (Basically add prop-types package and remove any references to React.proptypes)
chairmanwow 9y ago
This seems like engineering for engineering's sake. From the author's description, this was a pretty superficial refactoring that may or may not have been for the better. It seems like a bizarre decision to spend time migrating to a new system / tool that provides no immediate benefits. A thorough refactoring of their codebase seems like it would have been a better use of engineering time.
- fourstar 9y ago
  There are plenty of reasons for the upgrade: https://reactjs.org/blog/2017/09/26/react-v16.0.html https://reactjs.org/blog/2017/09/26/react-v16.0.html
- sillysaurus3 9y ago
  FWIW everyone keeps saying React 16 is worth it solely for the speed boost. It incorporates their Fibers work, which has been a long time coming.
  - Kiro 9y ago
    Not in this case though. Read the end of the article.
- iEchoic 9y ago
  React 16 adds Portals and Error Boundaries, which are very useful things that often change the way you write components. When you defer upgrading something that changes the way you write code, you accrue debt because you're increasing the amount of code written in a style that will be deprecated once you upgrade. If you're all-in on React (as Discord is), the upgrade to React 16 is inevitable. Given that, upgrading now makes sense.
- dmitriid 9y ago
  The more you delay the upgrade, the more painful it becomes in the future. At a previous workplace we had to go from React 0.13 to React 15. We had to re-write, fork and patch, or get rid of entire third-party libraries. There are no stepping stones in the JS ecosystem that let you do gradual updates if you are several versions behind.
realusername 9y ago
In my case, the main pain points were third-party packages, more than React 16 itself. For react you only had prop-types and createClass to change everywhere. The migration of react-router in particular was awful, the new react-router is so different from the old one they should have created another repository for the new version.
- marktucker 9y ago
  They are maintaining two branches. The 3.x branch has the same API as 2.x and works with React 16.
  - jamier1978 9y ago
    That's good to know. React Router is the only thing stopping me from updating to React 16. I can't find an NPM package, so assume you need to point it at Github?
    - evan_ 9y ago
      Just set the “react-router” entry in packages.json to “^3.0.0”
    - marktucker 9y ago
      You can do: npm install --save react-router@3 which will add "react-router": "^3.2.0" to your package.json.
- buf 9y ago
  Completely agree. The new react router is a massive step back in the same code base. Rewriting apps in the new version is a massive pain.
  - tedeh 9y ago
    That is true, but the new react-router makes better use of the component hierarchy which is the real beauty of React IMHO, by having the route components render conditionally based on the url. We had a lot of pain doing this rewrite ourselves, but I must say it was worth it in the end. Unfortunately, this is major version 4, so who is to say that the repo maintainers don't find an even better way to do it in six months, prompting a version 5 and so on...
gingerb 9y ago
This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle". I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea? When will people start to realise that this new method or technology they're implementing is deprecated already? There is no end to this and I actually hate it as it destroys my passion for coding. I code to create things, not to continuously change what's created already and works fine. As soon as I find a cool C job I'll definitely leave this mad house.
- heavenlyblue 9y ago
  It's impressive how most of the progress in the JS land is essentially adding the features most of the other languages have already had for years (or - at least had done them properly in the first place). And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.
  - weego 9y ago
    It's also incredibly frustrating that every step that is rediscovered that other languages just have is then subject to endless fragmentation over trivial differences that are put forward as core philosophical concerns. I know this is not unique to the JS ecosystem but it's definitely a lot worse than I've seen in the past.
    - bromuro 9y ago
      Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms. Those times were painful, now it’s much much better.
lucaspiller 9y ago
How does the performance of React 16 compare to Preact? I understand that Preact is still a smaller filesize, but fibers (and async when it’s enabled) sounds like it’ll be faster than Preact. We are using Preact for a small mobile site, so I’m wondering if it’s worth switching.
- harrygeez 9y ago
  I wish to know this as well. IIRC, preact is faster by the virtue of being smaller so it's loads faster, but React is actually more efficient when updating the state, in some ways.
- Touche 9y ago
  The "Fiber" stuff is FUD until we see some perf comparisons. It irks me that React gave their rewrite a codename and talked about perf, and so many people are now have this "Fiber is fast" stuff in their head without any real evidence. I've seen evidence that Preact is fast.
  - acemarke 9y ago
    The React team did say, many times, that React 16 was not intended to be a "make everything faster" release. The "React Fiber" internals rewrite was intended to enable making re-rendering asynchronous in the future, but for now, the overall rendering process is still done synchronously to maintain compatibility with 15 behavior-wise. It's possible that the changes may make things smoother for your app now, but this was not a pure-perf-oriented set of changes. (The future asynchronous rendering is also not strictly speed-related either, but rather opens up a lot of possibilities for how React prioritizes updates.) The initial improvement that Fiber gives is about splitting up the rendering process into bite-size chunks so that the determination of what does need to change doesn't block the main thread. The rewrite of the internals also made the codebase more maintainable, and gave them a chance to implement often-requested features like returning strings or arrays from render(), as well as implementing error boundaries.
    - Touche 9y ago
hex13 9y ago
"Facebook has done a good job of deprecating and warning for the last few months, but not all libraries are well-maintained and if you depend on or have forked a great many ancient ones, you will be in for a bit of a slog."). This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React based additional libraries, then upgrading all/troubleshooting can be painful. As it was ("We ran into an error which took us 2 days to track down to a library, ...")
- christophilus 9y ago
  Agree 100%. I always use zero-dependency libraries if they are available. The only library in my codebase that has a React dependency is react-redux. React upgrades have thus far been painless.
Touche 9y ago
This is why I prefer web components. This is nothing against React. But it's a library, and they make breaking changes just like all libraries (eventually) do. The great thing about web components is that they cannot make breaking changes now that it's been implemented by multiple libraries. It's stamped in time forever. If there ever comes a time where the existing API can't be updated any more because of mistakes or whatever, they'll just make a new API and your existing code will continue to work, forever. Look at XMLHttpRequest and fetch(). Did you have to migrating your XHR code over to fetch()? No, it works fine, and always will.
- TomMarius 9y ago
  Actually synchronous XHRs will stop working in Chrome soon.
  - Touche 9y ago
    Fair point, standards aren't immune to breaking changes, it's just a lot rarer, smaller in scope and with a much longer time frame to upgrade.
    - TomMarius 9y ago
      Definitely agreed, just wanted to point out that it happens.
- hazza1 9y ago
  I got pretty burnt by the big changes in custom elements v0->v1. Admittedly v0 was only a proposal but v1 took a long time coming.
- H1Supreme 9y ago
  When the Polyfills are gone (mostly), I'll come back to web components. I love the idea of web components, but the browsers are still pretty fragmented in terms of support. There's definitely progress, but an older Polymer 1.0 app of mine is painfully slow on everything but Chrome.
ojhughes 9y ago
Lesson 1: Don’t do it, the cost of migration will outweigh the benefits
MonicaSalma 9y ago
I am new to React16, so need to check several ideas. Thanks!

164 points by sidcool 9y ago

orliesaurus 9y ago

how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?

baddox 9y ago
The author hints that there probably aren’t significant performance improvements yet, but I’ve seen a spattering of tweets claiming to see fairly significantly real-world performance boosts. https://mobile.twitter.com/winkler1/status/911580798024912897?lang=en https://mobile.twitter.com/winkler1/status/91158079802491289...
- orliesaurus 9y ago
  thanks, nicely spotted tweet!
- nikcub 9y ago
  That benchmark needs more context because were I to guess i'd say they're using stream rendering[0][1] in React 16 I also agree with one of the comments in reply who linked to "How to win in web framework benchmarks"[2] Unlike, say, benchmarks for performing hash functions on graphics cards or frame rates on certain hardware the units of work being tested on web benchmarks very rarely reflect the units of work used in your own systems In performance and security critical components we write benchmark-*.{ts,js} tests and track performance of real-world components. At the moment in the mocha world there is no good way to keep a history of results, so we tend to copy+paste them as code comments (noticed this in a lot of projects) - but it wouldn't be difficult to write a storage backend here in sqlite or similar and store it in the same way coverage reports are If you're doing comparisons on modules you use - you can include them as devDependancies. This also forces you to abstract away your dependancies which is often a good thing. [0] https://reactjs.org/docs/react-dom-server.html#rendertonodestream https://reactjs.org/docs/react-dom-server.html#rendertonodes... [1] https://github.com/facebook/react/issues/6420 https://github.com/facebook/react/issues/6420 [2] https://medium.com/@localvoid/how-to-win-in-web-framework-benchmarks-8bc31af76ce7 https://medium.com/@localvoid/how-to-win-in-web-framework-be...
  - baddox 9y ago
    Indeed, it’s not easy to come up with a repeatable benchmark from which broad meaningful conclusions can be made. But if a real-world React application gets faster when upgrading, I’m all for sharing that, and it can be a useful estimate if that application is somewhat similar to my own codebase.
sergiotapia 9y ago
I can speak to _significant_ performance improvements when upgrading to React 16. Like night and day performance with minimal code tweaking. (Basically add prop-types package and remove any references to React.proptypes)

chairmanwow 9y ago

This seems like engineering for engineering's sake. From the author's description, this was a pretty superficial refactoring that may or may not have been for the better. It seems like a bizarre decision to spend time migrating to a new system / tool that provides no immediate benefits. A thorough refactoring of their codebase seems like it would have been a better use of engineering time.

fourstar 9y ago
There are plenty of reasons for the upgrade: https://reactjs.org/blog/2017/09/26/react-v16.0.html https://reactjs.org/blog/2017/09/26/react-v16.0.html
sillysaurus3 9y ago
FWIW everyone keeps saying React 16 is worth it solely for the speed boost. It incorporates their Fibers work, which has been a long time coming.
- Kiro 9y ago
  Not in this case though. Read the end of the article.
iEchoic 9y ago
React 16 adds Portals and Error Boundaries, which are very useful things that often change the way you write components. When you defer upgrading something that changes the way you write code, you accrue debt because you're increasing the amount of code written in a style that will be deprecated once you upgrade. If you're all-in on React (as Discord is), the upgrade to React 16 is inevitable. Given that, upgrading now makes sense.
dmitriid 9y ago
The more you delay the upgrade, the more painful it becomes in the future. At a previous workplace we had to go from React 0.13 to React 15. We had to re-write, fork and patch, or get rid of entire third-party libraries. There are no stepping stones in the JS ecosystem that let you do gradual updates if you are several versions behind.

realusername 9y ago

In my case, the main pain points were third-party packages, more than React 16 itself. For react you only had prop-types and createClass to change everywhere. The migration of react-router in particular was awful, the new react-router is so different from the old one they should have created another repository for the new version.

marktucker 9y ago
They are maintaining two branches. The 3.x branch has the same API as 2.x and works with React 16.
- jamier1978 9y ago
  That's good to know. React Router is the only thing stopping me from updating to React 16. I can't find an NPM package, so assume you need to point it at Github?
  - evan_ 9y ago
    Just set the “react-router” entry in packages.json to “^3.0.0”
  - marktucker 9y ago
    You can do: npm install --save react-router@3 which will add "react-router": "^3.2.0" to your package.json.
buf 9y ago
Completely agree. The new react router is a massive step back in the same code base. Rewriting apps in the new version is a massive pain.
- tedeh 9y ago
  That is true, but the new react-router makes better use of the component hierarchy which is the real beauty of React IMHO, by having the route components render conditionally based on the url. We had a lot of pain doing this rewrite ourselves, but I must say it was worth it in the end. Unfortunately, this is major version 4, so who is to say that the repo maintainers don't find an even better way to do it in six months, prompting a version 5 and so on...

gingerb 9y ago

This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle". I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea? When will people start to realise that this new method or technology they're implementing is deprecated already? There is no end to this and I actually hate it as it destroys my passion for coding. I code to create things, not to continuously change what's created already and works fine. As soon as I find a cool C job I'll definitely leave this mad house.

heavenlyblue 9y ago
It's impressive how most of the progress in the JS land is essentially adding the features most of the other languages have already had for years (or - at least had done them properly in the first place). And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.
- weego 9y ago
  It's also incredibly frustrating that every step that is rediscovered that other languages just have is then subject to endless fragmentation over trivial differences that are put forward as core philosophical concerns. I know this is not unique to the JS ecosystem but it's definitely a lot worse than I've seen in the past.
  - bromuro 9y ago
    Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms. Those times were painful, now it’s much much better.

lucaspiller 9y ago

How does the performance of React 16 compare to Preact? I understand that Preact is still a smaller filesize, but fibers (and async when it’s enabled) sounds like it’ll be faster than Preact. We are using Preact for a small mobile site, so I’m wondering if it’s worth switching.

harrygeez 9y ago
I wish to know this as well. IIRC, preact is faster by the virtue of being smaller so it's loads faster, but React is actually more efficient when updating the state, in some ways.
Touche 9y ago
The "Fiber" stuff is FUD until we see some perf comparisons. It irks me that React gave their rewrite a codename and talked about perf, and so many people are now have this "Fiber is fast" stuff in their head without any real evidence. I've seen evidence that Preact is fast.
- acemarke 9y ago
  The React team did say, many times, that React 16 was not intended to be a "make everything faster" release. The "React Fiber" internals rewrite was intended to enable making re-rendering asynchronous in the future, but for now, the overall rendering process is still done synchronously to maintain compatibility with 15 behavior-wise. It's possible that the changes may make things smoother for your app now, but this was not a pure-perf-oriented set of changes. (The future asynchronous rendering is also not strictly speed-related either, but rather opens up a lot of possibilities for how React prioritizes updates.) The initial improvement that Fiber gives is about splitting up the rendering process into bite-size chunks so that the determination of what does need to change doesn't block the main thread. The rewrite of the internals also made the codebase more maintainable, and gave them a chance to implement often-requested features like returning strings or arrays from render(), as well as implementing error boundaries.
  - Touche 9y ago

hex13 9y ago

"Facebook has done a good job of deprecating and warning for the last few months, but not all libraries are well-maintained and if you depend on or have forked a great many ancient ones, you will be in for a bit of a slog."). This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React based additional libraries, then upgrading all/troubleshooting can be painful. As it was ("We ran into an error which took us 2 days to track down to a library, ...")

christophilus 9y ago
Agree 100%. I always use zero-dependency libraries if they are available. The only library in my codebase that has a React dependency is react-redux. React upgrades have thus far been painless.

Touche 9y ago

This is why I prefer web components. This is nothing against React. But it's a library, and they make breaking changes just like all libraries (eventually) do. The great thing about web components is that they cannot make breaking changes now that it's been implemented by multiple libraries. It's stamped in time forever. If there ever comes a time where the existing API can't be updated any more because of mistakes or whatever, they'll just make a new API and your existing code will continue to work, forever. Look at XMLHttpRequest and fetch(). Did you have to migrating your XHR code over to fetch()? No, it works fine, and always will.

TomMarius 9y ago
Actually synchronous XHRs will stop working in Chrome soon.
- Touche 9y ago
  Fair point, standards aren't immune to breaking changes, it's just a lot rarer, smaller in scope and with a much longer time frame to upgrade.
  - TomMarius 9y ago
    Definitely agreed, just wanted to point out that it happens.
hazza1 9y ago
I got pretty burnt by the big changes in custom elements v0->v1. Admittedly v0 was only a proposal but v1 took a long time coming.
H1Supreme 9y ago
When the Polyfills are gone (mostly), I'll come back to web components. I love the idea of web components, but the browsers are still pretty fragmented in terms of support. There's definitely progress, but an older Polymer 1.0 app of mine is painfully slow on everything but Chrome.

ojhughes 9y ago

Lesson 1: Don’t do it, the cost of migration will outweigh the benefits

MonicaSalma 9y ago

I am new to React16, so need to check several ideas. Thanks!