Earlier quoted context omitted.
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 a…
React created roadblocks in our enterprise app
81–90 of 298 posts
Re: React created roadblocks in our enterprise app
#82The problem is not about react or not react, the problem is how to align big team to create an application. If a big team is going to be working on it you need some strong opinions around it. Do not mess with the package.json. I cant stress this enough. Actually, the most important file in your whole application is the package.json. Almost nobody should be allowed to add additional dependencies because is the main po…
It's been awhile since I've worked with npm, does it still do that thing where it changes package.json every time you `npm install`? I remember writing a script to discard package.json edits because my PR wasn't supposed to upgrade any libraries.
Re: React created roadblocks in our enterprise app
#83Re: React created roadblocks in our enterprise app
#84Technology 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.
Re: React created roadblocks in our enterprise app
#85I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about…
> The point about React including so little that you become reliant on a ton of external dependencies that see even more churn than the usual JS framework landscape is a very valid pain point, especially when you are building a very large application for the long-term. It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems. > React now looks completely different from Re…
> It's a feature, not a bug.
Yes, a small, light-weight framework can be a good thing. No one called it a bug. But like everything in life, there are trade-offs involved. And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things and don't have an army of web-devs to keep the house of cards from falling down.
Re: React created roadblocks in our enterprise app
#86Re: React created roadblocks in our enterprise app
#87I read the comments here first before reading the blog post, and I was expecting a very different type of (and lacking) blog post based on the combination of dismissive and defensive attitude permeating a lot of the comments here. To be honest, there isn't a lot the author is wrong about. Sure, having a .NET team adapting to React is harder but nothing seemed egregious in the way they tackled things. The point about…
Is that true? Can you give me an example of what you're thinking of? I've used React since pretty much the beginning and the only "completely different" looks I can recall is class-based components -> functional components + hooks. And even that evolution was pretty comfortable and backwards-compatible.
Re: React created roadblocks in our enterprise app
#88What should have happened ideally is that the blog post author would have said to the CTO:
- we're going with React
- you've chosen us to guide you in this
- you now need to trust that my advice on standards and approach is correct
- you need to get your developers to do it the way I say
- if you don't, then we will be building a frankenstein React project which is built like a .NET application
- the success of the project is at risk
And the CTO would have been wise enough to agree and pull his people into line and give the blog post author the authority to demand things be done as he says they should be done.
But that's politics and hard to do.
Re: React created roadblocks in our enterprise app
#89what I find, with virtually every "new technology" that's come out in the past 20 years is that the "way of doing things" is not only completely undocumented, but also not agreed on by any two people. I can't remember the last time I found technical documentation that even bothered to describe what problem the technology was actually designed to solve in the first place - or was even written by somebody who seemed to understand why that would be important.
Re: React created roadblocks in our enterprise app
#90Earlier quoted context omitted.
> The point about React including so little that you become reliant on a ton of external dependencies that see even more churn than the usual JS framework landscape is a very valid pain point, especially when you are building a very large application for the long-term. It's a feature, not a bug. Not understanding this is a red flag that you're going to run into problems. > React now looks completely different from Re…
This is again so dismissive of the author. He seems to have a substantial amount of experience with React. He isn't just some noob who jumped on some bandwagon and picked the latest sexiest thing for reasons. If anything, the entire team seemed to do far more due diligence in decision making than pretty much 90% of the move-fast and break things (TM) SV startups. > It's a feature, not a bug. Yes, a small, light-weigh…
Right, but this still isn't the fault of React. My gripe with this article, and view points like this, is that instead of taking ownership it's again the tool that gets blame and just further perpetuates the "js bad" meme.
> And I'm not entirely convinced that it is a good tradeoff in the crazy JS ecosystem where everything is changing and breaking all the time, especially if you are building more complex things.
Right, and if that's your opinion (and a perfectly valid one!) then don't pick the JS ecosystem and cry when it bites you.