3 ms·
I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose. Fort
by save_ferris 8y ago
I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose.
Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions).
The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong.
I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.
- woah 8y agoThe real issue here was that someone forced a bunch of developers to rewrite their entire product in a stack they don’t know, against their will.
- acemarke 8y agoHi, I'm a Redux maintainer. Any specific concerns that I can help with? You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org https://redux-starter-kit.js.org
- jamespollack 8y agoi love redux - surface area for bugs is reduced so much compared to the past. thanks!
- pault 8y agoAfter having some pretty extensive (heated) debates about the merits of redux here on HN, I've come to the opinion that the love/hate for redux is a consequence of the departure from MVC architectures that more experienced developers are accustomed to. There are decades of best practices built up around scaling object oriented MVC architectures, but react and redux come from a completely different school of programming where trying to apply traditional inheritance patterns is impossible and can mortally wound a project. There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary: > Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity. It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile. [0]: http://entity-systems.wikidot.com/ http://entity-systems.wikidot.com/
- simooooo 8y agoHaving to write immutably is very very hard to do without leaking. This (for me) negates all the great positives of redux.