FRONT-END DEVELOPMENT SERVICES

There are a few reasons to use Vue over Angular, although they might not apply for everyone:
Vue.js is a more flexible, less opinionated solution. That allows you to structure your app the way you want it to be, instead of being forced to do everything the Angular way. It’s only an interface layer so you can use it as a light feature in pages instead of a full blown SPA. It gives you bigger room to mix and match with other libraries, but you are also responsible for making more architectural decisions. For example, Vue.js’ core doesn’t come with routing or ajax functionalities by default, and usually assumes you are building the application using an external module bundler. This is probably the most important distinction.
Vue.js is much simpler than Angular, both in terms of API and design. You can learn almost everything about it really fast and get productive.
Vue.js has better performance and is much, much easier to optimize, because it doesn’t use dirty checking. Angular gets slow when there are a lot of watchers, because every time anything in the scope changes, all these watchers need to be re-evaluated again. Also, the digest cycle may have to run multiple times to “stabilize” if some watcher triggers another update. Angular users often have to resort to esoteric techniques to get around the digest cycle, and in some situations there’s simply no way to optimize a scope with a large amount of watchers. Vue.js doesn’t suffer from this at all because it uses a transparent dependency-tracking observing system with async queueing - all changes trigger independently unless they have explicit dependency relationships. The only optimization hint you’ll ever need is the track-by param on v-repeat lists.
Vue.js has a clearer separation between directives and components. Directives are meant to encapsulate DOM manipulations only, while Components stand for a self-contained unit that has its own view and data logic. In Angular there’s a lot of confusion between the two. But also note that Vue.js is a relatively young project, while Angular is battle-proven, Google-sponsored, and has a larger community.

React and Vue.js do have some similarity in that they both provide reactive & composable View components. However the internal implementation is fundamentally different. React is built upon a virtual DOM - an in-memory representation of what the actual DOM should look like. Data in React is largely immutable and DOM manipulations are calculated via diffing. On the contrary data in Vue.js is mutable and stateful by default, and changes are triggered through events. Instead of a virtual DOM, Vue.js uses the actual DOM as the template and keeps references to actual nodes for data bindings.
The virtual-DOM approach provides a functional way to describe your view at any point of time, which is really nice. Because it doesn’t use observables and re-renders the entire app on every update, the view is by definition guaranteed to be in sync with the data. It also opens up possibilities to isomorphic JavaScript applications.
Overall I’m a big fan of React’s design philosophy myself. But one issue with React (or JSX) is that your render function often involves a lot of logic, and ends up looking more like a piece of program (which in fact it is) rather than a visual representation of the interface. For some developers this is a bonus, but for designer/developer hybrids like me, having a template makes it much easier to think visually about the design and CSS. JSX mixed with JavaScript logic breaks that visual model I need to map the code to the design. In contrast, Vue.js pays the cost of a lightweight DSL (directives) so that we have a visually scannable template and with logic encapsulated into directives and filters.
Another issue with React is that because DOM updates are completely delegated to the Virtual DOM, it’s a bit tricky when you actually want to control the DOM yourself (although theoretically you can, you’d be essentially working against the library when you do that). For applications that needs ad-hoc custom DOM manipulations, this can become a pretty annoying restriction. On this front, Vue.js allows for more flexibility and there are multiple FWA/Awwwards winning sites built with Vue.js.

Polymer is yet another Google-sponsored project and in fact was a source of inspiration for Vue.js as well. Vue.js’ components can be loosely compared to Polymer’s custom elements, and both provide a very similar development style. The biggest difference is that Polymer is built upon the latest Web Components features, and requires non-trivial polyfills to work (with degraded performance) in browsers that don’t support those features natively. In contrast, Vue.js works without any dependencies down to IE9.
Also, in Polymer 1.0 the team has really made its data-binding system very limited in order to compensate for the performance. For example, the only expressions supported in Polymer templates are the boolean negation and single method calls. Its computed property implementation is also not very flexible.
Finally, when deploying to production, Polymer elements need to be bundled via a Polymer-specific tool called vulcanizer. In comparison, single file Vue components can leverage everything the Webpack ecosystem has to offer, and thus you can easily use ES6 and any CSS pre-processors you want in your Vue components.

First, Vue provides a cleaner syntax in getting and setting VM properties.
On a higher level, Vue differs from Knockout in that Vue’s component system encourages you to take a top-down, structure first, declarative design strategy, instead of imperatively build up ViewModels from bottom up. In Vue the source data are plain, logic-less objects (ones that you can directly JSON.stringify and throw into a post request), and the ViewModel simply proxies access to that data on itself. A Vue VM instance always connects raw data to a corresponding DOM element. In Knockout, the ViewModel essentially is the data and the line between Model and ViewModel is pretty blurry. This lack of differentiation in Knockout makes it much more likely to result in convoluted ViewModels.

Riot 2.0 provides a similar component-based development model (which is called a “tag” in Riot), with a minimal and beautifully designed API. I think Riot and Vue share a lot in design philosophies. However, despite being a bit heavier than Riot,

Vue does offer some significant advantages over Riot:
• True conditional rendering (Riot renders all if branches and simply show/hide them)
• A far-more powerful router (Riot’s routing API is just way too minimal)
• More mature tooling support (see webpack + vue-loader)
• Transition effect system (Riot has none)
• Better maintenance status (As of Aug 31st 2015, Riot has 25 open bugs while Vue has zero)
• Better performance. (Riot in fact uses dirty checking rather than a virtual-dom, and thus suffers from the same perf issues with Angular.)