Sessions is temporarily moving to YouTube, check out all our new videos here.

Vue.js: The Progressive Javascript Framework

Vito Huang speaking at Bristol JS in June, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

This is a talk about how Vue.js can make you more productive as a front-ender by making common task trivial and difficult task simpler.


- Yeah, thanks for coming. My name is Vito. I've been doing Vue.js for more than a year. Just wondering, who's been using Vue.js in here before? Just raise their hand. Who heard of Vue.js before but never use it? Okay, so there's a lot more people who have heard about it but never use it. So, what I'm gonna say is after the talk, go ahead and try it. If my talk, could be rubbish, so that's not, doesn't means that Vue.js is gonna be rubbish, so yeah, try different things. So yeah, today we're gonna talk about Vue.js, another JavaScript framework. Who doesn't need another one? Yeah, that's good. But this one I think is, really will make a big difference, 'cause the keywords in here is the progressive framework, not just any other framework, everything start with like small and then the idea of progressive is you starting with something small and gradually building something, something bigger, to make you think about what you're actually building rather than, heard these buzzwords like, oh yeah, we need to do this webpack or to get all this thing done, get everything, getting on there. The point of Vue.js, you can start with something really small, drop into your project, and then grow it organically if you wanted to. So normally, when you're building something, a single page app, or any sort of app, you would do your rendering. Basically, what you're doing in rendering is you have some sort of data you want to present to be the front end, that's the view layer of things. Most of the time, you want to keep your data consistent with the reaction. For example, if you have like a name, a name field in a form, you're allowed to be able to change, change that. You will present, you're rendering that name as some sort of H1 tag or input tag or something like that, but you also want feedback, it's coming back to keep your data consistent because if something changed, your data should be changing. And on top, the next layer up, once you have this small data you want to represent, you have components, you build components on top of that. And, component can be anything, could be a like a to-do list. You have to-do components in there, or you have an app, an app bar, and stuff like that in there. Once you've got that, you have different components and, on the sides, you want to present it to, in front end, using routing, because if you go to slash ABC, you want to use this component. If you go to slash users or cats or something like that, you want to use the cat component, obviously. As your project growing bigger and bigger, you would need some sort of state, because you have different components, different routes in there. You have slash users, slash post, or slash latest thing or something like that, your whole app just growing bigger and bigger. At that point, you would need some sort of state management, some sort of like, a source of the truth to represent your data, because there's so many interaction within your apps, you can have a click on this form that need to trigger some other change to elsewhere on the app or something like that, or some sort of like, if you're fetching data from the database, or any sort of like that, your app want to represent the whole, what's the latest view of your data? That, you would need some sort of a state management system to do that. And on the top of that, if you get, if you have like, I think it's an even bigger app, you'll be working with like a 20, or maybe like five, six people, or 20 people, you would need some sort of build system to automate everything, rather than just deciding, well that one page, it didn't change something, add a click event or something like that. So, we were going from the the rendering, most of the time, you have your data, you want to present to the user, see their, like a record of their latest post of something, or latest, suppose the, latest location data for, for other things. Basically, you're, you have your data, which is represented by state in there, you want to present into view. View is, it can be however you presented your thing, it can be like, it can be with a nice form, with the cat pictures in there, or different sort of thing, it doesn't really matter, but your view will provide some sort of interaction for the user. For example, if you have a post, people probably click on the things like, well yeah, I like this one, that means your data would need to change because you interact with the data, and then make a change to that, so the whole rendering is, it's only responsible for render your latest view from your I suppose latest representation of your data, 'cause your data can be changed by someone else outside the system. It doesn't really matter, it change from all over the place but the whole point of rendering is your view should give you a consistent, consistent state, the latest state of your data. And the Vue.js, that's this thing. This is how Vue.js actually, this is a normal, really simple hello world Vue.js. Here, you have app, which allow you to say make a new instant of view, and say so what data you have in this case, just the message itself. And then it will, you'll be using some sort of template will be parsing, it's actually two steps in there. The view will actually take whatever's inside the, inside the app itself, take a string, and then compile it into, into the virtual DOM, and then it will re-render itself, if your data is changed, for example, the message itself. The message, you can trigger the change of the message from anywhere else. it doesn't really matter, Vue doesn't care about that, well, for now. All it cares about, it render your data, and then keep track of that, if your stuff changed, it will keep change of that. This is actually what happened under the hood. Vue, same as React, have a virtual DOM, so every time you change, change on your view, it's actually, we're going through the whole virtual DOM itself. It doesn't go through the browser because sometimes, if you're just moving, for example a to-do list, if you're just moving things upside down, it doesn't need to change the whole list, whole tree, whole DOM itself. You only need to calculate the change in the virtual DOM, so that way, you don't need to re-render everything, everything from the beginning, for example, replacing the whole DOM tree in the real DOM tree, that could be expensive. So what Vue does is, it come with two part. The first part is the compiler itself which the job of the compiler is take any strings, like that H1 tag, take the string, and compile it into your JavaScript, which allow you to have powerful medication if you wanted to, for example in here, you have like, I got it wrong, but yeah, that should be H1 tag in there. Changing it too much, but the whole idea is it changed another, it created a sort of like a new node in the virtual DOM itself. Every time it want to update itself, it would check with the previous one, if there's anything change, it will try to re-render the thing into the DOM itself, but if nothing's changed in there or there's other change in other component itself, it wouldn't change anything in here. The good thing about virtual DOM is you have another layer between the DOM and your data. Sometimes, your data might be only change small part of the thing, you don't need to re-render the whole page of everything on the DOM itself. There'll be more benefit of using virtual DOM because JavaScript nowadays is really quick, you can just do the thing whatever you have before, and it will only change when your data is changed. So the next one is once we have a some sort of component represent the data, then we can build a complex app using the component system on a page, if you look at everything on a page, most of, well, pretty much all the thing break down into small component itself for example, search bar on the top right corner or top left corner, it can be a own component itself, you might be want, able to use that somewhere else later. So your whole app will be some sort of tree, some sort of component tree. For example, this could be the app itself. The app component maybe only containing the app, the menu bar, that would be always there, and beneath that, you can have like your user one, it will always have user information underneath all this thing, so you have a hierarchy of, hierarchy of your app, so you know which component is on the page, and you can mix and match whatever component we use, all this component on different, in the different component itself. So it's good to think about your, it's good to think about your app in terms of components. Because component is, is easy to test if they're isolated, if you just have that one, this thing, components in here doing the, for example a post, so always fetching a post, it doesn't care about where the post come from, as long as you provide some sort of like a URL API endpoint to the component itself as a property, get into the component. You can always do that sort of thing, so you can mix and match and reuse your component. That's the one of a big thing about React or Vue.js, you always build your component as small as possible, and then you can reuse that. And by the end of that, you have like, lots of component on a page, which is an app itself. Different page will be represent by different components. And, in Vue.js, this is how, this is one of the way you can write a component. They call that everything in, in a single file. It's called .vue, obviously. Within the component itself, off of the template, the template will get compiled into other JavaScript, into the virtual DOM, and then the script itself is how, how interact with the template, and then you also have the style. So you have everything, everything within the component in one file, which give you a overall visibility of if you change something, you should be able to, you should also change the style or something else, so the component should be self-contained. Everything, every component should be self-contained. And, if you see the style in there, the style is scoped. You don't have to be, put a scoped style. What scope means, the style in here will be only affecting this component itself. And it wouldn't affect anywhere else. So, if you think your component is it's self-contained, it should have its own style, and that way, you put a scope in there, and it will only affect the changes. What it does under the hood is it creates that element on a DOM, add extra tag to the, to the template itself. So it's only affecting the style, it's only affecting this component itself. And as you can see, within the component, you can have another component. You can import different component into your component, so you can have a hierarchy of things, for example, your user component, you can import a post component into that, and use that. As you can see, this, within this whole single Vue template, you can use the latest ES6 conventions, like import, or other shorthand, depends on what's, I think that is shorthand as well for that object itself, so you don't need to type another component equal to another component, that sort of thing. It just saves you lots of time, which is good. Yeah, it's a good thing about the single file is it's compiled by Webpack itself. And that means you're not limited to this format. You can use whatever template engine you want. You can use J. I don't think they call it J anymore, probably call it something else. Yeah, any sort of template engine, you can use like Twig or Liquid, or anything, it doesn't really matter. Same thing for the style. You can have CSS in there as well. So that's really convenient. And yeah, that's how you do your components. Once you have the components, you want to represent your app, how it looks from front end because on the first page, it will be just like a slash, that would be the homepage itself. You can put different components into that, but if people go to user something profile, it should be have a different component put on the page. That's the job of the routing. Every time you change, like slash ABC, the routing's job is get the latest component associated with that route and saying like, if you go to like the foo profile, it should be using the user component and the profile components within that. So you have, you sort of have a sign map of your app itself. You know what sort of, what sort of routing should be mapping to each component itself. Routing's actually a quite complicated thing because people, there's lots of other things you can do, you can do redirect, what's the latest active link, stuff like that, if people click on this thing, your component should be using a different component on the page, and that sort of thing. And also when people going to the user, it should be fetching the latest user data or something like that. It's not a topic itself, it's quite complicated but the whole idea is you should write your app as a smallest component as possible, have loads of these components, and compose them into like some sort tree, and use routing to represent them in front end, so you go to slash ABC or slash user, it will just pull out different corresponding components. After that, your app hopefully will get a lot bigger. Because you have the different components, and the routing, going to different places, then you will definitely need some sort of state management. State management is representing this thing. Basically, you have your state, it's your data, your data can be pulling, well, your component can be pulling different data from your state, and that should be, your component is the basically the view itself to have it represent your data, and the component is, is interactive because people click on this submit button on the form, or something, or some other thing like that. That would trigger some sort of action to make your form to be submitting to another server or or local JavaScript do some sort of validation. But the whole idea is for, is whenever people do some interaction on the page, they want to change something, they want to change your data because you presented a view of your data, it's like well, this is the user post in here, I want to add another one, that means they want to interact with your data, they want to add another thing to your state, which is your data, they want to add another post to your data, or they want to add, add a new form to it. So that interaction is the action itself. That action will, depends on the action itself. Some of them you can, you can mutate it directly, but some of them, you need to make a call to somewhere else, that will probably take another year to finish that, or if you're lucky, your API is quick enough, that should be coming back directly but, your action will, what will you do with the action? It could be failing Ajax requests or something like that. That should be reflecting the state change of that. If that's reflecting the state, that should tell the user, say like, you made this action, this thing happened, I want to present to you with this new viewing here, so that's how state management, in the small, supposing it's in, in its simplest form. Obviously when you have a bigger app, for example, if your user, if you're writing, it shows like a Facebook, if someone putting a post in there, you would change your current view for the user itself. You would probably change the other people's view, because the other people on another page viewing your page, you want to affect the change on the other page, or somewhere else on your app, basically. At that point, you would need better state management system. In Vue, there's something called Vuex. That allow you to do, to overall state management, and then come with a lots of other stuff, for example, the dev tool, allow you to see the time travel, time travel and other things. But idea is the same. You have your state in there. You have your view component, which is represent whatever's latest in your state, your data, whatever the latest view, add the only thing to your homepage or anything like that, and then you dispatch action. That action can be going to the back end or instant one, saying like, well someone toggle, toggle the menu, the menu should be open, simple as that, or someone click on this thing, something else will happen. That will, because an action will inevitably change something. That change is represented by the mutation itself. That mutation will going back to the state. Mutations also get recorded by the dev tool if you go to enable, that means allow you to see what sort of interaction on the pages, rather than on, rather than if you're just using jQuery, you always attach a click event, sometimes spend hours find out where it's actually triggering that click event, just take it out. I spent far too much time to figure out someone else code, it's like, this thing should work, but someone else triggered my stuff. I don't know where it is. That sort of thing. Yeah, I think just, I think the whole state management, that was sort of that part of the problem because every time you change something, it is recorded and then, and then you can see what sort of thing is changed. Next is how easy is it to use Vue.js? If you want to use Vue.js, there's something called Vue cli, which means do the, basically, depends what you want, if you would want to simply try it out, you can say vue in simple, and with your app name or something, it only give you a webpage with the simplest thing. You can go and play with it. If you want something really complicated, for example webpack, you can say vue in webpack, that give you all sort of stuff that, that give you like a single, all the good thing, all the webpack, using latest JavaScript library if you wanted to, so you don't need to limit yourself to ES5, you can use ES7. And they also come with testing of, unit testing thing with Mocha and Chai. Everything's there. Also with the end-to-end testing, like Nightwatch, which it use PhantomJS. That's how you go to this URL, click, go, and then click on this A tag, and you're expecting something else change. Basically that's testing from user point of view. I click, user go to this page, they don't know anything about your app, they click on this thing, they're expecting if something click the submit, the submit form should be gone, or should be doing other things, depends what you're doing, but that's for testing. Yeah, it's really easy to use. And another really useful thing about Vue cli is you can make your own templates. That means if you work in the company, and your company make some sort of plugin, have certain amount of structure, you can make into the template yourself. For example, that webpack, vue in webpack, that's the standard template. You can make your own one. That means you can, you can allow other people in your company to use the same sort of like code, like every time you start a new project, it will always have all this testing, your company-specific things in there. It's actually quite easy to use the template itself. And, yeah, it's great. And next thing is, is the dev tool. What are we talking about? This is one of the example app on Vue.js. I'm pretty sure if anyone use React before, you can really see this sort of thing. It's basically tell you on this, on your page, this page is powered by Vue, and you can see the component, here's the component itself. This whole web, whole page is, have a app component which is the route one, and we also have like a new stories view or what sort of, this sort of link, that link in there is the top link there, each link is the component itself and have progress bar. On this side, it tell you what's the data associated with this component right now? It also allows, well, for example, if you put, you can use the console to make interactive change to the data itself, or the property, it's basically the property itself, so you can see what it looked like if you want to change some bit of the code rather than you need to start everything from fresh. Next thing I'll talking about is server side rendering. Server side rendering is possible because Vue.js use virtual DOM. The DOM itself is represented by the JavaScript itself. So basically a bunch of code. It doesn't interact with the DOM. That means you can render your whole app on the server side rather than tell the browser to say, well, you got this JS, this page should be look like, and that sort of thing. Vue is really, I think it's really compared to React when I tried to set up the server side rendering, this is a lot easier because all you need to do, it's not much. All you need to do is create two entry points for your app if you want server side rendering. Everything else in app, you don't need to change any single thing. You only need to change two things on the server. You have server side entry points which means you get your latest data from your server directly, you don't need to do you Ajaxing on, if you do it on the client side, you still need to do your, no more Ajax go to server and fetch your data, but if you, it's just gonna render out your HTML directly to the browser itself, so you're just throwing out, throwing out a whole HTML, what this page look like. For example, this is a single page app. Normally, a single page app is, the first time you go to the page, it will go to the server and say, hey, what do you have? And the data will say, oh yeah, I've got this JavaScript file. You can have a look at this JavaScript file, and then browser will say go and look at that JavaScript file and try to make everything on the DOM itself. But on the server side rendering is, if the client go to the server asking for like, oh, slash user, ABC, because yours is a single page app, and you have server side rendering, it doesn't give you a JavaScript file anymore, it give you the whole, well, it still give you JavaScript file, but give you a whole HTML with all this content in there, rather than normal single page app, you just have an empty page with JavaScript on the page. But with server side rendering, it throw you everything associated with, with that entry point at that point of view. For example, if you go to slash user ABC, it should fetch your latest post because on the server, it have enough knowledge of what this page should be look like, and it have all the data it need to tell the browser, to work out all the HTML thing on the page saying that, well, you should have this H1 tag because you're using Vue. Well, you can use React, whatever the thing it is in there. Because of Vue, you represent everything in the component itself. Or, component only need some sort of data, it doesn't care where it come from, it's come from data, it come from Ajax or not on the server side, you already have the data going directly from your database, so you basically get your data, put that into your Vue.js code and saying like, oh yeah, I got this data and what sort of HTML should I have? And then the server side, oh yeah, you got this HTML, I can serve directly to the client itself rather than just getting a normal single JavaScript page with the blank stuff on the page. Yeah, that's a good thing, there's more benefit come with that. Once the server side rendering go to with a normal, some basic HTML, it can hydrate itself as well if you need it to. 'Cause sometime, you don't want it to fetch all the data. Some of them, it's like you don't really need on the page. For example a post, a user post. You have like, you just only want to present them with the latest post, like one, two, three, five posts on the page at the beginning. You don't want to fetch and doing some other things when they not need it yet. So that means, that you can use, do the client side hydration with make your HTML coming to life basically. So yeah, server side rendering is really good. Why is it good? Because it's good for SEO. Some company or some other people within the company, they thought like, well, Google need presenting a page with some sort of HTML, otherwise it's not good for SEO. I think that's total lie anymore. Google can parse the JavaScript and render a page itself. That shouldn't be argument. But if you actually need to do that sort of thing, yes, this server side rendering is good, and it's also good when you're on a mobile device. If you have a single page app, you don't want to outputting your whole single page app JavaScript to the client side, you just want to serve some sort of HTML first. That's when server side rendering is good for that. You're just like, well, I'll give you a bit of HTML first. If you want to do other thing, you can call me back later. I'm gonna do other thing more, interactive stuff with you on mobile, rather than waste their bandwidth to download a single page massive JavaScript with other stuff they don't actually need later on. Next is the Weex. It's native rendering. Because Vue.js is using virtual DOM, that means everything is in JavaScript, however you render it, however your app looks like, it depends on the device itself, depends on the browser or it depends on if you're on a native device. This bringing the benefit of if you just have the view file, you can put that thing into React, and then render it into different rendering engine if you need it to. For example, H5, that's the HTML5, you can use the Android anything so the whole benefit of this thing is you still have your app in the view component itself, because everything's made of component, component's really important. And then, and when you're writing iOS or Android app, you can reuse all your components, rather than writing a new one. Most of the time, when you're writing native app with a webpage, if you think it will list thing, it does pretty much the same thing, but it's rendering slightly differently. So all your logic and everything in the view file, it can stay, stay the same, it's just how you render it. How do you do that is they have something called JavaScript runtime, which is on iOS and Android. On iOS, they use something called JavaScriptCore, which is some sort of like small part of a Webkit, allow you to pass any JavaScript, pass any JavaScript, and then use that JavaScript to do everything you want. Because your view, your component is basically a Javascript file. And thanks to virtual DOM, because whatever you type in is a JavaScript file at the end of the day, it doesn't really matter if you're using H1 tag or H2 tag, everything will compile to some sort of JavaScript. And this JavaScript runtime can handle different sort of situation, like will tell you to use whatever rendering. The benefit of it's like you write your view file, your view component, you can use that anywhere. At the moment, it's not that stable, so I wouldn't recommend to use that now for production or anything, but it's good to know. In the future, they will improve a lot because lots of big company they're actually supporting this Vuex, they want to use this thing as well. So yeah, it's good. Yeah, that's pretty much it, thank you very much. - [Crowd Member] You said you've been using Vue.js for over a year now? - Yeah. - [Crowd Member] I was wondering what sort of problems it's helped you with in a kind of core sense, and what sort of projects you've used it on. - I used the, yeah. I think it does really help you to focus on the on the problem itself, rather than like, oh, I need to make this click do this thing. And then when I change this data, I need to write some sort of other JavaScript with jQuery to change the other thing on the remote end. Vue.js really help with your thinking, your thinking of like thinking more about your data. And once you have your data, how you represent your data. When something changed your data, how everything else should be changed around that. That's, I think that is one of the most important thing to take away. 'Cause most of the time, you're writing some glueing code in-between to make your app sort of reactive. You say that, well yeah, when the user click on this thing, you put some sort of jQuery, like you'll add an event on here, and then make some other thing changing here. That Vue.js really freed you from that sort of thinking and more into, I have this data in here, I want to, presenting in this way. If something, if someone makes sort of interaction to change I should change my data, and something else change, Vue handle all this change well, reactively. And that really free you to thinking in terms of how you should presenting your data and how you solve your problem rather than spend hours on like debugging on this, why this click doesn't work or why something, other things in there. So that helps a lot. One other thing I did is as my last job, I work in a eCommerce company, and we have the problem of on the product details page, when you go to a product detail, some people can click on one, for example a T-shirt, that's a product, when people click on this T-shirt, they can select different sizes and select different colour on that, different colour when you select sizes, the price should be changed, and everything else should be changed. That sort of thing is really easy to represent in Vue because what you're changing is you're only changing your data. You don't need to worry about how do I connect when someone selected colour, or when selecting the size, it free you from thinking of like how, when your data change, how everything else should change, if you have the component system in, like Vue in there. You're more like thinking of like when this thing change, I need to go to server and check if there's any stock for this product, or doing other things, rather than doing like some sort of other trivial things, how do I mix this thing together? It's just giving you a consistent view of your data and really help with your thinking as far as in the sense, you should always think about your data, not how they glue them together. Vue really helps that sort of thing, like how to glue your front end view into your data. Your data should be your source of truth, I guess. That the data is your state, you can make interaction with state, change your state. That Vue handle that really well, yeah. - [Crowd Member] I got one other question which is, when I started doing React, something we really struggled with was there were very few conventions about, and it was a bit of a kind of, like the Wild West, I guess. It was very kind of pure JavaScript but there were no ways of dealing with APIs and things like that. If you have a few more conventions in place that kind of put a few guidelines and processes in place that can help? - Yes, when you're using Vuex. I suppose I'll get you one of the slides. In here, actually Vuex is built by the same people making Vue, so they know about Vue. And in there, when you have some sort of action, it tell, it handle, well it just know, if you, it doesn't really matter if you're Ajax or instant one or something like that, so it handle that sort of thing automatically for you rather than if you're using React, you have, well, you can write you're own one in that, in that whole life circle of the component itself. Or if you're using Redux, you're probably using some, I think Thunk, which return a function and return another function to do, return another function to do something else. But, just to do Ajax requests within React, but in Vue.js, that sort of thing is a lot easier. You can make an action anytime you want. It doesn't really care about your action, is that Ajax take 10 minutes to return you back, or return instantly. Vuex handle that sort of thing automatically so you can say that's a sort of convention because it's just easier to use. And another convention I guess is the single view file. So within the single file itself, you will have, within the single file, this is sort of like unspoken rule, but not really a rule but everyone's following this because it's just easy to, easier to see your components at a glance, you see what your component, what the template things are, and you, you're separating out your template but if you like JSX, you can replace that with JSX as well to give you lots of flexibility. Yeah I guess, this is sort of convention because everyone following this. It's just seems, makes sense I guess. - [Crowd Member] How does Vue handle really, really live datasets? Does it slow down at all? - No, I don't have any, I don't ever see any problem with that yet because I've been doing a lot of mapping and GPS location and that sort of thing, coming real time. And most of the time is, most of the time, I find that the bottleneck is not Vue itself, it's more of like how you organise your app. That seems to be more like a problem because if you want to do some sort like a Sunday update, everything else in your states, no one can stop you if you do something, other thing, stupid thing, no one can stop you. Yeah, from my experience, I don't have any problem with handling lots of like real live time data coming in and that sort of thing. But other people might have bigger problem than me or doing any other thing, they might have coming to, coming to some sort of problem. But in general Vue, with the state handling is really quick, you shouldn't have any problem with that. If you have any problem, you probably need to do some of optimization on other bits of the code. It doesn't, I think at that point, it's more problem of your application rather than the framework itself. You probably need to rethink about how you actually, how your application gonna handle that amount, rather than you just throwing, throwing everything into the frameworks like, well yeah, good luck. How's this gonna handle? We render like everything else, yeah. But, no, I don't have any problem with that. - [Crowd Member] Please, a huge thank you.