Lessons from migrating a large codebase to React 16

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.

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.

> All of these old things still work.

The old things likely have bugs. And most libraries don't spend a lot of time patching old versions (why should they, it's free software). The longer time passes the less and less likely there will be bug/security patches. So if you want to own those bugs/security issues, sure, stay behind to avoid the cost of upgrading.

The GP's frustration is not with any individual change, it's the treadmill of changes that makes every refactor/rewrite an exercise in treading water.

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?

That is true, but the new react-router makes better use of the component hierarchy which is the real beauty of React IMHO, by having the route components render conditionally based on the url.

We had a lot of pain doing this rewrite ourselves, but I must say it was worth it in the end.

Unfortunately, this is major version 4, so who is to say that the repo maintainers don't find an even better way to do it in six months, prompting a version 5 and so on...

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.

Not in this case though. Read the end of the article.

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.

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.

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.

You probably weren’t mutating props...

My eyes kinda got wide when I read that part.

Fair point, standards aren't immune to breaking changes, it's just a lot rarer, smaller in scope and with a much longer time frame to upgrade.

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?

thanks, nicely spotted tweet!

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

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

[2] https://medium.com/@localvoid/how-to-win-in-web-framework-be...

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.

It's all perceived performances, not real, raw performances. Synchronous react rendering will still be as slow as ever.

This rewrite is a bit pointless to me, increase the complexity of using React on the long term (before, you could count on synchronous rendering having predictive results) and is just a hack to spread the cost of react's rendering across multiple frames. If anything your site will take longer to render now that it's async :)

I'm wary of progressively rendered sites (like Facebook) where buttons are rendered but don't work for the first few hundred milliseconds or seconds anyway. Complex websites can already defer the rendering of their most expensive parts (e.g google maps, etc); baking it in the framework sounds like engineers who had too much free time to me :p