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

211–220 of 298 posts

Re: React created roadblocks in our enterprise app

#211

Post by erlich »

bluefirebrand wrote: post #106
munchbunny wrote: post #40

Earlier quoted context omitted.

I've worked on stacks with .NET backends and React frontends, and there's a ton of truth to this. You can't use .NET concepts to bridge into an understanding of React. If you need to carry over .NET's paradigms, don't pick React. Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming langu…

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 that `useEffect` could modularize code that was otherwise split between `componentDidMount/Unmount/Update`...but couldn't a new class API also have solved this.

Maybe I just need to read the docs again to remind me. I'm all in for hooks, but it's rare that I think about what life could have been like if we kept class components.

Re: React created roadblocks in our enterprise app

#212

Post by erlich »

zmmmmm wrote: post #104
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'm still kind of stuck on the fact that they brought a team of .NET devs on to do a React project. What did they think was doing to happen when they used a team with no experience in the technology stack chosen? The conversation should have started with "What skills do the implementation team have?" before tech was chosen.

Is there a frontend framework you can choose that suits .NET devs? Maybe this would have been a better choice if there was. Maybe Angular was better. Or Ember.

Re: React created roadblocks in our enterprise app

#213

Post by cratermoon »

twobuy wrote: post #167
janaagaard wrote: post #163

Earlier quoted context omitted.

We have a pretty similar issue at work where our package-lock file switches URLs between npmjs.com and our own npm registry. Can you elaborate a bit on what the issue is and how to solve it?

This is likely referring to the .npmrc registry field.

Yep.

Re: React created roadblocks in our enterprise app

#214

Post by erlich »

akamaka wrote: post #58

I’ve built successful large enterprise apps in React, and would recommend it. Here’s how we avoided some of his pitfalls: * Small team of talented developers who didn’t always agree on libraries and methodology, but worked through disagreements to reach a consensus * Recognizing that libraries would change over a two year project, and being ready for major library migration and refactoring * Writing our own state man…

> why not create your own custom state management system from scratch

Normally "roll-your-own" is bad advice. But in enterprise apps I can see all you needing is an API client with normalized caching (Apollo or `react-query` for REST), and store as much of your page state in your query string, and the rest in React Context. I would reach for Recoil if React Context performance became an issue.

But rolling your own comes with so much personal risk if things go wrong - not good for politics.

Re: React created roadblocks in our enterprise app

#215

Post by lhorie »

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

I’m sure you make this comment in good faith, but no - every React project I’ve been part of sounds very similar to this. The others, not so much, and I’ve been doing frontend for over a decade. There is a distinct amount of churn and excess of dependencies / eternally unsolved problems that is particular to the React ecosystem. Note that your suggestions do not address the main problems: time spent upgrading librari…

IMHO, there's a bit of an irony that I see with a lot of React projects: people often say that w/ vanilla JS, you end up reinventing wheels poorly, yet this is exactly what a lot of React projects I see look like: people that don't really have framework-building experience attempting to cobble up something similar in scope to Angular or Ember by using React + a bunch of other libraries (often libraries they've never used before).

There's certainly a case to be made about large teams being a problem of their own, but FWIW, a lot of projects _don't_ have large frontend teams (I'd say 1 to 3 frontend devs is fairly typical). Standardization _across_ teams can definitely be a problem, but at some point one has to wonder if it isn't more sensible to just have each teams develop separate apps that load in separate pages, or, you know, just use a more batteries-included, prescriptive framework.

Re: React created roadblocks in our enterprise app

#216

Post by erlich »

sergiotapia wrote: post #3

I don't agree that React is not enterprise ready. The mistake OP made was reaching for Redux for some weird reason. Redux-saga, _thunks_? I guarantee this project used thunks of some kind because some blogger posted about it and it was popular and trendy. Pick boring tech that's objectively simple and not an exercise in genius. mobx, today: apollo-client (if you have a graphql api). I've never seen any other project…

Agree! Redux is never needed and was always a bad choice IMHO.

The goals of it seem so misaligned with developer productivity.

It was small, elegant library for the sake of being small. Ultimate flexibility that can do everything, but then required building heaps of stuff on top of it, and favoring this immutable one-way flow that just complicated things riding on the coat tails of flux.

> I've never seen any other project stain a framework as much as Redux has done.

100%

Re: React created roadblocks in our enterprise app

#217

Post by erlich »

nawgz wrote: post #65
zumu wrote: post #17

Earlier quoted context omitted.

> I've never seen any other project stain a framework as much as Redux has done. Is there a good article that would summarize the backlash against Redux? While I don't do front-end much anymore, Redux was such a productive tool for me when I was a contractor. I found it incredibly powerful and easy to work with, if cerebral for the uninitiated. Meanwhile, I had the exact opposite experience with apollo-client and the…

It sounds like GP drank the mobx juice to me. Honestly, after using mobx, it's almost impossible to understand why Redux is popular. MobX is more concise, more performant, has a crazy amount of built-in optimizations, and lets you forget about tracing your crazy graph of relationships just to update some view. Of course, mobx had "bad" (read: used decorators) syntax for a while, and only with MobX 6 did they clean it…

How would you compare MobX vs. Apollo + React Context?

Re: React created roadblocks in our enterprise app

#218

Post by julianmarq »

nawgz wrote: post #156
ralmidani wrote: post #150

Earlier quoted context omitted.

React is stable? React.createElement -> Sub-classing the Component class -> "just use hooks everywhere" in the span of a few years? Sure, Django went from function-based to class-based views, but the change was far less abrupt, and you can still use functional views if you want to. As for TypeScript, I agree it's amazing, but it's neither a framework nor a library for building web applications. It's more of a superse…

>React is stable? Yes. Despite what you're trying to imply about them "updating" too often, my code from 2016 still works correctly against the newest versions of React. That's pretty much the definition of stability to me. > the change was far less abrupt, and you can still use functional views if you want to So you are hating on React because you don't know this, but this exact optional progression has always been…

> hating on React

It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars.

They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway).

> With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.

How can you "promise" this? How can anyone "promise" this? I'm not even sure I understood what you meant by this. Even more so in this case as the tools you mentioned are geared to different types of applications.

The only way I can parse this sentence is that you're claiming that react is indisputably better at [not sure what you meant to do since you said "website" and a website doesn't need a backend$, but you mentioned backend regardless] than any tool in [whatever other language/framework, clearly, even if you're using Python as example] and I'm gonna need a source on that one. It's a pretty strong claim, assuming I didn't misinterpret it.

$ Technically, a website doesn't need a frontend either; it's debatable whether a website even needs javascript, but certainly not react, which is a library for creating web applications.

Re: React created roadblocks in our enterprise app

#219

Post by nicoburns »

flowerlad wrote: post #189
nicoburns wrote: post #151

Earlier quoted context omitted.

I suspect React has a much greater chance of being around in 10 years time than web components. Simply because there are a lot more people using React than web components. React is a boring, stable framework at this point.

> 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 complex at this point, but the API is still super simple.

Re: React created roadblocks in our enterprise app

#220

Post by fuzzy2 »

> 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 with developers that stopped longing. Longing for new technologies, new algorithms, …

Post reply on HN