Vue is a lovely framework. I confess it wasn’t my first option as a frontend developer but once I got my hands on it, there was no going back. That’s because there’s plenty to love here, especially its amazing documentation and the fact that it forces the developer to break things into smaller pieces of code, which end up helping with development and debugging.
I started with Vue 2 and had been refactoring a Vue 3 app for the last couple of months. At first, it’s just like using any other framework, with the difference that it takes much of the Vue way of thinking to a new way of organizing and calling properties.
Now that I have used Vue 3, I can confidently say that this is a great framework. Here are some of the reasons why:
Composition API
As a newcomer to Vue, there is a considerable learning curve.
Options API has a very structured way of organizing the code. In the end, a developer is using a big object with data, computed, and methods properties (there are more properties for specific scenarios) where each property has its own particularity.
One big advantage of Vue is that the code is very visual. It’s easy to know what’s a prop, what’s an event, and what’s reactive data because Options API organizes an object with those attributes in mind. That makes it easy to understand what’s going on in the code.
The big disadvantage is that the code is very Vue. You’re writing a mix of Vue with JavaScript, so there is a bigger learning curve compared to something in React where the JS part is pure JS with some React helpers to do the UI logic work.
That’s a problem that Composition API solves.
You can add a setup tag to the script tag and have pure JavaScript with some Vue helpers to make the UI logic work. All that is done without losing the easy understanding of what’s happening in the code. The helpers still mark your code which helps a Vue developer figure out what’s happening in the component.
Since you won’t be working with a big object anymore, if you need to call a variable, you can just call it. No more saving the component only to find out later that it doesn’t work because you forgot to add it before the property.
But if a team is in love with Options API, then they’ll be glad to learn that it is still supported. The Vue team is kind enough to keep everything working without breaking what was working before.
v-bind() in CSS
I love CSS. Really, I’m not lying. Sometimes we need to make something on our component to be styled dynamically.
In Vue 2, there is a way to do this using a mix of CSS custom properties with a Vue computed property. But this is a workaround. It works, but it is kind of cumbersome and it’s a bit hard to understand when you’re reading it.
In Vue 3, you can call v-bind() in your CSS. Just add your data property within the parentheses and the style is ready to be dynamic.
For the Love of Pinia
Like Vue, VueX has a strong opinion on how to organize your store. You need mutations to change a state, so every action involves a commit that is called in another file, which is asking a lot from the developer.
Pinia removes the need for mutations. It also asks for you to keep all the stores in one file, making the developer experience way more pleasant. This forces the team to think more about how to organize their store.
I can bring a personal anecdote to illustrate the importance of this. My team started working without much thought on an app that a lot of hands had worked on. So there was only one store with a lot of stuff going on. To make things easier to understand, my team got together and broke apart that big store into smaller specific stores, which helped a lot in understanding where a piece of state was coming from.
When there is no mutation, it’s way faster to debug a problem because there are only 2 places where things can go wrong: in a getter or in an action. And since we don’t need to use getters all the time, the problem is probably in the action.
The Bossy TypeScript
That’s a big thing. And it’s not just a new way of organizing your code, it’s another way of thinking of JavaScript.
JavaScript can make you lazy because it just wants to get things done. So it will accept a string when it should be a number and just run. As long as the application works, this will be someone else’s problem in the future.
As my example points out, that’s good and bad behavior from JavaScript.
When you start using TypeScript, there is that feeling of “Why do I need to do this?” It’s just more code for some IntelliSense that gets you tired because some errors don’t make sense. Basically, I was used to JavaScript’s eagerness for making my lazy code run. But avoiding the possible problems of something being undefined or of an endpoint not retrieving data makes sense.
I made the conscious decision to stop fighting my adoption of TypeScript and instead start embracing it as something that is here to help. Type make your code more reliable, which makes the application less prone to mysterious bugs. Ultimately, it aids in creating a better product and a better user experience for the end users.
Should You Go For Vue 3?
As with everything, it depends.
As a developer, the dev experience of working with Composition API has a lot of benefits. Considering that most frontend devs come from React, Vue 3 looks way more familiar than Options API.
Also, TypeScript brings a lot of benefits in defining object structures right in the code. When working with components, it’s pretty common to use an object as a prop. TypeScript demands that you create a type with the object structure of that prop. If you don’t have enough time to create proper documentation on how to use that component, the type can help you understand what that prop is expecting. Working with Vue is an amazing experience and Vue 3 only makes the experience better. So, you should give it a go to see how it feels for you.
By Gustavo Nering, BairesDev UX/UI and Frontend Developer
If you enjoyed this, be sure to check out our other Vue articles.
