In this podcast episode, we’re talking all about VueJS. What’s new in the 3.0 release, and how hard will it be to migrate? Drew McLellan talks to core team member Natalia Tepluhina to find out.

Show Notes

• VueJS
• The Vue 3 Migration Guide
• Natalia on Twitter
• Natalia’s personal webste

Weekly Update

• Different Ways To Design Digital Product Pages
  written by Suzanne Scacca
• Unit Testing In React Native Applications
  written by Fortune Ikechi
• 5 Ways Google Analytics Helps Web Developers In UI/UX Design
  written by Clara Buenconsejo
• Understanding TypeScript Generics
  written by Jamie Corkhill
• How To Use Face Motion To Interact With Typography
  written by Edoardo Cavazza

Transcript

Drew McLellan: She’s a passionate web developer, a Google Developer expert, and a conference speaker and author. Currently she’s a Staff Front Engineer at GitLab, but you may know her best as a Vue JS Core Team member. So clearly she knows her way around Vue better than almost anyone. But did you know she once taught a kangaroo to sing. My Smashing friends, please welcome Natalia Tepluhina.

Drew: Hi Natalia, how are you?

Natalia Tepluhina: Hi Drew, this was a really nice attempt on my last name. I need to give you credits. It was one of the best things that I ever heard from English speaker when they try to pronounce my last name. I guess it’s not possible if you’re not Russian speaking. It’s correct pronunciation is Tepluhina, but it’s like, that’s why I’m usually just asking people to call me Natalia and let’s stop at that.

Drew: Okay, well I made an effort. But the important question is, are you Smashing?

Natalia: Of course I am.

Drew: That’s good. So I wanted to talk to you today about some really exciting news that we have in September with the release of Vue 3.0. It’s been a major release in terms of version number but it really is a big release for Vue, and has been in the works for quite some time, hasn’t time it?

Natalia: It is. I think we first announced version three in 2018. I think it was announced in Spring, and the real work started in, I mean ideas was in Spring, the real work started in 2018 Autumn. And I think it was officially announced at the London Conference, which happened in October, 2018. Active work took two years. And it’s a lot if you think about, previous version was released in 2016. So half of these four years were also dedicated to Vue 3 work.

Drew: What was the sort of motivation factor in deciding that a new major version was called for? Was it a sort of conscious decision that, okay we’re going work on a major version, we’re going to work on Vue 3, or was it just sort of an accumulation of changes that simply required a version bump?

Natalia: No, I think it was an idea to create a new version due to a few very important things. So first of all, there was a motivation to change the reactivity. Previous one was built upon Object.defineProperty. And it had a few caveats, they’re all documented but still. You know, even if you document something that people shouldn’t do, they will do it anyway. And you would need to point them to the documentation. Nobody reads documentation by the way. For some reason it just happens. Until you point people out it doesn’t exist in docs it does. But okay. We will teach you anyway. So reactivity was one of the things.

Natalia: Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster. And also there was one pain point for a particular part of our, let’s say audience, people that use Vue. It was TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you are working with our state management Vuex. This was again a huge part. And the last one was, we kind of missed the functionality to abstract logic, in terms of not components but compossible logic parts. Like functions helpers and so on, but they should be able to include viewer activity as well. A nice example here could be React Hooks, right they allow you abstract the parts of the functionality and this was clearly missing in Vue. And I know that right now it sounds like, "You stole the feature from React." Not in fact. I believe that ideas cross-pollination is a big and nice part in our ecosystem and also it helps developers to switch between favorites, right?

Natalia: So we were working on these main features to create the Vue 3 as major version.

Drew: Now I think it’s one of the great things about existing in an open source ecosystem is that there’s a wealth of ideas and experience all out there from all sorts of different projects, and the ability to borrow those ideas and borrow the experience from other projects is really beneficial and makes everything stronger, doesn’t it?

Natalia: It is. I think it, it works the way we call an iteration value in GitLab. When you come up with an idea, it’s never perfect. It’s mostly like some very raw, very hard coded thing. Maybe change something, but it’s like definitely not perfect. And you need a few iterations over this idea to make it really good, not even perfect, just good. And happens with ideas in the ecosystem. Someone comes up with a good idea, and you just take it and make it better and better. And I bet that well, there will be something that will take some ideas from Vue, maybe they already taken some ideas from Vue, and make it better, and there is nothing bad here.

Natalia: I’m strongly against, like, "You are stealing ideas". This is not stealing, this is just cross-pollination.

Drew: Exactly, yeah. You mentioned that the migration to TypeScript, so Vue 3 itself is written using TypeScript now, is that correct?

Natalia: Yes, yes it does. And trust me, Drew, I was writing the documentation, the small document about how to use Vue with TypeScript. And I was like, okay, probably somehow like Vue 2. And I overcomplicated the document so hard, I was like typing everything explicitly. Looks good everything is typed. I can see types, so my ts-link is happy, so far so good. And then one of our developers who was working with TypeScript, "You don’t need to do this". Like how, how? "You don’t need to do explicit types to data. You just give it an initial value and ts-link knows its number. It’s already typed." Like, how come? "I removed 90% of explicit types from the document. There are only two things you will really need to type is proxy of the component, and computed properties will have. They still require return types. But the rest is like, typed automatically, just write a component with a method we call define component. And that’s it. It’s typed."

Natalia: It was like, it just works. And for me, and I was working with Angular in my past experience a lot, I have Stockholm Syndrome for TypeScript. Everything should be typed explicitly. I mean, if you have complex types, of course you will need to write interfaces, but this is how TypeScript works. Still, it’s so much easier to work with TypeScript right now with Vue 3.

Drew: So that’s great, so it’s a benefit both to the Vue Core Project, and to developers who are building applications using Vue because they can use TypeScript in their applications nicely with Vue now, where they couldn’t with 2.0, well any version of 2.0 so easily. Those who are familiar with the Vue community will be aware that Vue’s creator Evan You is still leading the project very actively. How does the Core Team function? How is it structured when it comes to the development process? It’s not all Evan is it?

Natalia: That’s such a great question Drew, because for years, literally, people were speaking about Vue as, I quote this and I will sound harsh, but sorry, it’s like, "A framework of one Chinese person, like Chinese framework even". And I mean even with Vue 1.X, there was already a team and there was a big team behind Vue 2 and even bigger team behind Vue 3. The thing is we all have different responsibilities when we speak about Vue.

Natalia: There are people who are working on Core, and this is not just Evan himself, he is doing most of work on Vue Core, definitely, and he’s leading the project as well. But there are people who works in Vue Core, and their contributions are absolutely invaluable. And there are a few new people, joining Vue team as well, that work in Core. And there are also smaller teams working on ecosystem, there are people that work on the Pure Router, like Eduardo, there are people working on Vue CLI, on Vuex, on documentation as well.

Natalia: There is a whole team that works on documentation because we believe that documentation is important. And currently on our website there is, I think 21, 20 or 21 person, always miss the count, that belong to the Core team, but this is not a static list. Because we, we’re not hiring obviously, we are an open source team, this is not paid job. But we believe that if someone contributes a lot to any of parts of the Vue ecosystem, when people already do the job of the Core team member, it’s just, giving them recognition with just access to the repositories and formal title.

Drew: That’s great because it’s a case where contributing to an open source project can really sort of pay back to an individual. They get some recognition and that can have an impact in your professional career and what have you.

Drew: For listeners who may not be used to Vue but perhaps they’re familiar with other reactive frameworks, such as you know React, Angular and so on. What are the big, sort of, headline changes with Vue 3 and specifically what problems are they trying to solve? You mentioned composition earlier as one of those things, is that on of the big changes?

Natalia: Yes, this is one of the biggest changes, and it’s actually one of the things that are, first of all, like let me make clear statement here. Composition API is purely additive. It’s not that you need to rewrite your components, you can add TypeScript to them. Or you might prefer, to use all syntax, now we call it Options API, and nothing will change for you in these terms. It’s like, when we’re speaking about new API, this is not a breaking change. I just want to emphasize this really, it’s really important to say because when it first announced the Composition API it was an awful moment.

Natalia: I think we didn’t really describe the changes nicely and we made it seem that standard build will be Composition API. It’s our bad completely and options were like, maybe we will deprecate it in future builds, not in Vue 3, clearly. And if there are any chances that people will read what you said wrong they will read it wrong.

Natalia: Immediately after this statement, it was RFC where we just proposed the change, Reddit exploded. Reddit was filled full of like, "Oh, my god. I will need to write everything. Oh, my god. Vue is new Angular. They are going to break all the things." And there was a guy who created an article on dev.to called, Vue’s Darkest Day. It was a darkest day, honestly. We felt so but I was like trying to kind of fight this on my own Twitter like, "People we are not really... They were saying that we started to change the RFC, I think Evan started to change the RFC without announcing changes. So he was like, "I will just quickly re-write this. Let’s like push into master". People were mad about this. Because they were arguing about certain points then you just refresh a page and those points not exist anymore. You feel like, am I a fool or just... What the hell? I mean, it was right there. I remember this. And I believe that our communication strategy could be better and this isn’t us.

Natalia: Right now, every single time I speak about composition, this is purely additive, people. This is just a nice feature. You can use it, you can not use it, you ar not obliged to. Just... It exists.

Drew: What is the sort of problem that somebody might get themselves into where the Composition API is a new thing that helps them get out of that problem? What problem is it solving?

Natalia: Imagine the component that has a few features inside of it. Let’s say it’s search and sorting. Let’s say we search for a certain list and we try to sort it. This is already two different features and the thing with Vue components is, they are split, based on the options, not based on the logic. Imagine your search has probably a query, because you need to make a query to search and array of results. And these are two reactive properties. In terms of your component, you put them to the option that is called data. And obviously you need some method to perform the sort. Maybe a button click, maybe something else, something that runs the search. You create the method. And for sorting you need to build something upon sorting options, another reactive property. Then you perform some calculation to sort the results.

Natalia: In Vue, for this, you also have computed properties, which is another option. At the end, your component became really fragmented. And imagine I’m a developer and I have a task to work only on searching part. I cannot split the component right now, because these two features are kind of cross in their ways. I search for some results and sorting them. And I need to jump from data to method, from method to computed and at the end it’s really hard to just switch the context. Especially if the component grows really big.

Natalia: What options did we have in Vue 2.0? First option was called mixins and mixin is just an object that can contain the same properties component can have and we are mixing them in with a component. Sounds good, I can just move all my search in there and what is the problem? There are a few. First, this is completely not flexible. If I want to search for a certain end point and I move this to mixin, this will be the only end point I can search for. Mixins don’t accept parameters. I created a mixin, it’s completely static. Second issue is mixin is mixed in, which means for certain properties it happens like a merge. For example if you have created hooks it will be merged. All the logic in the lifecycle hook from the mixin component are merged together. But if you have a data property, a cold query in the mixin and by any chance you have the same in the component, the component has a priority. It will be overridden. You will have no warnings. Absolutely. It will just happen and you will have no idea this happened.

Drew: All the scope is completely mixed?

Natalia: Yep, completely. There is no chance you will see and also, mixins are very unclear source. You just import the mixin with name and put it to view component property mixin, that’s it. It’s very implicit and I’m speaking about this from the point of my own experience. We have a logic in GitLab where a component contains two mixins and every of these two mixins contains another mixin. And here it goes, here is a property you need to check and it’s not in the component. Let’s go deeper, first level mixin. This one does not contain it and this one does not contain it as well. Where it is? You’re diving deep, just deeper down the rabbit hole, just to find this property and testing becomes a nightmare as well.

Natalia: Mixins are very, let me say, dumb ways of extracting the logic. It’s plain, it’s clear, it’s very easy to get. It brings you so many problems if you want to work with this on advanced level. Next way of abstracting logic in Vue 2.0 was renderless components. In Vue, component can contain a slot. Basically a piece where you can put anything from the parent component. A small window, a slot actually. And there is an idea of scoped slots. Imagine the child component that can expose its own scope back to parent and slot content will have an access to this. Imagine I have a component with a slot and component performs all the logic regarding searching, let’s say searching which has an end point with past parameters. Our child component, like searching and then it exposes this part of its scope back to parent. These are search results. Enjoy. Sounds good. Sounds definitely better than mixins. We can test parameters. The logic is explicit here, we are returning something. Issues? There are a few.

Natalia: First of all, you’ve created your component instance. This is not the cheapest operation in the world. Second part, it’s runtime. The component only works in runtime and this means that exposed property from this component will be only able in the slot you exposed it as a scope of slots, so your search results are only available in the small part of your template. If you want to play with the discrete part of the component, you don’t have access there. It’s runtime. There was no to action this logic if you needed a reactive state somewhere else. Of course it can create helper like a pure function and return results but, what if I need to operate for the reactive properties? That’s how Composition API was created. With the Composition API you can have standalone reactive state. Reactive state is not just part of the component anymore. You can make any object or primitive, reactive. And you can expose it back to parent, it’s very explicit.

Natalia: Every property you want to return to parent is exposed. It’s explicit, you can click on this, you can see where it is, what it is, and so on. And the best part, if you include the part of Composition API to old good component that has data methods, computer properties, whatever, it just works. It just works perfectly, you just add a few reactive properties and methods to your component and you can use them with old options API as well.

Drew: This sounds like it’s really going to help developers clean up their code bases when it comes to very complex components or even mildly complex combination of components. And you mentioned the testability of mixins and things, does the Composition API allow for better testability?

Natalia: Yes, definitely because Composition API, if we exclude lifecycle hooks from this, because you also can run another lifecycle hook in the composeable. It’s actually pure function. You have S-parameters, you’re doing something and outside of lifecycle hooks there are still side-effects. And testing pure functions, as you know, is probably the easiest thing. It’s just a black box, you have S-parameters, you have something to return.

Drew: That sounds a very comprehensive solution to a problem that I’m sure a lot of people building more complex apps with Vue will appreciate. And it certainly sounds like a really great way to eliminate the sort of bugs that I know can creep in with mixins, where it’s very easy to introduce bugs, like you mentioned, with the scope being merged and all those sorts of things.

Drew: I always think a massive consideration when choosing to build on top of a framework is its API stability over time. Maybe stability isn’t the right word, but I think many of us have been stung by building on top of a framework then undergoes a big reworking and leaves us with apps that either require a massive investment to migrate or they just end up being bound to an old version of a framework which then is no longer supported. It’s a horrible situation to be in. How much sleep am I going to lose moving a big project from Vue 2 to Vue 3?

Natalia: First of all, API surface is 90% the same that it was. We didn’t have that many deprecated things or deprecated filters which are replaceable with deprecated event hubs. If you want to use an EventEmitter you would need to replace a view based one with some external library as well. These are big changes, but speaking about migration... Let me make it clear, I’m really torn right now, because on the one hand I’m Vue JS Core Team member. On the other hand, I’m a Staff Engineer in the big project that uses Vue. If you are about to start migration right now, I would not recommend doing so. First of all, the ecosystem is not released, I mean if we speak about core libraries like Pure Router, PUX, Vue CLI, these are in the good shape but they are still release candidates, not releases. And if we speak about other ecosystems like not core libraries maybe, UI component libraries, maybe some form validation libraries, they are not ready, mostly, for Vue 3. And if you have a big project, you have so many dependencies you need to care. So this wold be a complicated thing.

Natalia: What are options? You have a big project, you want to use all this Composition API goodness. How to achieve this? First of all we plan to release an LTS build of Vue 2.0, Vue 2.7. That will include lots of deprecation warnings, so you will be able to see what is going to be deprecated, how to refactor it not to break it with Vue 3. So you will be still technically using Vue 2 but you will be preparing Vue 3 anyway because you have all the warnings.

Natalia: Second, we’ll use a migration tool that will be able to just run it and it will work as a codemod, replacing things that relate to Vue 2 with Vue 3 alternatives. Of course, no codemods are perfect. We aim to, first of all, make replacements whenever possible but also show warnings whenever deprecation is not easily handled. Codemod will be able to recognize a thing and throw a warning but not replace it by itself. This is like a big plan and by the moment Vue 2.7 is released and I think right now their estimation time arrival is December if I remember correctly, I would need to check the road map, but I think it’s December.

Natalia: The ecosystem will be also more or less ready. If you have a large project with Vue 2.0, just wait a bit more until Core is stabilized because even if you produce a perfect library it still needs some time to stabilize because people start using this, people start reporting bugs. If you’re about to use it for pet project and report bugs, please, you are very welcome to do so. And after this there will be a good smooth way of migrating to Vue 3.

Drew: So the migration tool that you mentioned sounds quite interesting. Is that basically a static analysis tool that looks through your code and...

Natalia: Yes, yes, yes, it’s a code or a tool. Right now it’s available in a very limited way. It’s available as a plug in of Vue CLI. If you have Vue CLI based project you can run Vue upgrade and see how the tool works. It’s not in the shape we want it to be so far. Unfortunately, I don’t work on a project built on Vue CLI. I would need to wait and check what is going on but, for example GitHub, we’ve already taken a few steps even without migration tool to prepare, because we know what is deprecated. It’s actually stated on the Vue 3 documentation.

Natalia: There is migration guide. You can see all the breaking changes and things that have deprecated and you can already work on part of them even on Vue 2.0 code base. For example, in Vue 2.6 we changed the syntax for slots. Syntax for scope slots was deprecated but not denied, it still exists. It gives a warning but you can run it. And of course, with a codebase that was seven years old, nobody cares about replacing all the deprecated syntax if it just works. There are no warning in production. Slots work. In development like, "Oh, I see some warning in the console. Maybe 20 of them, fine. It’s yellow not red. I don’t care".

Natalia: You know it happens to everyone. We created a huge epic to work on this. Find all the current sets of old syntax. We make an effort to replace our EventEmitters, again, seven years old project, don't judge us. We have EventEmitters. GitLab was working on EventHubs. We replaced Vue based fun with external libraries. I would recommend doing the same. Go through migration guide checking what can be replaced already and what changes you can already make to prepare and start working on this.

Drew: With the current state of the migration tool be a good way of just testing the waters with your codebase. Just running it and having a look to see what it flags up already, to see if it looks okay or if there are some big things or is it still to immature for that? Is it better to wait till December when it might actually be able to fix things.

Natalia: If I had a big project, I wouldn’t recommend doing so. If you have small bad project or maybe some personal project but it’s not that large I would recommend running it and checking issues like whatever you have because for two mid-sized projects I’ve been running it. I think one or two issues. I can’t say it’s immature. It’s already in a good shape. But for big projects again, it’s legacy, it’s some exotic stuff. Don’t do this in production, people.

Natalia: Also if you would like to play with the scaffolding of your project, right now Vue CLI supports two modes. You can create Vue 2 project, you can create Vue 3 project. And definitely give it a try at least. This is a good way for us as well because as you play, you discover bugs, you report bugs, we try to fix them and so on.

Drew: In the docs and on the development roadmap I see mention of a migration build. Is that something different to what we’ve talked about or is that what we’re talking about?

Natalia: No, no, it’s the same. It’s the same one and it should be ready but for now, if you plan migration, the main path is just read docs and follow whatever is said there because we definitely make an effort whenever we don’t have migration tool, documentation team went ahead and created a detailed guide of what is the change, why it has been made and what is actually a replacement here.

Drew: Yes, in the docs is quite a comprehensive migration guide as part of the Vue 3 docs and it mentions an awful lot of changes that need migrating. I guess some of those won’t impact every project. A lot of them were essentially edge cases for a lot of people. Is that fair?

Natalia: Yes, a good chunk of them for example, filters, definitely are some edge case because even at GitLab with, for the third time, seven years old codebase and a big one. We had one or two occurrences of filters and they were not used anymore. It was a good thing that we searched for them and removed them completely because like, "Oh, unused code" and again, who cares it just exists.

Natalia: I would say that totally breaking changes are the model changes. Take a look at this because every single project I know contains at least one Vue model, for sure. This should be checked and maybe attributes changes as well because currently we are including class and style, tubulars and ethers. And if you ever worked with Vue, previously it was not included. Right now, the way you pass class and style to a child components is slightly different and they’re definitely worth an attention.

Drew: That’s good to know. The 3.0 releases that come released with Vue, I mean you mentioned the ecosystem and everything around it, Vuex and all these other parts of the ecosystem that need to get forward to that level. Is that why, currently, the website, the big "Getting Started" button still all goes to Vue 2? It kind of feels like Vue 3 has been released but not with full confidence. But is it because of that ecosystem issue that it’s like that still?

Natalia: No, I think you just found a bug, let me just quickly check. No, get started is pointing to Vue 3, it’s fine. I mean if you go to vuejs.org it points to version two. This is intentional because we planned to replace it with sub-domain like Vue 2, which is work in progress, but so far we decide to leave vuejs.org where it is and create Vue 3 and that’s why there is a banner on vuejs.org. If you go to any doc-

Drew: There’s a very tiny banner at the top, yeah.

Natalia: Yes, like small.

Drew: Yeah.

Natalia: We should make it bigger, I guess. Bigger and with a better color contrast. My accessibility feelings stays like, "Oh, there is nothing of contrast there".

Drew: That’s good news. If somebody is starting, maybe not a big project, but if somebody is starting a personal project or wanting to learn Vue, certainly, Vue 3 is the place to start?

Natalia: I would say so. The learning curve is not that different by the way. Because it was an intention of the documentation team to have the old syntax options, I shouldn’t say old, it’s actually the current syntax. The familiar syntax as a default one. Because if you go through Vue 3 documentation you will see with the Composition API only in advanced topics and the learning path you have with Vue 3 is kind of similar to what you had in Vue 2. There is no big deal to start with a newer version if you just learning Vue and try to experiment with it and I believe it would be a better investment if we speak about career. Start learning the newer version because it will be overtaking all the projects. Eventually, maybe half of a year, a year, even for big sized projects there will be migration.

Drew: I seem to have in my personal career, a real talent of coming to platforms just as they’re in the process of a big migration. I mean even as far back as, do you remember, Macromedia Director, going back that far and Shockwave, Flash and all that kind of stuff. I came to that as they were transitioning to dot syntax and I had to learn both. And here I am, I find myself in the last month, working on a project in Vue for the first time, which is a Vue 2 project and learning as I go and looking forward to all the things that are coming in Vue 3. It’s certainly an interesting time to be learning something as it migrates but it sounds like it’s not too difficult with Vue and once the ecosystem has caught up with the Core then we should be in a good place.

Natalia: Oh, Drew, I just want to make a point about whatever you said about big project immigration. You can imagine me like, 2018 and I’m joining GitLab. I wasn’t Core Team members, I’m just a contributor at this moment.

Natalia: Immediately the same time Evan is like, "Oh,we are going to make Vue 3". Everyone like, "Yeah, cool". Spring of 2019 you are the Core Teeam. I mean the whole GitLab is like, "Oh, this is cute. We all having migration and you know who is kind of responsible for this?" And you can only imagine how it happens when you write documentation for Vue 3, everybody will be reading and your own company is like, "Oh, I want to learn something about Vue 3, I can’t understand your docs." So you’re like, "Oh, damn this is so painful" because you’re a developer there and tech writer, kind of here.

Natalia: You’re in the middle of this but, I have to say it’s really beneficial for framework as well because any big product created with a framework is a great, absolutely great battlefield to find bugs and bring them back to the library, to the ecosystem. I can say that tests, and GitLab is open sourced, Vue Test Utils, which is a testing tool for Vue. A team was using our testing code based around tests, which makes a lot of sense, right. Because you can find some edge cases and so on. But still, when I think about migrating GitLab to Vue 3, I feel like a personal responsibility for this. I’m not only in the middle of migration, I’m personally responsible for every single bug we will find.

Drew: Looking back at the previous generation of JavaScript frameworks, I think one of the most successful of those was jQuery, back in the day, and I think it gained traction because it had an extremely well designed API. Just this concept of taking a CSS selector and using it to query the DOM in your JavaScript was something that jQuery popularized. And I think that really resonated with hardworking developers who didn’t need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it’s doing. And if I need to do something I’ve not done before I can sort of guess at how it would be implemented and usually I’m right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It’s changed slightly but we had a concept that was called Documentation Driven Design. And it’s a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that’s why it’s intuitive. If it’s easy to explain, people probably will get it on themselves. That’s why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don’t need to explain what v-if is doing because it’s clear, right.

Drew: It really is.

Natalia: It’s kind of insulting and same with v-else. V-if, v-else-if, v-else and that’s it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It’s all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn’t work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, "It’s so nice to use". I’m just building the same stuff and it’s just been a pleasure. I don’t need to think about the tool, I’m thinking about what I’m going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I’ve been working with Angular from version two to version six on a commercial project and it’s a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it’s just hard being a developer. And after this, working with Vue is like, "Oh, it’s just like a walk in the park".

Drew: There can be a danger with software that when it’s so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that’s a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it’s better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I’d been speaking at, "Would you recommend Vue for big sized project, for enterprise project, for like serious project." And every single time I was like, "Yes, you can use it for small project, it’s easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, "You’re free. Build it." And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it’s not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, "What if Evan You is hit by a bus", I swear on dev.to. I’m like, "What are they so scared" and big companies are probably like, "What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this." And as we can see over years it’s good and stable and it’s developing and it’s not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it’s actually better for the framework.

Natalia: Last year we introduced the RFC process. It’s actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it’s not decided, it’s not set in stone. We just have an idea and we want to hear what community thinks. I believe it’s great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it’s true. It’s actually shaped by community. It’s not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They’re not shaping the framework and I believe this is great.

Drew: It’s quite telling when you mentioned the list of active Core Team members is 20ish people and they’re all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you’re at GitLab and there are other people who are just independent consultants and it’s not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, "We’re changing direction, we’re not going to do this anymore" and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I’ve spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you’re listening to this, the site will have changed and will just be Vue, but that’s also where you find the docs and in the docs is that really good migration guide that we mentioned. I’ve been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I’ve been learning about Apollo Client version three. It’s funny, because if you look at versions and I’ve been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we’re adjusting them at work but, for example, removing local resolvers, is like, "What do I do now? What do I do with my local queries?" If you’re curious about Apollo Client version three definitely give it a try. It’s interesting to see how it’s evolving.

Drew: I’m definitely going to give that a try. I’ve used Apollo on a couple of projects and it’s really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.