Ask anything to Vue.js Team

Held on 20 September 2017, 5:00 pm

Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. It is designed to be incrementally adoptable, with the ability to scale between just a library and a full-feature framework, depending on your use case.

Ask Vue.js Team about:

  • Using Vue.js
  • Contributing to code base
  • Vue.js roadblock
  • JavaScript ecosystem
  • General Programming advice

Hosted by:

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.

Comments (185)

Kunal Varma's photo

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 🙌

Evan You's photo

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.

Duane Rivera's photo

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?

Evan You's photo

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.

gusto's photo

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?

Show +1 replies
Evan You's photo

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.

Hanson's photo

I still use version 2 and works great, for example on Tempmailo.

Eduar Tua's photo

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?

Show +2 replies
Blake Newman's photo

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.

Blake Newman's photo

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.

Eric McCormick's photo

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

Guillaume Chau's photo

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!

Evan You's photo

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 :)

Richard Onsman's photo

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

Thorsten Lünborg's photo

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

Why would you not feel a need for it? jQuery’s 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’s $ref feature would allow you to do this without any DOM query at all)

Concerning animations, it’s worth learning how to use CSS transitions and animations (with or without using Vue’s <transition> for them), you often don’t 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’s 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’t find a good Vue plugin for, there’s 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:

eron's photo

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

Anthony Gore's photo

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

Thorsten Lünborg's photo

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’s fading out.

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

But in the meantime there’s 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:

gusto's photo

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?

Guillaume Chau's photo

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.

Nathan Reyes's photo

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.

Thorsten Lünborg's photo

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

Sure, you often find people on twitter who might say something that’s incorrect, wether it’s out of ignorance, misunderstanding or similar circumstances (don’t like templates? look, we have JSX, too!) - but those voices aren’t 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’t 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’t.

And it’s just hard to tell someone that their idea won’t 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 “no” to things people want.

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

Michel EDIGHOFFER's photo

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

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

Thorsten Lünborg's photo

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. ;)

Denny's photo

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?

Evan You's photo

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.

Richard Onsman's photo

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

Evan You's photo

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

ric0's photo

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.

Chris Fritz's photo

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.

Edouard Duplessis's photo

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.

Show +1 replies
Blake Newman's photo

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.

Phan An's photo

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.

Sylvain Pollet-Villard's photo

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).

Guillaume Chau's photo

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.

Blake Newman's photo

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:

Saif Al Falah's photo

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

Chris Fritz's photo

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
nicolasb's photo

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 ?

Guillaume Chau's photo

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!

Stephan de Vries's photo

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?

Show +2 replies
Thorsten Lünborg's photo

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

Stephan de Vries's photo

Thank you for answering!

Anthony Gore's photo

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

Guillaume Chau's photo

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.

gusto's photo

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

Show +2 replies
Phan An's photo

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

Chris Fritz's photo

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. 🙂

Estevan Montoya's photo

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

Thorsten Lünborg's photo

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

Eduardo San Martin Morote's photo

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 (

Vinayak Kulkarni's photo

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?

Thorsten Lünborg's photo

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.

gusto's photo

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.

Show +2 replies
Evan You's photo

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

Thorsten Lünborg's photo

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.

Vinayak Kulkarni's photo

Thoughts on Mesut Ozil? #COYG

Thorsten Lünborg's photo

As a German: Great soccer-player! :)

gusto's photo

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?

Thorsten Lünborg's photo

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’t 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’t 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’s 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’t 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 “How 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’t 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’s 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’s a win-win!

Alex Jover's photo

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

Show +1 replies
Guillaume Chau's photo

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.

Chris Fritz's photo

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.

gusto's photo

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?

Blake Newman's photo

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.

Greg Royan's photo

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?

Thorsten Lünborg's photo

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.

gusto's photo

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?

Thorsten Lünborg's photo

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 ;)

Vinayak Kulkarni's photo

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?

Evan You's photo

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.

Diego Castaño's photo

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

Evan You's photo

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.

Jon Hobbs-Smith's photo

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.

Eduardo San Martin Morote's photo

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:

Phan An's photo

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.

Haris khan's photo

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!

Show +2 replies
Thorsten Lünborg's photo

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

Haris khan's photo

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 ;)

Rémi Vanrenterghem's photo

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?

Eduardo San Martin Morote's photo

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

Phan An's photo

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.

Wuelber Castillo's photo

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?

Guillaume Chau's photo

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!

Markus Lanthaler's photo

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

Blake Newman's photo

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.

Mhe's photo

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 :)

Guillaume Chau's photo

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!

Blake Newman's photo

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.

Gokul Kathirvel's photo

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?

Blake Newman's photo

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.

Alex Scott's photo

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?

Phan An's photo

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.

Evan You's photo

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. :)

Ross Mahony's photo

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.

Guillaume Chau's photo

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.

Abner Chou's photo

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:

powpowpow's photo

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

Blake Newman's photo

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:

Thorsten Lünborg's photo

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.

Hosein's photo

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.

Show +1 replies
Hosein's photo

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 ?

Thorsten Lünborg's photo

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.

gusto's photo

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?

Blake Newman's photo

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.

Sébastien ROUL's photo

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

Show +1 replies
Blake Newman's photo

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

Sébastien ROUL's photo

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 :)

gusto's photo

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?

Eduardo San Martin Morote's photo

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

Blake Newman's photo

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

Stefan Buhrmester's photo

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

Chris Fritz's photo

Interesting idea! What would it taste like? 😄

The Jared Wilcurt's photo

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.

Thorsten Lünborg's photo

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:

Kevin Peters's photo

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.

Blake Newman's photo

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