5 ms·

Eh, React is 5 years old. I've been writing it professionally for 3. I'm not worried. And honestly -- React doesn't have the same pain points jQuery/Backbone/A

• ascagnel_ 9y ago
  I would argue React will be around a while for two reasons: - The core language has gotten a lot better with ES5+ features. Async, fetch promises, etc., are all now built-ins on modern browsers, and have learned lessons from the pain points the initial implementations in libraries like jQuery. - React itself is only a view layer with minimal concern about the form of your data -- you can use an array of other libraries on top of it to help with shared states, network requests, etc. Will someone come along and do a view layer better than React? Probably. Will it be as big of a leap as what we've seen over the past few years with ES5/6/7 & React? I don't think so.
• txsh 9y ago
  I feel this way about React but Redux seems awkward and worthy of replacement. Am I in the minority on this?
  • beefalo 9y ago
    You are not alone. After trying out GraphQL with Apollo, going back to Redux is painful.
  • rozenmd 9y ago
    There are tons of options for State Management before you even need Redux. Check out: Context API: https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html Unstated: https://github.com/jamiebuilds/unstated https://github.com/jamiebuilds/unstated MobX: https://github.com/mobxjs/mobx https://github.com/mobxjs/mobx
    • fouc 9y ago
      Meiosis is a simple state pattern, a very elegant approach to handling state: http://meiosis.js.org http://meiosis.js.org
    • egeozcan 9y ago
      There's also Baobab: https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab-react https://github.com/Yomguithereal/baobab-react
  • acemarke 9y ago
    I'm a Redux maintainer. Any particular pain points you're concerned about?
    • exogen 9y ago
      Not OP, but my day to day job is helping teams with their migration onto React (often for big sites you've used or have at least heard of). Here goes, although these probably aren't anything new to you: – As far as I understand, Redux was intentionally made to be low-level and unopinionated, with the idea that other libraries would build on top of it. That has not really borne out and it actively makes adoption extremely painful. Everyone just uses Redux directly in their apps. As a result, adopting Redux on every team I've ever been on has been a painful process of figuring out how to fill in the blanks that Redux left out. Like how to handle async actions and side effects, how to name action creators, where to put connect()ed components, etc. And the result never feels great. – Related to the above: it's extremely telling that I can't name a single library of reusable Redux actions/reducers/etc. Despite attempts to define things like "ducks", and there being hundreds/thousands of reusable React components published, there are none for Redux that anyone has ever paid any attention to. Because of the batteries-not-included philosophy, you pretty much just can't share your Redux code, because different apps might be building on vanilla Redux in too disparate a fashion with whatever middleware they chose. That's why I'm expecting the new Context API to displace a fair amount of Redux usage: because publishing reusable Context libraries is going to be brain-dead simple compared to reusable Redux. – Developers just don't get what they should connect() and how to design their components, and Redux doesn't really offer them much guidance. As an example, every single day I have to mention in code reviews that something like a "loadProducts" prop does not make any sense on something like a "SearchButton" component, just because our Redux action happens to be named "loadProducts" – an "onClick" prop that just happens to be mapped to "loadProducts" in connect() makes much more sense. But devs are lazy and just end up giving components a bad design with a bunch of props that wouldn't make sense if Redux were not involved. Most of my code reviews contain the words "design your component's API without even thinking about Redux yet!" There are more, but those are the main issues. btw, thanks for all the hard work you do!
      • 9y ago
  • keithnz 9y ago
    I find conceptually Redux is straightforward enough, just really wordy. I think perhaps if I got to choose again I might consider Mobx. I still use it for my react stuff but most new stuff I'm using Vue.
    • molloy 9y ago
      Mobx and Redux have slightly different use cases, IMO. I prefer Redux for larger projects and Mobx for smaller ones, though I've only used Redux in production so far.
  • Bizarro 9y ago
    No, you're probably in the majority. The problem isn't really the core concept of Redux, but needing to integrate the whole ecosystem around it - thunks, sagas, selector library, various other middleware. Standard redux is just too low-level. Take a look at Mobx State Tree https://github.com/mobxjs/mobx-state-tree https://github.com/mobxjs/mobx-state-tree
  • gunn 9y ago
    I created my own library after finding redux boilerplate heavy. I haven't publicized it yet, but you can see it here - https://github.com/gunn/pure-store https://github.com/gunn/pure-store It supports full typescript typing, and uses Immer to allow very direct store updates with immutability.
    • jamesiscool 9y ago
      Wow that look amazing, how can I subscribe react to the store? Will each component need something like mobx observer?
  • jetako 9y ago
    I've been using redux-zero on my latest projects with reasonable success. It does away with the distinction between actions and reducers, so you're basically just calling functions that update the app state. This eliminates almost all boilerplate-ish code compared to redux, but it comes with its own caveats. I think it's a solid choice for small to medium size applications. https://github.com/concretesolutions/redux-zero https://github.com/concretesolutions/redux-zero
  • hesarenu 9y ago
    Mobx. I went from redux fanboy to using mobx exclusively.
• Bizarro 9y ago
  I'm somewhat regretting not moving over to Vuejs from React when I had a better time opportunity. And I actually like JSX.
• vmware513 9y ago
  The best if you learn and practice the following four libraries and frameworks: React, Ember.js, Angular, Vue. You will see different concepts and you gonna be a real professional frontend dev. For example, you can create a simple interface or widget with React, but if you have to develop a complex big web application, Ember or Angular is a better choice. Most of these frameworks have great support, community and matured. Learning Ember is so easy as React: http://yoember.com http://yoember.com