Live data from Hacker News

React created roadblocks in our enterprise app

medium.com

81–90 of 298 posts

Re: React created roadblocks in our enterprise app

#81
post #37

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…

As the old saying goes, you can write FORTRAN in any programming language: https://blog.codinghorror.com/you-can-write-fortran-in-any-l...

Re: React created roadblocks in our enterprise app

#82

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

I never recall it doing that, you may be thinking of the `package-lock.json` which does get created still. It basically creates/records hashes of the packages that get installed when `npm install` runs. Shouldn't always be changes there but depending on how version flags are set in `package.json` an `npm install` could create new `package-lock.json` values if there's a newer version in the repo that gets upgraded/installed.

Re: React created roadblocks in our enterprise app

#83
Unsatisfying read. It wasn't React's fault. PM was looking for blood. Dumping a bunch of devs who have little experience with the tech onto the project. Little notion of process and conventions for the app. Only reason I'm commenting is that the three questions posed by the CTO are entirely valid questions and I wished they'd been answered.

Re: React created roadblocks in our enterprise app

#84

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

Re: React created roadblocks in our enterprise app

#85

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

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

#86
That was a very interesting read and described a lot of interesting, very valid, and very realistic challenges that I could see myself running into in a similar situation. However I don't agree with the conclusion that React shouldn't be recommended for enterprise... instead I found myself thinking, gee, there just happen to be other mindsets, skillsets, management styles, and general ways of doing things, and they collided poorly here. Enjoyed reading this but a bit offput by the FUDdy punchline.

Re: React created roadblocks in our enterprise app

#87

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

> React now looks completely different from React from 1-2 years ago. Libraries fall in and out of favor.

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

#88
One of the core reasons software projects run into problems is politics - and this article is about politics.

What 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

#89
> the new technology’s way of doing things

what 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

#90

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

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

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.

Post reply on HN