so strange muhammad. btw do you have wiki for yourself?

When Angular 2 was first announced, I actually thought - wow, this looks a lot more like Vue than Angular 1!

I think Angular 2 has improved a lot in terms of usability, but obviously still not as simple as Vue ;) In particular, you'd have to use TypeScript to get the best possible dev experience, it's great for people who like TypeScript but may not be that approachable for others.

Perf wise Angular 2 is very impressive - but in my opinion not significant enough to make it a decisive factor when choosing between frameworks.

Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it.

-- Steve Jobs

I think they are definitely still useful, even with Vuex because vuex getters must be pure and you still need computed properties to compute values that depend on component local state. Also Vuex is not going to be a required part to use Vue.

I actually started Vue before I joined Meteor, while I was still at Google Creative Lab. At that time React hadn't caught on, and Angular 1 was still al the rage. It started out as an experiment with this idea of making POJOs reactive for data binding (so far I believe Vue is still the only one that implements this reliably).

We didn't really figure out what to do with Vue in relation to Meteor - the company didn't really seem to be interested in it. I once proposed to work more on Vue and make it an official integrated view layer for Meteor, but the founders didn't like that idea.

Eventually Blaze is being phased out and the framework is essentially moving towards React. I can see that as a reasonable bet from a business perspective, but for me personally it definitely was demotivating.

• Machine: Macbook Pro 15'
• Editor: Sublime Text 3 w/ Material Theme
• Terminal: Iterm2
• Keyboard: I've tried many mechanical keyboards and even topres, but always - ended up going back to the Apple bluetooth keyboard ;)
• Productivity: I use Google Inbox as my GitHub issue todolist and keep track of other things in Google Keep.

Also, many people have asked about what did I use to create those diagrams on vuejs.org - those are hand-drawn with Adobe Illustrator :)

The release notes records all changes: https://github.com/vuejs/vuex/releases

Vuex is now at 0.6.2 and I think it has reached a pretty stable state. It is now used in vue-devtools itself (meta!), and the next release will likely be 1.0.

Some explanation on how the versions work in relation to breaking changes: when Vuex was at 0.2.0, it was always labeled unstable. Per semver, pre 1.0 versions can also break anytime, and the convention is if you see a minor digit bump, there is likely something breaking. When using npm, a version range like ^0.2.0 ensures you'd never get 0.3 or 0.4 when installing it.

The sad truth is for a lot of enterprises, their criteria for picking React/Angular is first because Facebook/Google is behind them. Their choices in turn affect the job market and it's a marketing advantage Vue simply doesn't have.

However, I believe Vue can compete with any major frameworks out there technically, and the advantage of Vue is its intuitiveness of the API and how easy it is to onboard a new dev to the team. I think Vue's current growth is primarily coming from individual developers and small teams, and there's still some marketing work to be done to make it more "adoptable" from an enterprise perspective.

I have messed around with paring up Vue with RethinkDB for a reactive stack, but at this moment there's enough work on the frontend alone, and also because Vue's beauty is that it works with any backend, so I'm probably not going that route any time soon.

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: docs.google.com/forms/d/1SgDgKZqyivEf5xl0EOWNfs68…

That's the next item on my todolist :)

You can refer to my answer to the flux-related question above regarding Vuex - it's a state management solution, and I believe it's going to be a critical piece if you want to build large-scale applications with Vue.

The latest vue-devtools already works with Vuex (with time travel):

I don't foresee a major release in the near term - but 1.1 will likely see some improvements to the current transition system to make it even more useful.

For the ecosystem, the next step is a new release for vue-router and an example of how it is supposed to work with vuex. After that, server-side rendering and test utils both seems like good ideas to tackle.

If I really do run out of ideas, I might try vue-native ;)

My long term vision for the project now is to make it a progressive framework: starting with a simple view layer as the core, with incrementally adoptable tools and libraries that enables large and ambitious applications. I want to make great ideas in web development accessible to as many people as possible.

So yes, I've left Meteor. This is a combination of quite a few things:

• Meteor as a framework is now front-end agnostic (which makes the frontend work mostly just integrating React/Angular) and the company doesn't seem interested in supporting Vue strategically.

• Meteor as a company is now primarily positioned as a PaaS (because Galaxy is currently its primary revenue source), and the focus of the company has a increasingly smaller overlap with my technical interest.

• Vue is growing faster than I thought.

I don't have a very clear plan at the moment, just exploring the possibilities of working on Vue fulltime while focusing on the baby. Oh and it's a boy :)

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

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.

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

The official guide :)

I spent a lot of time on it. Read it through and you're basically good to go.

If you prefer videos, the Laracasts series is probably the best starting point.

Coligo.io also has some nice tutorials.

Finally, more resources can be found at awesome-vue.

I'd say Vue is definitely easier to jump into than React, especially if you come from a traditional web development background (started with HTML/CSS/JS), because Vue components embrace what you already know while React tends to shove them away as lower level details and abstract over everything in JavaScript. That said, your mileage may vary. The interesting thing is that when you get into advanced level, there's in fact a lot of shared knowledge, such as build tools (webpack, babel, npm scripts) and state management (flux, redux, vuex).