Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React created roadblocks in our enterprise app

medium.com

Post reply on HN
Print view View original

41–50 of 298 posts

Re: React created roadblocks in our enterprise app

#41

Post by ourcat »

swsieber wrote: post #16
ourcat wrote: post #4

AngularJS was indeed a bit of a pain when we switched to Angular 2+ and beyond, but it was so worth it. I chose it because of the skillset that our current (small) team has. There's no way our 'designer' (more an HTML/CSS guy) could have wrapped his head around JSX, the way it mixes scripts with layout markup. The way Angular separates concerns for us is great. And the components are extremely flexible and reactive a…

Oof. I work on an angular app and the build is slow as molasses because it's big. And we of course don't want to move away from the official build tool because build time improvements are always "right around the corner".

True. The build times are slow.

But the recent versions (and updating is also a breeze - mostly) should be faster. And particularly if you drop support for ES5 browsers.

Re: React created roadblocks in our enterprise app

#42

Post by gregoriol »

iagorodriguez wrote: post #36

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…

You are describing a job I really would hate: no inovation, no try. If you can't even change the package.json without getting everyone angry, it's a horrible team to work in.

Re: React created roadblocks in our enterprise app

#44

Post by atum47 »

well, I'm on the opposite side: I failed two code interviews (before the job I have now) because I did not used React. One comment I will never forget from the feedback I got back from one of the reviewers: JavaScript vanilla is HARD to read. Another one was that I used a "global" css file, instead of having CSS in the same file as the "component".

Re: React created roadblocks in our enterprise app

#45

Post by dfsegoat »

rdgthree wrote: post #21
earthboundkid wrote: post #11

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

> They should be brave and take the blame for it!

Projection if I've ever seen it.

https://en.wikipedia.org/wiki/Psychological_projection

Re: React created roadblocks in our enterprise app

#46

Post by majormajor »

Spivak wrote: post #37
bluefirebrand wrote: post #15

Earlier quoted context omitted.

100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.

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!

Re: React created roadblocks in our enterprise app

#47

Post by devmor »

This had nothing to do with react, and everything to do with you rolling over and accepting what other people wanted to do differently irrespective of your project guidelines.

You can't expect an application to remain easy to develop when people do not adhere to your development protocols.

Re: React created roadblocks in our enterprise app

#48

Post by renke1 »

> “Why are file names dash-case when class names are PascalCase? It should reflect the class name, so from now on, we will name them SomePageComponent.tsx.”

That's actually a common practice. Files (modules, that is) are usually named after their principal export.

Re: React created roadblocks in our enterprise app

#49

Post by abhijitramesh »

bluefirebrand wrote: post #15
earthboundkid wrote: post #11

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.

100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.

Totally agree with this

Re: React created roadblocks in our enterprise app

#50

Post by vinceguidry »

earthboundkid wrote: post #11

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.

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.

Post reply on HN