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
And hooks. Sorry but React started to go crazy when hooks IMHO.
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-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]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.
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
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.
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/
It's my preferred go-to for Vue and React. Also opens the interesting possibility of supporting React and Vue components off the same stores..
What do you mean fractured? They official recommend Pinia: https://vuejs.org/guide/scaling-up/state-management.html#pin...
> Storybook 'out of the box' is broken and doesn't work at all (unable to resolve '@/...' imports). It's been painful.
So you're blaming Vue because of bad experience with storybook?
Follow all the steps.
$ jest
Error: Cannot find module 'vue-template-compiler'*
My experience is the same across the ecosystem; 3rd party packages, 1st party packages. My 'Out of the box' experience is:
It doesn't work unless you screw around and manually patch things.
There's good things too, but this comment:
> I am not googling days to fix tooling issues
Resonates with my experience at 0%. I don't care who's fault it is, the tooling experience has been bad.
(* no, I really did follow all the steps -> https://stackoverflow.com/questions/65790642/test-suite-fail..., it's just broken)
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 }
},
});
const counterStore = useCounterStore();
const isSomethingExceeded = counterStore.count; // .count does not get offered as an autocomplete option
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.
But I don't want that. I want to build interfaces and not "manually shift" my local state management.