💔 VueJS: аргументы "против"
HTML-код
- Опубликовано: 12 сен 2024
- / javascriptninja
💖 Видео создано при поддержке подписчиков проекта JavaScript.ninja на Patreon.
Хотите получать обучающий контент на 3 месяца раньше остальных? Присоединяйтесь!
---
Ссылка на подкаст ДевШахты про Вью - / devschacht-49
Судя по комментам, у нас комьюнити раскололось на реакт, ангуляр, вью и другие варианты. Просто как мне кажется, абсолютно не важно, какой фреймворк юзать, главное знать его проблемы и уметь их решать.
Виноват не микроскоп, а тот, кто им гвозди забивает. Илья в конце очень грамотно сделал акцент на задачи, где vue подходит более остальных.
Важно знать какой юзать закакой дают больше бабосиков
В общем, в итоге я понял в чем проблема...
ПЕРЕСТАНЬТЕ ПИСАТЬ ЛОГИКУ В ПРЕДСТАВЛЕНИЯХ!!!!!!!!!!!!!!!!
ХОРОШО БОЛЬШЕ НЕ БУДУ!!!!!!!!!!!!
В проектах c vue не участвовал, но меня смутили параграфы о наличии нескольких путей написать одно и то же, и безальтернативность инструментария. Это ведь плюсы. Первое решается соглашениями ( и в итоге позволяет выбрать лучшее в данный момент, но в рамках каких то), а второе обеспечивает простой перенос разработчиков. Было бы 10 тех же роутеров, было бы 10 проблем. В общем, я не понимаю.
Соглашение невозможно проконтролировать автоматически - это дополнительная ментальная нагрузка при кодревью (более того невозможно сформулировать соглашение, потому что оно сложное - тогда работать так, тогда иначе).
Что касается 10 роутеров - нормальная ситуация для экосистемы это наличие "мейнстрима" и "андердога", который закрывает то, что в мейнстриме решено плохо. Отсутствие андердога это риски
@@JavaScriptNinja я далеко не сеньор, но почему бы не запретить правилом Eslint, например, всё, кроме emit, и добавлять исключение, если ревьюер разрешил?
Ну и официальный плагин для eslint подключить, с настройками 'vue-recommended'.
@@heavis потому что в общем виде определить что в проп допустим передали функцию и потом эту функцию используют вместо эмита - невозможно :)
@@JavaScriptNinja зато возможно требовать описание типа пропа, вплоть до типа элементов, если это массив. такое, конечно, можно обойти, но это уже похоже на вредительство :)
Как говориться - каждому своё.
Лично я реакт не люблю как раз из-за наличия over9000 альтернативных библиотек для всего на свете, которые от проекта к проекту могут меняться. Т.е. приходя на проект, новый девелопер будет тупо тратить время на изучение архитектуры, зоопарка библиотек и принятых решений, вместо того чтобы сразу решать задачи с минимальной подготовкой.
Vue видится мне, как некий компромисс, между React и Angular - с одной стороны это всё ещё js как в реакте, с другой стороны есть строгая архитектура и адекватная система шаблонов, как в angular.
А вот по поводу потери реактивности - тут согласен, часто бывают такие случаи.
ну там разное бывает. у меня, например, был баг, когда при переходе по роуту не отвязывалась пользовательская директива, хотя в доках чётко написано - уничтожается всё. Всё на самом деле уничтожается - кроме директивы, которая почему-то не отвязывается. Пришлось руками вешать прослушиватель и руками же его отвязывать в хуках. Либо доки через жопу написаны, что иногда встречается, либо бага. Но это мелочи. В целом vue очень радует.
Потеря реактивности бывает от неопытности. Вначале часто такое было.
Потом ты понимаешь, что нужно использовать Vue.set() или не забывать записывать в data всё то, что ожидается быть реактивным.
Я так понимаю, что комментаторы тут это люди, которые вылупились только со знанием одного фреймворка, по этому постоянные холивары на эту тему.
Я даже не знаю в чем ваша беда, люди. Фреймворк это такая вещь, которую взял и выучил, или вы фильтруете офферы по конкретному фреймворку? Бред же, каждый Фреймворк имеет свои плюсы и минусы, главное знать в каком проекте минусы того или иного фреймворка будут менее явными.
В продакшене вы будете юзать то что вам скажут, а под свои проекты клепайте на чем хотите.
В вакансиях же требуют коммерческого опыта на фреймворке. Вот из за этого и фильтровать приходится
Вью сложен? Да ладно, ребят. Он не сложен, у него концепция другая. Примеры выбраны как раз такие, которые НЕЛЬЗЯ использовать в продакшне, их реализовывать нужно по другому!
P.S. Смотрел проматывая, на роутинге ангуляра вообще скипнул, просто полнейшая дичь. (чисто мое мнение)
Каждое мнение индивидуально. Особенно у автора канала ))
В целом многое по существу, просто раздуто до вселенских масштабов.
У Vue в принципе та же концепция, что и у Knockout-а. Ничего принципиального нового. Но часть принятых решений настолько ди... странная, что складывается ощущение, что "по-другому" это не на Vue :)
+Евгений Мнацаканов
это какие такие примеры выбраны, которые нельзя использовать в продакшене?) Хотя бы один сможешь назвать?)
@@kd8437 да та же передачу функции для эмита. Я вообще не понял что он имел в виду
Есть ли на канале свежое видео про тоже самое? Только уже на сегодняшнее день. Смогли ли решить проблемы озвученные в данном видео?
Спасибо за мнение. Давно "охочусь" на критику Vue. В видео вы перечислили, на мой взгляд, некритичные вещи, но критиковать надо, это полезно для всех.
Самый большой недостаток vue - он чертовски хорошь! 😁
Спасибо, хороший анализ. Особенно 5-ый пункт. Когда свой код, то еще ничего, но когда разгребаешь, это больно.
У меня тоже сложилось впечатление, что Vue это для ХХП. Я попробовал на средней мутности проекта Vue + Vuex и был вынужден на трети проекта переобуваться. Ибо столкнулся с одной достаточно дикой проблемой: tracking dependencies во Vue устроен ОЧЕНЬ СТРАННО. В чём суть? Суть в том что computed-value не может зависеть от computed-value. Скажем идеологически и визуально A зависит от B, где и A и B это computed values. Но B при этом зависит от 3000 observables. Тадададам...Во Vue на самом деле у вас A зависит не от B, а от B.observableDependecies. В случае моего проекта (расписание, таблицы, очень много вычисляемых значений и сильно большой граф данных) это приводит к тому, что 99.*% времени Vue просто считает зависимости. И чем дальше тем хуже. Т.е. со Vue проект оказался ну совсем не жизнеспособным. Да есть вариант сделать watch + self-controlled observables но это боже правый какая-то дичь. Или взять какой-нибудь RxJS и воспользоваться им, на скотче привязав его к Vuex. На деле я просто переписал всё на React + Redux + reselect и всё стало работать молниеносно и удобно.
Я не знаю причин такого решения. Возможно такая модель трекинга зависимостей удобнее в разработке. Но как с ней писать приложения - не понимаю. Это же дикая асимптотика.
Хз, что за проблема. Тоже делал потные таблицы с кучей компьютеда и подзависимостей - летало на ура. А так все предсказуемо довольно: одно значение изменилось - идёт пересчет. Я просто даже представить не могу, чего такого можно нафигачить, чтобы тормозило так.
Начинал с Vue. Пробовал React. Выбрал Angular.
Осталось четкое ощущение, что Vue ориентирован на легкое и быстрое написание кода. "Сперва написал, потом подумал". Низкий же порог в хода, к сожалению, подразумевает появление людей, которые вообще выстраивают приложение markup-first. Они как бы верстальщики и использую Vue, как какой-нибудь шаблонизатор.
У некоторых (далеко не у всех) адептов React'а тоже есть болезнь "быстрее писать", а голос в их голове говорит: "Хозяин, нужно больше кода...". Хотя стоит отметить, что в React-community огромное количество специалистов высочайшего класса. Но там скорее оттолкнул пресловутый Development Experience. Каждый раз работая с React, я ощущал себя так будто попал на радио-рынок или любую другую барахолку: вот лежит навороченная вундервафля, которая волшебным образом делает тебе хорошо, и тут же за соседнем прилавком картриджи от 8-bit'ных приставок, фен, роботизированная нога, а еще дальше правый силиконовый грудной имплант. WTF?!? Почти наверняка, если ты приходишь в новый React проект тебе придется учить API новых библиотек, которые делают плюс-минус тоже самое, но "по своему".
В этом смысле React - именно библиотека в отличие от Vue и Angular, которые действительно фрейморки. Именно консистентная и определенная экосистема делает их таковыми.
И Angular я выбрал также возможно из-за DX. Работая с ним, я ощущаю себя внутри огромного человекоподобного робота, который по нажатию одной кнопки делает все по красоте.
Но в итоге фреймворк это инструмент бизнеса, и принятие решения должно ложиться не на плечи разработчика. Понятно же, что есть QA, которым это нужно как-то тестировать, DevOps с их заботами, HR, которым нужно где-то искать квалифицированных разработчиков.
Для себя я выбрал Angular, не претендую на глубокий анализ темы, но у меня сложилось стойкое впечатление, что он наиболее сильно заточен на решение именно задач бизнеса.
В интернете от Вью чертыхаются и страдают только пользователи Реакта, почему-то.
Половина перечисленных "против" на самом деле "За". Ну или как минимум нейтральные. Остальные я тупо не понял в чем проблема была, описано как-то криво, как будто "против" вызваны просто не знанием особенностей Вью и его инфраструктуры.
Это не говоря уже о проблемах Реакта. Последний лишь наверно 25% от возможностей Вью из коробки. И все реактщики так или иначе пишут свой Вью в проектах, с нуля, кто во что горазд, в итоге получаем еще более сложную кастомную систему. Я уже молчу про дебаты разрабов что именно из либ для реакта юзать. Простой пример - у нас в компании две команды и два приложения. Одно на Вью я пишу, второе пишут на Реакте. У нас производительность просто в разы быстрее! Пока мы уже написали MVP и вывели в прод, реактщики все еще страдали созданием удобного им окружения, чтобы реакту было не скучно и он смог летать так же изи как и компоненты на Вью + Вьюкс.
>Пока мы уже написали MVP и вывели в прод.
Вот это как раз есть в видео про плюсы Vue.
>реактщики все еще страдали созданием удобного им окружения
А вот тут было бы интересно посмотреть на удобство поддержки проекта на Vue со временем. Наговнякать то быстро можно, а как потом это разбирать...
@@maxv5794 Да тоже самое, что и на реакте. Вся разница лишь в том, что если у вас уйдет техлид с реактом, то вы останетесь один на один с кастомной архитектурой (набором правил, одному ему любимых либ, паттернов, и т.п.). И потом новому челу, который имеет свой взгляд на то, как готовить Реакт, придется с этим жить. И терпеть. А если уйдет тех лид на Вью, то никто этого просто не заметит. Потому что а нафига там тех лид, если все описано в доках, зоопарка либ нет, и все подходы подробно разжеваны в бест-практис?
Насчет поддержки прям супер большого проекта, не знаю. Мы юзаем Вью со связкой с Рельсами. Раньше было хуже (кофе + jQuery). Как бы ни было сложно поддерживать Вью, это всяко легче и быстрее, чем юзать то, что раньше :)
Опять же, у нас на Вью бэкендеры-рельсовики пишут легко. Потому что многие принципы там схожи с рельсами, и все просто. А реактщики чот на рельсах писать не могут, увы.
В интернете от JQYERY чертыхаются и страдают только пользователи Реакта VUE ANGULAR, почему-то.!!!!1
даже без знаний архитектуры ежу понятно, что когда есть возможность получить возможность влиять на внутреннюю работу это не плохо. Это гибко.
@@AlexanderShelestov Раньше было хуже (кофе + jQuery). Тут я тебя понимаю очень хорошо)
Смотреть на скорости X2 ))
Чувак, бабушкин комод очень доставляет)
круть !
давайте ездить на телегах, потому, что на автомобилях СЛОЖНО 8-О
спасибо, очень годно
Спасибо за опыт
Мне как новичку в мире js , vue просто гладко вошел. и нравится) Пока до большинства упомянутых минусов не дошел)
Скорее всего и не дойдёте, ибо это выглядит не минусами ФВ в работе, а претензиями к эко-системе и философии vuejs. Автор не привёл ни одного примера из реального проекта на который оказал бы влияние один из этих "минусов", а только сплошные абстрактные рассуждения и субъективные предположения. В таком ключе минусы можно начинать искать в самом JS что уж там мелочиться!?
Отличный анализ, сталкивался с похожими проблемами.
спасибо
Илья, привет, никак не могу найти тоже самое про React, пожалуйста, направь на нужный путь.
Пункт 2.
Такие простые вещи один раз обсуждаются на проекте, а сделать что-то через жопу можно где угодно.
Не юзаю vue-router, пришлось сделать свой изоморфный велосипед. В целом vue+vuex отлично работает, в том числе в виде custom elements, чтобы можно было использовать их не как монолитный SPA, а как разрозненные компоненты на странице - такое решение вообще норм при постепенном добавлении функционала к существующему сайту на jquery )
Т.е. изначально требование было такое - написать компонент, не важно на чем - vue/angular/react и по быстрому добавить его на страницу, причем в разных местах. Ангуляр сразу провалил это задание (не знаю может это был ангуляр 1 или просто его не умею готовить). vue+vuex а также react+mobx зашли норм, в проекте даже есть страницы, на которых одновременно и vue и react компоненты используются внутри друг друга (через vue-custom-element), но в целом больше нравится vue.
чутка дополню:
1. отсутствие кастомных модификаторов как иллюстрация для "вам это не нужно": github.com/vuejs/vue/issues/3666 - только то, что есть
2. в догонку по компилятору темплейтов: в 2.х не реально подключать новые фичи языка, если их не поддерживает текущая версия Ноды. например, optional chaining github.com/vuejs/vue/issues/8861
1. Зачем, если есть get/set?
Пункт 3.
У друга на большом проекте выбрали Vue в основном потому, что Angular изначально слишком сложный, а в React невозможно за адекватное время выбрать правильное решение, для каждой мелочи по 100 вариантов.
тема с "непонятно как" напомнила 100500 вопросов на SO "как выбрать, где factory, а где service" для AngularJS
О да, помню эти времена
А какой бы Фреймворк вы бы выбрали для фронтенда большого интернет магазина с фильтрами, карточками, сложными формами?
Egor Doynikov ангулар
@@alex_chugaev А если еще и необходимо делать рендер страниц на стороне PHP?
Egor Doynikov возможно я чего-то не знаю, но на php невозможен рендеринг клиентских JavaScript приложений
22 год, проблемы решились?
Странный докладчик IMHO ) vuex, eslint и роутер вам в руки, слишком все раздуто, просто паника на корабле, react и angular можно воспринимать как flash player на фоне vue, а тем кто прогает на cofee script вообще надо по рукам надавать.
вот эт у тебя пригорело :D
Не ясно, какая у тебя проблема возникает с покрытием шаблонов в тестах? У тебя есть avoriaz/vue-test-utils, которые все прекрасно смаунтят, а дальше все что нужно ты сможешь посчитать и проверить на присутствие/отсутствие.
Как посчитать что все возможные пути рендеринга шаблона (совсем упрощенно - все v-if) были проверены?
(никак)
@@JavaScriptNinja как вариант тестирования снапшотами, плюс создание специального computed property (show), который отвечает за отображение всех блоков, которое в тестах подменять.
Например
компонент:
github.com/levchak0910/fakebet/blob/master/front/src/views/Bet.vue
тест (Testing snapshot):
github.com/levchak0910/fakebet/blob/master/front/tests/unit/views/Bet.vue.spec.js
снапшот:
github.com/levchak0910/fakebet/blob/master/front/tests/unit/views/__snapshots__/Bet.vue.spec.js.snap
Интересно узнать Ваше мнение
@@user-ko2ip7xy1j Не признаю тестирование снапшотами в принципе. Тесты должны проверять поведение, снапшоты это не проверяют
Что касается "специального компьютед проперти" - это не решение, потому что "отображение блоков" лишь один пример. Некоторые куски логики шаблона могут активироваться по очень хитрым условиям, и принудительно "активировать" эти условия "изнутри" каким-нибудь хаком противоречит идеологии тестирования - тестировать только публичный интерфейс
Не дай Бог, это видео увидит начинающий прогер, который просто залез посмотреть видео, стоит ли работать с VUE ... Это видео сломает ему мозг, и выпьет душу.
Автор молодец, задает правильные вопросы, на них же дает интересные ответы. Но как по мне, все гиперболизировано до невероятных масштабов.
Ну если человек не посмотрит первое видео, то сам виноват :)
Cмотрел первое видео. По сравнению со вторым, оно ниочем, прости автор. 5 минут рассказа о том что Vue это Vue :)
Для начинающего, эти плюсы ниочем не скажут, так как небыло прецедентов и танцев с бубном. А профи глянул в документацию, описание, примеры, и сам это все поймет через тех же 5 минут. :) Но, я говорю : - Большое спасибо за труд, это ценится. И критику, я даю, только для того, что бы подстегнуть тебя к записи видео, где все наглядно и по полочкам :)
Так сейчас уже 2020, как там с vue, решились проблемы?
Нет пока
4:20 причем здесь вообще DI в ангулар?? сервисы это просто сторонний код который можно вызвать в компоненте, ТОЧНО так же его можно написать и внутри компонента, просто логику выносят в сервис чтобы ее переиспользовать, причем здесь это к рендерингу??? ты точно так же в реакте можешь сделать ajax реквест внутри componentDidMount() и это тоже будет влиять на рендеринг компонента лол
DI в Angular это не ПРОСТО сторонний код. И речь совсем не о DI, ремарка про DI вынесена потому что "благодаря" DI один и тот же компонент может в разных поддеревьях рендерится по разному, потому что DI предоставил другой сервис под тем же именем
DI и просто import вообще о разном
softwareengineering.stackexchange.com/questions/336767/module-requiring-vs-dependency-injection-in-javascript
@@yevhenkozlov286 к сожалению учитывая что импорты статичны в спеке и через них подтягивает обычный разработчик зависимости - они решают одну задачу доставки зависимостей в код
@@JavaScriptNinja то была ремарка на утверждение qazyhn94, что нет разницы между DI в ангуляре и import + call где-то в cDM.
как по мне разница ощутимая - либо сам говоришь "нужно именно это"(а потом уже страдаешь при необходимости подменить, как, например, в юнит тестах), либо "ешь, шо дали"(и страдаешь сразу от необходимости писать регистрацию и потенциальной непредсказуемости)
а так обе вещи про зависимости, то понятно.
Как говорил Бьерн Страуструп существуют два тип языков : Языки на которых пищут, и языки которых обсирают. очень абстракное слово который можн пременить и в этом кейсе.
Вы путаете критику и "обсирание"
говорил Бьярне не так! "Существуют языки, которые критикуют и языки, которыми никто не пользуется"
Вообще не та цитата)
А хочень бы хотелось от вас увидить видео о angular.
Автор уже лукавит говоря, что стандартная библиотека хуже толпы библиотек из которых нужно еще выбрать что то стоящее. Пишу последнее время под ноду и всегда вспоминаю добрым словом стандартные библиотеки у руби и питона, про явовские и си шарповские вообще молчу. Кстати всем известно, что сторонние библиотеки больше страдают уязвимостью и иной раз не против слить ваши данные налево.
"Мотайте на ус", Илья: полагаю столько, как за это видео, ещё не "огребали" ))
Vue-router решает 90% задач??? Чтобы такое говорить, нужно привести хотя бы 1 пример из тех 10%....
Легко. Facebook-style navigation:
- открытие фото в ленте обновляет урл на ссылку на это фото, НО СОХРАНЯЕТ сзади ленту - т.е. после закрытия попапа вы возвращаетесь к ленте
- F5 на открытом фото приведет к тому, что вы попадете уже на страницу фото а не ленты
Это решается путем "блокировки" роутинга на конкретное изменение урла, и в некоторых роутерах это есть.
Сходу: такие же поведения есть к примеру в твиттере :)
Router({
routes: [
{
path: '/лента',
component: Лента,
props: { photoId: null }
},
{
path: '/лента/:photoId',
component: Лента,
props: (route) => ({ photoId: parseInt(route.params.photoId) })
}
]
})
@@user-bl7bj6jk4o Не сработает. Фото не имеет никакого отношения к ленте. вы можете открыть фото из ленты, из профиля, из поиска - откуда угодно. И везде поведение остается одно и то же - урл меняется на урл фото, но фото открывается в попапе
@Antaresx github.com/vuejs/vue-router/issues/703
Жутко устаревшее видео. Очень многое уже не так.
Сперва говоришь - ой, как у вью с темплейтом всё сложно, и пропсы, и слоты, и листенеры, и ещё атрибуты.... И про то, $emit. А потом "ой, а альтернатив вьюэксу, вью-роутеру нет". "Что так просто". "А вот у реакта есть 100500 альтернатив, можно выбрать"...
Так это претензии разного уровня - к ядру и к инфраструктуре
Поймал себя на мысли что не дожидаясь конца предложения понимал о какой проблеме речь. Всё так. Самая большая боль это вьюкс для меня, ощущение что я сражаюсь с его особенностями, нежели упрощаю себе работу.
вьюкс довольно простой. но как сказано в аннотации - использовать его нужно там, где он нужен. на самом деле он очень упрощает всё и убирает кучу кода из компонентов, остаётся только дёрнуть в нём получение данных, например, и забрать геттерами. иногда ещё очень удобно сделать мутацию неких данных и получить их в любом месте вашего приложения, хотя лично я стараюсь там держать только запросы к апи и данные, которые ими получаю.
"не нравится - не ешь"
github.com/vuejs/awesome-vue#state-management
23 год, проблемы решились?)
пришлось знакомиться с vue после react и это действительно боль сделать переиспользеумый компонент во vue, и по поводу ошибок это вообще жесть, хз где копать иногда
три года пишу на вуе, ни разу не имел проблем с написанием переиспользуемых компонентов.
может боль связана с ожиданиями что вуй должен быть привычным реактом?
Человек не понимает вью. Не понимает что говорит. Но у него есть дикое желание опустить вью. Как можно вначале говорить что разнообразие решений это плохо, а следующим же пунктом говорить о несуществовании альтернатив для Vue-router? ОЛО! Да и еще - реакт гавно) Angular2+ и Vue наше все.
1) С чего вы взяли, что есть дикое желание опустить вью? Рядом с этим видео я рассказываю о его сильных сторонах
2) Позволю объяснить про разнообразие, раз вы не поняли. Уже объяснял это, но кто ж читает комментарии, перед тем как высказать свое мнение :)
Если есть задача Х, и какой-нибудь инструмент А предлагает БОЛЬШЕ одного пути решения задачи Х - это не очень хорошо, потому что вносит разброд и шатание в управление проектом.
Если же есть семейство задач X1....XN для решения которых существует только инструмент А (пример - вью роутер),то это плохо, потому что с большой вероятностью существует задача Xk которую этот инструмент не решает (невозможно решить ВСЕ задачи семейства одним инструментом). В случае с вью роутером это к примеру (уже упоминал в одном из предыдущих комментариев) facebook-style navigation:
- открытие фото в ленте обновляет урл на ссылку на это фото, НО СОХРАНЯЕТ сзади ленту - т.е. после закрытия попапа вы возвращаетесь к ленте
- F5 на открытом фото приведет к тому, что вы попадете уже на страницу фото а не ленты
Это решается путем "блокировки" роутинга на конкретное изменение урла, и в некоторых роутерах это есть (но не во вью-роутере). И это лишь один из примеров.
Поэтому прежде чем судить, что автор "не понимает вью" - с удовольствием послушаю аргументы где именно его не понимаю :)
Простите, но это не похоже на весомые аргументы. Это скорей особенности, о которых следует знать. И елси Вы занимаетесь поиском аргументов "против", то Вы разумеется найдете их для себя, целую кучу. Тут если честно, пахнет откровенным консерватизмом. Если я ошибаюсь, то вероятно Вы выпустите ролик с названием "аргументы за Vue".
Он был выпущен раньше этого ролика :) на этом же канале
@@JavaScriptNinja о, спасибо, обязательно посмотрю, в таком случае возможно и не прав)
Вот видите, вы сами путаетесь в роутерах реакта. Ну и зачем такое обилие? И vuex совсем не монстр, решает кучу проблем, если вы заранее решите использовать его во всем проекте
Дальше уже песня, то в начале рассказ про крутую магию React, а потом, что Vue магия - это плохо.
То про отладку шаблонов... Может что-то делается не так, если нужно заниматься отладкой шаблонов?
Тоже самое про тесты в шаблонов...
Во втором пункте говорит что наличие альтернативы это плохо, в третьем что наличие альтернативы это хорошо... Синьйор блин.
Вот уж не думал что придётся пояснять :)
Наличие альтернативных путей сделать что-то плохо когда они все доступны одновременно.
Если мы говорим о разных реализациях роутера - наличие альтернативы - это хорошо (позволяет не забивать гвозди микроскопом), и в проекте никогда не будет двух роутеров - принцип "всегда понятно как делать что-то" не нарушается.
С удовольствием почитаю-послушаю-посмотрю конструктивную критику утверждений :)
Несколько роутеров = бОльшая вероятность упустить что-то и "взять не тот", в случае вю просто ищется решение проблемы, а так как роутер один, то комьюнити скорее всего имеет решение.
"позволяет не забивать гвозди микроскопом" в коне не согласен
Вю роутер - просто молоток которым можно забить любой гвоздь(большой или маленький) НО иногда не 100% удобно
Роутеры реакта - куча молотков на все случаи жизни, НО взять с собой можно только один(маленький, средний И тд)
@@Omeha2 можно взять хоть все. Другое дело, что в этом нет смысла
на 05:30 - не "сложно", а гибко ИМХО
Такое же про реакт есть?
следующее на очереди
JavaScript.Ninja не вышло пока? В плейлисте только про vue нашёл :(
А как относишься к $mol?
Важно и существенно 1 и 6.
Vue хорошо для быстрого выхода в продакшен, для того, чтобы все кто хотят сейчас получить СПА за недорого и быстро и проект не "мастодонт" - Вью единственный адекватный вариант.
Но есть одно но, проект будет одноразовый. Поддерживать невозможно.
И вроде как ты начинаешь на вью и все легко.. А потом... Чтоб я на это велосипеде ездил? Ну, его!
Выйдет вью3, но проблем №1 так и не решится похоже.
А в общем видео - легкий хейт. Обещанного про реакт так и не было.
Спасибо за комментарй. Обещанное про React будет :)
Видя как люди пишут на вью, я вообще нифига не удивлен подобным комментариям. Мб прежде чем писать такое, сначала нужно подумать, как правильно использовать инструмент, чтобы потом не удивляться тому, что он сломался?
Я прочел лишь одну книгу по программированию - Чистой Код от Мартина, и только это позволяет мне понимать, то как и для чего делать большую часть вещей, к чему нужно стремиться и чего придерживаться. А это лишь одна книга, которая говорит о низкоуровневой организации кода. И хотя книга, как мне показалась, ориентирована на бекенд разработку(да там даже код на JAVA..), то почерпнул для себя очень много полезных вещей.
Полагаю, если идти дальше, то можно научиться писать и вовсе отлично поддерживаемый и расширяемый код
Читайте доку, она потрясающая. Вью очень прост и легкий для входа. В общем этот ролик чистый субъективизм и непривычность работы в стеке
Сейчас с vue единственный минус как по мне - это ничтожно малое колличество вакансий по сравнению с реактом.
Помню как писал шаблоны в jsx на реакте, было не очень, возможно уже все поменялось, не знаю.
И другое дело vue, лично для меня было более интуитивно понятнее писать код. С vuex так же.
По поводу альтернатив, пишешь миксины, которые выполняют плюс минус ту логику, которая нужна и использовалась ранее и подключаешь в компоненты.
реакт и вью это самое просто что я видел, учите ангуляр и rxjs и поймете что такое нормальный чистый код
Ну он еще и код ревью делает. И тесты пишет. Прям святой человек.
Надо хайп устроит, и холивар, чтобы канал раскрутить))
Нет, просто часто спрашивали :) Надоело в каждом АМА овтечать
Вы должны понять что Vue не для новичков, к сожалению. Если что-то пйдет не так (а оно пойдет не так, у вас должен быть в запасе свой Еван Ю для отладки и починки неотлаживамого и неисправимого кода, чтобы просто заменить неработающий кусок новым работающим). Иногда, в принципе, осмысленен переход с Vue.js в некоторых местах на vanilla js, чтобы залатать те или иные дыры, но это звучит как ночной кошма, однако вместе с vanilla js вы поолучите mockups, karma, mocha, chai и 100% code coverage. Так что да, Vue.js только для тех, кто не бооится написать свой собственный Vue.js и понимает как это делать. То есть может форкнуться от Vue2, в противном случае, пока что лезть в бутылку рано. Но Vue 2 это лучший из двух Vue, который есть на данный момент. Ждем третьего прихода.
А что тогда для новичков? Мне, как новичку, vue показался самым простым и дружелюбным (в сравненении с angular и angular.js, react вообще страшно пробовать из-за обилия библиотек).
Короче автор разочаровал, теория на отлично, но практики 0. Все измеряются с точки зрения react.
Это так же как измерять react с точки зрения vue.
vimeo.com/304510118/9734474fb5 Вот "с примером" - конкретнее уже некуда (смотреть комфортно на 2х) - если разбирать каждый из пунктов так - то и в пару часов не влезть) - код из примера - github.com/jsninja-demos/vue-sofia-meetup
JavaScript.Ninja пример для vue адовый(еще и Jquery подътянули , клево). Можно было все намного проще
@@webs3787 Я специально два раза в том видео сакцентировал, что "jquery" здесь как пример - это может быть любой компонент, который не-родной для vue (к примеру любое maps API) или любой веб-компонент :) Поражаюсь, что я на это расставляю акцент в видео, люди же предпочли привязаться к jquery :)
Намного проще - с удовольствием посмотрю ваше решение
@@JavaScriptNinja С огорчением должен признать вашу правоту Илья, что есть проблема с пробросом, $listeners, реактивностью в данном контексте(github.com/jsninja-demos/vue-sofia-meetup, vimeo.com/304510118/9734474fb5).
ЗЫ: данную проблему встречал раннее, но думаю это баг работы $listeners
Эм. Вью + бабель = сорс мап. Не?
Нет.
@@JavaScriptNinja тогда что по вашему делает настройка "Enable production Source Map" в настройках проекта? goo.gl/images/KU9Khu
@@JavaScriptNinja или вот документация cli.vuejs.org/config/#productionsourcemap
Хотя с бабелем я погарячился
@@cannibalmtl генерирует сорсмапы для vue файлов. Но сорсмапы для шаблона не генерируются
ng serve \o
vue прекрасен, если не использовать vuex.
и сам vue
vuex просто нужно использовать грамотно, с ним нет проблем, он очень удобен. возможно это только тогда, когда его структура написана нормально, у меня нормально и проблем вообще нет, всё разложено чётко по полочкам, всё всегда под рукой. В своё время, я искал реализацию сторожевых хуков и очень годный пример был с использованием vuex. Vuex в примере имел грамотный синтаксис и структуру. Разобравшись с сторожевыми хуками, я оценил всю его мощь и удобство и перенёс туда все запросы к апи - код стал в разы чище в компонентах. Его стоит использовать, когда точно понимаешь зачем это надо. Если не понимаешь, то нефиг его добавлять в проект.
Ну и отдельная песня это Vue-файлы. Вроде мелочь, но бесит. 1 vue file = 1 vue component. И если я привык после React дробить всё на маленькие компоненты, то тут я должен буду плодить или в 3 раз больше файлов... Или писать большие компоненты. Я просто отказался от vue-файлов и завёл плагин для babel-я который компилирует шаблоны vue из `template: `
Пункт 1.
Вроде бы умный чувак, а говорит такие глупости. Компоненты высших порядков - это костыль для компенсации проектирования фреймворка жопой вместо головы, а не фишка.
... Слушаем дальше.