Advertisement
  1. Web Design
  2. Vue
Webdesign

Web Designers: Here’s Why You Should Learn Vue

by
Difficulty:IntermediateLength:MediumLanguages:

Let’s set the scene.

You’ve been building websites for a few years now. You started back before React became a big deal, and jQuery was still popular.

And, in fact, that’s exactly what your toolset was. As a designer, you once were on the leading edge of tech because you knew HTML, CSS, and enough jQuery to apply some logic to your pages.

Fast-forward a few years to now, and you’re feeling a bit left behind.

“Web designer” is slowly becoming a loaded phrase, like “programmer”. The possible toolset for a web designer today is far broader than one person can master.

What’s Changed?

The biggest areas of change certainly haven’t been in HTML. What you knew five years ago is still largely applicable today.

CSS has changed, but not in an unmanageably fast way. Some new specification adoption has occurred, and some new tools like CSS Grid have surfaced, but nothing is changing so much and so fast that you can’t get up to speed pretty quickly.

JavaScript, on the other hand, is entirely different now than it was ten years ago, and significantly different than it was five years ago.

Note that ten years ago, NodeJS had not even been released. “Back-end” and “JavaScript’ weren’t used to describe the same job. Looking at the Google Trends graph for NodeJS, the popularity of Node started growing around 2010, but as recently as two years ago it had only reached half the level of peak interest it has received in 2017. Translation: backend JavaScript is newly popular.

Google Trends graph for NodeJS
Google Trends graph for NodeJS

In 2013, new JavaScript-based frameworks started appearing on the scene. React was first introduced in March of that year, with the goal of providing a “learn once, write everywhere” approach to software on every platform. VueJS was introduced less than a year later as an alternative view-oriented JavaScript framework. The concept of JavaScript as a simple scripting language was being ripped out, and replaced with a much more mature JavaScript ecosystem. Around the same time, not only was there new interest and development in JavaScript frameworks, but also in maturing the language itself. With ES5 and now the year-oriented ES2015-ES2017, new features are added to JavaScript on a yearly basis.

It’s no wonder that if you are a web developer using a toolset you largely adopted five years ago, you feel a bit blindsided by this recent development.

In this series of articles, I’m going to introduce you to Vue JS, a modern component-oriented JavaScript framework. By the end of the three part series, you will know how to use Vue JS, but more importantly, you will be on the pathway to fluency with modern web design and front-end development techniques that power the world’s best and most used web platforms and applications.

Let’s get started!

It’s All About the Vue (View)

Vue JS operates primarily as a view-oriented framework. This should make you feel at home as a designer! The “view” is the centerpiece of everything that happens in Vue (hence the name).

With Vue, the interface is the ultimate representation of your user’s interaction. All of the data, methods, logic, and events are only important if they correctly affect the view itself.

Vue allows you to define a single rendering view quite easily. Let’s look at a Vue instance that renders a string to the browser. We load Vue (like this CDN hosted versions, for example: https://cdnjs.cloudflare.com/ajax/libs/vue/2.3.4/vue.min.js), then we add our JavaScript:

And some markup:

Here’s how that looks:

This simple example shows a few important concepts.

  1. A Vue instance can be used to simply render the contents of a given element. The Vue constructor takes some options. One of those options is the el option, short for “element’. This is a selector that points to an element in your HTML - in this case, the div with the class my-app.
  2. Data is passed to the view directly; Vue easily allows you to pass data from the data option to the view using the {{dataKey}} syntax. In this case, the rendered string inside the h1 tag is “Hello, Jonathan Cutrell”.
  3. No manual rendering call is necessary. If your Vue instance is constructed and an el is passed, Vue will automatically render to that element without any further code. Later, we’ll see how this rendering lifecycle management makes your application much less likely to be buggy.

For the Sake of Comparison

Let’s look at how we might accomplish the same thing with pure jQuery.

At first glance, this might not look much different from the first example. And, for simple cases like this, that might certainly be true.

However, Vue packs a punch that is hidden behind the scenes. For example, what if you want to change the name on the page?

In our string scenario, of course this isn’t a realistic change, but every 1s interval is going to update the first name to be a reversed version of itself. No other DOM manipulation or rendering is necessary.

Now, to accomplish the same thing with just jQuery?

Once again, the impact on the overall number of lines of code is relatively low for this example. However, the conceptual difference is significant. We’ll talk about that in the next section.

Where is Your Data?

One of the issues the average web designer has fallen prey to when using jQuery or a similar library to develop applications is a lack of separation of concerns. I’m sure you’ve heard this phrase before, but let’s make it more concrete with our name rendering example.

At any given point during the lifecycle of your application, where is the correct “version” of firstName stored?

With the Vue version, the information is always stored in the data object. If you update it there, it will update everywhere else correctly. The data is contained and managed in a single location.

In the jQuery version, the data is actually stored in the dom. There is no representation of the data in the JavaScript that is updated and then subsequently reflected. For example, you’ll notice that we set up an options object. This object is set statically once. However, when we update the name in the setInterval call, that option’s object is now no longer valid! This can be a problem. Furthermore, the options object can be updated at any point in time, or deleted entirely, and no impact will be made to the view (as long as the initial rendering has already occurred).

Why is this a problem?

Once again, with applications of this level of simplicity, it may be difficult to see why this matters. But as your application grows in complexity, even only slightly, storing data in the DOM can become extremely brittle and tedious.

Bridging the Gap: Homespun “State Management”

“So why don’t I just separate my concerns without using Vue?”

This is a natural question to ask. How might we separate our concerns without Vue then?

Aha! So now we’ve created our own rendering machine that allows for separation of concerns. We have our options object, and as long as we use our setOption() function, we will rerender any time the option is updated. So the data source is now separated from the view. Victory!

This is in fact a simple step towards some of the patterns that Vue uses under the hood. However, Vue has a lot more functionality and power than we’ve presented in this very simple use case.

For example, what if we set the firstName to the same thing it is already set to? We don’t need to rerender that whole thing, do we? But our application code doesn’t know how to differentiate that scenario. This is something that Vue does for you, under the hood.

Coming Up

There’s been a lot to take in for a first look, so sit back and soak it up! In part two of this tutorial series we’ll get Vue up and running whilst answering some of your initial questions.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.