My experience with Vue 3

May 30, 2024 Roberto Magalhães

Our UX/UI and Frontend developer, Gustavo Nering, shares insights into why he loves this framework.

Vue is a lovely framework. I confess that it wasn't my first choice as a frontend developer, but once I got my hands on it there was no looking back. That's because there's a lot to love here, especially its incredible documentation and the fact that it forces the developer to break things down into smaller pieces of code, which ultimately help with development and debugging.

I started with Vue 2 and have refactored a Vue 3 app over the last few months. In principle, it's like using any other framework, with the difference that it takes a lot of Vue's way of thinking into a new way of organizing and calling properties.

Now that I've used Vue 3, I can safely say that this is a great framework . Here are some of the reasons:

Composition API

As a beginner with Vue, there is a considerable learning curve.

The Options API has a very structured way of organizing the code. Ultimately, a developer is using a large object with data properties, computed properties and methods (there are more properties for specific scenarios) where each property has its own particularity.

A 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 the Options API organizes an object with these attributes in mind. This makes it easier to understand what is happening in the code.

The big downside is that the code is very Vue. You're writing a mix of Vue and JavaScript, so there's a bigger learning curve compared to something in React where the JS part is pure JS with some React helpers to make the UI logic work.

This is a problem that the Composition API solves.

You can add a configuration tag to the script tag and have pure JavaScript with some Vue helpers to make the UI logic work. All this without losing the easy understanding of what is happening in the code. Helpers even mark up your code, which helps a Vue developer figure out what's going on in the component.

Since you won't be working with a large object anymore, if you need to call a variable, 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 the Options API, they'll be happy to know it's still supported. The Vue team is kind enough to keep everything working without breaking what worked before.

v-bind in CSS

I love CSS. Seriously, I'm not lying. Sometimes we need to make something in our component dynamically styled.

In Vue 2, there is a way to do this using a combination of CSS custom properties with a Vue computed property. But this is a workaround. It works, but it's kind of complicated and a little hard to understand when you're reading it.

In Vue 3 you can call v-bind in your CSS. Just add your data property in parentheses and the style is ready to be dynamic.

For the love of Pinia

Just like Vue, VueX has a strong opinion on how to organize your store. You need mutations to change a state, so each action involves a commit that is called on another file, which is very demanding on the developer.

Pinia eliminates the need for mutations. It also asks you to keep all stores in a single file, making the developer experience much more pleasant. This forces the team to think more about how to organize their store.

I can tell you a personal anecdote to illustrate the importance of this. My team started working without much thought on an application that many people worked on. So there was just one store with a lot of things going on. To make it easier to understand, my team got together and divided that large store into specific smaller stores, which helped a lot in understanding where a piece of state came from.

When there is no mutation, it is much 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.

Bossy TypeScript

That's a big deal. And it's not just a new way of organizing your code, it's another way of thinking about 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 execute. As long as the app works, that's someone else's problem in the future.

As my example points out, this is both good and bad JavaScript behavior.

When you start using TypeScript, that feeling of “Why do I need to do this?” It's just more code for some IntelliSense that leaves you tired because some errors don't make sense. Basically, I was used to JavaScript's eagerness to make my slow code run. But it makes sense to avoid the potential problems of something being undefined or an endpoint not retrieving data.

I made a conscious decision to stop fighting the adoption of TypeScript and instead start embracing it as something that is here to help. Type makes your code more reliable, which makes your application less prone to mysterious bugs. Ultimately, it helps create a better product and better user experience for end users.

Should you opt for Vue 3?

As with everything, it depends.

As a developer, the development experience of working with the Composition API brings many benefits. Considering most frontend developers come from React, Vue 3 seems much more familiar than the Options API.

Additionally, TypeScript brings many benefits to defining object structures directly in code. When working with components, it is quite common to use an object as a support. TypeScript requires you to create a type with the object structure of this property. If you don't have enough time to create adequate documentation about how to use this component, the type can help you understand what this support expects. Working with Vue is an incredible experience and Vue 3 only makes the experience even better. So, you should try it to see how it goes for you.

If you liked this, be sure to check out our other Vue articles.