Technology problems are usually just human problems behind a mask. In this case, the real problem was a poorly skilled team with bad leadership, and React just exacerbated the problems by giving the team enough rope to hang itself.
> React’s team enjoy experimenting with new ideas, but this is killing the ecosystem! They should be brave and take the blame for it!
Have to make a lot of assumptions with this sort of thing, but I can't imagine that attitude results in high quality engineering work.
https://reactjs.org/blog/2015/02/24/streamlining-react-eleme...
Projection if I've ever seen it.
Now when you hire someone new you're going to be looking for React experience but then having to re-train them to think in .NET, or looking for .NET experience but training them to write React... and any time you have dependency upgrades, you're gonna be fighting more impedance mismatches.
Most tech debt that slows down feature development has more to do with the code structure than with the language or framework, so if you're intent on preserving the structure and style I don't know that you should be doing a rewrite at all!
Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming language too. Then try to pick up React.
.NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.
I agree for the most part. More specifically you're not going to write functional code in C# and feel particularly good about what comes out. F# is a different story.
Speaking from experience a .NET (C#) backend and a React frontend is perfectly viable. The key is to keep the paradigms in their respective lanes, and if you're going to write code for both, get used to switching your mindset instead of converging the tools.
Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
I've found that sometimes hooks can make things less flexible, more verbose, more error prone, and harder to reason about. Sometimes a class might have made things easier to understand.
I loved the fact that `useEffect` could modularize code that was otherwise split between `componentDidMount/Unmount/Update`...but couldn't a new class API also have solved this.
Maybe I just need to read the docs again to remind me. I'm all in for hooks, but it's rare that I think about what life could have been like if we kept class components.
“Advantageous” does not necessarily mean “easier to learn.” I’d say that for people coming from OOP, FP style is certainly unfamiliar and takes more getting used to. But for a front-end program that must always receive/send data to hand wave some other systems in order to do anything useful, it makes things much, much simpler. A whole class of problems disappears. The closer it gets to (state) => UI the easier it is to reason about and debug.
I still think that Reagent, the Clojurescript wrapper for React, is the best version of React available. All of the state management is handled by CLJS itself, and the language design prevents accidental mutation. You can still mutate things where appropriate, but it is always an intentional choice. A framework like re-frame takes this even further, with similar ideas as Redux but with better language support for and enforcement of the paradigm.
> Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
At the end of the day you just end up thinking of the chunks of JSX and how they map to parts of the DOM, and who cares if those chunks of JSX are wrapped into a function or a class...
Given this kind of team and leadership, why does that still make React the best choice for them?
Maybe the team is a bunch of n00bs, so what? Wouldn't the perfect framework/language make it hard[er] to screw things up regardless of the lack of dev skill? For a big multi-year project it often strikes me that the best tools are those which are old, boring, and unlikely to change.
That being said, huge-multi-year development in _any_ js framework seems terrifying to me because of the churn in the general js/browser environment.
Also: I think the author doesn't cover this a lot, but it sounds like they REALLY saved their bacon by doing the boring due-diligence of carefully documenting the decision process behind all the choices they made. They probably would have had slowdowns and surprises and roadblocks no matter what, but someone's still got a job because they took time to get it in writing.
At that same job, our app team was switching to Swift for its new code, which no doubt has had considerable churn since then, since it was before ABI stability or SwiftUI or whatever (I’m not a Swift dev so just guessing from the outside on the specifics).
— Peopleware (1987) by Tom DeMarco & Timothy Lister
Most enterprise teams are poorly skilled with bad leadership. Modern frameworks and coding paradigms are a bad fit.
No it wouldn't, not for an enterprise application that is supposed to last a decade or more. Instead you want to use standards such as Web Components that will last essentially forever.
If the project develops issues after all the initial stakeholders have moved on, it's the new stakeholders' problem.