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.
Well said. It was frustrating how little he talked about the actual problems with the codebase, instead choosing to handwave and blame it all on React. The dig on the React team in particular was bizarre:
> 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.
I've worked on stacks with .NET backends and React frontends, and there's a ton of truth to this. You can't use .NET concepts to bridge into an understanding of React. If you need to carry over .NET's paradigms, don't pick React.
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.
This really does nail it. Despite React having a somewhat OOP approach to a lot of things (and Class Components being the de facto for years), React best practices have evolved to be a very functional approach.
.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.
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.
The trouble that React has to deal with is that JavaScript lacks good built-in support for pure functions and immutable data. Hooks are an opinionated way to make React work more like FP, and there are still gotchas because of JS’s lack of enforcement.
“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...
> .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.
I'm still kind of stuck on the fact that they brought a team of .NET devs on to do a React project. What did they think was doing to happen when they used a team with no experience in the technology stack chosen? The conversation should have started with "What skills do the implementation team have?" before tech was chosen.
Is there a frontend framework you can choose that suits .NET devs? Maybe this would have been a better choice if there was. Maybe Angular was better. Or Ember.
I mean for a greenfield project sure but a port of an existing large application that is already coded in a specific style you likely want to preserve as much of that as possible to make the translation more mechanical.
If you're porting between two languages/frameworks with radically different approaches, preserving the original project's approach in the new code is going to give you something that's probably worse than the original!
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!
Well said. I went through the whole article and it just seems to me that instead of asking .NET devs to build a react app, you could have just hired react devs and none of the problems would've existed. Or have the entire team go through a proper react bootcamp. As a dev, I can say for sure, devs not learning new things and keeping up to date are the worst. The ones you need are the ones who try new things and then create solutions that are best fit for the problem with a rational mindset. Pretty much everything else will slow your development eventually, be it react or something else.
Bootcamps are just ways to extract money from the pockets of Enterprises with more money than sense. I worked on a project with some COBOL programmers who went to through a "Java in 21 Days" program. They were decent COBOL programmers, I actually learned some useful things about that language and the IBM environment. But Java programmers they were NOT. https://thedailywtf.com/articles/The_Brillant_Paula_Bean
It actually depends. Sure there's plenty of ones that are complete garbage, but well structured ones work well, especially in two situations: 1. For people who have 0 coding experience to get introduced to how to start coding and where to look to learn more 2. Experienced devs who need a good overview of a new technology that they can further explore more on their own. It's not a bandaid, do a bootcamp and you'll be gods kind of a solution.
Yeah, but Enterprises with more money than sense aren't going to pick the good bootcamps, they're going to go with whatever gets the highest rating in Gartner's Magic Quadrant, or whatever one is run by the guy who golfs with the CEO.
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.
Does JS really churn more than other environments? I first saw React in production at work in 2015. That’s almost six years ago. Before React, sure, there was a lot of churn, but there has been a huge time period in which no one got fired for choosing React plus Webpack.
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).
You're just making the author's point for them. A more opinionated framework that matched the team that was supposed to code with it would have worked better for them over the lifecycle of the project.
Most enterprise teams are poorly skilled with bad leadership. Modern frameworks and coding paradigms are a bad fit.
> A more opinionated framework that matched the team that was supposed to code with it would have worked better for them over the lifecycle of the project.
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.
Now that's just silly. Longevity of the enterprise application is of no concern at all. The only things that matter is on-time and on-budget. If you can't deliver that, then you run into the problem the author of the article ran into, his bosses yelling at him and his career and job in jeopardy.
If the project develops issues after all the initial stakeholders have moved on, it's the new stakeholders' problem.
Not everything is a problem. If you design a language and only one human in the world it able to learn it. Then this is not a people problem but a language problem ! You can't control the skill of the team, this can't be the problem this is a fact.
At some point one has to see the trend of all these people hanging themselves with this one platform and maybe there's something to the platform, ecosystem, or community that is lending itself to the hangings.
