7 ms·

Congratulations to the Vue team, this is definitely a big win for them. Reading through the RFC is really interesting. They specifically call out the dependenc

Congratulations to the Vue team, this is definitely a big win for them. Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM. And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices have shifted so drastically in the last few years.

vmception 5y ago
I agree with that. Its been like a twilight zone interviewing for anything frontend in Silicon Valley the last couple years as they "me too" for React, while I use Vue on my own projects. Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.
ggregoire 5y ago
Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years). Oh boy I was wrong. Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core. At the end of the day it makes me more productive, so I guess that big shift was also a big win.
- flowerlad 5y ago
  > you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug... What kind of application are you developing? Do you have complex UI? Or just lots and lots of pages where you reuse components a lot?
  - ggregoire 5y ago
    The kind of app that has 60k LOC, dozen of pages, makes 15 fetches per page (e.g. a report with 5 charts and 3 series per chart), reuse data between pages to avoid remaking the same fetches, have 1 or 2 forms synchronized between every page (like dates and selects filters), save the filters into the URL query params to be able to share the report and restore it when you open/refresh the app, and so on. You end up with code like this at the bottom of your files myCustomHOC1( myCustomHOC2( withRouter( reduxForm({ form: 'filters', initialValues, destroyOnUnmount: false })( connect(mapStateToProps, mapActionsToProps)(MyComponent) ) ) ) ) Although it's probably not that common anymore (as OC said, practices changed), it was a common pattern a few years ago. In the new project I started last week, I'm using only hooks/context and a few libraries like react-router (useHistory, useParams), react-query (useQuery, useMutation), react-hooks-form (useForm)… and it has been a breath of fresh air. react-query is definitely another "big shift", it completely changed the way I used to think about fetching data and centralize it. It's very good, I highly recommend to try it.
    - flowerlad 5y ago
      Your example would be considerably simpler if you had separation of concerns [1]. You have routing, data fetching, redux, visual components, all in that small snippet. Sadly React devs seem to do this all the time... its like they have never heard of MVC. [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
      - ratww 5y ago
        I suggest searching what each of those HOCs is doing. This code is not dealing with routing, fetching, managing state or rendering. It is merely "gluing" those things together. Doing that can be considered a "single concern". Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at. Also notice there's a disclaimer on your linked article here the author retracts the recommendation.
- mosdl 5y ago
  props propagation was indeed horrible, but you can use context to avoid that (or use other stores).
- ricardobeat 5y ago
  I've been through two large-scale projects now where we went 100% into hooks, and after a couple years the excitement has faded and I often wonder if it was worth it. It seems to end up making code even more complex than before, even though components look simpler on the surface. Not enough to go back to classes, but doesn't feel as good as those first steps. I absolutely hate the manual dependency tracking and having every single thing be wrapped in a useX() method to avoid unnecessary updates.
  - dcgudeman 5y ago
    Is it really that bad? eslint-plugin-react-hooks installs by default when creating a project with create-react-app, which basically does the work for you.
  - onion2k 5y ago
    ... having every single thing be wrapped in a useX() method to avoid unnecessary updates That is a bit annoying, but it's significantly less annoying than having a single huge componentShouldUpdate function that deals with everything a complicated component uses. Hooks don't really change the work a component does. The logic is essentially the same. They just break it down in to smaller, more reusable, more declarative units. That's usually nicer to work with and a lot more "React-y".
  - midrus 5y ago
    Same experience here
  - iamsaitam 5y ago
    In my opinion, the issue here is going 100%. There are use cases where having a class component is easier to manage, f.ex: if you make use of external classes.
- nanagojo 5y ago
  IMO it is good that the React team was open into investigating different paradigms. It's a good thing and you rarely see this with other big projects.
  - hitekker 5y ago
    Well-led projects tend to create new spin-offs rather than overextend their original idea. The former is riskier and more liable to fail, whereas the latter chases diminishing returns and undermines the conceptual integrity of the system. Microsoft forcing Windows on mobile devices in the 2000s is an easy example of that kind of failed leadership. This subject matter is covered extensively in: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
- robertwt7 5y ago
  Yeah this is true, everyone doesn't like change in the beginning. but once I started using hooks for a couple of weeks, it is amazing to see that my productivity is increased a lot
- cyberpsybin 5y ago
  Still waiting for Suspense copium
- midrus 5y ago
  I like hooks, but I've found them to be the biggest foot guns in my 20 year career. Forget a dependency in the dependencies array, forget an useMemo or a useCallback and your application will rerender like crazy. Yes, it looks nice from the point of view of understanding the code, but what actually happens at runtime and the amount of miss steps they can produce is astounding. Nowadays I'm using Vue and it is way, way easier to deal with due to the reactivity model.
wayneftw 5y ago
Facebook is a steward not a dependency. React has been free and open source and largely driven by the needs of the community. Right down to that time when the community cried out about Facebook's odd license clause regarding patents. And they changed it. But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long run if they never make any big shifts, I suppose. Then again, none of the big shifts in React broke anything permanently, did they? I could be wrong about this, I haven't been paying attention since the very beginning…
- gentleman11 5y ago
  Angularjs didn’t really stick around after google moved on to angular 2, despite being open source. People who still wanted a similar workflow switched to vue. I think that’s the concern
  - cout 5y ago
    There's plenty of angularjs still around, for projects that can't or don't want to move to angular 2. The official end-of-life keeps getting pushed back, and I won't be surprised if someone r eventually forks it.
    - ducharmdev 5y ago
      Wow, had no idea AngularJS hadn't hit it's EOL yet
- worker767424 5y ago
  Compare this to HHVM which evolved into a PHP fork no one other than Slack uses.
- porker 5y ago
  > We'll see how Vue fairs in the long run if they never make any big shifts, I suppose. Vue 2 to Vue 3 has felt like a big shift. Big enough to leave most libraries incompatible with Vue3 and a lot of community forks spread around while library authors work out how (and if) to support both versions. Vue 3 is an improvement to work with IMO but it's a rewrite your code kind of upgrade.
buchanaf 5y ago
I don't know. I'm not as familiar with Vue, but React's ecosystem is in such a good spot right now. Between things like RTKQ (or react-query), Material-UI, and react-hook-form, the abstractions over common web use-cases are just so terrific to work with nowadays. And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.

vmception 5y ago

I agree with that. Its been like a twilight zone interviewing for anything frontend in Silicon Valley the last couple years as they "me too" for React, while I use Vue on my own projects. Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.

ggregoire 5y ago

Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years). Oh boy I was wrong. Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core. At the end of the day it makes me more productive, so I guess that big shift was also a big win.

flowerlad 5y ago
> you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug... What kind of application are you developing? Do you have complex UI? Or just lots and lots of pages where you reuse components a lot?
- ggregoire 5y ago
  The kind of app that has 60k LOC, dozen of pages, makes 15 fetches per page (e.g. a report with 5 charts and 3 series per chart), reuse data between pages to avoid remaking the same fetches, have 1 or 2 forms synchronized between every page (like dates and selects filters), save the filters into the URL query params to be able to share the report and restore it when you open/refresh the app, and so on. You end up with code like this at the bottom of your files myCustomHOC1( myCustomHOC2( withRouter( reduxForm({ form: 'filters', initialValues, destroyOnUnmount: false })( connect(mapStateToProps, mapActionsToProps)(MyComponent) ) ) ) ) Although it's probably not that common anymore (as OC said, practices changed), it was a common pattern a few years ago. In the new project I started last week, I'm using only hooks/context and a few libraries like react-router (useHistory, useParams), react-query (useQuery, useMutation), react-hooks-form (useForm)… and it has been a breath of fresh air. react-query is definitely another "big shift", it completely changed the way I used to think about fetching data and centralize it. It's very good, I highly recommend to try it.
  - flowerlad 5y ago
    Your example would be considerably simpler if you had separation of concerns [1]. You have routing, data fetching, redux, visual components, all in that small snippet. Sadly React devs seem to do this all the time... its like they have never heard of MVC. [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
    - ratww 5y ago
      I suggest searching what each of those HOCs is doing. This code is not dealing with routing, fetching, managing state or rendering. It is merely "gluing" those things together. Doing that can be considered a "single concern". Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at. Also notice there's a disclaimer on your linked article here the author retracts the recommendation.
mosdl 5y ago
props propagation was indeed horrible, but you can use context to avoid that (or use other stores).
ricardobeat 5y ago
I've been through two large-scale projects now where we went 100% into hooks, and after a couple years the excitement has faded and I often wonder if it was worth it. It seems to end up making code even more complex than before, even though components look simpler on the surface. Not enough to go back to classes, but doesn't feel as good as those first steps. I absolutely hate the manual dependency tracking and having every single thing be wrapped in a useX() method to avoid unnecessary updates.
- dcgudeman 5y ago
  Is it really that bad? eslint-plugin-react-hooks installs by default when creating a project with create-react-app, which basically does the work for you.
- onion2k 5y ago
  ... having every single thing be wrapped in a useX() method to avoid unnecessary updates That is a bit annoying, but it's significantly less annoying than having a single huge componentShouldUpdate function that deals with everything a complicated component uses. Hooks don't really change the work a component does. The logic is essentially the same. They just break it down in to smaller, more reusable, more declarative units. That's usually nicer to work with and a lot more "React-y".
- midrus 5y ago
  Same experience here
- iamsaitam 5y ago
  In my opinion, the issue here is going 100%. There are use cases where having a class component is easier to manage, f.ex: if you make use of external classes.
nanagojo 5y ago
IMO it is good that the React team was open into investigating different paradigms. It's a good thing and you rarely see this with other big projects.
- hitekker 5y ago
  Well-led projects tend to create new spin-offs rather than overextend their original idea. The former is riskier and more liable to fail, whereas the latter chases diminishing returns and undermines the conceptual integrity of the system. Microsoft forcing Windows on mobile devices in the 2000s is an easy example of that kind of failed leadership. This subject matter is covered extensively in: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
robertwt7 5y ago
Yeah this is true, everyone doesn't like change in the beginning. but once I started using hooks for a couple of weeks, it is amazing to see that my productivity is increased a lot
cyberpsybin 5y ago
Still waiting for Suspense copium
midrus 5y ago
I like hooks, but I've found them to be the biggest foot guns in my 20 year career. Forget a dependency in the dependencies array, forget an useMemo or a useCallback and your application will rerender like crazy. Yes, it looks nice from the point of view of understanding the code, but what actually happens at runtime and the amount of miss steps they can produce is astounding. Nowadays I'm using Vue and it is way, way easier to deal with due to the reactivity model.

wayneftw 5y ago

Facebook is a steward not a dependency. React has been free and open source and largely driven by the needs of the community. Right down to that time when the community cried out about Facebook's odd license clause regarding patents. And they changed it. But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long run if they never make any big shifts, I suppose. Then again, none of the big shifts in React broke anything permanently, did they? I could be wrong about this, I haven't been paying attention since the very beginning…

gentleman11 5y ago
Angularjs didn’t really stick around after google moved on to angular 2, despite being open source. People who still wanted a similar workflow switched to vue. I think that’s the concern
- cout 5y ago
  There's plenty of angularjs still around, for projects that can't or don't want to move to angular 2. The official end-of-life keeps getting pushed back, and I won't be surprised if someone r eventually forks it.
  - ducharmdev 5y ago
    Wow, had no idea AngularJS hadn't hit it's EOL yet
worker767424 5y ago
Compare this to HHVM which evolved into a PHP fork no one other than Slack uses.
porker 5y ago
> We'll see how Vue fairs in the long run if they never make any big shifts, I suppose. Vue 2 to Vue 3 has felt like a big shift. Big enough to leave most libraries incompatible with Vue3 and a lot of community forks spread around while library authors work out how (and if) to support both versions. Vue 3 is an improvement to work with IMO but it's a rewrite your code kind of upgrade.

buchanaf 5y ago

I don't know. I'm not as familiar with Vue, but React's ecosystem is in such a good spot right now. Between things like RTKQ (or react-query), Material-UI, and react-hook-form, the abstractions over common web use-cases are just so terrific to work with nowadays. And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.