9 ms·

I fear that by the time I'm good enough at react, another library will come out

deleted 9y ago
[deleted]
ng12 9y ago
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/Angular1 did where I couldn't wait to move on after 6 months. We'd have to see an absolutely massive paradigm shift before I'd regret writing my apps in React.
- 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
babaganoosh89 9y ago
Probably next big thing will be straight web components or UI libraries like react or angular converting to web components. So everything should be nicely interoperable in the future, it'd just be a matter of how your modeling your data.
- TomMarius 9y ago
  I personally think that it will be React(-like), but in Rust, using Wasm.
  - veeti 9y ago
    Have you seen https://github.com/DenisKolodin/yew https://github.com/DenisKolodin/yew?
- RobertRoberts 9y ago
  I agree, the libraries will get lighter, just like jQuery has been doing for some time. I tried Vue again recently, and it was a 30 second copy/paste and it just worked instantly. 2 minutes later I had an example working inline with a project I am working on. (how long does it take to build your first React app?) Web components are the dream of sharing code widely across many different systems, just like HTML, CSS and JS do. This is why it will beat React in the long term, wrapped in a lighter weight set of frameworks. Just the other day there was an article discussing how the virtual dom could be improved with a static dom, and then only partially updated at the edges, something React isn't even designed to do. (ie, it does a complete diff of the dom and manages the entire view, correct me if I am wrong here) Finally, if performance is your game, browser optimized code, whether it's web assembly or simple improvements to components, it will always beat a virtualized layer on top of it. Again, React will lose on this point too. The question is, how long will it take before there truly is something better widely available? Or is it here already and we can't see it's value yet?
- tropshop 9y ago
  I recently found https://svelte.technology https://svelte.technology and looking forward to trying it out. It has no run-time like React or any other virtual DOM engine, but instead does compile-time static analysis. It is a Rich Harris project (authored Rollup, Ractive, Bublé) so might be worth paying attention to.
projectramo 9y ago
That's why I am going to wait till next year to start learning JQuery. Should be stable and mature by then.
- combatentropy 9y ago
  Too late, http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
  - exodust 9y ago
    The left column of that site only confirms (for me) how much friendlier Jquery is and that I don't want to give it up.
    - technion 9y ago
      The site only goes to IE10 though. The first three examples, which are probably the worst, improve greatly in more modern browsers that include the fetch() API. In my view even the jQuery examples look a lot better if you can write ES6.
      - chrisan 9y ago
        The first example is not really apples to apples as it doesn't even have error handling which makes the native function look longer. Probably because getJson doesnt support errors by default and you have to use promises http://api.jquery.com/jquery.getjson/ http://api.jquery.com/jquery.getjson/ I ran into this issue of jquery silently failing a while ago and will always remember that pain point
        exodust 9y ago
        I don't think I've ever used getJSON(), only ever the longer form ajax(), and never had issues with error handling, well at least since jquery 1.9 when deferred promises came good. Using .then() to chain events together is very smooth, what I always wanted. I'm lightweight with JS mostly though!
syndacks 9y ago
i fear that eventually you'll be able to just design something in Sketch and press a button for the rest...
- Taig 9y ago
  And then be asked a dozen questions how the layout should behave on small and wide screens, should the headline be ellipsized or word-wrapped? I don't see a general purpose solution for this kind of problem coming anytime soon.
  - filleduchaos 9y ago
    ...uhhh, Sketch has had artboards for ages
  - murukesh_s 9y ago
    Why not have defaults for that and let u choose it if needed?
galieos_ghost 9y ago
React will be around a while due to the ecosystem and the fact massive companies are using it. Big companies aren't going to rewrite their entire front-end for the next flavor of the month framework. React-native gives it staying power as well.
paxys 9y ago
90% of what you learn will be high-level transferrable concepts, that you can already apply to Vue or Elm or whatever else.
fouc 9y ago
You could start with mithril.js, it's a react-like vdom library with a minimal set of api, and vanilla JS for everything else. I've been using it the past 6 weeks and super happy with it. I'm sticking with the hyperscript form of it, but you can use JSX if you want.
manigandham 9y ago
It seems that way, but the fundamentals are simple: functional/declarative programming using self-contained components, just like using regular HTML tags where you pass in all the attributes in the tag to customize it, but now with javascript for much more flexibility in what you can pass in via those attributes. Those fundamentals are useful everywhere, like backend event-sourcing, CQRS, message-driven actor systems, and even all of the other libraries like Vue, Angular, etc. Learning any of these is like learning 80% of the rest. Also React has some of the best release and upgrade notes along with tooling so that you can take an app through versions very easily.
deleted 9y ago
[deleted]

deleted 9y ago

[deleted]

ng12 9y ago

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/Angular1 did where I couldn't wait to move on after 6 months. We'd have to see an absolutely massive paradigm shift before I'd regret writing my apps in React.

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

babaganoosh89 9y ago

Probably next big thing will be straight web components or UI libraries like react or angular converting to web components. So everything should be nicely interoperable in the future, it'd just be a matter of how your modeling your data.

TomMarius 9y ago
I personally think that it will be React(-like), but in Rust, using Wasm.
- veeti 9y ago
  Have you seen https://github.com/DenisKolodin/yew https://github.com/DenisKolodin/yew?
RobertRoberts 9y ago
I agree, the libraries will get lighter, just like jQuery has been doing for some time. I tried Vue again recently, and it was a 30 second copy/paste and it just worked instantly. 2 minutes later I had an example working inline with a project I am working on. (how long does it take to build your first React app?) Web components are the dream of sharing code widely across many different systems, just like HTML, CSS and JS do. This is why it will beat React in the long term, wrapped in a lighter weight set of frameworks. Just the other day there was an article discussing how the virtual dom could be improved with a static dom, and then only partially updated at the edges, something React isn't even designed to do. (ie, it does a complete diff of the dom and manages the entire view, correct me if I am wrong here) Finally, if performance is your game, browser optimized code, whether it's web assembly or simple improvements to components, it will always beat a virtualized layer on top of it. Again, React will lose on this point too. The question is, how long will it take before there truly is something better widely available? Or is it here already and we can't see it's value yet?
tropshop 9y ago
I recently found https://svelte.technology https://svelte.technology and looking forward to trying it out. It has no run-time like React or any other virtual DOM engine, but instead does compile-time static analysis. It is a Rich Harris project (authored Rollup, Ractive, Bublé) so might be worth paying attention to.

projectramo 9y ago

That's why I am going to wait till next year to start learning JQuery. Should be stable and mature by then.

combatentropy 9y ago
Too late, http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
- exodust 9y ago
  The left column of that site only confirms (for me) how much friendlier Jquery is and that I don't want to give it up.
  - technion 9y ago
    The site only goes to IE10 though. The first three examples, which are probably the worst, improve greatly in more modern browsers that include the fetch() API. In my view even the jQuery examples look a lot better if you can write ES6.
    - chrisan 9y ago
      The first example is not really apples to apples as it doesn't even have error handling which makes the native function look longer. Probably because getJson doesnt support errors by default and you have to use promises http://api.jquery.com/jquery.getjson/ http://api.jquery.com/jquery.getjson/ I ran into this issue of jquery silently failing a while ago and will always remember that pain point
      - exodust 9y ago
        I don't think I've ever used getJSON(), only ever the longer form ajax(), and never had issues with error handling, well at least since jquery 1.9 when deferred promises came good. Using .then() to chain events together is very smooth, what I always wanted. I'm lightweight with JS mostly though!

syndacks 9y ago

i fear that eventually you'll be able to just design something in Sketch and press a button for the rest...

Taig 9y ago
And then be asked a dozen questions how the layout should behave on small and wide screens, should the headline be ellipsized or word-wrapped? I don't see a general purpose solution for this kind of problem coming anytime soon.
- filleduchaos 9y ago
  ...uhhh, Sketch has had artboards for ages
- murukesh_s 9y ago
  Why not have defaults for that and let u choose it if needed?

galieos_ghost 9y ago

React will be around a while due to the ecosystem and the fact massive companies are using it. Big companies aren't going to rewrite their entire front-end for the next flavor of the month framework. React-native gives it staying power as well.

paxys 9y ago

90% of what you learn will be high-level transferrable concepts, that you can already apply to Vue or Elm or whatever else.

fouc 9y ago

You could start with mithril.js, it's a react-like vdom library with a minimal set of api, and vanilla JS for everything else. I've been using it the past 6 weeks and super happy with it. I'm sticking with the hyperscript form of it, but you can use JSX if you want.

manigandham 9y ago

It seems that way, but the fundamentals are simple: functional/declarative programming using self-contained components, just like using regular HTML tags where you pass in all the attributes in the tag to customize it, but now with javascript for much more flexibility in what you can pass in via those attributes. Those fundamentals are useful everywhere, like backend event-sourcing, CQRS, message-driven actor systems, and even all of the other libraries like Vue, Angular, etc. Learning any of these is like learning 80% of the rest. Also React has some of the best release and upgrade notes along with tooling so that you can take an app through versions very easily.

deleted 9y ago

[deleted]