
Lessons from migrating a large codebase to React 16 - sidcool
https://blog.discordapp.com/lessons-from-migrating-a-large-codebase-to-react-16-e60e49102aa6
======
gingerb
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.

~~~
heavenlyblue
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.

~~~
bryanlarsen
Sure, Haskell & OCaml have had a lot of these features for years, but they can
hardly be called "most languages". Other languages are also in the progress of
adding similar features (C++, for example) or aren't getting them (C).

Javascript has more library churn, but the alternative is being stuck on
something like BOOST. ugh.

~~~
heavenlyblue
Let's be clear: JavaScript tries to be both a platform and a programming
language.

People hate it because there's no practical reason why we're forced to use
JavaScript in order to program - and most of the people who are productive are
probably using some sort of variation on ECMAScript that makes it bearable
anyway.

~~~
CharlesW
> _Let 's be clear: JavaScript tries to be both a platform and a programming
> language._

I'm not sure how you came to this conclusion. JavaScript is the common
language for two major platforms (browsers, Node.js) and _many_ smaller ones
(Cocos2d, enyo JS, Espruino, GNOME Shell, Kinoma XS6, NativeScript, Weex,
etc.).

~~~
heavenlyblue
Um what?

\- browsers: used since the 90s because there's no other alternative

\- node.js: created because JS is used in browsers and it's easier to write
code in a single language for browsers and servers

\- Cocos2d: you're clearly lying as the only place where JS is mentioned is
Cocos2d-html, as there's again - no alternative

\- enyo JS: again, used clearly due to the fact that modern - browsers are
available for all of the modern platforms

\- Weex, NativeScript: typical "native app" libraries which use a webkit pane
for most of the rendering, again - javascript here is circumstantial since you
can't choose anything else

\- GNOME Shell, Kinoma XS6: OK. These are the only ones that make any sort of
a strong point in your message; but as far as it goes - modern linux distros
are moving to Python for systems programming anyway. So learning JS here is a
miss.

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

~~~
davedx
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.

~~~
mercer
Agreed! After being burned by React-Router, more than once, I actually would
opt for manually implementing a Redux-et-all solution with something like
History.js over using React-Router again. Which is pretty worrying considering
how important routing is, or should be, in the ecosystem.

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

~~~
dmitriid
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.

~~~
throw2016
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.

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

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

~~~
christophilus
Agree 100%. I always use zero-dependency libraries if they are available. The
only library in my codebase that has a React dependency is react-redux. React
upgrades have thus far been painless.

------
Touche
This is why I prefer web components. This is nothing against React. But it's a
library, and they make breaking changes just like all libraries (eventually)
do.

The great thing about web components is that they _cannot_ make breaking
changes now that it's been implemented by multiple libraries. It's stamped in
time forever.

If there ever comes a time where the existing API can't be updated any more
because of mistakes or whatever, they'll just make a new API and your existing
code will continue to work, _forever_. Look at XMLHttpRequest and fetch(). Did
you have to migrating your XHR code over to fetch()? No, it works fine, and
always will.

~~~
H1Supreme
When the Polyfills are gone (mostly), I'll come back to web components. I love
the idea of web components, but the browsers are still pretty fragmented in
terms of support.

There's definitely progress, but an older Polymer 1.0 app of mine is painfully
slow on everything but Chrome.

~~~
ergo14
Hm, DBmon benchmarks show that Polymer 1.x with polyfills is a lot faster than
Angular 1.x which has thousands of production sites and was acceptable not
that long ago. So I'm not sure that non-polyfill execution will really fix the
performance for you.

Maybe chrome is better at rendering your application structure?

------
orliesaurus
how much faster (snappier) is the app written using React 16 (numbers or stats
anywhere?) and was it really worth it?

~~~
baddox
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...](https://mobile.twitter.com/winkler1/status/911580798024912897?lang=en)

~~~
nikcub
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...](https://reactjs.org/docs/react-dom-
server.html#rendertonodestream)

[1]
[https://github.com/facebook/react/issues/6420](https://github.com/facebook/react/issues/6420)

[2] [https://medium.com/@localvoid/how-to-win-in-web-framework-
be...](https://medium.com/@localvoid/how-to-win-in-web-framework-
benchmarks-8bc31af76ce7)

~~~
baddox
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.

------
lucaspiller
How 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.

~~~
Touche
The "Fiber" stuff is FUD until we see some perf comparisons. It irks me that
React gave their rewrite a codename and talked about perf, and so many people
are now have this "Fiber is fast" stuff in their head without any real
evidence. I've seen evidence that Preact is fast.

~~~
acemarke
The React team did say, many times, that React 16 was not intended to be a
"make everything faster" release. The "React Fiber" internals rewrite was
intended to enable making re-rendering asynchronous in the future, but for
now, the overall rendering process is still done synchronously to maintain
compatibility with 15 behavior-wise. It's possible that the changes may make
things smoother for your app now, but this was not a pure-perf-oriented set of
changes. (The future asynchronous rendering is also not strictly speed-related
either, but rather opens up a lot of possibilities for how React prioritizes
updates.)

The initial improvement that Fiber gives is about splitting up the rendering
process into bite-size chunks so that the determination of what does need to
change doesn't block the main thread. The rewrite of the internals also made
the codebase more maintainable, and gave them a chance to implement often-
requested features like returning strings or arrays from render(), as well as
implementing error boundaries.

~~~
Touche
You know very well that community doesn't hear nuance, all they hear is that
Fiber=fast and this is why people question the Preact developers with stuff
like "will you implement Fiber". I know that FUD wasn't the goal, but FUD is
the result of overhyping a rewrite and giving it a codename.

~~~
acemarke
"Implementing Fiber in Preact" is a valid question, on the grounds that React
16 offers a bunch of new user-facing features too.

------
ojhughes
Lesson 1: Don’t do it, the cost of migration will outweigh the benefits

