Hacker News Reader

Comment by forgottenacc57 | Hacker News Reader

>>time-travel debugging, hot module reloading, and simple and easy undo/redo capabilities

These things are prime selling points of Redux and it's interesting that they are simply unimportant bells and whistles not worth the massive increase in complexity and cognitive load that Redux brings to ReactJS applications. Use Redux and you have to write a lot more code, really for no good purpose when in most cases you can just store a (HERESY!) global variable and get straight on with the job without twisting your mind around actions and all the other Redux guff.

Redux is an anti pattern.

This article also breathlessly praises webpack, which is a massively complex and configuration heavy JavaScript tool and one of the prime culprits responsible for the JavaScript build tool ecosystem being so damn complex. Webpack needs to go the way if it's predecessors and he replaced with something simple.

View on HN

I have always felt that the Redux projects I've seen are extremely bureaucratic. I don't know if they are outliers, if they are just 'Redux done wrong', but typically I find that every piece of behaviour is split out across multiple layers, generally in different files, to the point it is very difficult to reason what a particular button or event will actually _do_.

I notice also that in these projects, every pull request takes many files. Whereas in an Angular 1 project there would be an update to a template and a controller, now each PR comprise updates to a reducer, a container, a component, a saga, a 'lifecycle component', an action creator, and a props schema.

As for Webpack, I don't understand the popularity. I find configuring it awkward, not least because it relies on third-party plugins of highly variable quality. Most plugins are very poorly documented, and those that aren't invariably seem to have big fat DEPRECATED notices. It seems that any plugin that makes enough assumptions to be useful is inevitably chucked in favour of something that is totally configurable but by default equally useless. YMMV.

At least with Gulp, I could step through a build process and write a little bridging code when two plugins stepped on each others toes. Webpack doesn't give me any such chances.

Redux is a cat that thinks it's a lion.

It's not managing the combined state of a massive 1000-system enterprise mess, it's just pushing some shit out through a browser.

what is "lifecycle component"?

Redux DevTools is immensely useful. Being able to see all of your state for your application and clearly know exactly which action caused some invalid state is great. It also enables QA to export the actions which caused some invalid state rather than needing to laboriously and perhaps inaccurately describe a series of steps.

Redux itself can cause people to write quite a bit of boilerplate, however it massively improves testability, and if you use the correct abstractions and debugging techniques around it definitely decreases cognitive load. The problem is that it's possible for people to misunderstand how it should be used and shoot themselves in the foot.

I agree that Webpack is complex, however it is much more manageable than a series of folders containing obtuse Grunt/Gulp tasks, ad-hoc scripts and wrapper plugins.

I think it says it all the Redux comes with its own set of tools to see WTF is going on inside it.

None of it is necessary. Your code base will thank you as will the gods of software simplicity when you rip out all the Redux and Redux tooling and write this.app.globals.myvar='selected'

Honestly, think about all the time you spend writing not React code but Redux code - it's crazy and totally wasted time and effort.

> rip out all the Redux and Redux tooling and write this.app.globals.myvar='selected'

It's obvious you have no idea what you are talking about.

It's lazy to make an ad hominem attack. I write big feature rich react apps without Redux and never hit any situation where I sit around going "damn I need time travel and hot loading and and extra thousand lines of Redux code to remember state."

I'm sorry, I read your comments, and I could write a 5000 word essay, trying to show you that your perception of Redux is totally wrong, but I'm not going to bother, because I'm sure this won't change your mind in the slightest.

> extra thousand lines of Redux code to remember state

Sorry for yet another ad hominem attack, but this just shows that you are doing something wrong. Yes, Redux requires some amount boilerplate code, but if you need thousands of additional lines of code for state management, then you are lacking code abstraction skills.

Reactjs is dead simple until you introduce Redux.

I think applications can be architected that don't need it.

Isolation of state and transactional, external mutation of sate demonstrate correctness in exchange for (minor) boilerplate that, frankly, only looks complicated (and never should look complex, it's trivial) until you've actually read the code.

You can build an application without functional state management. Of course you can. But, frankly, you can't demonstrate conclusively that you know it's correct or where incorrectness stems from. Which strikes me as something of a problem, and one that does violence to the verb "architect".

> Yes, Redux requires some amount boilerplate code

I think you're underplaying this. The Redux apps I've seen thread data through a great many layers - action creators, actions, reducers, sagas, schemas - and I think it's fair to say that compared to other projects, Redux apps have very long 'chains of operation' (I want to avoid value-laden terms like 'structure' or 'bureaucracy').

Is it worth it? I'm not sure. The Redux apps I've seen have used this 'highly formalized' approach to handle quite simple interfaces. Maybe I'd have different feelings if I was writing something bigger?

It's not that I hate Redux, or think it out and out 'sucks'; but I've worked on a lot of projects and first Redux ones I've worked on seem unusually difficult to reason about, and a few of my colleagues share my feelings. We feel like it is hard to reason exactly what an event or command exactly 'does', and that the diffusion of behaviour across files plays a part in that.

Ok, maybe I underplayed it a bit, and I certainly also had a different opinion when I started to get into Redux.

It is true that if you do Redux "by the book", as taught in the official documentation, then it is indeed quite verbose and confusing in the beginning. But once it makes "click" and you start to understand what the point of all these moving parts is, then it's possible to come up with thin abstractions on top of it to reduce the boilerplate. It would have been great if there was a common "standard" way how to do this, but on the other hand, having the flexibility and power to do things how you want, to make it fit your team and project, is quite nice.

For example, we never liked those huge switch statements in reducers. We just use plain objects, where the key corresponds to the action name, and the value is the reducer function. Not really a big deal, but it just shows that you have the freedom to lay out your Redux app however you see fit.

We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.

And then there is the possibility to use middle wares, which can greatly help in debugging and tracing down actions.

So far everyone in my team is very happy with Redux (and React of course).

> We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.

I think that's a much more pragmatic approach for smaller applications.

I knew this would trigger a remark ;) I'm absolutely aware of the importance of separation of concerns. And our SPA is not small.

I just became less dogmatic about it. We all have been taught how important it is to separate HTML/CSS/JS, but then came React along and put HTML into JS, many people were outraged, including me. I thought I'd never use that crap that violates basic principles of software design, but here I am and I'm loving it. In the context of UI it makes sense to me. Same with Redux.

Could you please give me an example in which cases you think it could become problematic to have actions, action creators and reducers in a single file? In an application that is not small?

Can we not agree redux requires too much boiler plate code but putting everything in the global scope is a bad practice for a variety of reasons.

This thread is exactly why "js developer" gets stereotyped.

Try looking at egghead.io tutorials; Dan Abramov has a series showing the implementation of redux and it really is quite tiny. It solves one problem and solves it well: ensuring that components get notified when state changes.

  this.app.globals.myvar='selected'

How do you find out which part of your code set your global mutable state object (e.g. `this.app.globals[propertyName] = stateType` or `$globals.myvar = 'selected'` or `window.app.globals['myvar'] = 'selectedd'`)? What if two or more bits of logic try to set this variable at the same time and it ends up with a value that you didn't expect? How will you control that `myvar` can only be set to particular values dependent on other state? How will a QA engineer demonstrate to you that it was this state change which broke your application?

Your 'solution' is a bad practice, and Redux is a huge improvement over it.

It's such a dead simple solution that it's never been a problem. Certainly doesn't warrant replacing with all the code and complexity of Redux, which introduces its own demand for testing and QA, and I would argue offsets its own value due to its complexity.

In software development simple = understandable and reliable.

But I just demonstrated that it's not understandable or reliable. You are proposing a solution where any badly written code can affect your global state in a way that you can't control for, and in a way that you will not be able to search for.

Eventually you are going to get bugs, and you are going to have a hard time tracking them down for the reasons I've described.

It might be okay if you work on small projects without many team members, but in larger projects it's extremely annoying to have these kinds of issues.

I wonder if it's maybe the architecture of my application that means I don't need to store much state, and I only store state that doesn't seem to subject my app to the issues you describe.

When I hear about these apps with a heavy reliance on client side state I wonder what the heck they are doing... if you've got so much complex data/logic does it really belong in client state? I'd see it as a problem and try to architect it out, or store it somewhere.

It's absolutely possible to do something that has the issues I'm describing and never see any bugs because you are disciplined and careful. However, as a contractor, I have worked with plenty of teams where due to horrible deadlines and sloppy practices all of the problems I've described have occurred. Basically: once you climb over the learning curve, Redux helps you here.

> Eventually you are going to get bugs,

I read:"Sometimes you are going to get event bus." Indeed sometimes simple event bus (pub-sub etc.) could be sufficient for replace Redux. EventEmitter is already a dispatcher. And then you can easily listen to each event in your app, like in Redux.

I think the key to the scalable apps is good architecture (and correct design patterns), not framework.

And Redux is good as education tool. It encourages people to use one global event bus("dispatch" function), it educates about principles of functional programming. It shows people advantages of event sourcing and CQRS. I think the most value of Redux is that people got educated.

But I don't think Redux (at least Redux alone, without Redux-saga or other solutions) is good tool for use in production code. It's too low level. Too many moving parts. No clear way "what should go where". And JS sucks when comes to immutable code (either Object.assign / ... mess or necessity of using third part library like Immutable.js)

Additionally people don't know how to use it properly. Redux codebases are usually much worse than Redux really demands (e.g. people use ugly switch/case despite the fact in Redux docs there are instructions how to get rid of them: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...

> How do you find out which part of your code set your global mutable state object

Generally, it's easy. My state variable represents a single concept in my problem domain, so there's usually only a single source of truth that would ever update it.

> What if two or more bits of logic try to set this variable at the same time

Generally, this will only happen if the variable is actually a derived property, rather than a primary one. I handle this by making my primary properties observables, and my derived properties read-only computeds. Taking this approach, I don't think I've ever had the quandary you describe, and I've built everything from very thick SPAs to very thin and nimble content sites.

> How will you control that `myvar` can only be set to particular values dependent on other state?

It seems to me a matter of simple discipline.

> How will a QA engineer demonstrate to you that it was this state change which broke your application?

She might write a failing test case, or use the debugging tools I've added to the console. She certainly wouldn't mess about with something as proprietary as Redux devtools, because at that point I'll be unable to move to better JS technologies without getting cross-team buy in. At most companies, that basically means it just won't happen.

Your solution is for everybody in your team to maintain a high level of discipline and for QA engineers to use homegrown debugging tools you've added into the console.

You have effectively advocated for both NIH syndrome and a social solution to a technical problem (effectively "it is possible to write error-prone and difficult to debug code so we should ask everybody in the team to be more disciplined" vs. "lets make it impossible to express error-prone logic, and lets make it easy to observe our state"). I think Yaron Minsky's "Make illegal states unrepresentable" is appropriate here.

From where I'm sitting, your reply looks a lot like an insult. I hope I'm just reading it badly, but as is, I don't think we're going to have a productive discussion.

Where is he insulting you? It reads as a pretty even-handed extrapolation from your assertions. Maybe a little incredulity, but your assertions are a little incredible.

Maybe they are incredible.

I suppose the reason I don't 'get' Redux is probably that I don't 'get' the problem it claims to solve. Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from. But that's just not an issue I've had in the apps I've built.

Maybe the apps I call 'thick client' really aren't? Then again, I've done a fair few gigs in this game, on lots of kinds of projects, so I'd expect by now to have the perspective to say which was which.

That experience also makes me a little stubborn. I've had a few exchanges like this, where people have reacted with incredulity. They remind me a little of the arguments I had convincing people to abandon 'semantic' CSS, or grouping templates and view logic into components. I think history was on my side, at least in those cases, so I no longer feel abashed to walk against the crowd.

> Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from.

Prior to React/Redux we used two-way data binding with first kendo then Knockout.js in a non trivial SPA. It was a nightmare to figure out where certain change events came from. It became a big ball of (un)observable spaghetti. Now you will tell me that our problem was that we let it come this far, and I totally agree with you, but the whole app was started years ago by inexperienced web developers (they were C/C++ devs), then it grew historically into an unmaintainable monster. This was long before I joined the company, and my team is now like the 4th generation working on and refactoring that code.

Redux makes it laughably easy to figure out where state changes come from. Not only that, but time travel debugging is a thing. For the parts that are mostly React/Redux, we made a little debug UI for QA so that they can serialize the last n states, send it to a database and automatically link it to issues. It's still more or less a proof of concept and not as useful as it could be, because not everything is stored in Redux yet, but it did show us that once we are where we want to be it will be an incredibly useful tool to reproduce bugs. Besides that writing unit tests for React/Redux is also easy, compared to other libs/frameworks.

May I ask with what kind of technologies you've been working with so far? Because reading your comments gives me the impression you live in a perfect world, with highly experienced and disciplined team mates, with no problems what so ever. If so congrats, you've won the lottery I guess.

What Simon describes here is why stuff like event log datastores (Kafka, mostly) and CQRS-patterned systems are becoming so powerful, too. If you can just say here is every event that has gone through the system modeled as unambiguous transforms on immutable state, replaying--for both DR and debugging--is a trivial and super helpful exercise.

"thick" client is really meaningless term, when it can mean anything between "5k+ LoC" and "100k+ LoC". I'd argue redux is best used for projects closer to that upper bound.

But I don't have real experience with it. I just extrapolate from general overusage of strong (but inappropriate for smaller projects) tools in JS world and subsequent annoying whining about "JS fatigue".

I fail to see how is any framework code is easier to debug than vanilla js.

React is pain to debug unless internal React error catching logic fires

With vanilla js, things are as simple as putting breakpoints in code and running it in Chrome's standard debugger

I'd love to see the code of your vanilla js SPA :) Or does the server render the HTML, and JS just adds a little bit of interactions? Because then you are right, you may not necessarily need React (but it can also render on the server)

Whether it's in PHP, Python or JS, this type of anti-pattern is considered as such for good reason. I don't know how many days (months?) of my life have been wasted debugging "why is this variable changing, and from where?!?". Accompanied of course by much cursing the developer to the n-th generation who thought it would be a good idea to use a global variable.

>> Redux DevTools is immensely useful

If you use @ngrx/store, they can be used with Angular2+ as well.

https://github.com/ngrx/store-devtools

I don't know enough about React to say whether or not I like Redux, but I've written enough Angular code to know that Angular's lack of a good state manager is a problem. A lot of Angular apps end up storing an object in $rootScope that's treated like a global state, and that leads to weird side effects and bugs if you're not careful. Something like Vuex would be be a great addition to Angular.

> ... $rootScope ...

Didn't you write AngularJS code then?

As the article riffs about at length, Angular (Angular 2+) and AngularJS (Angular 1) are fundamentally different.

Maybe I'm doing it wrong but when I (rarely) need state between components I just plop it into a global variable, of which there only ends up being s handful, and it's never been a problem. When I tried to use Redux first it burned my brain trying to grasp its architecture and how to write the various bits of code it needed, all replaceable with this.app.globals.foo=42

Like @ngrx/store?

https://github.com/ngrx/store

In Angular 1 I have always used Services for storing state and sharing it between components. In the latest versions of Angular we have started using angular-redux.

Undo / redo is a nice to have? If you are building spa web front ends the right way these are essential. Using modals with OK/Cancel buttons to confirm actions is not ok in a web app. It should work more like you are editing a document in a structured way hence undo becomes a requirement. Trying to undo in a web app where state is stored inside components becomes a nightmare. Redux makes this a heck of a lot easier.

Reply on news.ycombinator.com