React created roadblocks in our enterprise app • Hacker News Board

Re: React created roadblocks in our enterprise app

#271

Post by dumbfoundded » Sat, Jan 23, 2021, 5:49 PM UTC

worik wrote: post #138

dumbfoundded wrote: post #102

Earlier quoted context omitted.

The best choice is always what the team has the most confidence with their skill set on delivering. Your framing is unhelpful. You can build amazing things with both React and .Net patterns. If you're on a deadline, you should probably stick with what you know. Every language and framework has different tradeoffs.

True. My framing is unhelpful. I was reacting, emotionally, to the blaming of the old guard. I do think that Java Script frameworks would be great if they were stable. And for enterprise software - for any sensible definition - stability is a very important criterion. But it is easier to write than it is to read so they keep reinventing the wheel, keep making new, not better, things.

I think the benefit of the new javascript frameworks, in particularly React + Typescript, enables complicated webapps. Facebook is probably the best example of enterprise scale.

The problem with the javascript ecosystem (other than javascript itself) is that browsers constantly change and webapps are expected to be increasingly sophisticated. The stacks can't really settle down until our expectations of what they should do stabilizes. I feel that's why we seen much less churn on the backend.

Re: React created roadblocks in our enterprise app

#272

Post by vinceguidry » Sat, Jan 23, 2021, 6:24 PM UTC

interlocutor wrote: post #78

vinceguidry wrote: post #50

Earlier quoted context omitted.

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.

Re: React created roadblocks in our enterprise app

#273

Post by varispeed » Sat, Jan 23, 2021, 7:40 PM UTC

hertzrat wrote: post #8

There are a variety of clips of Jonathan blows twitch stream where he talks about web development. He feels that it has gotten so inefficient and complicated that it now takes 20x as long to create something as it needs to. He suggested that it would be faster for most teams to create their tech stacks utterly from scratch. He further argued that once this efficiency problem gets figured out, most web jobs will disap…

Things got more complex because the problems got more complex. Creating a stack from scratch is something that a contractor would suggest to a company, so then they will have full bookings for fixing those. I was at couple of companies who were React/Angular/.NET shy and their CTO wanted to show off building ultimate framework that will make company millions. Every developer had to spend weeks figuring out how to use it and then they always f up something. One gone bankrupt another is rebuilding everything with React...

Re: React created roadblocks in our enterprise app

#274

Post by pas » Sat, Jan 23, 2021, 8:52 PM UTC

dirtnugget wrote: post #264

pas wrote: post #258

Earlier quoted context omitted.

I'd pick RxJs over Redux, naturally if a team should use whatever they're happy with.

RxJS is not a replacement for redux, in fact ngrx is a redux implementation based on RxJS and Angular. It brings everything, including effects with their own plugins and it is quite a pleasure to work with.

I'm aware, I'm saying that using (a few singleton) services for managing state plus RxJS to effectively propagate (state) changes into every other component/service provides a comfortable development workflow/mindset. (I find redux-like patterns unnecessarily complex.)

Re: React created roadblocks in our enterprise app

#275

Post by dirtnugget » Sat, Jan 23, 2021, 10:10 PM UTC

pas wrote: post #274

dirtnugget wrote: post #264

Earlier quoted context omitted.

RxJS is not a replacement for redux, in fact ngrx is a redux implementation based on RxJS and Angular. It brings everything, including effects with their own plugins and it is quite a pleasure to work with.

I'm aware, I'm saying that using (a few singleton) services for managing state plus RxJS to effectively propagate (state) changes into every other component/service provides a comfortable development workflow/mindset. (I find redux-like patterns unnecessarily complex.)

Yes that I completely true. However, not sure of you know @ngrx/entity but it solves 80% of all business logic I need in a clean way. An most of the time creating services I end up building exactly what the framework gives me

Re: React created roadblocks in our enterprise app

#276

Post by worik » Sat, Jan 23, 2021, 10:57 PM UTC

sli wrote: post #254

nawgz wrote: post #199

Earlier quoted context omitted.

“We judge ourselves by our intentions and others by their actions”

Great reply to this mindset. The chance that anyone who makes this claim has actually evaluated enough (or any) JS projects to see why they churn is effectively zero. We have version pinning for a reason. It lets churn exist without forcing the effects of it onto other developers. I don't care if a library I use gets updated every week or even every day, I'm not installing every new version when it's released, that's…

I have evaluated a lot of Javascript frameworks, back in the day.

I have seen nothing new in JS frame works. I have seen a lot of old in JS frame works.

The whole area stinks. Repeating mistakes of yesteryear.

Easier to write than read - explains a lot

Re: React created roadblocks in our enterprise app

#277

Post by earthboundkid » Sun, Jan 24, 2021, 12:33 AM UTC

hospadar wrote: post #77

jt2190 wrote: post #27

Earlier quoted context omitted.

> ... the real problem was a poorly skilled team with bad leadership... Given this kind of team and leadership, why does that still make React the best choice for them?

AMEN! 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/b…

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

Re: React created roadblocks in our enterprise app

#278

Post by earthboundkid » Sun, Jan 24, 2021, 12:35 AM UTC

interlocutor wrote: post #78

vinceguidry wrote: post #50

Earlier quoted context omitted.

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.

Lol, Web Components aren’t a standard. They’re a series of unrelated technologies and a good PR campaign.

https://blog.carlmjohnson.net/post/2020/web-components/

Re: React created roadblocks in our enterprise app

#279

Post by jlbooker » Sun, Jan 24, 2021, 2:52 AM UTC

> He already has a development partner in India, but they lack experience in building web applications.

That was never going to go well.

> They want to use the .NET guidelines and design patterns in React.

Yes, you have .NET developers trying to be web developers. Totally different skill set. That's not going to go well, or quickly.

Re: React created roadblocks in our enterprise app

#280

Post by mpawelski » Sun, Jan 24, 2021, 12:07 PM UTC

fuzzy2 wrote: post #227

pas wrote: post #221

Earlier quoted context omitted.

Angular has built in dependency injection, recommends to use services to encapsulate state. Built-in services use RxJs for propagating changes by default, and following that pattern gets you very far. Especially for an enterprise app. https://angular.io/guide/singleton-services

Hm, right, forgot about DI. Still, RxJS is the one thing many of my peers just cannot seem to grasp. So IMHO that's actually a minus.

I think RxJs evolved from "Reactive Extensions for .NET" which was quite popular even 10 years ago. So the core idea is probably well understood by many .NET devs.