Комментарии 56
Пользователи ангуляра используют фичу Х не по назначению и стреляют себе в ногу? Мы просто уберем фичу Х. Чтоб не говорили, что ангуляр тормозит. Вы использовали её по назначению? Нас не волнует.
Вы хотите наследование в ангуляре? Вы возмущены тем, что всю нашу документацию мы старательно прикидываемся ООП-комплементарными, а на самом деле нет? Мы за вас очень страдаем, но наследование делать не будем. Потому что это очень сложно™.
Хорошим примером полезных добавленных, но позже безвозвратно убранных фич в Angular будет пресловутый роутер, а именно: именованные роуты (да они были) и, например, route reuse.
Про второе вообще можно написать отдельный пост — но суть, что раньше это был просто один параматр вроде reuse: false, а теперь нужно имплементировать немаленький класс RouteReuseStrategy
И о какой фиче идет речь?
К сожалению уже не вспомню, больше чем полгода прошло. Но про роутер хорошо написано. Крайне грустно видеть, что раньше роутер был гораздо более адекватен в применении, чем роутер сейчас.
Vue.mixin({ created() {// logic… }})
Я бы сказал это нужно только когда вы делаете фреймворк и хотите экспортировать этот миксин наружу, т.к. он полезен сам по себе. Ну или когда этот миксин действительно используется в большом количестве компонентов.
Красота миксинов в том, что a) это просто объект и b) его легко использовать в любом количестве компонентов, не загрязняя общий инстанс Vue.
В конце концов есть плагины, которые делают почти то же самое, что и глобальные миксины.
А вот это совсем не правда. Миксины просто добавляют свойства и методы в данный компонент, в то время как плагины позволяют манипулировать Vue каким угодно образом. Vuex работает как плагин, а не как миксин, vue-router тоже.
Поверьте, я хорошо понимаю разницу между миксином и плагином, к тому же написал, что и то и другое — очень полезный функционал.
Поинт в том, что есть степени свободы в сравнении с Angular. Можно также привести пример с computed vs watched property. Опять же, они преследуют разные цели и нужны для разных задач, но новичкам (особенно), не всегда очевидно что использовать и где.
ПроизводительностьПо вашей ссылке vue прогигрывает ангуляру: 1.38 против 1.28, а в статье наоборот, как так?
Vue не будет иметь и этих проблем, т.к. произойдет переход на Proxy, и появится возможность также отслеживать добавление/удаление пропертей.Переход будет когда все (необходимые) браузеры будут это поддерживать, а не когда будет релиз vue.
Но даже так, коэффициэнт который я вижу по ссылке — 1.14, и уж никак не ниже у Angular против Vue. Вы точно сраниваете обычные версии а не с vuex, no-zone и тд?
У просто ангуляра всё те же 1.38.
Не увидел у вас vue-property-decorator и vuex-class в seed. Принципиально не используете?
Он очень пригодится для Node, но в обычным Vue приложениях считаю слишком большим оверхедом.
Вообще, то же самое касается и vue-property-decorator и vuex-class — как раз то место в статье, где описаны причины использования Vue.extend.
Все эти вещи добавляют дополнительную сложность и TS специфику там, где изначально она не предусмотрена — больше проблем и сложнее поддержка.
Мы стремимся использовать сторонние вещи только по необходимости.
ЗЫ: vuex-class использовал на pet проекте, проблемы были, а большой пользы не ощутил
Angular предназначен только для SPA-приложений
А Vue для чего предназначен? оО
В Angular 1.x точно так же было можно посадить приложение на любой узел в дереве, не знал, что из 2.x это убрали.
В js можно примерно всё. Вопрос только в том, скольких усилий это будет стоить в реализации и в поддержке.
Вообще они вроде как сделали возможность использовать отдельные компоненты на странице не превращая все в SPA, см. Angular Elements.
Из коробки нет:
HTTP
Валидации
i18n
… и тд?
А мне кажется это больше преимущество, нежели недостаток.
Как в противовес можно сопоставить python flask и django.
Именно SFC мы и используем (смотри код стайл раздел), Vue.extend необходим для поддержки TypeScript, примерно как здесь.
В посте есть наш вариант использования с кастингом (после раздела «Другие проблемы»). То есть используется и Vue проверка типа и интерфейс TS.
Нам нравится в первую очередь с точки зрения файловой структуры — очень удобно работать с едиными файлами.
С точки зрения IDE работа с .vue файлами очень удобна — подсветка синтаксиса работает, сворачивание, итд.
У нас общие стили вынесены в отдельные обще-проектные стилевые файлы, а компоненты имеют только специфичные им стили. Таким образом стили в .vue довольно небольшие, а то и отсутствуют вовсе.
Примерно так же и для шаблона. Скрипт тег также обычно довольно короткий, так как основная логика находится в store.
PPS: Кстати английский вариант предыдущей статьи был настолько успешен, что у меня даже состоялось прямое общение (видео) с основными виновниками — но работу не предложили =(
Статей от товарищей с реальным опытом немного, в основном все по верхам, успешность заслуженная.
С ангуляром в принципе все ясно, что, как, для чего, где соломки постелить. Сам запостил им кучу багов и фичреквестов по формам, роутеру, хттп модулю и так далее, но они в развитие модулей не слишком-то и вкладываются, а местами ощущение, что модули пишут как в первый раз. Больше всего меня разозлил автор роутера (а может и всех трех), который параллельно писал по нему книгу и имел совесть продавать ее за деньги. Ну и один раз имел несчатье выбрать родную ангулярную реализацию i18n (адок) (до сих пор по этой теме глухо, я так понимаю к 7й версии сделают).
angular-cli я не пользуюсь, как и react-scripts и даже vue-cli, вебпак или роллап более-менее поддаются настройке и не лишают меня свободы выбора и не добавляют лишних проблем.
Vue, с точки зрения обычного программиста тоже самое (ну для некоторых он еще и очень простой, можно накидать этого вуе как попало куда попало, подключается-то легко), а с поддержкой тайпскрипта все заметно хуже. В сухом остатке выходит выгоднее использовать ангуляр, как более полное решение.
Видимо вы используете WebStorm
В VScode оно может и работает, но не через сам пакет линтера — т.к. отдельно он не умеет этого. Соответственно, нельзя запустить на CI — а значит толку от такого линтера немного.
Кто нибудь сравнивал эти фреймворки между собой? Я имею в виду RactiveJS vs Vue и React vs RiotJS?
Кстати, только что проверил: сам Typescirpt сохраняет jsdoc при генерации тайпингов, так что ситуация «в тайпингах нет докблоков» возможна только для js-библиотек, и виноваты в ней исключительно авторы тайпингов, а не язык.
Структурирование кода — миксины зло. Они затрудняют понимание кода компонента, при не очень строгом код ревью разные миксины используют друг друга, и появляется неописуемая лапша. Правда в том, что это сложно проконтролировать. Проще вообще запретить их использование (как по факту сделано в реакте).
Подпишусь. Миксины это чистая динамика, смотря в код бывает очень сложно отследить откуда что прилетело. По сути это манки патчинг.
Честно говоря, после этой статьи серьезно попробовать Vue c TS желания не прибавилось, а без TS жизнь уже не мила.
Касательно миксинов не соглашусь — да их нужно грамотно использовать, но в реальности мне этот подход гораздо больше нравится, нежели в Angular (никак). С точки зрения поддержки — мы для себя пока проблем не видим, но если это столь необходимо — class component позволяет делать миксин классом от которого компонент наследуется = рефакторинг и все остальное будет работать.
По поводу магии хотелось бы увидеть конкретный пример. Не сталкивался. Навигация работает в вебшторме отлично с TypeScript.
Со статическими методами классов работать гораздо приятнее с точки зрения TypeScript.
По основным претензиям вижу что TS вам не очень близок и пытаться вас к его использованию склонять не собираюсь, но Ctrl+Q ним особо не нужен, а качество тайпингов зависит от библиотек и тех кто эти тайпинги поддерживает — то есть не все ваши аргументы валидны.
Про миксины больше спорить смысла нет — это скорее персональные предпочтения.
Однако, лично мне, плагины и штуки вида this.$v, this.$t итд — нравятся. Даже очень.
Более того, в случае с TS это отлично поддерживается, и использование плагина без тайпингов сразу приведет к ошибке.
Касательно качества тайпингов — да, такая проблема сущетсвует, но на нее влиять проще всего, конкретно для Vuelidate они еще не финализированы и мы используем кастомизированную версию.
А уж добавить доки в тайпинги Vuex — дело одного очень простого и короткого PR'а.
Это опенсорс, и на некоторые вещи можно влиять самостоятельно.
Впрочем, я допускаю, что еще через год какие-то неявные вещи могут всплыть, но пока предпосылок к этому нет. Появятся — обязательно напишу новый пост, как есть.
Вообще, миксины есть в тайпскрипте с версии 2.2 и их можно использовать с ангуляром (но наверное не нужно), единственная проблема — баг с лайфсайкл методами, компилятор не пока не понимает, что они есть в миксине.
Как я начал любить Vue