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

71–80 of 80 posts

Re: Lessons from migrating a large codebase to React 16

#71

Post by timdorr »

davnicwil wrote: post #64
timdorr wrote: post #59

Earlier quoted context omitted.

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

3.0 just removed deprecated features from 2.0. There were a handful of other tiny things, but a pretty bland major release otherwise.

Re: Lessons from migrating a large codebase to React 16

#72

Post by davnicwil »

timdorr wrote: post #71
davnicwil wrote: post #64

Earlier quoted context omitted.

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

3.0 just removed deprecated features from 2.0. There were a handful of other tiny things, but a pretty bland major release otherwise.

Sure, but whether or not 3.x changed significantly from 2.x isn't really what I'm asking about, I was more wondering if you imagined upon the release of 3 (or 2 for that matter) that it was more or less the final stable overall design, or were significant future redesigns/rewrites still in the plan at that point?

Re: Lessons from migrating a large codebase to React 16

#73

Post by linkmotif »

pluma wrote: post #70
linkmotif wrote: post #32

Earlier quoted context omitted.

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…

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

Yeah that’s what I’m saying :)

Re: Lessons from migrating a large codebase to React 16

#74

Post by marktucker »

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?

You can do:

    npm install --save react-router@3
which will add "react-router": "^3.2.0" to your package.json.

Re: Lessons from migrating a large codebase to React 16

#75

Post by chairmanwow »

weego wrote: post #57
skeeterbug wrote: post #46

Earlier quoted context omitted.

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.

Thanks for sharing! This is a viewpoint that I've never encountered before as only having entered the game in the last 3 years.

Re: Lessons from migrating a large codebase to React 16

#76

Post by boubiyeah »

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.

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

Re: Lessons from migrating a large codebase to React 16

#77

Post by acemarke »

Touche wrote: post #69
acemarke wrote: post #56

Earlier quoted context omitted.

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.

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

Re: Lessons from migrating a large codebase to React 16

#78

Post by zackify »

zackify wrote: post #53
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.

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

Lol love how I get downvotes for stating facts

Re: Lessons from migrating a large codebase to React 16

#79

Post by danabramov »

linkmotif wrote: post #73
pluma wrote: post #70

Earlier quoted context omitted.

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…

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

Re: Lessons from migrating a large codebase to React 16

#80

Post by ergo14 »

H1Supreme wrote: post #50
Touche wrote: post #40

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

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.

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?

Post reply on HN