5 ms·

I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or h

I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or having to do it the React/Redux way which was honestly overly engineered and non-productive. Frontend shouldn't be complicated and we've been lied to, you are not Facebook, you don't have billions to throw at engineering, you must pick the path of list resistance

42e6e8c8-f7b8-4 4y ago
I believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.
- firtoz 4y ago
  I switched to zustand from redux and I am loving it.
- theteapot 4y ago
  > I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.
  - aliswe 4y ago
    To me, this is where React started to make sense ...
  - lifeplusplus 4y ago
    I had a project where state was coming through redux, from parents via props, context somewhere from parent elements, xhr fetch/graphql, local storage... Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions
    - KronisLV 4y ago
      > Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions You know, with how hooks work in Vue, things seem be easier to understand and get started with. Though at least with React I've had plenty of projects end up with render loops that are hard to debug because of how everything is written. So much so, that I wrote a blog post about it a while back "Modern React is broken": https://blog.kronis.dev/everything%20is%20broken/modern-react-is-broken https://blog.kronis.dev/everything%20is%20broken/modern-reac... Personally I wish that we could already have some tooling that'd tell you something along the lines of: Render loop detected! The following chain of calls was responsible for it: A -> B -> C -> A -> B -> ... Please check the useEffect hook on line X, which has the following items in its dependency array which changed: [Y, Z]
    - thatswrong0 4y ago
      React components don't function like regular JS functions, but look like regular functions. So that's obviously not a legitimate knock against them - you're working within the React runtime. It's not normal Javascript. And lifecycle methods are just as "magical" as hooks. If you just thought about why the "rules of hooks" exist for a moment instead of just hating change for the sake of it existing, you could probably intuit how they work under the hood. Lastly, lifecycle methods don't allow you to co-locate feature-related code, can actually create more bugs (if you have logic in `componentDidMount` but forget to add something similar to `componentDidUpdate` for example), and any logic contained within lifecycle methods isn't composable / reusable. I really don't understand where you're coming from at all with this.
      - lifeplusplus 4y ago
        React should act like a framework/library, not become a transpiler and create javascript 2.0. It's hugely confusing, and harder to reason. I shouldn't have to learn about internals of the library to figure out what's wrong with my code. it's a smell of bad library, this wasn't the problem when simple class functions were used as lifecycle methods.
  - shirogane86x 4y ago
    As someone who didn't get react at all before hooks, and still doesn't 100% get react with class components (but is quite proficient with hooks) what's the issue with hooks specifically? genuinely curious. I find react with class components very messy, and especially in the basic components, I find useState + useEffect a lot cleaner and easy to reason about than setState and all the lifecycle hooks...
MentallyRetired 4y ago
Bingo. React is great for insane amounts of fine grained control. But I don't want that. I want to build interfaces and not "manually shift" my local state management.
wokwokwok 4y ago
I'm pretty surprised. I recently did the same, and hand's down, the vue ecosystem is weak. Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work at all (unable to resolve '@/...' imports). It's been painful. > Everything is intuitive and I am not googling days to fix tooling issues That has not been my experience; I spent literally 3 days customizing my storybook install to make it work, and digging through 'try this...' threads on https://github.com/storybookjs/storybook/issues/11989 https://github.com/storybookjs/storybook/issues/11989
- ishitatsuyuki 4y ago
  > poor support for style libraries like tailwind Can't relate. Tailwind works fine with anything that supports PostCSS. I run it with Vite and there's zero issues. > the state management ecosystem is fractured between vuex and pinia This is also just not true. Pinia is officially replacing Vuex as the recommended store library for Vue [1]. They're also vastly similar in how they do things, so the knowledge transfer over from Vuex to Pinia. And Pinia just address most of the design goals mentioned in the article in the most simple way. As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer. But as long as you're not doing those sophisticated things, Vue 2 examples should work out-of-box on Vue 3 as well. There are surely less resources for the composition API, but the official introduction guide has been good enough in my experience. [1]: https://vuex.vuejs.org/#what-is-vuex https://vuex.vuejs.org/#what-is-vuex
  - KronisLV 4y ago
    > As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer. I actually recently looked into most of the frameworks out there and their migration efforts. So far, I only found three viable options for Vue 3: - PrimeVue https://www.primefaces.org/primevue/ - Quasar https://quasar.dev/ - Element Plus https://element-plus.org/en-US/ We went with PrimeVue and while using PrimeFaces was an incredible pain with Java, the Vue version seems a bit better. Then again, it's kind of odd that libraries as popular as Bootstrap don't have complete bindings in the form of Vue 3 components.
KronisLV 4y ago
I like React's easy approach to making components a bit more, even more than Vue 3 with Composition API. That said, Pinia (https://pinia.vuejs.org/ https://pinia.vuejs.org/) does indeed seem like an excellent approach to state management! My only problem is that my IDE of choice (WebStorm) is incapable of providing any sort of autocomplete for it, with JavaScript. For example, consider the following store, as an example from their documentation: export const useCounterStore = defineStore('counter', { state: () => { return { count: 0 } }, }); Really simple to define it and then change it with $patch, right? Well, when I try to access the field which is included in the default values, my IDE won't show me the available fields when used in some component: const counterStore = useCounterStore(); const isSomethingExceeded = counterStore.count; // .count does not get offered as an autocomplete option That is kind of annoying, when you have a whole bunch of different fields in there, even if you can predict which kinds. Well, there's also the thing where WebStorm refuses to insert <script setup> tag or even add imports inside of it if it's present in the header of the page, but instead I get a redundant <script> tag at the bottom with the old Vue syntax for defining components, which I then have to clean up manually.

42e6e8c8-f7b8-4 4y ago

I believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.

firtoz 4y ago
I switched to zustand from redux and I am loving it.
theteapot 4y ago
> I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.
- aliswe 4y ago
  To me, this is where React started to make sense ...
- lifeplusplus 4y ago
  I had a project where state was coming through redux, from parents via props, context somewhere from parent elements, xhr fetch/graphql, local storage... Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions
  - KronisLV 4y ago
    > Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions You know, with how hooks work in Vue, things seem be easier to understand and get started with. Though at least with React I've had plenty of projects end up with render loops that are hard to debug because of how everything is written. So much so, that I wrote a blog post about it a while back "Modern React is broken": https://blog.kronis.dev/everything%20is%20broken/modern-react-is-broken https://blog.kronis.dev/everything%20is%20broken/modern-reac... Personally I wish that we could already have some tooling that'd tell you something along the lines of: Render loop detected! The following chain of calls was responsible for it: A -> B -> C -> A -> B -> ... Please check the useEffect hook on line X, which has the following items in its dependency array which changed: [Y, Z]
  - thatswrong0 4y ago
    React components don't function like regular JS functions, but look like regular functions. So that's obviously not a legitimate knock against them - you're working within the React runtime. It's not normal Javascript. And lifecycle methods are just as "magical" as hooks. If you just thought about why the "rules of hooks" exist for a moment instead of just hating change for the sake of it existing, you could probably intuit how they work under the hood. Lastly, lifecycle methods don't allow you to co-locate feature-related code, can actually create more bugs (if you have logic in `componentDidMount` but forget to add something similar to `componentDidUpdate` for example), and any logic contained within lifecycle methods isn't composable / reusable. I really don't understand where you're coming from at all with this.
    - lifeplusplus 4y ago
      React should act like a framework/library, not become a transpiler and create javascript 2.0. It's hugely confusing, and harder to reason. I shouldn't have to learn about internals of the library to figure out what's wrong with my code. it's a smell of bad library, this wasn't the problem when simple class functions were used as lifecycle methods.
- shirogane86x 4y ago
  As someone who didn't get react at all before hooks, and still doesn't 100% get react with class components (but is quite proficient with hooks) what's the issue with hooks specifically? genuinely curious. I find react with class components very messy, and especially in the basic components, I find useState + useEffect a lot cleaner and easy to reason about than setState and all the lifecycle hooks...

MentallyRetired 4y ago

Bingo. React is great for insane amounts of fine grained control. But I don't want that. I want to build interfaces and not "manually shift" my local state management.

wokwokwok 4y ago

I'm pretty surprised. I recently did the same, and hand's down, the vue ecosystem is weak. Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work at all (unable to resolve '@/...' imports). It's been painful. > Everything is intuitive and I am not googling days to fix tooling issues That has not been my experience; I spent literally 3 days customizing my storybook install to make it work, and digging through 'try this...' threads on https://github.com/storybookjs/storybook/issues/11989 https://github.com/storybookjs/storybook/issues/11989

ishitatsuyuki 4y ago
> poor support for style libraries like tailwind Can't relate. Tailwind works fine with anything that supports PostCSS. I run it with Vite and there's zero issues. > the state management ecosystem is fractured between vuex and pinia This is also just not true. Pinia is officially replacing Vuex as the recommended store library for Vue [1]. They're also vastly similar in how they do things, so the knowledge transfer over from Vuex to Pinia. And Pinia just address most of the design goals mentioned in the article in the most simple way. As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer. But as long as you're not doing those sophisticated things, Vue 2 examples should work out-of-box on Vue 3 as well. There are surely less resources for the composition API, but the official introduction guide has been good enough in my experience. [1]: https://vuex.vuejs.org/#what-is-vuex https://vuex.vuejs.org/#what-is-vuex
- KronisLV 4y ago
  > As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer. I actually recently looked into most of the frameworks out there and their migration efforts. So far, I only found three viable options for Vue 3: - PrimeVue https://www.primefaces.org/primevue/ - Quasar https://quasar.dev/ - Element Plus https://element-plus.org/en-US/ We went with PrimeVue and while using PrimeFaces was an incredible pain with Java, the Vue version seems a bit better. Then again, it's kind of odd that libraries as popular as Bootstrap don't have complete bindings in the form of Vue 3 components.

KronisLV 4y ago

I like React's easy approach to making components a bit more, even more than Vue 3 with Composition API. That said, Pinia (https://pinia.vuejs.org/ https://pinia.vuejs.org/) does indeed seem like an excellent approach to state management! My only problem is that my IDE of choice (WebStorm) is incapable of providing any sort of autocomplete for it, with JavaScript. For example, consider the following store, as an example from their documentation: export const useCounterStore = defineStore('counter', { state: () => { return { count: 0 } }, }); Really simple to define it and then change it with $patch, right? Well, when I try to access the field which is included in the default values, my IDE won't show me the available fields when used in some component: const counterStore = useCounterStore(); const isSomethingExceeded = counterStore.count; // .count does not get offered as an autocomplete option That is kind of annoying, when you have a whole bunch of different fields in there, even if you can predict which kinds. Well, there's also the thing where WebStorm refuses to insert <script setup> tag or even add imports inside of it if it's present in the header of the page, but instead I get a redundant <script> tag at the bottom with the old Vue syntax for defining components, which I then have to clean up manually.