5 ms·

Beg to differ, yes, implicit call order will result in huge clusterfucks. React+Redux is already causing Frankenstein apps (which is not implicitly caused by th

• blindwatchmaker 8y ago
  What way of structuring frontend prior to the react/redux 'fad' do you think was superior?
  • fouc 8y ago
    That's a loaded question. What about comparing to the current day alternatives and upcoming ones? People have learned from react/redux and are pursuing alternatives.
  • murukesh_s 8y ago
    Dont think anything was superior but that doesnt mean its perfect. It still amaze me how much time we have to spent(engineer) to get a frontend working. It really should be a completely or semi completely visual process.
    • woah 8y ago
      It's always strange when people act indignant about the fact that engineering a large frontend is difficult, like the world owes it to them for it to be easy. Frontend code is by nature highly repetitive, but each different unit has its own arbitrary tweaks because of the fact that people have to use it. This makes it very hard to abstract. There are a million visual frontend builders out there, and they are all terrible, because you can never get them to do what you want. They are only usable to build example apps, and if used for anything real, require a huge amount of hacking around which results in code that is worse than what it would have been otherwise.
      • ng12 8y ago
        Yep. Underestimating frontend complexity is how we got into this mess. Say what you will about framework churn, React is the first one where I really feel like it's easy to apply basic coding hygiene (e.g. treating abstraction and composition as first-order concerns).
      • ecnahc515 8y ago
        While I agree with you, I think it's important to maybe specify that visual frontend builders generally suck -- for web frontends. In general, the visual UI builders for mobile apps tend to be very good. The reason I think it's important to mention this is because I believe that the amount of variability you have to deal with in the web is far greater, which is why I believe these visual frontend builder systems tend to fall apart.
        • chrisco255 8y ago
          There's two layers to front end development. There is the visual layer and the arrangement of UI elements on the screen...and then there's application state management, routing, http request handling, data caching, inlining assets, etc that all come into play as well. UI builders might help you arrange elements on the screen but they do little to help with the latter except for minor cases like click through handlers.
        • AstralStorm 8y ago
          Visual UI builders for mobile cannot even handle reusable components directly. (Similar dialogs via mixin or inheritance, style extraction etc.) Custom widgets? Amount of work to get them running in one of these is a nightmare. Compare that to game engines such as Unity or UDK and their editors, it's so bad it's laughable.
          • murukesh_s 8y ago
            Why do you think anyone haven't built a good one yet?
      • murukesh_s 8y ago
• tomjakubowski 8y ago
  On the contrary: Redux's insistence on serializable events and side effect-free reducers makes debugging these pernicious "state update" ordering issues, which exist with or without Redux, a far easier job.
  • ng12 8y ago
    Agreed. I like to tell people that I like Redux's devtools more than I like Redux. There's a payoff for all the boilerplate.
    • bryanrasmussen 8y ago
      if someone doesn't want to they don't need to write most of the Redux boilerplate, my last project a colleague wrote out all the boilerplate you normally see in a reducer - 100s of lines, and then I had to go write a new reducer of the same level of complexity and managed to write it with maybe 20 lines of Object.Assign and some values lookup. For him he found my code harder to reason about because it was not explicit everywhere, but for me his was harder to reason about because I had to read the same thing over and over again with just different names. But I wonder which one devtools would have handled easier, probably his.
    • acemarke 8y ago
      Please check out our new `redux-starter-kit` package, which includes utilities to simplify common use cases like store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically: https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/
  • andy_ppp 8y ago
    I don’t agree that state update ordering has ever been an issue, it’s a straw man to justify redux with. The correct solution here is to not design UI updates that can fail because of ordering! Mobx removes all the boilerplate and is far simpler to reason about and test in complex systems. Also async actions/side effects are built in, not third party. If you haven’t tried Mobx it is definitely worth saving yourself thousands of lines of boilerplate in your next project.
• hesarenu 8y ago
  It's boilerplate rather then Frankenstein.
• platform 8y ago
  When we deal with state full objects (classes instances/ database objects/ in memory caches) -- we have to segregate the operations on those objects as: ( 1 ) Operation can be applied multiple times -- result will not change (idempotant op) -- eg delete, select ( 2 ) Operation order is important (eg balance cannot increment before payment is processed ) ( 3 ) operation order is not important, or ordering conflicts can be mitigated by the solution/underlying platform completely. So what React team has realized, is that updating a state variable ( a change operation), often falls into ( 2 ). As react getting more and more use, it tries to find more and more areas to optimize. Which is good. In both time and ram-space dimensions... For the React's run-time system, to perform global optimizations, it is really important to know what order the developer had implied in his/her design for case ( 2 ). Very similar, to what an optmizing compiler, would like to know about a flow of calls/etc. this is very difficult to do for a user level application in JS. Without some help from the developer using the library, those optimizations cannot be done, or they will cause user's state to get corrupted. Their solution is to keep the existing machinery as is, but allow a user to 'tell' the framework about the state variables a bit more than usual. To me this this a fair tradeoff/ask. So I will have to learn a bit more, and may be even restructure my code, to let React (and React Native) to do better global optimizations.... Why not ?! Most programming languages syntax is poor as specifying the intended order of function invocation or value change rules, as 'compile-time' directive. (well, I at least, do not know of any language that let's me do that -- so I resort to forcing some order though function arguments and return type, so that a call to nxt function, must have a certain type provided by a return of a previous function... I think explicit state management, is absolutely the correct problem to tackle. it is difficult and error prone. It is not fair, in my view, to judge React added complexity in this area, as 'deterioration'. Ideally these types of things should have been solved by the compilers .. but javascript (and browser) ecosystem is probably 10-15 years away from even thinking about this.
• politician 8y ago
  You have to concede though that once someone sets up the call order, it's really unlikely to change unless there are bugs or someone's coming to do some yak-shaving. People just don't write productive programs where the instruction sequencing at the function level is non-deterministic or chaotic. The UI is already insane enough with CSS and browser differences fighting you every step of the way to make it worse with clever preambles.
  • joesb 8y ago
    It doesn't even matter if the call order change. Your code will be restarted. It's the same implicit call order you have when a language runtime allocate local variable on stack.
• joesb 8y ago
  When you declare a variable in your code, the variable is actually allocated a slot on the stack, which means there are implicit call orders when you declare a variable. There's nothing wrong with implicit call order when you only call it once.
  • pxndx 8y ago
    But that's not exposed to the developers in a bug-prone way.
• davnicwil 8y ago
  You can write really messy confusing apps with lots of magic and indirection with anything, redux included, but redux by design enforces a single, mono directional and easily traceable chain of events whenever you fire an action. Whether you have 1 action or 100, this doesn't change. It's not, in my view, a pattern which works in the simple case but doesn't scale up. Actually the complexity of understanding redux actions and their effects doesn't seem to change much at all from small to very large apps. This may come down to a well designed state tree (data model), or designing simple actions that don't try to do too much. There are actually big parallels with API design. It might even be the same problem. So does a badly designed REST API mean REST as a concept is the cause? Of course not. In most cases, REST isn't even a limiting factor. It's just been badly designed and badly implemented. I think it's the same with blaming redux for a poorly designed, poorly implemented web app.
  • cageface 8y ago
    In actual use I've seen that Redux apps often wind up with a lot of accidental data dependencies that probably wouldn't have happened without a centralized store. For example devs will lazily use a "currentUser" key in the store for all kinds of unrelated stuff and subtle bugs creep in. Another common problem with Redux is memory issues because various components don't clear their data out of the store when they're unmounted. Redux has some nice features but at this point I recommend people avoid it until they start to suffer from some of the problems it was designed to solve. You can get pretty far with a lot less complexity by use using local component state in vanilla React.
    • davnicwil 8y ago
      I absolutely agree with you and that's been my experience too, I've seen exactly those problems in both my own code and others' code. It took me personally many iterations over various projects to learn the boundaries of where redux makes more sense and where component state makes more sense. That's perhaps the biggest actual inherent problem with redux, that it may implicitly encourage everything to be in the one single centralised store, for newcomers. That's a hard problem to solve, though I'm fairly certain Dan Abramov and the other maintainers have tried to make it clear that this, and using redux at all in simple apps, is usually a mistake.
• danabramov 8y ago
  I'd love to debate the part about persistent call order but the rest of your comment has nothing to do with the content of my article and appears to be a generic rant. Could you help me see how it would result in "huge clusterfucks" with an example? Note React doesn't rely on particular call order. You can move your calls around any way you like. Just that it's persistent between re-renders.
  • RubenSandwich 8y ago
    Dan, I've seen this a few times already. I believe people are misunderstanding "persistent call order" to mean that they cannot change call order between versions of their app. I wonder if another name would help people understand this, maybe: "Non-conditional call order."? That does better highlight that you are worried about conditionals. (It doesn't address the loop issuie though.) Hmm, here is another one. "Static call order"? I guess what I'm saying and what I'm reading from the parent comment is that they are misunderstanding the name.
    • danabramov 8y ago
      Static is pretty good.