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.
"This seems like engineering for engineering's sake."—this describes a lot, if not a majority of work done in frontend these days.
Lessons from migrating a large codebase to React 16
21–30 of 80 posts
Re: Lessons from migrating a large codebase to React 16
#22This 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.
Literally the only reason a migration could be painful if you're on the latest version of 15 before upgrading is that your code or your dependencies are using deprecated APIs, which the latest version of React 15 will helpfully warn about. You can fix that before migrating.
Re: Lessons from migrating a large codebase to React 16
#23This 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
#24In 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
#25I 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.
Re: Lessons from migrating a large codebase to React 16
#26This 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…
And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.
Re: Lessons from migrating a large codebase to React 16
#27In 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.
Re: Lessons from migrating a large codebase to React 16
#28This 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…
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.
Re: Lessons from migrating a large codebase to React 16
#29This 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.
It's only a bizarre decision if you approach it exclusively from a short-term view.
Re: Lessons from migrating a large codebase to React 16
#30This 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, ...")