React created roadblocks in our enterprise app • Hacker News Board

Re: React created roadblocks in our enterprise app

#221

Post by pas » Sat, Jan 23, 2021, 12:43 AM UTC

fuzzy2 wrote: post #220

> Angular would have been a better choice in this case because of similar design patterns. Well sure maybe superficially. There’s classes and then… that’s it. I don’t really see any other part of Angular that would help a (somewhat) experienced (pure) .NET developer in any way. There’s no batteries-included state management either. Technology switches are hard. I don’t think the problem is with .NET specifically but…

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

Re: React created roadblocks in our enterprise app

#222

Post by cratermoon » Sat, Jan 23, 2021, 12:49 AM UTC

darth_avocado wrote: post #200

cratermoon wrote: post #137

Earlier quoted context omitted.

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…

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.

Re: React created roadblocks in our enterprise app

#223

Post by dragonwriter » Sat, Jan 23, 2021, 12:53 AM UTC

_coveredInBees wrote: post #110

arcticfox wrote: post #87

Earlier quoted context omitted.

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

I think the large things in my admittedly limited experience were hooks and context API. Which in a sense isn't a massive change, but the problem is that just like the author of this article mentions, now there are more ways for things to be done, and moreover, because React is a small framework itself, all your 20+ dependency libs have probably moved on and implemented everything with hooks. So now you pretty much n…

> I think the large things in my admittedly limited experience were hooks and context API.

Which, sure, is where a lot of the new goodies are going, but in enterprise land (where I recall working on apps that were .NET 2.0 and .NET 1.1 that were first written well after either was current and are still, AFAIK, being maintained, and on those platforms) writing apps with the still-fully-support class components and ignoring the newfangled options would be completely within the scope of normal approaches. Having new options doesn’t make something less stable, not supporting the old way of doing things is unstable.

> you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think

AFAICT, there’s no active platform where that’s not true, if you want to stay up to date with the newest libs and toys and APIs and current group think.

In enterprise land, though, we typically (at least for any given product team, and often at a larger organizational level) tend to go to the opposite extreme: we plant our flag someplace that was out-of-fashion of the hipsters for years before we even started the project, and nothing that doesn’t actually break what we have built that happens after that really matters. Pushing things out of that rut often takes effort.

Re: React created roadblocks in our enterprise app

#224

Post by flowerlad » Sat, Jan 23, 2021, 12:57 AM UTC

nicoburns wrote: post #219

flowerlad wrote: post #189

Earlier quoted context omitted.

> Simply because there are a lot more people using React than web components. Couldn't you have said that about React vs Angular 5 years ago? > React is a boring, stable framework at this point. And that's why it won't be the most popular framework in 10 years time. React started off as a simple and straightforward library. The React team didn't want to stand still, so they improved it. The "improvements" are making…

1. 5 years ago no: React was already the #1 JS frontend framework at that point. In terms of mindshare if not project volume. 2. I think the key difference is that Angular was a nightmare to work with, especially on larger projects. Whereas React is fairly simple, and tends to be easily maintainable over time. > React started off as a simple and straightforward library. It still is. The implementation is kinda comple…

> In terms of mindshare if not project volume.

Regardless, you missed the point. Which was that, frameworks come and go. The DOM and other APIs implemented by the browser, on the other hand, are here to stay. Very few things built into the browser have been taken away (such as blink and frameset).

> The implementation is kinda complex at this point

Right. And that makes failures and perf issues hard to track down.

If you know how to program using APIs and components built into the browser, that is easier at this point.

Re: React created roadblocks in our enterprise app

#225

Post by randomdude402 » Sat, Jan 23, 2021, 12:58 AM UTC

erlich wrote: post #197

iamsb wrote: post #32

As a counter point, I was almost fired for not choosing to build a SPA for an internal app which was going to be used by 3-5 people, 5-10 times a month, if that many. I worked at large accounting software provider, and internal billing system used static pricing which was changed once a year. The company wanted to move to a more flexible system where pricing can be setup based on few rules like customer type. For thi…

If you join an early stage startup today, it will only be a matter of time until a developer comes in who builds a microservice for what would normally be a single function calling a third party api and then discovers that Kubernetes is necessary. Its almost impossible to stop this happening because business folk want microservices, or they might have heard microservices were going out of fashion but still want Kuber…

I have met enough devs that don't necessarily love to make everything Dockerized microservices on Kubernetes, just that if we don't learn this stuff we risk becoming unemployable.

Re: React created roadblocks in our enterprise app

#226

Post by andrewstuart » Sat, Jan 23, 2021, 1:03 AM UTC

worik wrote: post #185

andrewstuart wrote: post #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…

"- you need to get your developers to do it the way I say" You have a team of developers that have a collective experience of perhaps eighty years in your organisation. Do as I say, me who just popped in and afterwards will pop out again.... That is how millions and millions of dollars are lost in this business.

If a CTO engages an external company to lead them into a project using new technologies for that team, then that CTO would be well advised to accept that their supplier has the right knowledge to advise them.

Re: React created roadblocks in our enterprise app

#227

Post by fuzzy2 » Sat, Jan 23, 2021, 1:12 AM UTC

pas wrote: post #221

fuzzy2 wrote: post #220

> Angular would have been a better choice in this case because of similar design patterns. Well sure maybe superficially. There’s classes and then… that’s it. I don’t really see any other part of Angular that would help a (somewhat) experienced (pure) .NET developer in any way. There’s no batteries-included state management either. Technology switches are hard. I don’t think the problem is with .NET specifically but…

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.

Re: React created roadblocks in our enterprise app

#228

Post by filoeleven » Sat, Jan 23, 2021, 1:21 AM UTC

erlich wrote: post #211

bluefirebrand wrote: post #106

Earlier quoted context omitted.

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.

> evolved to be a very functional approach 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 tha…

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.

Re: React created roadblocks in our enterprise app

#229

Post by plorkyeran » Sat, Jan 23, 2021, 1:26 AM UTC

midrus wrote: post #175

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…

> If a big team is going to be working on it you need some strong opinions around it. You are just stating the problem the article complains about. Whose opinions are those? You need to take a lot of decisions. Moreover, those decisions which seemed good (to you...or the one that dictates those strong opinions) at the time you took it, are not valid just months or years down the road. So you will need to reevaluate t…

> Whose opinions are those? You need to take a lot of decisions.

Making those sorts of decisions is supposed to be what the architect does. It sounds like the author did not do so.

Re: React created roadblocks in our enterprise app

#230

Post by Barrin92 » Sat, Jan 23, 2021, 1:34 AM UTC

midrus wrote: post #175

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…

> If a big team is going to be working on it you need some strong opinions around it. You are just stating the problem the article complains about. Whose opinions are those? You need to take a lot of decisions. Moreover, those decisions which seemed good (to you...or the one that dictates those strong opinions) at the time you took it, are not valid just months or years down the road. So you will need to reevaluate t…

>Whose opinions are those?

the person who has the authority to call the shots and leads the project.

The error is right there in the article:

"After nine months, we have more than 50 pages created. The developers notice that function components are as good as class components and start using them. So, now the project no longer follows the original coding guidelines. It’s more like a personal choice for each developer. And for me, that is OK."

This is where the screw up happens. This is not okay, and as the person responsible for the architecture the author should have made a clear and concise decision and then get everyone to comply with it. You cannot let your developers run wild and then complain a year later when everything is a jumbled mess. Even more opinionated frameworks won't save you because the application is so large it likely would have happened regardless.