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

61–70 of 80 posts

Re: Lessons from migrating a large codebase to React 16

#61

Post by jjawssd »

mattferderer wrote: post #54
Touche wrote: post #39

Earlier quoted context omitted.

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

Where can we learn more about these "enterprise type" libraries?

Re: Lessons from migrating a large codebase to React 16

#62

Post by TomMarius »

Touche wrote: post #45
TomMarius wrote: post #42

Earlier quoted context omitted.

Actually synchronous XHRs will stop working in Chrome soon.

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.

Definitely agreed, just wanted to point out that it happens.

Re: Lessons from migrating a large codebase to React 16

#63

Post by heavenlyblue »

CharlesW wrote: post #60
heavenlyblue wrote: post #49

Earlier quoted context omitted.

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

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.

Re: Lessons from migrating a large codebase to React 16

#64

Post by davnicwil »

timdorr wrote: post #59
tedeh wrote: post #31

Earlier quoted context omitted.

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

Happy react router user here, at various major versions. Thanks for the great work!

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

Out of curiosity, was this also the thinking when 3.x was released?

Or when 3.x was released was there more of a philosophy that the problem space was still being explored, and major design changes were still possible and acceptable?

Re: Lessons from migrating a large codebase to React 16

#65

Post by jczhang »

gingerb wrote: 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…

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

There are good reasons for those changes. As you are a full stack JS developer, I'd recommend you dig deeper and find out why. It might alleviate your frustration.

Re: Lessons from migrating a large codebase to React 16

#66

Post by pushedx »

gingerb wrote: 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…

JavaScript is a young language. It's been around for 21 years.

C has been around for 45 years.

I'm sure things will be relatively stable 24 years from now in terms of web development, but then there will be a new medium for writing code with massive churn in commonly-used libraries and techniques.

A need to learn new things in a young language will never die.

Even C++, which is "only" 34 years old is experiencing massive changes to its syntax and common practices.

Re: Lessons from migrating a large codebase to React 16

#67

Post by fatbird »

jczhang wrote: post #65
gingerb wrote: 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…

"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?" There are good reasons for those changes. As you are a full stack JS developer, I'd recommend you dig deeper and find out why. It might alleviate your frustration.

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.

Re: Lessons from migrating a large codebase to React 16

#68

Post by colemorrison »

gingerb wrote: 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…

On one hand, I absolutely agree. The amount of change that happens for the sake of nothing more than change is laughable theme in front-end development.

And if it's not for changes sake it becomes some weird squabble over how to best handle X, and we wind up with numerous ways to do so. At that point we have to take a bet as to which approach we think will be supported and pushed forward in the future (i.e. promises? generators? callbacks? async/await?). If we're right? Great. If we're wrong. Well, let's hope the libs we're using keep support for the way we've written our code.

On the other hand, it does finally seem like React has one the shake out of front-end frameworks. While it's ever changing, it does seem like it's longevity will be far greater than most front-end frameworks of the past. And it does solve a lot of the BS that one would deal with if they didn't have a framework to leverage.

But yeah.. The danger with front-end development is how fast the knowledge depreciates.

edit: by danger, I more mean difficulty of keeping up with.

Re: Lessons from migrating a large codebase to React 16

#69

Post by Touche »

acemarke wrote: post #56
Touche wrote: post #41

Earlier quoted context omitted.

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

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.

Re: Lessons from migrating a large codebase to React 16

#70

Post by pluma »

linkmotif wrote: post #32
pluma wrote: post #22

Earlier quoted context omitted.

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.

Post reply on HN