Lessons from migrating a large codebase to React 16
blog.discordapp.com
Lessons from migrating a large codebase to React 16
1–10 of 80 posts
Re: Lessons from migrating a large codebase to React 16
#2how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?
Re: Lessons from migrating a large codebase to React 16
#3how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?
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/91158079802491289...
Re: Lessons from migrating a large codebase to React 16
#4how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?
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/91158079802491289...
thanks, nicely spotted tweet!
Re: Lessons from migrating a large codebase to React 16
#5how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?
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)
Re: Lessons from migrating a large codebase to React 16
#6This 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.
Re: Lessons from migrating a large codebase to React 16
#7This 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.
There are plenty of reasons for the upgrade: https://reactjs.org/blog/2017/09/26/react-v16.0.html
Re: Lessons from migrating a large codebase to React 16
#8This 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.
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.
Re: Lessons from migrating a large codebase to React 16
#9how much faster (snappier) is the app written using React 16 (numbers or stats anywhere?) and was it really worth it?
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/91158079802491289...
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#rendertonodes...
[1] https://github.com/facebook/react/issues/6420
[2] https://medium.com/@localvoid/how-to-win-in-web-framework-be...
Re: Lessons from migrating a large codebase to React 16
#10This 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.
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.