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

131–140 of 298 posts

Re: React created roadblocks in our enterprise app

#131

Post by cratermoon »

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

I watched it. It was dumb. A textbook example of some major fallacies: The first is mistaking your level of desire for something to happen with the actual probability of it happening. It's clear he doesn't just think web programming is going to collapse, he wants it to happen. And it's distorted his estimation of its likelihood. I'm sure in 2030 he'll be making videos confidently predicting the collapse of web progra…

> an expert in one domain considers its complexity to be inherent and unavoidable, while assuming other domains, of which they are ignorant, are inherently simple

Like the data science guy I worked with who complained we were making authentication and access control complicated.

Re: React created roadblocks in our enterprise app

#132

Post by sergiotapia »

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

Given the choice of MobX vs Redux, I don't understand how a library with one ninth the number of downloads on NPM is the more "boring" one.

use it, you'll know why it's qualified as "boring".

Re: React created roadblocks in our enterprise app

#133

Post by nawgz »

_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 spent a yea rdoing a lot of intensive React + Electron + D3 + MobX in 2018

Right, and that code still runs and compiles exactly as it did then, correct?

The fact that other tools move on doesn't mean you have to. Actually, out of what you just said, D3, MobX, and React all have not removed any of the APIs you could've used back in 2018. Did people maybe rewrite some tools to support hooks, and in doing so find that hooks were a more concise and readable solution? Yeah, they did, so we moved to hooks.

> a year spent just writing and learning good software in Python gains me so much more transferable skills to anything I touch as a software engineer in the future

How so? This is a complete non-sequitur. If you consider data science / ML to be the entirety of software engineering, then maybe you have a point, but since you even put (for example) beside Python it just looks to me like you hate JS and will pretend it's not software engineering so you can avoid it. Any time you've spent tweaking build systems or updating libraries for no reason is on you, not on JS.

Re: React created roadblocks in our enterprise app

#134

Post by brlewis »

jorl17 wrote: post #121
bastawhiz wrote: post #120

I think some of the points are valid (.Net folks are not going to have a great time working on a React codebase). I think some of the problems are a result of the decision to use Redux. Redux was very much in vogue for a while, but in every project I've used it for, it really hampers DX when you start to get stuck in on a large project. To do stuff that involves async (read: everything), you need helpers (thunks, sag…

What do you suggest developers use instead of Redux?

Not the OP, but I'd suggest using what's built into React, i.e. keeping shared state in a parent component, until you hit one of the reasons the Redux docs enumerate for using it: https://redux.js.org/faq/general#when-should-i-use-redux

Re: React created roadblocks in our enterprise app

#135

Post by postalrat »

unphased wrote: post #125
_coveredInBees wrote: post #56

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…

To pile onto your point, webpack is clearly on its way out, it's all about snowpack now (afaik). I never got a chance to get into learning webpack, and I'm glad now. Throws hands up

Just recently I had to switch a project from snowpack to webpack because adding the features I needed to snowpack added up to too much additional work.

Like parcel snowpack works great when you can use it. Hoping it catches on because I really loved how fast it was.

Re: React created roadblocks in our enterprise app

#136

Post by jeroenhd »

jorl17 wrote: post #121
bastawhiz wrote: post #120

I think some of the points are valid (.Net folks are not going to have a great time working on a React codebase). I think some of the problems are a result of the decision to use Redux. Redux was very much in vogue for a while, but in every project I've used it for, it really hampers DX when you start to get stuck in on a large project. To do stuff that involves async (read: everything), you need helpers (thunks, sag…

What do you suggest developers use instead of Redux?

It all depends on the scope of the project, but if you use Redux as a way to keep a cache of backend data so you don't need to request everything every again in every component or pass everything down in props, then you could consider a system like graphql. One project I'm working on part time is switching from class based components + Redux to functional components + graphql and I must say I'm enjoying graphql a lot more than I was writing actions, sagas and reducers.

I don't have any recommendations for pure client side applications though, but for those you can probably get away with using contexts and hooks for quite a lot of the state management.

Re: React created roadblocks in our enterprise app

#137

Post by cratermoon »

darth_avocado wrote: post #84
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. 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 c…

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

Re: React created roadblocks in our enterprise app

#138

Post by worik »

dumbfoundded wrote: post #102
worik wrote: post #26

Earlier quoted context omitted.

The experienced .NET development team got blind-sided by a script kiddy with a Java Script package fetish.

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.

Re: React created roadblocks in our enterprise app

#139

Post by franklyt »

nickthemagicman wrote: post #79
franklyt wrote: post #62

The main problem I’m having here is that I can’t think of any JavaScript framework that has solved this problem. Angular is just too cumbersome, though it gets an honorable mention. Perhaps there is so much churn here because the correct way hasn’t been discovered yet?

The problem is how broken all of it is trying to work around browsers native warts. As future versions of native JS becomes better and web assembly takes over, things will probably improve massively.

To me, it seems like the concept of the DOM might be the problem.
Post reply on HN