Become a ninja with Vue (free sample)

The sixth version of the specification reached its final state in 2015. So it’s now supported by modern browsers, but there are still browsers in the wild that don’t support it yet, or only support it partially. And of course, now that we have a new specification every year (ES2016, ES2017, etc.), some browsers will always be late. You might be thinking: what’s the point of all this, if I need to be careful on what I can use? And you’d be right, because there aren’t that many apps that can afford to ignore older browsers. But, since virtually every JS developer who has tried ES2015+ wants to write ES2015+ apps, the community has found a solution: a transpiler.

A transpiler takes ES2015+ source code and generates ES5 code that can run in every browser. It even generates the source map files, which allows you to debug directly the ES2015+ source code from the browser. Back in 2015, there were two main alternatives to transpile ES2015+ code:

The source code of Vue itself was at first transpiled with Babel, before switching to TypeScript for the version 3.0. TypeScript is an open source language developed by Microsoft. It’s a typed superset of JavaScript that compiles to plain JavaScript, but we’ll dive into it very soon.

Let’s be honest: Babel has waaaay more steam than Traceur nowadays, so I would advise you to use it. It is now the de-facto standard in this area.

So if you want to play with ES2015+, or set it up in one of your projects, take a look at these transpilers, and add a build step to your process. It will take your ES2015+ source files and generate the equivalent ES5 code. It works very well but, of course, some new features are quite hard or impossible to transform in ES5, as they just did not exist. However, the current state is largely good enough for us to use without worrying, so let’s have a look at all these shiny new things we can do in JavaScript!

If you have been writing JS for some time, you know that the var declaration is tricky. In pretty much any other language, a variable is declared where the declaration is done. But in JS, there is a concept, called "hoisting", which actually declares a variable at the top of the function, even if you declared it later.

So declaring a variable like name in the if block:

is equivalent to declaring it at the top of the function:

ES2015 introduces a new keyword for variable declaration, let, behaving much more like what you would expect:

The variable name is now restricted to its block. let has been introduced to replace var in the long run, so you can pretty much drop the good old var keyword and start using let instead. The cool thing is, it should be painless to use let, and if you can’t, you have probably spotted something wrong with your code!

Since we are on the topic of new keywords and variables, there is another one that can be of interest. ES2015 introduces const to declare…​ constants! When you declare a variable with const, it has to be initialized, and you can’t assign another value later.

As for variables declared with let, constants are not hoisted and are only declared at the block level.

One small thing might surprise you: you can initialize a constant with an object and later modify the object content.

But you can’t assign another object:

Same thing with arrays:

Not a new keyword, but it can also catch your attention when reading ES2015 code. There is now a shortcut for creating objects, when the object property you want to create has the same name as the variable used as the value.

Example:

can be simplified to:

Similarly, when you want to define a method in the object:

you can simplify it to:

This new feature can also catch your attention when reading ES2015 code. There is now a shortcut for assigning variables from objects or arrays.

In ES5:

Now, in ES2015, you can do:

And you will have the same result. It can be a little disturbing, as the key is the property to look for in the object, and the value is the variable to assign. But it works great! Even better: if the variable you want to assign has the same name as the property, you can simply write:

The cool thing is that it also works with nested objects:

And the same is possible with arrays:

Of course, it also works for arrays in arrays, or arrays in objects, etc.

One interesting use of this can be for multiple return values. Imagine a function randomPonyInRace that returns a pony and its position in a race.

The new destructuring feature assigns the position returned by the method to the position variable, and the pony to the pony variable! And if you don’t care about the position, you can write:

And you will only have the pony.

It is also possible to assign a value to the destructured variable if it is undefined in the object:

The position variable will now contain 1.

One of the characteristics of JavaScript is that it allows developers to call a function with any number of arguments:

The last case is the one most relevant to us. Usually, we pass fewer arguments when the parameters are optional, like in the following example:

The optional parameters usually have a default value. The OR operator will return the right operand if the left one is undefined, as will be the case if the parameter was not provided (to be completely accurate, if it is falsy, i.e 0, false, "", etc.). Using this trick, we can then call the function getPonies with:

This worked alright, but it was not really obvious the parameters were optional ones with default values, without reading the function body. ES2015 introduces a more precise way to have default parameters, directly in the function definition:

Now it is perfectly clear the size parameter will be 10, and the page parameter will be 1 if not provided.

The default value can also be a function call:

or even other variables, either global variables, or other parameters of the function:

This mechanism for parameters can also be applied to values, for example when using a destructuring assignment:

ES2015 introduces a new syntax to define variable parameters in functions. As said in the previous part, you could always pass extra arguments to a function and get them with the special arguments variable. So you could have done something like this:

But I think we can agree that it’s neither pretty nor obvious: since the ponies parameter is never used, how do we know that we can pass several ponies?

ES2015 gives us a way better syntax, using the rest operator …​:

ponies is now a true array on which we can iterate. The for …​ of loop used for iteration is also a new feature in ES2015. It makes sure that you iterate over the collection values, and not also over its properties as for …​ in would do. Don’t you think our code is prettier and more obvious now?

The rest operator can also work when destructuring data:

The rest operator is not to be confused with the spread operator which, I’ll give you that, looks awfully similar! But the spread operator is the opposite: it takes an array and spreads it in variable arguments. The only examples I have in mind are functions like min or max, that receive variable arguments, and that you might want to call on an array:

One of the most emblematic new features: ES2015 introduces classes to JavaScript! You can now easily use classes and inheritance in JavaScript. You always could, using prototypal inheritance, but that was not an easy task, especially for beginners.

Now it’s very easy, take a look:

Class declarations, unlike function declarations, are not hoisted, so you need to declare a class before using it. You may have noticed the special function constructor. It is the function being called when we create a new pony, with the new operator. Here it needs a color, and we create a new Pony instance with the color set to "blue". A class can also have methods, callable on an instance, as the method toString() here.

It can also have static attributes and methods:

Static methods can be called only on the class directly:

A class can have getters and setters, if you want to hook onto these operations:

And, of course, if you have classes, you also have inheritance out of the box in ES2015.

Animal is called the base class, and Pony the derived class. As you can see, the derived class has the methods of the base class. It can also override them:

As you can see, the keyword super allows calling the method of the base class, with super.speed() for example.

The super keyword can also be used in constructors, to call the base class constructor:

Promises are not so new, and you might know them or use them already, as they were available via third-party libraries. But since you will use them a lot in Vue, and even if you’re just using JS, I think it’s important to make a stop.

Promises aim to simplify asynchronous programming. Our JS code is full of async stuff, like AJAX requests, and usually we use callbacks to handle the result and the error. But it can get messy, with callbacks inside callbacks, and it makes the code hard to read and to maintain. Promises are much nicer than callbacks, as they flatten the code, and thus make it easier to understand. Let’s consider a simple use case, where we need to fetch a user, then their rights, then update a menu when we have these.

With callbacks:

Now, let’s compare it with promises:

I like this version, because it executes as you read it: I want to fetch a user, then get their rights, then update the menu.

As you can see, a promise is a 'thenable' object, which simply means it has a then method. This method takes two arguments: one success callback and one reject callback. The promise has three states:

When the promise is fulfilled, then the success callback is called, with the result as an argument. If the promise is rejected, then the reject callback is called, with a rejected value or an error as the argument.

So, how do you create a promise? Pretty simple, there is a new class called Promise, whose constructor expects a function with two parameters, resolve and reject.

Once you have created the promise, you can register callbacks, using the then method. This method can receive two parameters, the two callbacks you want to call in case of success or in case of failure. Here we only pass a success callback, ignoring the potential error:

Once the promise is resolved, the success callback (here simply logging the user on the console) will be called.

The cool part is that it flattens the code. For example, if your resolve callback is also returning a promise, you can write:

but more beautifully:

Another interesting thing is the error handling, as you can use one handler per promise, or one for all the chain.

One per promise:

One for the chain:

You should seriously look into Promises, because they are going to be the new way to write APIs, and every library will use them. Even the standard ones: the new Fetch API does for example.

One thing I like a lot in ES2015 is the new arrow function syntax, using the 'fat arrow' operator (⇒). It is SO useful for callbacks and anonymous functions!

Let’s take our previous example with promises:

can be written with arrow functions like this:

How cool is it? THAT cool!

Note that the return is also implicit if there is no block: no need to write user ⇒ return getRights(user). But if we did have a block, we would need the explicit return:

And it has a special trick, a great power over normal functions: the this stays lexically bounded, which means that these functions don’t have a new this as other functions do. Let’s take an example, where you are iterating over an array with the map function to find the max.

In ES5:

You would expect this to work, but it doesn’t. If you have a good eye, you may have noticed that the forEach in the find function uses this, but the this is not bound to an object. So this.max is not the max of the maxFinder object…​ Of course, you can fix it easily, using an alias:

or binding the this:

or even passing it as a second parameter of the forEach function (as it was designed for):

But there is now an even more elegant solution with the arrow function syntax:

That makes the arrow functions the perfect candidates for anonymous functions in callbacks!

We were talking about promises earlier, and it’s worth knowing that another keyword was introduced to handle them more synchronously: await.

This is not a feature introduced in ECMAScript 2015 but in ECMAScript 2017, and to use await, your function must be marked as async. When you use the await keyword in front of a Promise, you pause the execution of your async function, wait for the Promise to resolve, and then resume the execution of the async function. The returned value will be the resolved value.

So we can write our previous example using async/await like this:

And your code now looks like it is synchronous! Another cool feature of async/await is that you can use a simple try/catch to handle errors:

Note that async/await is still asynchronous, although it looks like synchronous. The function execution is paused and resumed, but just like with callbacks, this doesn’t block the thread: other JavaScript events can be handled while the execution is paused.

This is a short one: you now have proper collections in ES2015. Yay \o/! We used to have dictionaries filling the role of a map, but we can now use the class Map:

We also have a class Set:

You can iterate over a collection, with the new syntax for …​ of:

You’ll see that the for …​ of syntax is also supported by Vue to iterate over a collection in a template.

Composing strings has always been painful in JavaScript, as we usually have to use concatenation:

Template literals are a new small feature, where you have to use backticks (`) instead of quotes or simple quotes, and you have a basic templating system, with multiline support:

The multiline support is especially great when you are writing HTML strings, as we will do for our Vue components:

One last feature is the ability to tag them. You can define a function, and apply it to a template string. Here askQuestion adds an interrogation point at the end of the string:

So what’s the difference with a simple function? The tag function in fact receives several arguments:

For example if we have a template string containing expressions:

then the tag function will receive the various static and dynamic parts. Here we have a tag function to uppercase the names of the protagonists:

Let’s now talk about one of the big changes introduced: modules.

A standard way to organize functions in namespaces and to dynamically load code in JS has always been lacking. Node.js has been one of the leaders in this, with a thriving ecosystem of modules using the CommonJS convention. On the browser side, there is also the AMD (Asynchronous Module Definition) API, used by RequireJS. But none of these were a real standard, thus leading to endless discussions on what’s best.

ES2015 aims to create a syntax using the best from both worlds, without caring about the actual implementation. The Ecma TC39 committee (which is responsible for evolving ES2015 and authoring the specification of the language) wanted to have a nice and easy syntax (that’s arguably CommonJS’s strong suit), but to support asynchronous loading (like AMD), and a few goodies like the possibility to statically analyze the code by tools and support cyclic dependencies nicely. The new syntax handles how you export and import things to and from modules.

This module thing is really important in Vue, as pretty much everything is defined in modules, which you have to import when you want to use them. Let’s say I want to expose a function to bet on a specific pony in a race, and a function to start the race.

In races.service.js:

As you can see, this is fairly easy: the new keyword export does a straightforward job and exports the two functions.

Now, let’s say one of our application components needs to call these functions.

In another file:

That’s what is called a named export. Here we are importing the two functions, and we have to specify the filename containing these functions - here 'races.service'. Of course, you can import only one method if you need, and you can even give it an alias:

And if you want to use all the exported symbols (functions, constants, classes etc.) from the module, you can use a wildcard '*'.

As you would do with other languages, use the wildcard with care, only when you really want all the functions, or most of them. As this will be analyzed by our IDEs, we will see auto-import soon and that will free us from the bother of importing the right things.

With a wildcard, you have to use an alias, and I kind of like it, because it makes the rest of the code clearer:

If your module exposes only one function or value or class, you don’t have to use named export, and you can leverage the default keyword. It works great for classes for example:

Notice the lack of curly braces to import a default. You can import it with the alias you want, but to be consistent, it’s better to call the import with the module name (except if you have multiple modules with the same name of course, then you can choose an alias that allows you to distinguish them). And of course, you can mix default export with named ones, but obviously with only one default per module.

In Vue, you’re going to use a lot of these imports in your app. Each component will be an object, generally isolated in its own file and exported, and then imported when needed in other components.

That ends our gentle introduction to ES2015+. We skipped some other parts, but if you’re comfortable with this chapter, you will have no problem writing your apps in ES2015+. If you want to have a deeper understanding of this, I highly recommend Exploring JS by Axel Rauschmayer or Understanding ES6 from Nicholas C. Zakas…​ Both ebooks can be read online for free, but don’t forget to buy it to support their authors. They have done great work! Actually I’ve re-read Speaking JS, Axel’s previous book, and I again learned a few things, so if you want to refresh your JS skills, I definitely recommend it!

You may have heard that Vue apps can be written in ES5, ES2015+ or TypeScript. And you may be wondering what TypeScript is, or what it brings to the table.

JavaScript is dynamically typed. That means you can do things like:

And it works. That’s great for all sort of things, as you can pass pretty much any object to a function, and it works, as long as the object has the properties the function needs:

This dynamic nature allows wonderful things, but it is also a pain for a few other reasons compared to more statically-typed languages. The most obvious might be when you call an unknown function in JS from another API, you pretty much have to read the doc (or, worse, the function code) to know what the parameter should look like. Take a look at our previous example: the method printColor needs a parameter with a color property. That can be hard to guess, and of course it is much worse in day-to-day work, where we use various libraries and services developed by fellow developers. One of Ninja Squad’s co-founders is often complaining about the lack of types in JS, and finds it regrettable he can’t be as productive and write as good code as he would in a more statically-typed environment. And he is not entirely wrong, even if he is sometimes ranting for the sake of it too! Without type information, IDEs have no real clue if you’re doing something wrong, and tools can’t help you find bugs in your code. Of course, we have tests in our apps, and Vue has always been keen on making testing easy, but it’s nearly impossible to have a perfect test coverage.

That leads to the maintainability topic. JS code can become hard to maintain, despite tests and documentation. Refactoring a huge JS app is no easy task, compared to what could be done in other statically-typed languages. Maintainability is a very important topic, and types help humans and tools to avoid mistakes when writing and maintaining code.

Vue started as a pure JavaScript framework, but the core team wanted to help us to write better JS, by adding some type information to our code. It’s not a very new concept in JS. It was even the subject of the ECMAScript 4 specification, which was later abandoned.

That’s why Vue supports TypeScript, the Microsoft language, since Vue 2.0. The support for TypeScript in Vue 2.0, however, was not perfect. So when Vue 3.0 was announced, one of the big features was an improved support of TypeScript: in fact the framework itself is now written in TypeScript!

I think this was a smart move for several reasons. TypeScript is very popular, with an active community and ecosystem. We use it a lot to build front-end applications, and, honestly, it’s a great language.

TypeScript is a Microsoft project. But it’s not the Microsoft you have in mind, from the Ballmer and Gates years. It’s the Microsoft of the Nadella era, the one opening up to its community, and, well, open-source.

The main reason to bet on TypeScript is the type system it offers. It’s an optional type system that helps without getting in the way. In fact, after coding some time with it, it’s hard to go back to raw JavaScript. You can still write Vue apps just using JavaScript, but using TypeScript will improve the experience.

As I said, I really enjoy this language, and we will have a look at what TypeScript offers in the next section. At the end, you’ll have enough understanding to read any Vue code, and you’ll be able to choose whether you want to use it or not (or just a little), in your apps.

You may be wondering: why use typed code in Vue apps? From our experience, the main reason is the ease to refactor. You will usually have types representing your entities: a User, an Account, an Invoice, whatever…​ But it’s quite rare to have a perfect model on the first go. Over the time, the entities evolve, or grow, or split into several ones. Fields get new names, and in a JavaScript application, you get no guarantee that you haven’t broken half your pages…​ This is where TypeScript shines: the compiler guides you to change everything that needs to be changed, and you’ll sleep better at nights.

That’s why we’re going to spend some time learning TypeScript (TS). And maybe one day the type system will make its way through the standard committee, we’ll have types in JS, and all this will be usual.

Ready? Let’s dive in!

The general syntax to add type info in TypeScript is rather straightforward:

The types are easy to remember:

In such cases, the types are optional because the TS compiler can guess them (it’s called "type inference") from the values.

The type can also come from your app, as with the following class Pony:

TypeScript also supports what some languages call "generics", for example for an array:

The array can only contain ponies, and the generic notation, using <>, indicates this. You may be wondering what the point of doing this is. Adding types information will help the compiler catch possible mistakes:

So, if you need a variable to have multiple types, does it mean you’re screwed? No, because TS has a special type, called any.

It’s really useful when you don’t know the type of a value, either because it’s from a dynamic content or from a library you’re using.

If your variable can only be of type number or boolean, you can use a union type:

TypeScript also offers enum. For example, a race in our app can be either ready, started or done.

The enum is in fact a numeric value, starting at 0. You can set the value you want, though:

Since TypeScript 2.4, you can even specify a string value:

To be honest though, we don’t use enums a lot in our projects: we use union types. They are simpler and cover roughly the same use-cases:

TypeScript even allows you to create your own types, so you could do something like:

You can also set the return type of a function:

If the function returns nothing, you can show it using void:

That’s a good first step. But as I said earlier, JavaScript is great for its dynamic nature. A function will work if it receives an object with the correct property:

This function can be applied to any object with a score property. How do you translate this in TypeScript? It’s easy: you define an interface, which is like the "shape" of the object.

It means that the parameter must have a property called score of the type number. You can name these interfaces, of course:

You’ll see that we often use interfaces throughout the book to represent our entities. We use interfaces for our models in our other projects as well. We usually append a Model suffix to make it clear. It’s then very easy to create a new entity:

Another treat of JavaScript is that arguments are optional. You can omit them, and they will become undefined. But if you define a function with typed parameter in TypeScript, the compiler will shout at you if you forget them:

To show that a parameter is optional in a function (or a property in an interface), you can add ? after the parameter. Here, the points parameter could be optional:

You may also be interested in describing a parameter that must have a specific function instead of a property:

The interface definition will be:

A class can implement an interface. For us, the Pony class should be able to run, so we can write:

The compiler will force us to implement a run method in the class. If we implement it badly, by expecting a string instead of a number for example, the compiler will yell:

You can also implement several interfaces if you want:

And an interface can extend one or several others:

When you’re defining a class in TypeScript, you can have properties and methods in your class. You may realize that properties in classes are not a standard ES2015 feature. It is only possible in TypeScript.

Everything is public by default, but you can use the private keyword to hide a property or a method. If you add private or public to a constructor parameter, it is a shortcut to create and initialize a private or public member:

Which is the same as the more verbose:

These shortcuts are really useful, and we’ll rely on them a lot in Vue!

When working with external libraries written in JS, you may think we are doomed because we don’t know what types of parameter the function in that library will expect. That’s one of the cool things with the TypeScript community: its members have defined interfaces for the types and functions exposed by the popular JavaScript libraries!

The files containing these interfaces have a special .d.ts extension. They contain a list of the library’s public functions. A good place to look for these files is DefinitelyTyped. For example, if you want to use the testing library Jest in your TypeScript application, you can download the proper file from the repo directly with NPM:

Even cooler, since TypeScript 1.6, the compiler will auto-discover the type definitions of an NPM library if they are packaged with the library itself. More and more projects are adopting this approach, and so is Vue. So you don’t even have to worry about including the interfaces in your Vue project: the TS compiler will figure it out by itself if you are using NPM to manage your dependencies!

So my advice would be to give TypeScript a try! All my examples from here will be in TypeScript, as Vue and all the tooling around are really designed for it.

You can use the readonly keyword to mark the property of a class or interface as…​ read only! That way, the compiler will refuse to compile any code trying to assign a new value to the property:

The keyof keyword can be used to get a type representing the union of the names of the properties of another type. For example, you have a PonyModel interface:

You want to build a function that returns the value of a property. You could implement a naive version:

Two problems here:

This is where keyof can shine. keyof allows you to list all the keys of a type:

So we can use this type to make getProperty safer, by declaring that:

We killed two birds with one stone here:

Now let’s see how we can leverage keyof to do even more.

Let’s say you want to create a type that has exactly the same properties as PonyModel, but you want every property to be optional. You can of course define it manually:

But you can do something more generic with a mapped type:

The Partial type is a transformation that applies the ? modifier to every property of a type! In fact, you don’t have to define the type Partial yourself, because since version 2.1, it’s part of the language itself, and it’s declared exactly like in the above example.

TypeScript offers others mapped types out of the box.

Union types are really handy. Let’s say your application has authenticated users and anonymous users, and sometimes you need to do a different action depending on that. You can model this as:

I don’t know about you, but I don’t like these as …​ explicit casts. Maybe we can do better?

One possibility is to use a type guard, a special function whose sole purpose is to help the TypeScript compiler.

This is better! But we still need to return a default value, even if we covered all the possibilities.

We can slightly improve the situation if we drop the type guards and use a union type instead.

This is even better, as TypeScript automatically narrows the type in the else branch.

Sometimes you know that the model will grow in the future, and that more cases will need to be handled. For example if you introduce an AdminUser. In that case, you can use a switch. A switch statement will break if one of the cases is not handled. So introducing our AdminUser, or another type of user later, would automatically add compilation errors in every place you need to handle it!

I hope these patterns will help you. Now let’s focus on Web Components.

Components are an old fantasy in development. Something you can grab off the shelves and drop into your app, something that would work right away and bring a needed functionality to your users.

My friends, this time has come.

Well, maybe. At least, there is the start of something.

That’s not completely new. We have had components in web development for quite some time, but they usually require some kind of dependency, like jQuery, Dojo, Prototype, AngularJS, etc. Not necessarily libraries you wanted to add to your app.

Web Components attempt to solve this problem: let’s have reusable and encapsulated components.

They rely on a set of emerging standards that browsers don’t perfectly support yet. But, still, it’s an interesting topic, even if there’s a chance we’ll have to wait a few years to use them fully, or even if the concept never takes off.

This emerging standard is defined in 3 specifications:

Note that the samples are most likely to work in a recent Chrome or Firefox browser.

Custom elements are a new standard allowing developers to create their own DOM elements, making something like <ns-pony></ns-pony> a perfectly valid HTML element. The specification defines how to declare such elements, how to make them extend existing elements, how to define your API, etc.

Declaring a custom element is done using customElements.define:

And you can then use it:

Note that the name must contain a dash, so that the browser knows it is a custom element. Of course, your custom element can have properties and methods, and it also has lifecycle callbacks, to be able to execute code when the component is inserted or removed, or when one of its attributes changes. It can also have a template of its own. Maybe the ns-pony displays an image of the pony or just its name:

If you try to look at the DOM, you’ll see <ns-pony><h1>General Soda</h1></ns-pony>. But that means the CSS and JavaScript logic of your app can have undesired effects on your component. So, usually, the template is hidden and encapsulated in something called Shadow DOM, and you’ll only see <ns-pony></ns-pony> if you inspect the DOM, despite the fact that the browser displays the pony’s name.

With a mysterious name like this, you expect something with great powers. And surely it is. The Shadow DOM is a way to encapsulate the DOM of our component. This encapsulation means that the stylesheet and JavaScript logic of your app will not apply on the component and ruin it inadvertently. It gives us the perfect tool to hide the internals of a component, and be sure nothing leaks from the component to the app, or vice versa.

Going back to our previous example:

If you try to inspect it now you should see:

Now, even if you try to add some style to the h1 elements, the visual aspect of the component won’t change at all: that’s because the Shadow DOM acts like a barrier.

Until now, we just used a string as a template of our web component. But that’s usually not the way you do that. Instead, the best practice is to use the <template> element.

A template specified in a <template> element is not displayed in your browser. Its main goal is to be cloned in an element at some point. What you declare inside will be inert: scripts don’t run, images don’t load, etc. Its content can’t be queried by the rest of the page using usual methods like getElementById() and it can be safely placed anywhere in your page.

To use a template, it needs to be cloned:

All these things put together make the Web Components. I’m far from being an expert on this topic, and there are all sorts of twisted traps on this road.

As Web Components are not fully supported by every browser, there is a polyfill you can include in your app to make sure it will work. The polyfill is called web-component.js, and it’s worth noting that it is a joint effort from Google, Mozilla and Microsoft among others.

On top of this polyfill, a few libraries have seen the light. All aim to facilitate working with Web Components, and often come with some ready-to-use Web Components.

Among the most notable initiatives, you find:

I won’t go into the details, but you can easily use an already existing component. Let’s say you want a Google Map in your app:

There are a LOT of components out there. You can have an overview on https://www.webcomponents.org/.

You can do a lot of cool things with LitElement and other similar frameworks, like two-way data binding, default values for attributes, emit custom events, react to attribute changes, repeat elements if we give a collection to a component, etc.

That’s obviously far too short a chapter to tell you everything there is to say on Web Components, but you’ll see that some concepts are going to pop out along your read. And you’ll definitely see that Vue has been designed to make it easy to use Web Components with our Vue components. It is even possible to export our own Vue components as Web Components.

Vue always marketed itself as a progressive framework that, unlike other alternatives like Angular or React, you can adopt progressively. You can take your existing static HTML, or jQuery application and easily sprinkle a bit of Vue on top of it.

So first I’d like to demonstrate how easy it is to set up Vue.

Let’s make an empty index.html file:

Now let’s add some HTML for Vue to handle:

The curly braces around user are specific to the Vue templating syntax, indicating that user should be replaced by its value. We’ll explain everything in details in the following chapter, don’t worry.

If you load the page in your browser, you’ll see that it displays Hello {{ user }}. That’s normal, as we haven’t used Vue yet.

Now let’s add Vue. Vue is released on NPM and some sites (called CDNs, for Content Delivery Network) make NPM packages available for inclusion in our HTML pages. Unpkg is one of them. We can use it to add Vue to our page. Of course, you could also choose to download the file and serve it by yourself.

If you reload the application, you’ll see that Vue emits a warning in the console, informing us that we are using a development version. You can use vue.global.prod.js to use the production version, and make it disappear. The production doesn’t do any checks in our code, is minified, and is a bit faster.

We now need to create our application. Vue offers a createApp function to create an application. To call it, we need a root component.

To create a component, we simply need to create an object that defines it. This object can have various properties, but for now we’ll just add a setup function. Again we’ll explain thoroughly later, but the name is explanatory enough: this function is here to set up the component, and Vue is going to call it for us when the component is initialized.

The setup function just returns an object with a property user and a value for this property. But if you reload your page, still nothing happens: we need to call createApp with our component.

createApp creates an application that needs to be "mounted" in some place in the DOM: here we use the div with the ID app. If you reload the page, you should now see Hello Cédric. Congratulations, you have your first Vue application.

Maybe we can add another component? We’ll build another one, displaying the number of unread messages.

Let’s add a new object called UnreadMessagesComponent, with a similar setup property:

Unlike the root component which is using the template inside the #app div, we want to define a template for UnreadMessagesComponent. This can be done by adding a script tag with a special type text/x-template. This type guarantees that the browser won’t care about this script. You can then reference the template by its ID inside the component definition:

We want to be able to insert the unread messages component inside our main template. To do that, we need to tell the root component it’s allowed to use the unread messages component, and we need to assign it a PascalCase name:

We can now use the tag <unread-messages></unread-messages> (which is the dash-case version of UnreadMessages) to insert the component where we want:

Comparing to other frameworks, a Vue application is super easy to start: just pure JavaScript and HTML, no tooling, components are simple objects. Even someone that doesn’t know Vue can understand what’s going on. And this is one of the strengths of the framework: it’s easy to start, easy to grasp, and you can progressively learn the features.

We could stick to this minimal setup for our projects, but, let’s face it, it will not scale for long. We will soon have too many components to fit in one file, we would really love to use TypeScript instead of JavaScript, to add tests, to add some kind of code analysis, etc.

We could set up all the needed tools by hand, but instead let’s leverage the work of the community and use the Vue CLI (that has been the standard for many years), or the now recommended tool Vite.

The Vue CLI (Command Line Interface) was born to help developers build Vue applications. It can scaffold an application and build it, and offers a large ecosystem of plugins. Each plugin offers some kind of features, like unit testing or linting or TypeScript support. It also offers a graphical user interface!

One of the cool features of the CLI is the ability to develop each component in a dedicated file, with a .vue extension. In this file you can define everything related to this component: its JavaScript/TypeScript definition, its HTML template, and even its CSS styles. This is called a Single File Component, or SFC.

The CLI is overall super handy to avoid having to learn and configure all the underlying tools (Node.js, NPM, Webpack, TypeScript, etc…​). It is still very flexible, and you can configure most behaviors.

But the CLI is now in maintenance mode, and Vite is the recommended alternative. Let’s talk about the underlying reasons.

When writing modern JavaScript/TypeScript applications, you often need a tool that can bundle all the assets (code, styles, images, fonts).

For a long time, Webpack was the undisputed favorite. Webpack comes with a simple but super handy feature: it understands all the JavaScript module types that exist (modern ECMAScript modules, but also AMD or CommonJS modules, formats that were existing before the standard). This understanding makes it easy to use pretty much any library you can find on the Internet (most often on NPM): you just install it, import it in one of your files, and Webpack takes care of the rest. Even if you use libraries with completely different formats, Webpack happily converts them and packages all your code and the code of the libraries together into one giant JS file: a bundle. This is a super important task, because even if the standard defined ES Modules back in 2015, most browsers have been supporting them very recently!

The other task of Webpack is to help during development, by providing a dev server and watching your project (it can even do HMR, a fancy word that stands for Hot Module Reloading). When something changes, Webpack reads the entrypoint of our application (main.ts for example), then it reads its imports and loads these files, then it reads the imports of the imported files and loads them…​ You get the idea! When everything is loaded, it re-bundles everything into one large file, both your code and the imported libraries from your node_modules, changing the module format if needed. The browser then reloads to display our changes 😅. This can be time-consuming when working on large projects with hundreds or thousands of files, even if Webpack comes with caches and heuristics to be as fast as possible.

Vue CLI (like a lot of tools out there) is using Webpack for most of its work, both when building the application with npm run build, or when running the dev server with npm run serve.

This is great as the Webpack ecosystem is incredibly rich in plugins and loaders: you can do pretty much what you want with it. On the other hand, a Webpack configuration can quickly get a bit overwhelming with all these options.

If I talk about Webpack and what bundlers do, it’s because we have serious alternatives nowadays, and it can be hard to understand what they do, and what are their differences. To be honest, I’m not sure that I understand all the details myself, and I’ve contributed quite a lot to Vue and Angular CLIs, both heavily based on Webpack! But let me try to explain anyway.

A serious contender is Rollup. Rollup intends to keep things simpler than Webpack, by not doing so much out of the box, but often doing it faster than Webpack. Its author is Rich Harris, who is also the author of the Svelte framework. Rich wrote a famous article called "Webpack and Rollup: the same but different". His guideline is "Use Webpack for apps, and Rollup for libraries". In fact, Rollup can do a lot of what Webpack does for production builds, but it does not come with a dev server that can watch your files during development.

Another incredible alternative is esbuild. Unlike Webpack and Rollup, esbuild itself is not written in JavaScript. It is written in Go and compiled to native code. It has also been designed with parallelism in mind. That makes it way faster than Webpack and Rollup. Like 10x-100x faster 🤯.

So why don’t we use esbuild instead of Webpack? That’s exactly what Evan You, the author of Vue, thought when developing Vue 3. He had another brilliant idea. In 2018, Firefox shipped the support of native ECMAScript Modules (often called native ESM). In 2019, it was Node.js, and then most browsers followed. Nowadays, your personal browser can probably understand native ESM without issues. Evan imagined a tool that would serve files as native ESM to the browser, doing the heavy lifting with esbuild to transform source files into ESM files if needed (for example for TypeScript or Vue files or legacy module formats).

Vite (the French word for "fast") was born.

The idea behind Vite is that, as modern browsers support ES Modules, we can now use them directly, at least during development, instead of generating a bundle.

So when you load a page in the browser when developing with Vite, you don’t load a single large file of JS containing all the application: you load just the few ES modules needed for this page, each in their own file (and each over their own HTTP request). If an ES module has imports, then the browser loads these imports as well.

So Vite is mainly a dev server, in charge of answering the browser requests, and responding with the requested ES modules. As we may have written our code in TypeScript, or using SFC in .vue extension (see below), Vite sometimes needs to transform the files on our disk into a proper ES module that the browser can understand. This is where esbuild comes into play! Vite is built on top of esbuild, and when a requested file needs to be transformed, it asks esbuild to do the job and then sends the result to the browser. If you change something in a file, then Vite only sends the updated module to the browser, instead of having to rebuild the whole bundle as Webpack-based tools do!

Vite also uses esbuild to optimize a few things. For example if you use a library with a ton of files, it "pre-bundles" it into a single file using esbuild and serves it to the browser in one request instead of a few dozens/hundreds. This pre-bundling is done once when starting the server, so you don’t pay the cost every time you refresh.

The fun thing is that Vite is not tied to Vue: it can be used with Svelte, React and others. In fact some other frameworks now recommend to use Vite! Svelte, from Rich Harris, was one of the first to do so, and now officially recommends it.

esbuild is really good for the JS bundling part, but it is not (yet) capable of splitting the application in several bundles, or properly handling CSS (whereas Webpack and Rollup do it out of the box). So it is not suited for bundling the application for production. That’s where Rollup comes into play: Vite relies on esbuild during development, but uses Rollup to bundle for production. Maybe in the future it’ll use esbuild for everything.

Vite is more than just an esbuild wrapper. As we saw, esbuild transforms files really fast. But Vite does not ask esbuild to transpile the requested files on every reload: it leverages the browser cache to do as little as possible. So if you load a page that you already loaded, it will be displayed in an instant. Vite also comes with a ton of other features, and a rich plugin ecosystem.

An important note: esbuild transpiles TypeScript to JavaScript, but it does not compile it: it completely ignores the type-checking part! That makes it super fast, but it also means that you have no typechecking from Vite during development. To check that your application properly compiles, you have to run Volar (vue-tsc), usually when building the application.

Are you excited? Because I am! Vite comes with project templates for React, Svelte and Vue, but the Vue team started a small project on top of Vite called create-vue. And that project is now the official recommendation when you start new Vue 3 projects.

create-vue is built on top of Vite, and provides templates for Vue 3 projects.

To get started, you simply use:

The npm create something command in fact downloads and executes the create-something package. So here npm create vue executes the create-vue package.

You then have to choose:

and your project is ready!

We will of course deep-dive into all these technologies along the book.

Want to give it a try?

To build your first Vite app, follow our online exercise Getting Started ! It’s part of our Pro Pack, but is accessible to all of our readers.

Done?

If you followed the instructions (and reached a 100% score I hope!), you have an application up and running. Let’s look at a few files. The entry point of the application is a file called main.ts:

It mounts an App component defined in App.vue, looking similar to this when created:

App.vue is a Single File Component. Let’s look into it!

A Single File Component (SFC) defines:

The tooling compiles the TypeScript code to JavaScript for us. It also compiles the template to JavaScript (we’ll explain in a later chapter what happens under the hood). The Vue compiler, unlike the browser, understands the PascalCase syntax, so we can use either <hello-world> or <HelloWorld> for our child component. We’ll use the PascalCase version from now on.

As you saw in the exercise, Vite can execute the unit tests, end-to-end tests, linter…​ Each exercise comes with the unit tests and e2e tests already written, so you’ll be able to check your code at every step. And Vite is super fast, so the developer experience is really enjoyable 🚀.

Now that we peeked into what the tooling can do for us, and are ready to build more components, let’s move on to the template syntax.

The templating syntax

How to build components

Script setup

Slots

Advanced component patterns

How to build components

Forms

The many ways to define components

Script setup

Forms

Slots

Global

Style your components

Router

Advanced component patterns

Custom directives

State Management

Internationalization

From zero to something

Style your components

Testing your app

Lazy-loading

Performances

The templating syntax

Script setup

Composition API

State Management

Router

The many ways to define components

Script setup

Suspense

Global

The many ways to define components

Performances

The templating syntax

Forms

Style your components

Provide/inject

State Management

Animations and transition effects

How to build components

Forms

Suspense

Router

Forms

Slots

Directives

Router

Slots

The wonderful world of Web Components

How to build components

Under the hood

Global