Hacker News Reader

Comment by chairmanwow | Hacker News Reader

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.

View on HN

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.

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.

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.

At some point you need to get off the treadmill to stabilize the code, improve it or just make it better.

Constantly trying to keep up either needs a larger team to keep up and do those things, or you compromise somewhere.

Yeah, it's the fine line of "do we upgrade now or can we postpone the upgrade"

There are in the Ember community. They do such a fantastic job of transitioning between versions.

I have had my complaints in the past when I don't touch an Ember app for a year, but for the most part, they provide ample "stepping stones" to bring the community along without too much anxiety.

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.

There are plenty of reasons for the upgrade: https://reactjs.org/blog/2017/09/26/react-v16.0.html

I'm afraid with all due respect to the author, I have to concur.

"Right now, it isn’t clear that the advantages are significant" - so why invest the time in doing so? Why not use a tried and tested version until such times as you either need features from the newer version or some third party dependencies you absolutely need require it?

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.

You probably weren’t mutating props...

My eyes kinda got wide when I read that part.

To be fair, mutating props was frowned upon pretty early on. Also, emphasis on upgrading to the latest version of React 15 before upgrading to React 16.

React has pretty thorough deprecation warnings on the final releases of each major version about what is going away with the next major. Once you've gotten rid of all deprecation warnings, migrating to the next major should be uneventful.

This means you can take your sweet time when upgrading, migrating your code without breaking your entire application.

> To be fair, mutating props was frowned upon pretty early on.

Yeah that’s what I’m saying :)

The Discord article authors are incorrect in saying mutating props broke with React 16.

What really happened is that they switched from createClass to ES6 classes. ES6 class methods have implicit 'use strict' mode.

They weren't forced to switch to ES6 classes if they didn't want to. createClass is on npm (create-react-class) and still works fine.

"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.

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.

Reply on news.ycombinator.com