Hacker News Reader

Comment by lioeters | Hacker News Reader

This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. In retrospect, over-engineered React code can be worse than decently organized jQuery code, but some jQuery mess was worse than any React code. So I guess I'm saying, React did raise the bar and standard of quality - but it can get to be too much, sometimes a judicious use of old familiar tool gets the job done.

View on HN

You reminded me of a time where one of my clients asked me to add a feature on a file uploader written in react/redux. This was early 2021.

I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways, the form literally had a textual input, a button to open the file explorer and a submit button.

It took few weeks one of their Romanian team to build it and apparently that team was reassigned and nobody could touch it without them.

I remember writing pages and pages of notes to understand how this all tied up in those extremely complex chains and claiming progress after few hours when I achieved to simplify the flow by removing a handful of these actions. Hooray.

Then it suddenly dawned on me that...I could just rewrite it from scratch.

Nuked the entirety of that nonsense and replaced it with a single useState in a matter of few hours also implemented the newly requested features.

The client could not believe my progress and the fact I also removed many of their previous issues.

Then I had a second realization: React was useless too and it got dropped for native HTML forms and a handful of JS callbacks.

> I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways

I 100% believe this, as it describes all the redux codebases I've seen. The library seems to be an antipattern of indirection.

I really can't understand how someone would make 30 redux actions for a simple use case, as someone has implemented the exact same thing. But yes, not a fan of Redux myself

Many years ago, I used Redux to build real time streaming data processing layer. Basically I need to receive, merge, and process multiple data streams into a single realtime data pool. After that,consuming the realtime data becomes dead easy.

Even now I am not sure I could find a better tool to deal with real time data and synchronization. But for simple crud Redux is mostly overkill

https://rxjs.dev/guide/observer

True but rx was even more niche than redux. It was much easier to hire redux devs

you got to the crux of it. Redux became a trend, surfing on its popularity at a time React wasn't providing the reactive piece it needed, plus the time machine demo just amazed everyone. The author got his job at Facebook. It carried millions of developers to use that lib, the author even said it isn't necessarily the go to mechanism, but hiring manager stuck with the idea that all projects redux magicians, since all projects needed React.

For the anecdote, I remember my manager admitting we can't fix the legacy app, but we can put lipstick on the pig with React.

Have some pity for those Senior Expert Architect Full-Stack Developers (fresh out of boot camp) in urgent need of job security.

The original developers weren't bootcampers but engineering graduates.

And in the same way faang is filled with leetcode blackbelt charlatans writing slop, so is Romania apparently.

Great generalization of an entire country's sector workforce.

I'm sure you'd 100% approve of such a statement of your country when based on one anecdotal recount (even if it true).

It's not about Romania or any other country.

I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.

It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.

This sounds like an engineering quality problem rather than a tooling problem.

Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.

Redux Toolkit has been a nice batteries-included way to use redux for a while now https://redux-toolkit.js.org/

But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.

I took a look at the quickstart guide at https://redux-toolkit.js.org/tutorials/quick-start and to me it still seems to add a lot of indirection.

"We'll build a big centralised store and take slices out of it" still feels like something you should eventually realise your app now needs rather than a starting point, even in libraries which do it without as much ceremony and indirection as Redux.

This brought back flashbacks of a brief moment when I was left as the sole maintainer of a “soon-to-be-axed-but-currently-critical” feature in a checkout flow developed by people who A) knew redux and B) were not me. They recently implanted some state updates before departing, and the bugs for that fell to me. I think I spent a few days tracing the code and understanding how they managed their state, and I think I needed to touch about five files to fully encompass the updates for one data point - I felt nuts!

> The library seems to be an antipattern of indirection.

Auto-generated actions from slices are a codified way to do what was once considered an antipattern: Tying an action directly to a single reducer, instead of actions being an action the user could do on a page (which multiple reducers could respond to).

I hear you saying that React raised the floor but also lowered the ceiling.

>> This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related.

To be fair, jQuery was a response to the the IE and JS variant mess of the early 2000s. jQuery made development possible without debugging across three browser varients.

Standardized selectors was the big use case for me

React made complex interactive UIs a lot easier to manage than jQuery, but that resulted in many developers adding a lot more complexity just because they could.

Reply on news.ycombinator.com