Vue Application Recommendation for Create App

March 12, 2023 Written by Md Ferdous Hassan Alin. Posted in Javascript, Programming Language No Comments

When you’re starting a new Vue application, you have to make a lot of choices. Should you choose Vue 2 or Vue 3? Should you use a state management system? Should you use something called the Options API or Composition API?

There are a lot of things you have to choose and it’s not always easy to understand what the best choice is. So in this post, I’m going to break down what I consider the best stack for Vue JS and one that you should highly consider using in the future.

And this stack will also give you the most support. It should be a long reading and I consider it the easiest to start with. Let’s just dive into the main description.

So we’re going to cover a lot of things here today.

We’re going to talk about:

So these are kind of the major things that you want to consider when you’re creating a Vue application.

Vue Version

So let’s go into the very first topic and this is the Vue version. We actually have two primary candidates here and I’m going to set this up and we’re always going to try to consider a couple of different options and really the second place option, and a lot of these are pretty good too. So of course we have Vue 2 And it’s been around for a long time, everybody knows and loves it. And then there’s Vue 3, which has been out for over a year now.

So if I was creating an app today for 2023, 2022, 2021, and in the future, I would certainly choose Vue Three. I think the idea of creating a Vue 2 app is not the right answer because:

Vue 3 first is the latest and greatest.
It has the Composition API
It has way better types of support
It has a smaller
Faster
We know for a fact that the Vue core team is going to continuously be adding updates and upgrades to Vue Three.

while Vue 2, I know there’s maybe one more update that’s going to happen, but then they’re going to be done with updates. So if you want future support, Vue 3 is the way to go.And of course, there’s a script set up.

Now some of these things you can add to Vue 2. There’s certain libraries. The ecosystem has really made it easy for people who are stuck on Vue 2 to use some of these features. But why start on Vue 2 and have to add all these extra libraries when you can just start on Vue 3 and get everything for free?

The only warning I would say here why you may not want to start with Vue 3 is if you have a specific project and it has a very specific library you have to use and that library does not support Vue 3 Yet. There is some circumstances where that could happen. But I would say that since it’s almost a year and a half after Vue 3 has been out there, most of the big libraries have Vue 3 support now.

So I think that is going away and if your library is so specific that they refuse to upgrade to Vue 3 or make it compatible with Vue 3, you may want to consider using a different library at this point because I have a feeling that that library is probably never going to be updated ever again.

So let’s go into our next topic and that is Build Tools.

Build Tools

Basically how we’re going to create the app. So really right now I think the two major contenders of creating an app and we’re going to think of this in the Vue 3 lens because that’s the one I recommended is to use either Vue CLI or Vite. So both are scaffolding tools.

Well, let me rephrase that. Vue CLI is definitely a scaffolding tool. It has some cool features like Vue UI. You can kind of look at your app with this UI interface. It has this plugin support inside of it, and then when you create apps with it, it has this scaffolding tool that will ask you a set of questions.

While Vite is more of an ESMB tool, it supports more than just It supports, supports React, supports felt. So I would definitely go with Vite. So you might be surprised by this because Vite is definitely newer and I’m not just picking it because:

it’s newer and it’s been created by Evan You, but I feel like Vite is going to be the direction where the Vue ecosystem is going to go in the future.
I have a feeling that Vue CLI one day will probably be using Vite or they’ll combine Vite and Vue CLI into one somehow. I have a feeling that Vue CLI, which uses web pack days, is numbered. I also feel like it’s just a better tool.
it has super fast reload times,
Has HMR.

One of the biggest reasons I might hesitate to recommend Vite is because you don’t have some of that plugin system that Vue CLI has, or if you just start with Vite out of the box, you’re going to have to install your own router. It doesn’t give you any nice cool menu to choose some things like your ES, Linter, or Prettier. But right now there are so many community templates for Vite that has those things in them. I really don’t feel like that’s a big barrier.

So if you have to have a router and you have to have some sort of state management system or a few other things and you don’t want to bother with having to install Vite and then look up different ways of doing things and you want it all in one, there’s definitely a ton of templates on that.

Okay, Now let’s talk about single-file component layouts.

Single File Component (SFC) layouts

So this is kind of a hot topic too in the Vue community recently. So let’s take a look at the contenders.

Before version 2, Vue only had one way to craft components- the Options API. Now with Vue 3, an alternate technique- the Composition API- has been introduced. This article aims to clarify the distinctions between these two options.

Let’s start with looking at a simple setup with Options API:

export default {
data() {
return {
name: ‘Vue 3 App’,
};
},
methods: {
showTxt() {
console.log(`this is ${this.name}`);
},
},
mounted() {
this.showTxt();
},
};

If we take a look at the code, we notice 3 things, that are the building blocks of the Options API:

Data:This function returns the first-time reactive data that is applicable to the component when it is initialized.
Methods:When declaring methods for a component, you will need to include them with the component instance. These methods can be easily accessed from the instance itself or used in template expressions. It is recommended not to use arrow functions when declaring methods as they won’t have access to the instance’s ‘this’.
Mounted: Component mounting is when the lifecycle hook is triggered and the component is rendered into the DOM. This happens after the creation and completion initialization of all the elements needed.

Other common things we can run into with Options API and are not in the code above are:

Props: In order for Vue to properly identify which external properties should be treated as fallthrough attributes, components must have explicit props declarations.
Watch: The watch option in Vue allows one to specify callbacks to be called whenever a reactive component’s property is changed. These properties can be declared via data or computed and those are the values that are watched for changes, which then invoke the associated callbacks.

Now let’s take a look at the same example, but using Composition API:

export default {
setup() {
const name = ref(‘Vue 3 App’);

const showTxt = () => console.log(`This is ${name.value}`);

onMounted(() => {
showTxt();
});

return { name };

},
};

Composition API requires a lot less code to define components than previous versions, as it solely uses the setup hook. Besides this, ref is what makes the data reactive and returns an object containing its value property.

Code Sharing

Options API and Composition API have distinct approaches when it comes to code sharing. The former offers two options – mixins and renderless components. While using the former can be complicated as it’s difficult to pinpoint where the code has originated from, the latter provides more transparency and flexibility

Mixins are extremely handy & efficient when it comes to sharing reusable functionalities with Vue components. A mixin can contain pretty much any component option and if a component uses it, all the options will be blended into its own. For instance, here is an example of a mixin:

// define a mixin object
var myMixin = {
created: function () {
this.helloWorld()
},
methods: {
helloWorld: function () {
console.log(‘hello from my mixin!’)
}
}
}

// define a component that uses this mixin
var Component = Vue.extend({
mixins: [myMixin]
})

Although mixins can be beneficial, they are often tricky to debug and understand for inexperienced developers. Moreover, global mixins may also lead to naming clashes with components.

The Composition API provides an efficient solution that doesn’t involve the usage of mixins. Within the setup procedure, we can easily organize our code according to its purpose. Additionally, it helps to share certain pieces of reactive logic with other components which is quite useful.

Now let’s take a look at renderless components. A renderless component is a component that doesn’t render any of its own HTML. Instead, it only manages state and behaviour, which gives the parent component complete control over what should be rendered. That means, that if you move logic out of a UI component and into a renderless component, you can reuse it.

Composables

Composition API also supports rendering fewer components, in fact, it’s one of the things Composition API and Options API have in common. However, a major advantage of Composition API is compostable. They are reusable pieces of code and thanks to them, we can write reactive code anywhere. We’ve not bound to the scope of a Vue component anymore. Here is a simple example of counter-composable:

import { computed, ref } from ‘vue’;

export function count() {
const counter = ref(0);
const addOne = () => { counter.value += 1 };

return {
counter,
addOne,
};
}

And here we can see, how to use it in a component.

<template>
<div>Count: {{ counter }}</div>
<button @click=”addOne”>
+
</button>
</template>

<script>
import { count } from ‘../composables/counter-example’;

export default {
setup() {
const {
counter,
addOne,
} = count();

return {
counter,
addOne,
};
},
};
</script>

Composables are a great way to keep your components organized and consistent. They allow you to extract reusable data & functions which can then be used in multiple other components. You can also call them composition functions if you’re feeling fancy. Having composables clearly organize where your code is stored can make development much easier!

Another major advantage of Composition API is that it makes constants and dependencies available in the template:

<template>
<div>
<button @click=”create”>
Save
</button>
</div>
</template>

<script>
import { create } from ‘./services’;

export default {
setup() {
return {
create,
};
},
};
</script>

When doing the same thing using the Options API, it can feel awkward. You either have to add constants and dependencies to your data option or use the created hook to add non-reactive variables to the this context. Composition API saves us some trouble here, as we can simply export them from setup hook and make them available inside the template.

This about sums up the comparison and to conclude things, if you came to a point, where you decided to migrate to the latest version of Vue, as of reasons stated above, Composition API may be worth the trouble as it optimizes the code very nicely and will consequently give your app a better performance. If you are starting from scratch, Composition API would be recommended.

So let’s take a look at the router.

Router

Now, the router is pretty simple in our case here. If you’re creating a new app, you want to use the Vue router or the Next version. It’s under the Next tag, but it’s basically version four. It’s the official Vue router. It works really well. I haven’t seen too many complaints about it.Maybe a couple of little issues people have had, but they’re very responsive on their GitHub page. It works great.

And this would be the one that you want to use next is State management.

State Management

So this is the idea if you want to share data between different places in the app. So let’s say you have multiple components and you want to share information.

So back in the day, Vuex was the management system kind of based on the flux pattern. And then there was Pina that just came out, I don’t know a couple of years ago. That’s been slowly gaming popularity too, which is very similar to Vuex but it’s more of a lightweight version of it. So if I was creating an app today, I would definitely use Pinia.

It’s recommended by the core team now.
In fact, some people say that Pina and Vuex are going to combine into one. So I would say just use Pina for right now.
It has excellent typescript support, which makes it a little bit more straightforward to use than Vuex, meaning that they took out like mutations kind of the ideal way. If you want to add state management into your Vue app, I would say a caveat, you may not need to use a reactive or a state management system at all because there is things like ref or reactive and both allow you to share data between multiple components.
You can easily create what’s called a composable that you can import into your components that has some data that is basically shared in the whole app because it’s reactive or rest. And you can kind of create a ministate management system yourself with very little effort. So that’s the first thing I would do.

Let’s take a look at Testing Frameworks.

Testing Frameworks

So really the two testing frameworks everybody talks about with Vue is the at testing Library Vue which is built on the Vue test utile.

It’s kind of like a lightweight layer on top of it and then Cyprus. So between these two, I would say use both. A good recommendation is to use both the testing library Vue and Cypress together. So use the test-leading library Vue for more of your unit testing, but then use Cyprus for your bigger apps for your end-to-end testing. I think both together work really well.

And then I would also suggest adding these to your pull request to your build system, to your continuous integration continuous deployment system. That way these tests are run every time you do anything. That way you can make sure that you don’t accidentally break stuff when you push something into your code base.

Now, let’s talk about the starter templates.

StarterTemplates

There’s really two starter templates I’d recommend. One is the Vue 3 enterprise boilerplate and the other one is Vitesse. Vitesse is a really cool start template, but I’ve also really liked Vue three enterprise boilerplate.

But I would really choose Vitesse. Because:

It uses Vite.
Has lots of features:
- Has file-based routing
- Pinia
- Auto imports.

I think this is going to this is like probably the best starter template I’ve seen for Vue 3.The next topic is Component Libraries. Let’s move on.

Component Libraries

This is a hot topic in the Vue community too. So there are a ton of different component libraries, and they have been slowly upgrading to Vue 3. But we know the Vue Alpha version is Vue 3 compatible. It’s a material design framework. There’s also Quasar, which they call beyond the framework.

It does so many different things. It’s like a framework, but it also has its own CLI. It can even also compile down to be used in mobile apps.

It’s really crazy, everything it has, but really, I would choose none of them. And this is kind of funny, because I know there are a lot of people that love both of those frameworks, and there are so many other ones out there.

I would say I would settle for something more lightweight, like Tailwind CSS or Bootstrap, just to keep it lightweight. And I really feel like those are great if you need a really quick project. But I just throw Tailwind into almost all my projects because it’s just so simple.

I like the utility classes, so I highly recommend Tailwind CSS, and you can get that working with Vue 3 not a problem.

Final Word

That’s all about the recommendation for Vue application. So let me say that this is my opinion. You may have your own. Make sure if you do have a difference in opinion, leave a comment below. I really appreciate it.