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

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

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

Хорошим примером полезных добавленных, но позже безвозвратно убранных фич в Angular будет пресловутый роутер, а именно: именованные роуты (да они были) и, например, route reuse.


Про второе вообще можно написать отдельный пост — но суть, что раньше это был просто один параматр вроде reuse: false, а теперь нужно имплементировать немаленький класс RouteReuseStrategy

Я много смотрел на рассказы об Ivy, но не заметил там ничего на тему наследования. Если говорить предметно, то наследование в ангуляре можно выразить и сейчас (typescript-то наследовать и вовсе никто не помешает, а с декораторами есть определенные решения), просто это, мягко говоря, совсем кривые способы.

И о какой фиче идет речь?

К сожалению уже не вспомню, больше чем полгода прошло. Но про роутер хорошо написано. Крайне грустно видеть, что раньше роутер был гораздо более адекватен в применении, чем роутер сейчас.
Vue.mixin({ created() {// logic… }})

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


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

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

Эх, я же специально написал что пример утрированный.
Поверьте, я хорошо понимаю разницу между миксином и плагином, к тому же написал, что и то и другое — очень полезный функционал.

Поинт в том, что есть степени свободы в сравнении с Angular. Можно также привести пример с computed vs watched property. Опять же, они преследуют разные цели и нужны для разных задач, но новичкам (особенно), не всегда очевидно что использовать и где.
Производительность
По вашей ссылке vue прогигрывает ангуляру: 1.38 против 1.28, а в статье наоборот, как так?
Vue не будет иметь и этих проблем, т.к. произойдет переход на Proxy, и появится возможность также отслеживать добавление/удаление пропертей.
Переход будет когда все (необходимые) браузеры будут это поддерживать, а не когда будет релиз vue.
Касательно производительности взята часть таблицы — если брать все результаты, разницы почти не будет, поэтому я и написал, что основное заметное место большей скорости работы Vue — начальная загрузка страницы.
Но даже так, коэффициэнт который я вижу по ссылке — 1.14, и уж никак не ниже у Angular против Vue. Вы точно сраниваете обычные версии а не с vuex, no-zone и тд?
1.28 у ангуляра без использования Zone.js. Что лишает его некоторых фич, ну и всё-таки это «возьмите наш крутой фреймворк и сами доработайте молотком».
У просто ангуляра всё те же 1.38.
Для DI можно использовать InversifyJS — совместим со vue-class-component через LazyInjection декоратор — можно инжектировать не через конструктор.

Не увидел у вас vue-property-decorator и vuex-class в seed. Принципиально не используете?
Про InversifyJS в курсе, но именно и не хочется тащить все это на фронт-энд.
Он очень пригодится для Node, но в обычным Vue приложениях считаю слишком большим оверхедом.

Вообще, то же самое касается и vue-property-decorator и vuex-class — как раз то место в статье, где описаны причины использования Vue.extend.
Все эти вещи добавляют дополнительную сложность и TS специфику там, где изначально она не предусмотрена — больше проблем и сложнее поддержка.
Мы стремимся использовать сторонние вещи только по необходимости.

ЗЫ: vuex-class использовал на pet проекте, проблемы были, а большой пользы не ощутил
UFO landed and left these words here
Angular предназначен только для SPA-приложений

А Vue для чего предназначен? оО

UFO landed and left these words here

В Angular 1.x точно так же было можно посадить приложение на любой узел в дереве, не знал, что из 2.x это убрали.

UFO landed and left these words here
Это будет неудобно, но почему «не прокатит»-то? При желании можно и несколько аппликух впихнуть на одну страницу (по крайней мере, пока у них ангулярские зависимости полностью совпадают по версиям), и в многостраничный контекст их вписать, в произвольной N-to-N конфигурации.

В js можно примерно всё. Вопрос только в том, скольких усилий это будет стоить в реализации и в поддержке.
UFO landed and left these words here
Конечно. Именно поэтому я и написал, что «будет неудобно». И поддерживать это будет неудобно. И так далее.

Но сделать-то можно, и даже без моря усилий.
UFO landed and left these words here
какой бред вы несете! Статью прочтите еще раз, там и про роутинг(отличный) и про стэйт есть.

Вообще они вроде как сделали возможность использовать отдельные компоненты на странице не превращая все в SPA, см. Angular Elements.

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

А мне кажется это больше преимущество, нежели недостаток.
Как в противовес можно сопоставить python flask и django.
Вы не упомянули Single File Components — на мой взгляд это одна из главных фич, которая заставляет влюбиться во Vue. Любопытно, а почему вы используете Vue.extend а не SFC? По поводу тестирования у Vue есть схожая с React библиотека тестирования (написание тестов очень похоже)
В стринговом описании — нет.
В посте есть наш вариант использования с кастингом (после раздела «Другие проблемы»). То есть используется и Vue проверка типа и интерфейс TS.
UFO landed and left these words here
А чем удобно все сваливать в один файл? Я бы делал шаблон в этом vue файле, а скрипт и стили подключал обычным образом (link / script теги) — vue поддерживает такой подход. Тогда получились бы трех файловые компоненты, что как по мне удобнее по многим причинам, а на выходе после сборки пускай это будет 1 файл.
На самом деле никто вам не запрещает, это отлично поддерживается Vue.

Нам нравится в первую очередь с точки зрения файловой структуры — очень удобно работать с едиными файлами.
С точки зрения IDE работа с .vue файлами очень удобна — подсветка синтаксиса работает, сворачивание, итд.

У нас общие стили вынесены в отдельные обще-проектные стилевые файлы, а компоненты имеют только специфичные им стили. Таким образом стили в .vue довольно небольшие, а то и отсутствуют вовсе.
Примерно так же и для шаблона. Скрипт тег также обычно довольно короткий, так как основная логика находится в store.
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');
};
А на тайпинг вас перебрасывает из TS-кода или из JS-кода? Если второе, то это уже похоже на баг IDE.

Кстати, только что проверил: сам Typescirpt сохраняет jsdoc при генерации тайпингов, так что ситуация «в тайпингах нет докблоков» возможна только для js-библиотек, и виноваты в ней исключительно авторы тайпингов, а не язык.
Из JS. Во vue.js такое сплошь и рядом — все мапперы из Vuex например. шторм 2018.1.
Структурирование кода — миксины зло. Они затрудняют понимание кода компонента, при не очень строгом код ревью разные миксины используют друг друга, и появляется неописуемая лапша. Правда в том, что это сложно проконтролировать. Проще вообще запретить их использование (как по факту сделано в реакте).

Подпишусь. Миксины это чистая динамика, смотря в код бывает очень сложно отследить откуда что прилетело. По сути это манки патчинг.

Честно говоря, после этой статьи серьезно попробовать Vue c TS желания не прибавилось, а без TS жизнь уже не мила.
Не совсем манки патчинг, но всё равно бяка. Манки патчинг в чистом виде — это как плагины ставятся :) Тот же vue-i18n

Касательно миксинов не соглашусь — да их нужно грамотно использовать, но в реальности мне этот подход гораздо больше нравится, нежели в Angular (никак). С точки зрения поддержки — мы для себя пока проблем не видим, но если это столь необходимо — class component позволяет делать миксин классом от которого компонент наследуется = рефакторинг и все остальное будет работать.


По поводу магии хотелось бы увидеть конкретный пример. Не сталкивался. Навигация работает в вебшторме отлично с TypeScript.


Со статическими методами классов работать гораздо приятнее с точки зрения TypeScript.


По основным претензиям вижу что TS вам не очень близок и пытаться вас к его использованию склонять не собираюсь, но Ctrl+Q ним особо не нужен, а качество тайпингов зависит от библиотек и тех кто эти тайпинги поддерживает — то есть не все ваши аргументы валидны.

То есть миксины нативно поддерживаются какой-то IDE? Для той же функциональности я сейчас предлагаю использовать такое:
import { someReusableMethod } from './mixins';

export default {
  methods: {
    someReusableMethod,
    someOtherMethod() { /*... */ }
  }
}


И ваш пример с extends mixin() несколько лучше, но классика множественного наследования — если два миксина пересекаются по именам, из какого унаследуется реализация? Как мне понять, из какого места прилетела реализация, если всё, что в компоненте есть — this.someMethod()?

Сам концепт динамического связывания в рантайме — не очень хорош, если всё, зачем вы его используете — статическое связывание.

Про магию — в контекст прилетает масса странного, что непонятно откуда берется. Vuelidate -> this.$v, I18N -> this.$t, Vuex -> this.$store, Router -> this.$route, был еще vue-resource -> this.$http. Конкретно в компоненте это и есть магия, когда «ниоткуда» появляется нечто. Впрочем сама модель построения фреймворка такая. Это «easy, not simple». Само конструирование инстанса из частичек конфигурационного объекта, сборка в единое всех этих computed, data, methods, watch — из-за чего с вычислением this такие проблемы — по сути разновидность магии.

TS — мне нравится типизированный код, и когда язык не вынуждает аннотировать типы на каждый чих. Но (возможно завышенные ожидания) я ожидаю что типизировано будет всё. И ломаться в рантайме по несоответствию типов не будет (будет по минимуму). Пока из того, что я слышу — TS даже в полном «фарше» не может этого обеспечить. Но да, это личное предпочтение.

Статические методы — это, как мне кажется, притащили из Java, где функций вообще нет. Я для JS считаю это антипаттерном, который только создает бойлерплейт код.

Качество тайпингов — извините, но минимум сам Vuex вот такой — то есть одна из основных библиотек экосистемы. То, что вам докблоки не нужны — ок, верю, но это не значит, что они никому не нужны. Бегать в онлайн документацию чтобы уточнить порядок аргументов и какие принимаются — надоедает.

Про миксины больше спорить смысла нет — это скорее персональные предпочтения.
Однако, лично мне, плагины и штуки вида this.$v, this.$t итд — нравятся. Даже очень.
Более того, в случае с TS это отлично поддерживается, и использование плагина без тайпингов сразу приведет к ошибке.


Касательно качества тайпингов — да, такая проблема сущетсвует, но на нее влиять проще всего, конкретно для Vuelidate они еще не финализированы и мы используем кастомизированную версию.
А уж добавить доки в тайпинги Vuex — дело одного очень простого и короткого PR'а.


Это опенсорс, и на некоторые вещи можно влиять самостоятельно.

Vuex — мы не используем TS, и очень досадно, что комбинация IDE+Vuex при появлении тайпингов стала доставлять неудобства. Простой и короткий PR — это удалить тайпинги? :)
Я уже писал выше: проблема на стороне IDE. Пишите разработчикам и не приплетайте язык, он ни в чем не виноват.
Не воспринимайте это так всерьез, никто на тайпинги не покушается :)
Можно еще вопрос оффтопный, а сколько лет вашему проекту на Vue? И какое количество разработчиков? Просто грабли с миксинами у нас выросли после полутора лет, поначалу тоже всё было (казалось) радужно.
У нас много проектов на Vue. Самый длительный — около года, благодаря тому, что строгое код ревью, линтер и TS были с первого дня — проблем никаких. Уверен что в части миксинов их и не возникнет, т.к. создаются они только для тех случаев когда действительно нужны.

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

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

UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.