Как я начал любить Vue

Главной (хронической?) болью от ангуляра для меня остались даже не их местами дико монструозные решения, а отношение к разработке.

Пользователи ангуляра используют фичу Х не по назначению и стреляют себе в ногу? Мы просто уберем фичу Х. Чтоб не говорили, что ангуляр тормозит. Вы использовали её по назначению? Нас не волнует.

Вы хотите наследование в ангуляре? Вы возмущены тем, что всю нашу документацию мы старательно прикидываемся ООП-комплементарными, а на самом деле нет? Мы за вас очень страдаем, но наследование делать не будем. Потому что это очень сложно™.

Vue.mixin({ created() {// logic… }})

Я бы сказал это нужно только когда вы делаете фреймворк и хотите экспортировать этот миксин наружу, т.к. он полезен сам по себе. Ну или когда этот миксин действительно используется в большом количестве компонентов.
Красота миксинов в том, что a) это просто объект и b) его легко использовать в любом количестве компонентов, не загрязняя общий инстанс Vue.

В конце концов есть плагины, которые делают почти то же самое, что и глобальные миксины.

А вот это совсем не правда. Миксины просто добавляют свойства и методы в данный компонент, в то время как плагины позволяют манипулировать Vue каким угодно образом. Vuex работает как плагин, а не как миксин, vue-router тоже.

Производительность

По вашей ссылке vue прогигрывает ангуляру: 1.38 против 1.28, а в статье наоборот, как так?

Vue не будет иметь и этих проблем, т.к. произойдет переход на Proxy, и появится возможность также отслеживать добавление/удаление пропертей.

Переход будет когда все (необходимые) браузеры будут это поддерживать, а не когда будет релиз vue.

Для DI можно использовать InversifyJS — совместим со vue-class-component через LazyInjection декоратор — можно инжектировать не через конструктор.

Не увидел у вас vue-property-decorator и vuex-class в seed. Принципиально не используете?

Из коробки нет:
HTTP
Валидации
i18n
… и тд?

А мне кажется это больше преимущество, нежели недостаток.
Как в противовес можно сопоставить python flask и django.

Вы не упомянули Single File Components — на мой взгляд это одна из главных фич, которая заставляет влюбиться во Vue. Любопытно, а почему вы используете Vue.extend а не SFC? По поводу тестирования у Vue есть схожая с React библиотека тестирования (написание тестов очень похоже)

PPS: Кстати английский вариант предыдущей статьи был настолько успешен, что у меня даже состоялось прямое общение (видео) с основными виновниками — но работу не предложили =(

Статей от товарищей с реальным опытом немного, в основном все по верхам, успешность заслуженная.

С ангуляром в принципе все ясно, что, как, для чего, где соломки постелить. Сам запостил им кучу багов и фичреквестов по формам, роутеру, хттп модулю и так далее, но они в развитие модулей не слишком-то и вкладываются, а местами ощущение, что модули пишут как в первый раз. Больше всего меня разозлил автор роутера (а может и всех трех), который параллельно писал по нему книгу и имел совесть продавать ее за деньги. Ну и один раз имел несчатье выбрать родную ангулярную реализацию i18n (адок) (до сих пор по этой теме глухо, я так понимаю к 7й версии сделают).

angular-cli я не пользуюсь, как и react-scripts и даже vue-cli, вебпак или роллап более-менее поддаются настройке и не лишают меня свободы выбора и не добавляют лишних проблем.

Vue, с точки зрения обычного программиста тоже самое (ну для некоторых он еще и очень простой, можно накидать этого вуе как попало куда попало, подключается-то легко), а с поддержкой тайпскрипта все заметно хуже. В сухом остатке выходит выгоднее использовать ангуляр, как более полное решение.

Насчет Tslint: в vscode поддерживается в файлах с расширением .vue
Видимо вы используете WebStorm

прощу прощения, вот тут написали переход с Angular на Vue с подробным описанием почему не на React. А почему бы например не перейти на RactiveJS аналог Vue, или например RiotJS аналог React только лучше?
Кто нибудь сравнивал эти фреймворки между собой? Я имею в виду RactiveJS vs Vue и React vs RiotJS?

По некоторым пунктам автор излишне оптимистичен.

Структурирование кода — миксины зло. Они затрудняют понимание кода компонента, при не очень строгом код ревью разные миксины используют друг друга, и появляется неописуемая лапша. Правда в том, что это сложно проконтролировать. Проще вообще запретить их использование (как по факту сделано в реакте).

В одной из статей (и выступлений) предлагалось делать автоимпорт компонентов через webpack — мне кажется, это вообще за гранью.

Магия везде — по коду компонента в шторме минимум сложно понять, что откуда прилетает. Мапперы на vuex не навигируются нормально. Магии в связке react/redux — ощутимо меньше.
Маппинг по-разному работает, где-то можно писать имена с неймспейсами, где-то нельзя.

VirtualDOM — вызов создания VNode настолько развесистый, что HOC становится лютой экзотикой. Очень много всего транслировать. Сравните с HOC в реакте.

Отдельная хрень — этот ваш TypeScript. То есть сам по себе он норм (хотя наш проект его не использует). Но! В шторме есть такая замечательная штука — Ctrl+Q, и навигация в код зависимости. До поры-до времени всё было ок, пока в библиотеках массово не стали завозить TS тайпинги. Докблоков в них нет, Ctrl+Q фактически умер, переход на код перебрасывает в тайпинг, и приходится по дереву зависимости руками искать реальный источник. Вот так TS уничтожает существующую экосистему.

Отдельно про TS применительно к Vue. Нормального вывода объектного контекста, как я понимаю, до сих пор нет (не особо слежу, но наличие двух разных способов прикрутить TS говорит за это). Фокусы с модификацией инстанса внешними плагинами жизнь для TS не облегчают — this.$somePlugin.xxx.zzz.ttt. Как с TS нормально уживается this.$refs.xxx — вообще загадка. Про дублирование деклараций пропсов уже решено?

Про внутренности Vue.js — не пинал только ленивый. Эван со товарищи конечно крутой, но недокументированный код — не круто. Back to VDOM — было удивительно узнать, что оно заимствованное из другой библиотеке. Просто как-то не афишируется. Сейчас начинают наконец-то появляться статьи о внутреннем устройстве фреймворка, это радует.

Сервисы для HTTP в статических классах — круто. Есть подход проще — фабричная функция, которая создает «ресурсы», их экспортируем в одной точке. Импорты в местах использования будут включать только необходимое, без классического «банан, гориллу, которая его держит, и все джунгли впридачу».

const resource = (url, method = 'get') => (params = {}) => axios({ url: typeof url === 'function' ? url(params) : url, method, ...params });

export const resourceUsers = resource('/api/users');
export const resourceUpdateUser = resource(({ id }) => `/api/users/${ id }`, 'patch');
};