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

41–50 of 80 posts

Re: Lessons from migrating a large codebase to React 16

#41

Post by Touche »

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.

Re: Lessons from migrating a large codebase to React 16

#42

Post by TomMarius »

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…

Actually synchronous XHRs will stop working in Chrome soon.

Re: Lessons from migrating a large codebase to React 16

#43

Post by throw2016 »

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.

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.

Re: Lessons from migrating a large codebase to React 16

#45

Post by Touche »

TomMarius wrote: post #42
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…

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.

Re: Lessons from migrating a large codebase to React 16

#46

Post by skeeterbug »

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.

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

Re: Lessons from migrating a large codebase to React 16

#47

Post by hazza1 »

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…

I got pretty burnt by the big changes in custom elements v0->v1. Admittedly v0 was only a proposal but v1 took a long time coming.

Re: Lessons from migrating a large codebase to React 16

#49

Post by heavenlyblue »

bryanlarsen wrote: post #34
heavenlyblue wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: Lessons from migrating a large codebase to React 16

#50

Post by H1Supreme »

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.

Post reply on HN