Live data from Hacker News

Lessons from migrating a large codebase to React 16

blog.discordapp.com

21–30 of 80 posts

Re: Lessons from migrating a large codebase to React 16

#21
post #19

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.

You say that, but their engineering team has been consistently producing one of the better performing electron apps I know. I've seen a lot of praise on HN about their product, so I think they must be doing something right.

Re: Lessons from migrating a large codebase to React 16

#22

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.

I've migrated two applications from React 15 to 16 and it was completely painless. I only had to bump all dependencies to the latest version.

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

#23

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.

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.

It's very easy to upgrade React incrementally. The only problem is that it's likely not so easy to upgrade your related dependencies incrementally. Especially if they use internal APIs or aren't regularly updated.

Re: Lessons from migrating a large codebase to React 16

#24

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.

They are maintaining two branches. The 3.x branch has the same API as 2.x and works with React 16.

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?

Re: Lessons from migrating a large codebase to React 16

#25
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.

Re: Lessons from migrating a large codebase to React 16

#26
post #25

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…

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

#27

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.

This has been my experience of react-router since its inception. When react-router does a major API version bump, they really mean it. I don't use it in any projects I have full control over, but unfortunately due to its popularity in larger projects I've had to use it.

Re: Lessons from migrating a large codebase to React 16

#28
post #25

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…

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.

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.

Re: Lessons from migrating a large codebase to React 16

#29

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.

The author says so explicitely in the conclusion "The biggest advantage, like most tech debt payments, will come down the road.".

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

#30
"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, ...")

Post reply on HN