I am Evan You. Ask me anything.

Evan You is the author of Vue.js and previously he used to work for Meteor and Google.

Vue.js is a library for building interactive web interfaces. The goal of Vue.js is to provide the benefits of reactive data binding and composable view components with an API that is as simple as possible.

Vue.js itself is not a full-blown framework - it is focused on the view layer only. It is therefore very easy to pick up and to integrate with other libraries or existing projects. On the other hand, when used in combination with proper tooling and supporting libraries, Vue.js is also perfectly capable of powering sophisticated Single-Page Applications.

Shoot any questions you want Evan to answer!

Ask a Question

38 discussions

How do you manage building and supporting a successful library outside of your day job? Have you considered having a company sponsor your development work?

It does takes a lot of time and effort - I think during the 1.0 release process I worked until 1~2am almost every day. But I guess the biggest reason is because I am passionate about it so I enjoy working on it most of the time.

I definitely hope some company would sponsor me so that I can work on Vue fulltime - in fact I just recently started a Patreon campaign: https://www.patreon.com/evanyou

If any company wants to discuss some custom sponsorship arrangement, I'm also happy to talk :)

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

Looking over the list of contributors on GitHub, it looks like 99% of the work is you. Have you thought about the ongoing governance of the project if you get hit by a bus / take a demanding job / loose interest / etc? Is there a logical successor?

Yes, this is indeed a problem I have been thinking about lately, especially as the scope of the project grows. However, there are already numerous passionate users who are contributing occasionally - what I need to do is probably empower them and give them more incentive to contribute. That's why I just started an open call for collaborators and already received 30+ applications so far. I'm hoping to build a team so that it's no longer just me :)

BTW if anyone is interested, here's the application link: https://docs.google.com/forms/d/1SgDgKZqyivEf5xl0EOWNfs68Xy3f4oBzLXIlwlS0BIs/viewform

Reply to this…

What is you typically day like? How do you manage your work and open source?

I worked remotely for Meteor, so my day is usually quite flexible. I don't really have a strict working schedule, and I mostly work by picking off items from my todolists/inboxes. We tracked work stuff in Asana and I tracked personal stuff in Google Keep, and I also use Google Inbox to treat GitHub emails like a todolist. So I'd pick a task, focus on it until it's done, then enter the next. It's kinda like unrolling a callstack ;)

Reply to this…

Little personal. What happened to meteor? :) What are future plans? Is your newborn baby girl or boy? :)

Show all replies

Thanks for the answer! :)

Reply to this…

Hi Evan.. What're your thoughts on unidirectional data flow and flux architecture? The React world and front-end developers are growing crazy about it. Wondering what are your thoughts on this.

I think the idea behind Flux/unidirectional data flow is actually simple and is a natural way to manage shared state between view components. But the original description/implementation from Facebook made it more complex than necessary, which is why there came so many different flavors of flux implementations.

The primary problem that Flux solves is shared state. Without a mechanism to hold shared state, we naturally tend to store state inside view components. We would then often find state being scattered across view components and resort to two-way binding or cross-component communication to synchronize the state between components. The problem with that these synchronization attempts makes reasoning about state changes very hard. With Flux, because the only way to affect shared state is by dispatching actions, this ensures all changes to the state are trackable, thus making the data flow much easier to understand.

Notice that the above explanation has nothing to do with what view layer you are using. The same principles can be applied equally well to both React and Vue (or any other declarative view layers). For example, it's possible to use Redux with Vue via simple bindings such as revue. But in fact Vue now has its own Flux-inspired state management solution, Vuex.

Vuex is heavily inspired by Redux, but with some design tradeoffs to focus on simplicity and compatibility with Vue. It's also hot-reloadable, and supports time-travel debugging via vue-devtools, and it takes full advantage of Vue's reactivity system to ensure the performance is optimized by default.

Reply to this…

Load more responses