this post was submitted on 19 Jun 2023
17 points (100.0% liked)
Vue.js
468 readers
10 users here now
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I was a big fan of Vue 2. Vue 3 is a completely different library if you choose to adopt the composition API (which is where everything is headed). If everyone is going to have to learn a totally new composition pattern, might as well look at what else is out there.
Kinda similar to the big overhaul between Angular 1 and 2
Vue 3's Composition API and composables are more similar to React functional components and hooks than it is to Vue 2 and its Options API. That's not to say that React Hooks and Vue Composables are apples-to-apples. They still have different approaches to reactivity and so on, but the programming model is more familiar between the two.
Coming to Vue 3 from 2 was a bit of whiplash. However I've been working with it for a few days now and have come to appreciate how much more flexible and powerful it is to have access to Vue's reactive primitives anywhere - you don't have to write all your business logic in the scope of a Vue instance.
That said, it comes with a much higher learning curve. Vue 2 gave you guardrails, an easily understood component class structure, etc. That's what I liked about it as it scaled well to large teams. Whereas React scaled to a large team quickly turns into a complete mess. Ask 10 different React engineers and you'll get 10 surprisingly different approaches to how to implement components and architect applications.
Truth. As someone who cares more about getting the job done and done well, Vue 3 seemed like a step back to me. If it's moving to be more and more like React, why wouldn't I just use React? These frameworks don't need to be as complex as they're being made to be, and Vue 2 proved that. Vue 3 loses the magic for me.
I will say it took a bit of warming up to the composition API but referencing the static variables as opposed to
this.variableName
made it easy to spot a bunch of dead code in our components. I also don't have to think about reactivity like I used to.Vue.set
andVue.observable
just aren't necessary any more. So from a surface level it seems you're more abstracted and removed from the target browser code it outputs but from a cognitive overhead standpoint it's been a simpler, cleaner experience using the composition api and build toolchain.My only complaint is inside the script block you have to reference computed values as
variableName.value
instead of justvariableName
. If it wasn't for eslint to tell me I forgot to type ".value" when referencing a computed value in the script block I'd probably screw this up a lot. Having to depend on eslint to address a shortcoming in the api feels wrong to me.