Vue.js Team

The Progressive JavaScript Framework

Hosted by

20th September 2017, 5:00 pm

This AMA is over!

Thank the host

Message from the host 馃挰

Thank you for joining our AMA. The questions were brilliant; we all had much fun answering them. Here is a summary of the AMA:

  • Vue 2.5 is coming
  • vue-cli 3.0 has started and we want the community to participate
  • We plan public roadmap to make it easier to get on board and contribute.
  • Egoist and Linusborg might or might not be machines/AI
  • React patent issues don't affect Vue; we are unlikely to see any issues surrounding this. Vue will remain on MIT license.
  • Company backing is not an issue for us. We believe Vue has already surpassed the critical mass and "survival" is really no longer an issue.
  • Weex, NativeScript + Vue, and other tooling will be supported by the team for the long term. We are helping to mature the documentation and bridge the gap to help adoption.
  • React Fiber is interesting. Vue can leverage some learnings, and we will watch the space. Although we don't see a strong need to implement something similar.
  • Vue 3.0 is in the planning phase, targeting evergreen browsers. This will help us enhance the reactivity system and reduce library size. 2.x and 3.x will be maintained in parallel.
  • Web components will not (yet) be part of core, but we will continue to watch this space
  • We wish Wordpress all the best with their upcoming challenges and will support them as much as we can. It's still too early to say what will happen here, but we are very excited as a team on the prospects it brings.

Are there any plans for an official package, similar to React Native, for Vue?

Do you feel that if Vue has a Native package (Vue Native 馃槑), it's adoption would see a rapid growth and hopefully be adopted & supported by major players?

Thank you for your amazing work. Kudos 馃檶

Currently we have no plans for such an initiative to be taken on by the core team itself, because there are already existing solutions such as Weex and NativeScript + Vue. The core team has limited bandwidth and it would be unwise to invest time in yet another competing solution.

We know that Weex, being from a Chinese company (alibaba), its documentation, learning resources and community engagement in the western world are not as abundant as those of ReactNative, but the core technology itself is absolutely rock solid. It has been used in production at Alibaba for almost 2 years, and has endured the tests of extreme scenarios (the "double 11", similar to Black Friday except with even higher traffic).

NativeScript + Vue is also interesting - although not as mature as Weex/ReactNative at this point, it's definitely worth keeping an eye on.

From the team's perspective, I think it's worthwhile for us to bridge the gap of adoption, helping these projects with better documentation, and a better onboarding experience as smooth as using Vue itself.

Vue.js is awesome; there's no question about it. Considering the recent license changes to ReactJS, many developers and startup are curious these days.

How can we be sure that this won't happen with Vue.js?

First a small correction: React has always been using that license (BSD + patent clause), it was only brought into attention again due to Apache foundation banning the license from its projects.

Regarding the question: the most critical difference is that Vue is not owned by a major corporation that has to defend itself or exert competitive leverage with patents. Facebook chose to enforce the patent clause to protect itself from patent litigations. In comparison, we do not own or leverage any known patents in Vue, nor are we a for-profit company that could become target of patent trolls, so we have no incentive to complicate our license with problematic clauses like Facebook's.

Even in the worst case scenario where a future version of Vue switches to a less-open license, all past versions of Vue are still under MIT, and can be forked if necessary. But as explained above, this is extremely unlikely to happen.

Browsing Github issues we can find some hints that Vue 3 may show up in the upcoming future. What are the key features or changes that you consider and how do you imagine potential transition from Vue 2?

The main idea behind the next version of Vue is to refine and improve its API and internals, and it won't be a very different release (unlike 1.0 vs. 2.0).

Vue 3.0 will drop support for older browsers in order to take advantage of new web APIs like Proxy to improve its performance and remove all the reactivity system limitations. For example, you will be able to do this.myArray[1] = 'new_value' and Vue will detect this change and update your components automatically. Also, your data will be tracked lazily so Vue will be faster with large datasets.

The upgrade to v3.0 should be quite easy since most of the API won't change. The only thing to consider is it will only support "evergreen" browsers (including MS Edge) which means it will not work on Internet Explorer. But don't worry in case you target older browsers, both Vue 2.0 and Vue 3.0 will evolve with the same features and be maintained in parallel until those browsers aren't used anymore.

Vue 3 is not going to be one of those "big change releases" - the main difference will be that Vue 3 only targets modern "evergreen" browsers (i.e. IE11 & below are out).

Resetting the browser support baseline gives the opportunity to:

  • Rewrite the reactivity system using ES2015 Proxies. This will get rid of almost all of the existing gotchas/compromises in the current reactivity system, and has potential to improve performance as well.

  • We can drop all the code dealing with compatibility issues and esoteric bugs in older browsers. This should shed some good amount of weight from the lib size.

This is really the main point - we strive to keep the public API close to 100% compatible, and v2/v3 will be maintained in parallel with feature parity until the older browsers completely phase out.

A lot of people is worried about a big company not backing Vue, is that a real problem for the future adoption of the technology?

I don't think so, personally. I'd even say it's a strength. We're not supported by a single company with a single perspective and use case, but by many companies and individuals, all over the world, with wildly varying needs.

Vue is in many ways for the community, by the community - both in the sense that we're funded directly by the community (by our companies, on Patreon, and now OpenCollective), and that most members of the Vue team are themselves community members that use Vue in our work every day. 馃檪

It might also be worth mentioning that big company backing doesn't necessarily has a positive correlation with the longevity or adoptability of the project - you may get a completely incompatible rewrite, patent licensing issues, or project being abandoned outright. Granted, in a more generic sense, big company backed projects are more likely to survive than independent/community-driven ones, but Vue has already surpassed that critical mass and "survival" is really no longer a concern in my opinion.

One extra point i can raise, is that since the beginning Vue has always adopted the feedback from it's users. We aim to build the tools for the community and support the needs.

Not saying React, Angular won't do the same, but it's a nice spin on the 'backing' argument. We have the flexibility, as a team with no agenda to serve the community as well as we can.

To me also it matters more about those using the tool, and people use Vue this is what will keep the ecosystem running.

There are more and more companies using Vue, including some very big names. Who have vested interest in supporting the ecosystem. So there is no worries of Vue dying out, as we will continue to support and make it better.

I love Vue for its great simplicity to use, the high quality documentation, and the entire ecosystem* around it. What are the next major efforts for the team and how or where can I best follow those efforts?

(aka if I see something I can help with, I'd love to, otherwise just follow)

*vue-cli, easily used and extended templates, VS Code's vetur, Chrome DevTools extension

What's currently in the works:

  • vue-test-utils (the beta will be released soon)
  • eslint-plugin-vue 3.0
  • vue-cli complete overhaul
  • Vue 3.0
  • Vue 2.0 new features as well
  • Official Style Guide
  • Official Cookbook

If you want to help, don't hesitate to look for open issues!

Yes, we are planning to setup a public roadmap so that the community can get a better hold of the things we are working on! Stay tuned :)

I have no question, but I use Vue on a daily basis and I just want to thank you all

Should developers to use jQuery with Vue.js? Why and why not?

My take on this is this: You shouldn鈥檛 feel that you need it, most of the time - but if you do, there鈥檚 nothing wrong with that (We鈥檒l get to jQuery plugins further down).

Why would you not feel a need for it? jQuery鈥檚 core functionality (the parts I used and see used) has three main areas of focus:

  1. Making DOM manipulation really easy
  2. Making animations easy
  3. AJAX

Concerning DOM manipulation, Vue takes care of that in almost all cases. In the few where you actually might need to access the DOM (to focus() an input element programmatically, for example), the DOM API provided by current Browsers is more than good enough in many cases, so you can do that with a simply document.getElementById(鈥#myy-id鈥).focus() (Actually, this is a bad example as Vue鈥檚 $ref feature would allow you to do this without any DOM query at all)

Concerning animations, it鈥檚 worth learning how to use CSS transitions and animations (with or without using Vue鈥檚 <transition> for them), you often don鈥檛 need any JS to animate your content beautifully. If you do need JS animations, there are many other solutions that are more lightweight than jQuery for that.

And concerning AJAX, we now have more modern solutions like axios, which support great features like cancellation and are very lightweight at the same time. So especially if all you need from jQuery is AJAX, you probably should look at something like axios to improve the filesize of your bundle.

But what about plugins? Well, jQuery obviously still has the biggest plugin ecosystem around, simply because it鈥檚 been around much longer and was (and is) extremely popular. So if you find that you want or have to use a jQuery plugin that you can鈥檛 find a good Vue plugin for, there鈥檚 nothing wrong with using jQuery and its plugins to achieve what you want.

That being said, many functionalities that you might want to use a jQuery plugin for are pretty trivial to implement in Vue (tabs, modals and the like for example), so it might be worth just trying out if you can recreate the functionality you want in Vue - you might be surprised how quickly you can do that in many cases.

For an exmaple of how to interate a jquery plugin with Vue, and what to look out for, tke a look at this article:

Will Vue.js utilize web component APIs in the future?

This is not something we plan to support in the core in the short term, since it will take a while for full support in all browsers / old IE鈥檚 fading out.

Once we see adoption and support mature, we will surely revisit this question, but it鈥檚 not a priority for now.

But in the meantime there鈥檚 a really good package by a guy named Karol that allows you to wrap your Vue components in a Web components wrapper, so you can use Vue components as web components today very easily.

You can find it here:

Can you explain the upcoming reactivity system rewrite? What will be the gain from the user perspective and what potential side effects we should be aware of?

Vue 3.0 will use the Proxy API to power its reactivity system. It will improve its performance and remove all the reactivity system limitations.

For example, you will be able to do this.myArray[1] = 'new_value' and Vue will detect this change and update your components automatically. Adding entirely new properties will work too. As a result, Vue.set will be deprecated.

It will also allow performance improvements for large arrays, and lazy reactivity conversion will make using big datasets faster.

Currently, we foresee one possible breaking change: Vue will use Proxies for the values accessed on the component instance, so equality checks with the original values will fail.

What is the biggest challenge in trying to support something that is used by other people? Do any of you ever get frustrated by others' misconceptions about Vue or that it doesn't often get the credit it deserves?

Thank you and keep up the hard work.

Looking at the success of our project so far, I think it鈥檚 obvious that a lot of people value it for what is is and does, so credit isn鈥檛 much of an issue in my eyes.

Sure, you often find people on twitter who might say something that鈥檚 incorrect, wether it鈥檚 out of ignorance, misunderstanding or similar circumstances (don鈥檛 like templates? look, we have JSX, too!) - but those voices aren鈥檛 very loud in my perimeter.

What I find much harder is to disappoint the people who love Vue when they come up with an idea for it that they see as a great addition or new feature, and we have to tell them that their idea won鈥檛 make it into core (or one of our official support libraries).

As a maintainer of a popular project such as Vue, you get flooded with feature requests, both small and big, often great, sometimes silly, often useful, but also often not useful enough to a large enough percentage of the user base to justify the increase in file size and the additional code we then have to test and maintain. We do receive a lot of great suggestions and PRs, and we also accept/merge a lot of them, but many others, we don鈥檛.

And it鈥檚 just hard to tell someone that their idea won鈥檛 make it, even though we can relate and understand that this idea is very useful to that person. We have to prioritize, and that often means to say 鈥渘o鈥 to things people want.

Luckily, in most cases people are understanding and can accept that their need isn鈥檛 enough for feature X, so bad feelings or expressions of false entitlement, anger or similar negative reactions are rare.

Thank you guys for your work on Vue, your many side projects, and help in the community. With FB's move to React Fiber, have you given any thought towards implementing something similar? Are the concerns FB's attempting to address even applicable?

It's interesting because as far as I can tell, Fiber matters more in environments like ReactNative where the JS runtime talks asynchronously to the underlying native rendering engine. The implications are not as significant on the web. On the other hand, the current Fiber implementation is just "laying the groundwork for further experiments" - I'm also curious to see what concrete use cases can be built on top of it, before that, we don't see a strong need to implement something similar.

Also, technically, Vue's update system already processes component updates as discrete jobs in a scheduler, so instead of a complete rewrite we may be able to improve the current system to reap some of the benefits that surface from Fiber in the future.

Evan You: Why did you start Vue.js project? What was your initial thought? What problem were you trying to solve?

I answered this in more detail in an interview with Between the Wires:

With Weex or NativeScrict, we can make Vue a native solution.

But, will Vue.js team make a single native package ? (named "Vueative" ?)

Weex was adopted by the Apache Foundation, so it has already found an "official" OSS home. We will of course continue to collaborate and support their development and integration with Vue, but won't make this an official solution inside of the vuejs organisation.

Concerning Nativescript, to be honest I don't think we had time to discuss this in-depth. For now, we will let the community work on this and improve it. If it makes sense to integrate in in the future (and if the creator is willing), that is a possibility, but not on our todo-list.

We are also not actively planning to come up with a solution for native implementation of our own, that's not where our core compentence is right now, at least from what I can tell about our teams strenghts.

Personal opinion about the name suggestion: it's not clear how to pronounce it, so it probably would not get my vote. ;)

Vue.js is definitely mature. I see new upcoming challenges as heading toward definitive growth and more "React-ish" kind of moves tempting you.

What do you think it would take to stay true to your initial mission and values despite external forces pulling you in different directions?

Because I know you want to keep your independent style and approach. And that's awesome.

I think it helps that most team members are developers and designers who build things with Vue all day, for a wide variety of companies and uses cases. We are the community that's using Vue.

Hi Vue.js team ! I falled in love with vue-class-component and vue-property-decorator, and all my Vue projects are now using them. Now that class and property decorators are stage 2 at tc39, I was wondering if you plan to make an official template which use decorators (either ES6+Babel or Typescript).

vue-cli will receive a complete overhaul in the near future. It will use a more 'upgradable' approach to templates to you will be able to update the template and add more features to it like SSR, PWA, Typescript and more!

So there is a good change that there will be a class-centric template 'block' that you will be able to add to your application in a single command.

Note: there are also some TS upgrades coming that will make the Type System even better. You can take a look at the progress here:

Any thought about the debate on WordPress js.

I know @blakenewman and @yyx990803 have already posting theirs views and/or comments. But I would like to know what the other team members are thinking about it... and would like the Hashnode Community learn more about it.

I know a lot of WordPress developers who use Vue and love it. It鈥檚 different from the other options in that it scales down as well as it scales up. You can drop it in and start coding like jQuery, or use it to build a complex single-page applications or server-side rendered apps.

That seems very much in the WordPress philosophy to me. You can start a WordPress site without having to do much coding, then you can add in plugins, then configure those plugins, then build your own plugins and templates, etc. WordPress scales with their skills and Vue offers a similar learning path.

That said, no one knows the needs of WordPress like the WordPress team - there are always considerations outsiders like me aren鈥檛 aware of. So no matter what happens, I trust that they鈥檒l have weighed all the options and made the best decision for their community.

I know you asked for other opinions from other members. I will add that i think all the core team are on the same page, and will support the Wordpress team as much as we can.

We hope all the best for the team, and support any of there decisions they will make now and in the future. At the moment it is still early days, and it is unclear on the move they will commit too. If however they do switch to Vue as a default, we will find ways to embrace the Wordpress community and the team to ensure they get the best results.

As a WordPress developer/user myself, I'd be more than happy to see Vue integrated with WP at some level 鈥 project Guttenberg is definitely a good start. Whatever WP team's decision may be though, including possibly coming with an entirely framework-agnostic solution, we'll for sure be supporting it and offer help wherever we can.

Which, according to you, is the best resource (other than your own docs) to get started with Vue?

I have to get it out of the way: do read the docs. 馃槃

If something confuses you, open an issue, as we're constantly improving them. We generally hear that people can get through them and feel pretty confident with Vue in less than a day!

Now to answer your question, I can't pick just one, but here are some great options beyond the free stuff you might find while Googling. A few resources that I've heard great things about:

  • "Introduction to Vue.js" video course on Frontend Masters, by Sarah Drasner
  • "The Majesty of Vue.js" book, by Alex Kyriakidis
  • "Vue JS 2 - The Complete Guide" Udemy course, by Maximilian Schwarzm眉ller

What did you plan about mobile app ? I follow weex but documentation is a little obscure and i don't see lots of project using it in production (some chinese company but it's all). Did you think weex and his documentation are production ready ?

Else we have other alternatives with nativescript and vue (but still in progress), OnsenUI for not native apps ...

What is the best way for mobile apps with vuejs ?

Our plan regarding Weex and NativeScript Vue is to help writing documentations and improve the on-boarding experience. As you mentioned, there are a lot of hybrid solutions as well from the community!

Do you like the idea of build-only frameworks like Svelte? Would Vue.js ever go in this direction?

In its current form, Vue needs too much runtime for that to be possible. You would end up with a lot of duplicated code for each component.

Note that Vue is very light and is even smaller than jQuery, so it may not be worth the effort and the possible loss of features.

Hi there! Thank you for hosting this AMA!

Currently, each Vue component requires at most one root element. Are there any plans to allow multiple root elements in components?

This is true, currently Vue instances/component only accept one root node. This is one of the things that React Fiber brings, and is something we can possibly learn from. For now it is not on the agenda as it will require heavy changes, but is on our radar to look into.

I also believe having a single root node, is also a good thing. The component readability is clear and concise, and predictable.

It may be worth noting that Vue does support conditional root nodes, e.g. something like this will work just fine:

  <div v-if="loggedIn"></div>
  <div v-else></div>

...and functional components can also create multiple root nodes.

Thank you for answering!

With Vue releases named after anime titles, how many of you actually watches anime?

Not sure how many of us watch anime or read manga so I'll just go ahead and say I do (mostly read manga now) and wait for others to chime in :p

I mostly don't. :]

I know for a fact that Egoist and Evan are hardcore anime fans.

I do watch some anime and have read a little manga, though I'm not as well-watched as many others. Lately, I've been really enjoying Mushishi. 馃檪

Is there anyone else apart from Evan You maintaining the core of Vue.js?

Evan does do a lot of the maintaining with Vue core (, most of the other packages have a higher amount of contributions from the core team. However, i know it's on all the core teams agenda to become more involved in the core.

I would like to note that there is more and more contributions done by the public, which is awesome. There is also many large changes being made in the core such as improved TS support, that are not produced by Evan.

I would like to point out that we are using the 'Squash and Merge' feature on GitHub when merging PRs, so the commit count isn't very representative of the community contributions.

Definitely! For example, the multiple conditional root nodes on a template mentioned in another answer was one of my contributions. 馃檪

Many big features also go through a lot of discussion on GitHub or internally before they're implemented, regardless of who writes the final code.

Will it be a major shift in JS world when WordPress decides to choose Vue now that it has ditched React cause of all the license issues?

First, that's not a "when", but an "if", and a big one.

We are far from the only good option (winks at preact et. al.), so let's see how this all plays out ;)

that being said, of course this would be a big boost for the Vue community. But one thing to keep in mind is that this would foremost concern the backend - people can and will use whatever they want on the frontend, so we wont achieve world dominance (yet).

From what we can see, the WP team is very careful to try and find a solution that is highly adoptable for everyone interested in contributing or extending wordpress, so personally I suspect that they will take their time in finding something that fits that bill, and it might no necessarily be a plain-and-simple 1:1 adoption of any of the frameworks out there.

Beside Nuxt, what do you recommend for a static site generation?

Ream is a small framework similar to nuxt, but much less opinionated, and it also can generate static sites like nuxt. It's maintained by the fabulous @egoist, on of our core constributors and one of the most creative and productive contributors to the Vue ecosystem out there.

But for a static site, sometimes other tools, that don't rely on Vue SSR, as a good or even better fit. Our Website is done with Hexo, for example

If you don't need your site to have Vue components, you can use other tools like Hexo, Middleman, Hugo. If you want to use Vue component, I think Nuxt is the best solution out there to build a static site. You can, of course, build the generator yourself, it would be a nice way to learn SSR (

Thoughts on Mesut Ozil? #COYG

As a German: Great soccer-player! :)

What did you guys learn from your work on Vue and from contact with its userbase, be it on chats, meetups or consulting work? Was there anything you were expecting that didn't happen during last year of Vue growth or something that did happen, but wasn't expected?

One of my main areas of focus in the core team is user support, mainly on our own forum (, as well as on Twitter, SO and sometimes even reddit.

(Shoutout to our great community moderators on the forum volunteering their time to help us help the community with their questions - your efforts are highly apprechiated and the forum wouldn鈥檛 be the same without you!)

However, I want to take this question as an opportunity to say something about what you can learn from helping others:

For starters, you will learn a lot yourself, and you will do so faster and more in-depth than you would from reading tutorials or asking questions about your own problems - that was my personal experience when starting with Vue.

When I started out, I was actually looking for a frontend framework to pick up, and I was looking for something that was easy to get into - so naturally, I got hooked by Vue :) However, at the time I didn鈥檛 really have any projects to use it on, as I was (and still am) not a developer in my main job. But since I am a very curious person and always want to learn something, I started to play around with a few demos, tried to replicate stuff I found on github etc. And after a short while, I started answering questions on the Vue forum.

And the magical thing is this: When you try to solve other people鈥檚 problems, and try to explain how something actually works, and why it works that way, or why it makes more sense to do X instead of Y, you will very quickly find that many things that you thought you knew (because you used the feature once or read a blog post about it), you don鈥檛 actually know them, understand them. In trying to help others, you start looking up stuff in docs, blog posts, start to read the source of projects that you might not have read otherwise, and then have to translate your new-found knowledge into language that the other person can understand.

For me, this increased my in-depth knowledge of Vue (and also Javascript itself) drastically in a very short amount of time, compared to my advances when I tried to teach myself with tutorials.

So the message I want to give you, the readers with this story is: Next time you have some time, instead of reading blogpost No1001 about 鈥淗ow to create awesome feature everyone writes a blog post about鈥, go to our forum, or Stack Overflow, or the issue list of one of your favourite projects, and try to help out. And If you don鈥檛 know the answer, or are not sure, start investigating. Put some time into it. Try to provide the person having the problem with the best possible answer you can give - You will gain at least as much from this as the person you are helping, if not more.

It鈥檚 also very motivating and satisfying to help people out (at least for me), and I think it has something to do with how people are wired: I think many can relate when I say that we often are quick to help people we care about, and often do so with more passion and effort than we would put in when it was about our own problems.

So you can take advantage of this, and boost your own learning by helping others. It鈥檚 a win-win!

Using the opportunity, can you guys officially and honestly confirm or deny that Egoist is an artificial intelligence written by Evan to solve all Vue-related problems, one package a day? I know many people who are raising such suspicions, because of how active he is in the ecosystem and how high quality his packages are.

I can confirm Egoist is a real person, and not Evan.

I have similar suspicions, though I was unable to confirm them so far.

Another theory of mine is that egoist really is a group of people sharing the same personality, so who knows?

But to be serious, his output and creativity really is nothing short of amazing and he is a great source of inspiration to me.

Don't blow it please, now I have to tune the algorithm

Evan, while you are at it, please add a NSFW filter for anime tweets - I live in constant fear of my boss seeing underpants on my work screen.

What are your thoughts in mutable vs inmutable approaches to handle application state in fe frameworks ?

The potential problem with mutability is when the same piece of state could be mutated by different parts of your code over a period of time - this would make things difficult to reason about for sure. However, when you enforce a state management pattern such as Vuex (with strict mode on) on your shared state, the system essentially protects you from those scenarios by enforcing mutations to be synchronous and structured in a way that reflects the intention of the code. This achieves a similar end result of the immutable style Redux uses, both in terms of scalability and testability, while retaining the familiar state assigning syntax.

The reason Vuex sticks with a mutable style is largely tied to how Vue's reactivity system works. Dependency tracking works most efficiently when state is mutated instead of replaced by entirely new values. By using a mutable style, Vuex retains Vue's performance characteristics (accurate component update boundaries with minimal over-rendering).

An advantage the Redux has though, is that state snapshots are cheaper than Vuex's due to immutable + structure sharing by design.

There are also some nice characteristics about Redux reducers being pure functions, but (in my opinion) they don't manifest as being significantly advantageous in the majority of applications.

Using something like Immutable.js brings yet another layer of indirection and in some cases extra conversion cost between immutable wrappers and raw js values, so it's a tradeoff even for React users, and in my opinion not a good fit for Vue apps.

I try to follow Vue community close but so far I have yet to find a popular Vue package written by a woman. It's of course highly possible they are parts of larger teams or stay behind package names, but except for Sarah Drasner who makes high quality tutorials, courses and talks about Vue (and codes brilliant animations), we don't see women active in Vue community. What can we as fellow developers do to make the community more open for them?

First of all, I wouldn't be too sure about all of the authors being guys - many packages have authors that are not sporting a full name and profile pick to tell, so just keep that in mind.

That being said, the best thing we can do is promote females that publish something great, or contribute in other ways, like Sarah does with her tutorials, courses and articles. Spread the word on twitter, discord and other places suitable.

Sidenote: Sarah just joined us and will support our docs team with more and better examples, recipes and certainly some lines of code here and there ;)

Can I know what are your thoughts on Facebook's patents on VDOM (the most lucrative thing about Vue) and whether it'll affect the open-source community if Facebook decide to do something about it?

There is really no definitive answer to the patent question because nothing is certain until someone goes to court. But here are a few things to consider:

  • So far I haven't seen any evidence on FB actually holding a patent on the concept of VDOM. React was published in 2013 and if no related patents were filed before 2014 (1 year after public closure), everything becomes public domain.

  • If Facebook actually owns a patent on VDOM and uses it to sue users of Vue/Preact/Cycle (or, as I said in another answer, they most likely have a patent portfolio that allows them to sue you whenever they want), this will be what I call "OSS reputation suicide" - they are essentially violating the good will they've been promising, and will lose everything they've gained from OSS and drive off community members and even employers with good conscious. They will lose far more than what they gain and I believe they are smarter than that.

Not sure if these questions are best for here or another forum.

Question 1: Vue developer tools works amazing when working on small scale applications with simple mution paths, but anytime we try to use it in our complex mutation webapp it crashes instantly with the increase in mutations. Is there a plan to improve the performance of the dev tools?

Question 2: Vuex Plugin examples for sockets isnt extremely clear, especially if you are subscribing to multiple sockets and I have not been able to find an example of anyone else using plugins extensively. How would one best integrate with Sockets for vuex?

Hm, we haven't found a lot of problems with devtools even in big apps, but there are of course some scenarios where performance can become a problem, mostly with very large datasets or high frequency commits to the store, e.g. from a socket.

If that breaks the devtools for you, chances are it will also be problematic for your app's general performance, at least on slower devices. so it might be worthwhile to cache incoming socket messages in an array and do bulk commits with a throttled function.

Open a thread on the forum and we can discuss this further.

That also counts for the second questions, which I don't think I can answer here with the information provided.

Next year's VueConf will take place in London. Were there other alternatives, signaled by potential organizers? Are you aware of plans for other big Vue-related gigs, similar to VueConf or the New York meetings?

VueConf will be expanding its branding, to extend to multiple regions. This will enable us to support the communities around the world.

The new branding will be VueConf [Region], such as VueConf EU. There will also be announcements for the US and other regions soon. This will become the official brand for conferences.

Vue.js London ( is not a replacement for the VueConf. Although not an 'official' sponsored event, we will bring the same awesome value to the conference. We also welcome any other conferences to pop up, to support other communities.

My company has a big code-base (mainly a component library) written in Angular which we'd love to port to Vue but it's too much work to do it in one go.

Are there any plans for an official way to use Vue in existing AngularJS apps to slowly transition? There are a few tutorials and 'hacky' suggestions on the web but I think lots of people would make the jump if it was easier.

There's no official solution (or plans) for that, but you can use to progressively migrate an angular app to Vue. I know of a French company called Toucan Toco which is doing the migration but using a custom angular directives for Vue component I think. Akryum also shared these slides:

What I did personally with great success in a project of mine is to create a Vue app (using vue-cli and webpack template) alongside with the Angular app. Communication between the two apps was done via a global event bus (an empty Vue instance). To display a Vue component inside the Angular app, @linusborg's Portal Vue was utilized.

Any plans to improve TypeScript support and make it work out of the box with vue-cli

Yes, there are many interesting things happening in that world. We will be release 2.5 soon (early october estimate), this will improve the TS support.

We will be providing a migration guide, but most of the changes should not affect you as an end user. There may be upgrades needed to libraries that dig into the type layers a bit heavier. You can take a look at the github PR if you want to find more details.

I bet you've heard of MoonJS. What do you think about it? Are there ideas VueJS could benefit from like it did for Angular and React?

Yes, we have! The idea was pretty exciting because we thought, hey, that's what Preact is for React. But to me, Moon is not as close to Vue as Preact is to React in terms of API, and this is probably because it seems to have more features:

  • Moon doesn't proxy data, props, nor methods, you have to use this.get() to access things and this.callMethod to call a method
  • The reactivity isn't transparent: you have to set values with this.set
  • You can use moustaches ({{ }}) anywhere which is something we removed on purpose to promote the use of v-bind or its shorthand : which prevents the browser from parsing some attributes before they actually have a value (eg: the src attribute of an image)
  • Some naming is different (eg v-cloak = m-mask)

Of course, I imagine the author had to take into account the size limit and that's why he dropped some of features and API, to keep it fast and small.

It does have many other things like a routing solution (although its api is very different from vue-router), a global store, a cli, ...

Personally, I haven't used it yet but it could be fun to test it

I didn't see any extra feature we could benefit from but I don't know the project enough to be fair 馃檪 We can of course, always learn from somebody else code

To add to Eduardo's answer: While we've been learning from other projects like Angular and React, to be brutally honest, at the current state I don't think Moon offers much more than what Vue does, if at all. For example, one thing I noticed about Moon (correct me if I'm wrong) is the lack of filters. When I can't say we're big fans of filters (and filters in Vue are just functions anyway) there are certain cases where filters do shine. SFC is also something I don't see supported by Moon.

What is a great starting point to study the Vue.js code? I would really like to study the library code but I often find myself in a situation where I don't know where to look first, what files should I look for to begin with. Do you have any tips for this?

You can start looking at the test suite and try improving it. It's a great way to learn more about the API and the internals!

Just wanna say, you all are awesome! The team answers the question so quick and in detail in the vue.js forum. Especially Thorsten, because he answered most of my questions :) Thanks!

Happy to help :)

If you find some free time, just answer a question yourself every once in a while and we are even ;)

Also: A big shoutout and "thank you" to all the other great people putting time and effort in helping other on the forum, on discord and wherever else!

Thorsten is a machine. Every time I've tried to meet him in real life, something comes up, so I'm not even 100% sure he's human. I can confirm he's 100% German though. 馃槢

I'm open to a skype session to prove my human-ness if that's necessary, chis ;)

Good point Thorsten, sure will love to give back, will keep on problems I can help and skype still not trustable can be anything playing on webcam stream ;)

I'm just a-week-old-Vue-developer ;) I mainly code using ember.js! I feel vuejs as a combination of various frameworks (react - say, flux architecture, angular - say, HTML attribute kind of things and ember - say, computed properties ). Is that true that Vue was born by integrating all the pros of various frameworks?

I believe this to be true, it certainly evolved with the learnings from other frameworks/libraries. As do many other frameworks, the great thing about OSS is that we can learn from each other to make the web a better platform to develop on.

Hi ! Will VUEJS move to typescript (like NG2 does) ?

Vue will not 'move' to Typescript, but the 2.5 release (in the beginning of October) will improve Typescript support a lot.

We are bringing updates for TS in Vue 2.5, this will make it even better and easier for you to use TypeScript:

Thkx for answer... We didnt want to move NG2 cause of TS, so it's a good news that VueJS is not going to impose it :)

After the official release of vue-test-utils, will there be a separate official testing guide similar to SSR one? I know the new package comes with its own documentation, but is there any plan for a broader guide for testing?

This will be happening, we are currently improving the documentation.

For the 2.5 release there will be a full guide on unit testing, amongst other things such as improved TypeScript typing support.

We are aiming release of 2.5 for the beginning of October.

I have really loved learning Vue this year, I am new to it. I come from a backend development background so don't have a lot of the front-end expertise as a lot of other folk. A challenge I have found is making decisions in design and frameworks that have big impact on your project. Once you are committed there is a lot of effort to change For example I am using Vue with Nuxt and Vuetify. I want to see how SSR behaves and I want a GUI framework that is responsive and supports this design choice. But that is just one of many options.

What is the most common / recommended setup for Vue projects?

One of my concerns is for these other frameworks as well. I don't think Vue is going anywhere but who says Vuetify is going to be around in a year or maybe something new would be the next big thing.

Any suggestions on what we can do to best decide on what core components / frameworks to use?

thanks for all the great work you guys do by the way.

Thanks for your feedback! We are currently working on a Cookbook that will feature recommended libraries and code examples for several use cases. In the mean time, you can ask on the forum.

Hey, Why Vue doesn't use custom tags (like some other frameworks) and and prefers changing it into div or any other valid tag ? (actually I'm fan of this method) And my other q : Since I'm Ember dev too, Is there any plan to create anything like EmberData in Vue too? cause that's awesome and really helps in big projects.

Custom tag names in the templates are treated as components. If the corresponding component is not found, Vue will warn you. It would be difficult to get around this IMHO.

Thanks, but I meant why Vue does not use that custom tag name in build process, is it because of better support in old browsers? or something similar. Any thought on my second question ?

I think you are talking about implementations of the web components standard, and libraries like polymer that use it.

Currently web components are an emerging standard and we don't feel that the case is settled enough to commit to it. Also, there's still open questions about how certain features of Vue could be implemented in web components as well as we have them in Vue itself.

But with vue-custom-element, you can transform Vue components into web components, so it's possible if you really want to.

As someone that is becoming very familiar with VueJS as a developer, I would like to also start contributing.

What parts of the Vue framework would you recommend would be the easiest to learn from?

I'd suggest starting with the tests. While Vue's test coverage is 100%, I'm sure there's room for improvement there. Reading through the test cases is also an excellent way to learn about Vue's internals and APIs.

Make sure to read the Contributing Guide, especially the section on project structure. It's also necessary to familiarize yourself with the development tools used (Flow, rollup, webpack, jasmine, karma...)

I also have plans for an in-depth guide on how to read and understand Vue's source code, but that will take some time to finish. :)

Vue is awesome, and our project is considering using it. However, the recently Facebook React Patent issue has raised our attention, does Vue use any patent that holds by Facebook? Here is an extend read about the BSD+Patent license, where the author stats using Vue and Preact may be riskier than using React:

1) "Don't use Vue for large-scale projects and also if you have a large team Angular is better.", do you agree with this?

2) How about functional programming in Vue?

3) What a beautiful logo Vue has :)

1) Opinion: I don't think it's true. Vue is fully featured, has all the tools and official library to create very large applications. More options are coming like a better ESLint plugin to enforce best practices. Personally, I worked on one project that counted 200+ components and counting.

2) You can use functional programming, especially in computed properties and when using Vuex.

3) Evan's Illustrator skills at work!

Reversed order:

3) Thank you, we have more logo's on the way for the supporting ecosystem. 2) With 12 lines of code you can make Vue functional: 1) No, Vue is being used by large enterprise companies for large projects. So by that factor, it works. Like React, Angular and others libraries i can't see any issues with scaling. With large project the main factor is keeping code constistant and clean.

Vue is known for it's abilitity to be simple and lean, so that in itself massively helps scale Vue applications.

I print data and the result is [ob: Observer]锛孴here's data in there, but you can't get it out

This is a little hard to answer, we would need more description and an example. It could be how your browser is logging the object. Could you create a reproduction here:

I assume your question is how to log data to the console and read it?

The issue you experience is due to Vue's Reactivity system, which extends objects with getter and setter methods to track changes and react to them.

However, When I log something to the console, it's usually quite readable. If you really need a plain output, you can use JSON.parse/stringify to create fresh, plain object.

I demo both things here:

Also, we recommend to use your devtools in Chrome or Firefox to inspect your component's data - it formats it nicely for you.

I like chocolate, so I'm really curious to know, do you have any plans for Vue-flavoured chocolate?

Interesting idea! What would it taste like? 馃槃

During the summer, the official chat recommendation was moved from Gitter to new Discord server (, its 7k users with a peak of 400+ online at the moment. Are you satisfied with the change so far? What made you to consider it?

I personally am! I think the ux of discord is just far superior to gitter. Discord really feel super responsive. Egoist created the server, I'm not sure who proposed it but I think some of us were already using discord for development and were enjoying it much

I think discord is great, I am a late comer to using discord. But with my brief experience it looks to me that it's doing better at it's job compared to that of

What's your opinion on corporations enforcing less open licenses on their Open Source projects? e.g. Facebook's BSD license

Is this justified?

Facebook may have its (good) reasons for that, even more so being a big company that may want to protect itself from others (as patent fights in courts are very costly).

Which method do you prefer for write and manage CSS? Vue's own Scoped styles (which is similar to CSS Modules), or any other CSS-in-js tool?

The answers are going to be very different depending on personal preferences 馃槀 but mine is BEM for libs and sometimes apps, scoped styles for apps component so I don't have to worry too much about it affecting the rest of the app

Not, you can also use CSS Modules:

As Eduardo mentioned it comes down to preference, however the inbuilt tools are very powerful. It's down to the team/personal preference. There is also cases where one is better that the other, so you can use them as required in your application.

Whats your plan with competing with other frameworks?

We don't like to say that we are competing. Every framework/library has it's use case. However, we do like to say we always strive to improve, and learn from the surrounding ecosystems.

There's no plans to "compete". We have friendly relations with maintainers and contributors of many of the other popular framework, and we strongly believe that we have just as much to learn from them as they can hopefully learn from us.

It's not a game we want to "win" - we just want to provide a useful tool for people to work with and enjoy, and we also believe that the most important thing to consider is "the right tool for the right job" - and there are certainly jobs that other frameworks are just as well, or better suited to do that Vue.

Vue.js has removed some of the core functionalities like Filters in Vue2.0.

  1. Would not be it really handy and helpful for developers to have them?

  2. What's the trade-off for Vue.js between features in framework vs size of the framework(which makes it pretty fast)?

Except that filters are still there ;)

We do actually support filters in Vue 2. We added them back for v-bind and moustache interpolations. If you want to read the long discussions we have about this, you should be able to find the issue on Github quite easily by searching filters 2.0

At the moment, we're very careful about adding new features, we take into account the amount of code needed to make it work because it means a bigger lib and also more code to maintain. We also think about how it affects existing features. For example, we try to avoid adding multiple ways of achieving the exact same simple thing because it may be confusing for newcomers. So we try to keep Vue easy to use but powerful by providing warnings whenever possible (that are stripped off in production mode) and by keeping the API surface small. Although it may be a bit too large for v2 at the moment

We have production apps using angular 1 as well as ng2 with typescript. Is it relatively straightforward to build new features with vue and have them work in our apps. Are there known/significant integration and build hurdles for hybrid vue usage in angular apps?

Looking at the answer '...the hardest part is telling people that it (feature) won't make it into core', what types of feature requests are common that would not make it into core?

We quite often receive ideas about additions to the template language that make some things a bit easier, save some keystrokes, or add a bit of nice "magic".

Most of the time, we decline those requests because we want to keep the template-specific syntax (which people have to learn and memorize) small, and rely on Javascript expressions wherever possible.

This keeps API surface small and keeps the template compiler efficient and easier to maintain.

I would say right now, very small syntax sugar feature requests are the most rejected ones.

Is Vue.js a good project for open source newbs to contribute to? I am becoming more and more familiar with it, and would love to contribute. Any pointers?

I believe Vue's ecosystem is broad enough for every enthusiastic developer to contribute their part. Depends on how familiar you are with Vue, you can choose to contribute to the core Vue.js framework itself as a builder, or the website as a user, among others.

Somewhat related: How to Contribute to Open Source, an excellent guide by GitHub themselves

The best way to contribute to any project is to look at issues and check for bugs. Some of them are simple. Sometimes projects have a special label for issues that are good as a first-time contribution. They're usually easier than other bugs and they may be comments with some pointers Also, a very good way to contribute to a project is by helping with the docs. It may sound meaningless but docs are super important and you really learn much by helping out in docs. I know Chris would love some help at vuejs/ 馃槃

Are there plans to improve the user experience of vue-cli. It doesn't have the same "ease-of-use" as the rest of things associated with officially supported Vue repos. Will additional focus be given to improving it from a user flow perspective.

In fact, yes. We just started a discussion about Version 3.0 of vue-cli, and we are planning to change it quite heavily, while keeping the current, boilerplate-generator type functionalilty in place as an option.

You can check out and participate in the dicsussion here:


I'm checking again on using Vue in production for a client. The upstream Vue version deliberately fails mounting on the body element (el === document.body || el === document.documentElement && fail or something like that).

Yes, Vue 2.0 does replace the element it is mounted on, but there is nothing DOM uncompliant in replacing the body, even while this will often fail due to browsers trying to close runaway tags, or 3rd party code doing the same.

I insist on re-enabling mounting on the body element as a very useful thing. When trying to do SEO friendly SSR on our previous projects with vue 1.x, we were very pleased how well it worked with routing. On client-side, routed body element worked like magic to automate things like event listener attachment, setting ARIA attributes according to page content, lang or text direction properties, or changing contextmenu attribute when it was still a thing.

I tried to remove the check and use vue 2 on our past projects, and so far, nothing breaks. The few 3rd party scripts that rewrite the body as a string have to be removed and rewritten for use with an SPA anyways.

Dan Abramov of React did an excellent job explaining why you shouldn't render/mount to body:

How can we educate software developers to be more inclusive and participate in open source?

I think currently the OSS community is maturing across the board, there are many great devs out there that have done a fantastic job at promoting the value of OSS.

It can however be difficult, and lots of our time is unpaid and completely voluntary. So the main thing i can say is be nice, there is nothing more frustrating than being had a go at.

Building a friendly community and being friendly in that community, is key in my opinion.

Over the last 6 months or so, I've been creating proof-of-concepts for migrating some of my company's large projects to Vue. In doing that, I've come up with some assets/enhancements that are useful for large projects I'd love to feed back upstream (in particular, enhancements to the webpack vue-cli template for building with more configurability, and also a Cordova/Vue template). Assuming you might be interested, what would be the best way to get that in front of you guys and start the conversation?

Sounds great! 馃檪 A good place to start might be this discussion making plans for Vue CLI 3.0. Or on the webpack template, you could open an issue to discuss a specific feature/enhancement.

That's pretty cool to hear! I hope, you can help us improve the existing The best way is to either open small PR for every improvement that you have or open an issue listing the improvements that you want to make so we can discuss it

Thanks for the interest to contribute back! We are in fact planning an upgrade for vue-cli and we'd love your input here:

What does your workspace look like? Also, what editors and applications do you prefer?

I can't tell which one of Atom and VS Code I like the most.

I'll answer as if this question for myself (I hope the question is not just for Evan, otherwise I'll look like an idiot 馃槀) I don't have a regular workspace as I just move to different desktops when I need to code at work. The only constant is my 13" laptop. I use Spacemacs (Emacs + Vim) as my editor and from time to time Vim in the console These days, all we need is a Browser 馃榿. But, I do use slack and discord a lot. About native applications, I really like 1Password and Alfred

I use VSCode alot of the time

My workplace looks like a house, because I'm a (mostly remote) consultant. 馃槃 I use VS Code personally, but whatever makes you productive is great!

Seemingly odd question, but...what exactly was the train of events that led to the creation of Vue?

In case Evan doesn't get around to answer this personally, he talked about this in this interview:

Hi all, fantastic work you have done with Vue.js so far. I would like to know when the vue-test-utils package will be released. As it would be a definitive must-have for a wider adoption in the company I work for (Orange not to name it). We have a test driven development philosophy for many services and it would help us a lot ! Keep Vue.js as cool as it already is !

With Vue 2.5, which is aimed for end September to early October. We will also provide full documentation around the unit testing subject.

We are currently in the final code review and working on the guide to go with it. We plan on releasing it with Vue 2.5, which we currently think will be released in the beginning of october.

A follow up on my previous question that Phan answered,

Phan, do you think I am not aware of the issue with too much code always competing for the document.body? Dan Abramov gives amateurish reasoning on the issue in the article you linked. Do not read his stuff.

A lot of shoddy written third party code competes for document.body or the body sting content, and you always have to rewrite code that runs into conflict while doing so invariably of how you use Vue on the page.

In our case we need to do that. We have complete control over 3rd party code, and we rewrite stuff that misbehaves.

How to get in touch with you guys outside of AMA?

It may also be nice to know your use case and why wish so much to use the body?

In our case we need to do that. We have complete control over 3rd party code, and we rewrite stuff that misbehaves.

If that's the case, you are free and certainly able to fork Vue and remove the code that keeps it from mounting to body, or even better, submit a well-tested PR on github, along with a guide on how to deal with the problems of 3rd party-code competing for body.

We however have to focus our limited resources on supporting the needs of the larger community. As mounting to body can create problems that, as you explained, have to be worked around in 3rd-party code, we don't feel like it's a good idea to implement it as it will certainly introduce subtle bugs for many of our users that have to rely on 3rd party code they can't control.

As a sidenote, a little less agressive tone would help the conversation. And dan is awesome :)

Why we need access to body? First thing, it is programmatic access to setting and unsetting event handlers. It was extremely convenient to do it from the markup on a hash-routed website with a lot of views, especially if you want to map keyboard input for each route/view.

Another indispensable use case was to handle setting properties and hints for different screen readers. Some screen readers or accessibility tools effectively have their own mark-up formats, and dom addons, so effectively you have to develop a website for a certain browser set, AND, a specific screen reader.

Being able to programmatically set classes, lang, dir, and metadata properties (SEO meta, hints for ecommerce search engines) with router mounted on body was quite convenient too.

Finally, having document.body DOM object being rewritten from Vue's DOM also worked well with routable sites where a view/route has a code that does something to the body DOM object that is specific to that route AND/OR a reactive data in it. I'd say, this is the most hard thing to implement when the upstream code from Vue and 3rd party Vue modules has no awareness of such possibility.

Although i don't recommend overwriting the body, you can do something like this.

You could also get the innerHTML of the body to replace the body as is.

Hacktoberfest is starting soon (Link: Are there any plans to integrate this event into the vue ecosystem? Last year there was a special label 'hacktoberfest' for issues to participate in this event.

This is a nice idea, we will look into it :)