Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from migrating a large codebase to React 16

blog.discordapp.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Lessons from migrating a large codebase to React 16

#51

Post by dmitriid »

throw2016 wrote: post #43
dmitriid wrote: post #18

Earlier quoted context omitted.

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.

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"

Re: Lessons from migrating a large codebase to React 16

#52

Post by evan_ »

jamier1978 wrote: post #24
marktucker wrote: post #14

Earlier quoted context omitted.

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?

Just set the “react-router” entry in packages.json to “^3.0.0”

Re: Lessons from migrating a large codebase to React 16

#53

Post by zackify »

Touche wrote: post #39
Sacho wrote: post #35

Earlier quoted context omitted.

> 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? Who's forcing you to do this? All of these old things s…

> 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 old things likely have bugs" Do you even have experience with React? It sounds like you don't. Because there's no "bugs" with using createClass or proptypes, it's simply been split out into a separate package that you can still use if you want.

Re: Lessons from migrating a large codebase to React 16

#54

Post by mattferderer »

Touche wrote: post #39
Sacho wrote: post #35

Earlier quoted context omitted.

> 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? Who's forcing you to do this? All of these old things s…

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

There are "enterprise type" libraries for JavaScript developers that move slower & focus on stability over performance or productivity increases. Some are backed by a company that offers paid support. While I haven't used it, I've heard good things about Telerik.

Re: Lessons from migrating a large codebase to React 16

#55

Post by atonse »

dmitriid wrote: post #18
chairmanwow wrote: post #6

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.

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.

Re: Lessons from migrating a large codebase to React 16

#56

Post by acemarke »

Touche wrote: post #41
lucaspiller wrote: post #13

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.

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.

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.

Re: Lessons from migrating a large codebase to React 16

#57

Post by weego »

skeeterbug wrote: post #46
bromuro wrote: post #36

Earlier quoted context omitted.

Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms. Those times were painful, now it’s much much better.

Yeah, I don't think these people worked on code that targeted IE6-8. Horrible times.

I've been writing production JavaScript since 1999. Writing compatible JS used to be a horrible pain, now everything about writing and maintaining your JS is the pain and browsers by comparison are highly forgiving.

Re: Lessons from migrating a large codebase to React 16

#58

Post by weego »

bromuro wrote: post #36
weego wrote: post #28

Earlier quoted context omitted.

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.

Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms. Those times were painful, now it’s much much better.

I'm talking more ecosystem than core language changes. Though of course, core language changes are part of the build and tooling ecosystem because of everyone constantly wanting to write code that is years ahead of what browsers are actually supporting. Build and package management tooling, frameworks etc.

Re: Lessons from migrating a large codebase to React 16

#59

Post by timdorr »

tedeh wrote: post #31
buf wrote: post #17

Earlier quoted context omitted.

Completely agree. The new react router is a massive step back in the same code base. Rewriting apps in the new version is a massive pain.

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 mont…

React Router maintainer here!

The only things we're looking at for another major version are some changes to the default API behaviors (making `exact` default to true, for instance). There are potentially some changes to path matching, but that's being driven by path-to-regexp, not our own development.

Yes, 4.0 was a big change, but a necessary one. Now that we're in a great place, we plan on keeping things relatively stable indefinitely. Pencils down, as it were. Outside of some major upstream change with React itself, future versions will be more evolutionary than revolutionary.

Re: Lessons from migrating a large codebase to React 16

#60

Post by CharlesW »

heavenlyblue wrote: post #49
bryanlarsen wrote: post #34

Earlier quoted context omitted.

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.

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.

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

Post reply on HN