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.
Lessons from migrating a large codebase to React 16
11–20 of 80 posts
Re: Lessons from migrating a large codebase to React 16
#12Earlier quoted context omitted.
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 i…
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.
Re: Lessons from migrating a large codebase to React 16
#13How 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.
Re: Lessons from migrating a large codebase to React 16
#14In 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.
They are maintaining two branches. The 3.x branch has the same API as 2.x and works with React 16.
Re: Lessons from migrating a large codebase to React 16
#15This 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.
Not in this case though. Read the end of the article.
Re: Lessons from migrating a large codebase to React 16
#16How 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.
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.
Re: Lessons from migrating a large codebase to React 16
#17In 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.
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.
Re: Lessons from migrating a large codebase to React 16
#18This 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.
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.
Re: Lessons from migrating a large codebase to React 16
#19This 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.
"This seems like engineering for engineering's sake."—this describes a lot, if not a majority of work done in frontend these days.
Re: Lessons from migrating a large codebase to React 16
#20This 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.
"This seems like engineering for engineering's sake."—this describes a lot, if not a majority of work done in frontend these days.
To me, it describes more the attitude some people have torward new technologies developed by new people, by criticizing without knowing enough the things they criticize.