Как говорил М.Т. Калашников: «Просто» сделать в 1000 раз сложнее, чем «сложно». Веб-индустрии понадобилось более половины десятилетия, чтобы прийти от фреймворков-монстров к простой и элегантной конструкции. В IT простота это не только сэкономленные часы работы, а ещё и прозрачная архитектура, выливающаяся в понятный код, меньшее число багов, более быстрое внесение изменений и много других приятных вещей.
В этой статье я проведу сравнение Vue.js с двумя наиболее популярными на данный момент фреймворками: Angular и React. Vue.js намного моложе, поэтому разговор будет прежде всего о нём, об Angular и React грамотные разработчики и так знают. Я бы не начинал этот разговор, если бы Vue не предлагал чего-то действительно стоящего. К счастью это так, и я утверждаю, что в большинстве случаев Vue.js может серьёзно снизить сложность ваших программ, сделать код более лаконичным и выразительным, а отладку — короче и проще. Подробности под катом. Поехали!
Если совсем кратко, то Vue.js — невероятно ненавязчивый фреймворк. Если Angular и React заставляют вас установить целый зоопарк зависимостей, то Vue в минимальной конфигурации не просит от вас абсолютно ничего, кроме собственного js-файла. За это он даёт custom controls, data binding, кастомные директивы и, фактически, все востребованные фишки основных фреймворков. Пример ненавязчивости:
Достаточно просто подключить библиотеку, создать контейнер и вызвать конструктор, всё как в старом добром Angular 1, только без его тормозов:
Это действительно весь код, который вам нужен, это не шутка. Вы можете прямо сейчас скопировать его в редактор, сохранить как something.html и он будет работать. Без плясок с бубном, dependency hell и прочих артефактов современности. Не буду рассказывать как то же самое делается в React или Angular 2+. Про то, как вытащить JSX из React или как писать без TypeScript на Angular 2+ можно написать целую статью.
Что касается конкатенации и минификации кода, то для Vue доступно много решений с готовыми сборщиками на том же yeomen (например github.com/birdgg/generator-vuejs), так же как и для React или Angular. Разница в том, что у вас есть право выбора, использовать их, не использовать, или самому создать сборщик под особенности конкретного проекта.
Распространённый сценарий развития большинства веб-приложений — увеличение плотности функционала:
Если такие компоненты встречаются в приложении один раз — ничего страшного, но чаще бывает, что они раскиданы по разным страницам и в большом количестве. Без custom control такие задачи решаются через боль, мучения и большие затраты времени, с custom controls это делается быстрее в несколько раз. Если вы не сталкивались с такой проблемой — значит у вас не было более-менее серьёзных проектов. Custom controls — это абсолютно must have в современном frontend-программировании. В Angular 1 custom controls отсутствовали (если не считать директивы, которые изначально предназначались совсем для других вещей). В Angular 2+ и React они есть, но достаются довольно дорого. Синтаксис Vue.js очень похож на Angular 2+, но без его ограничений. Немного модифицируем код, представленный выше:
Получилось чуть подлиннее, но у нас здесь custom controls. Custom controls в 20 строчках кода, Карл! При этом сам компонент занял всего 4 строчки. Что это значит на практике: что вы можете делить свой код на компоненты настолько мелко, насколько вам хочется, с минимальными издержками. Если в React создание отдельного компонента — целая история, с завязкой, кульминацией и развязкой, то в Vue это просто несколько секунд. И дело не в этих секундах, а в том, что с большим количеством компонентов у вас будут слабее зависимости и меньше багов.
Это синтетический пример компонента, но в реальных Vue.js раскрывает себя ещё лучше. Мы можем, например:
и многое другое. Для большинства этих функций нужно подключать сборщик (в документации описан webpack), однако вам дают выбор, использовать Vue на 10%, 50% или на все 100%. Плюс, на мой взгляд, они выбрали самый стабильный и прозрачный сборщик из существующих, но вы можете поменять и его. Вообще Vue поражает своей модульностью и слабосвязанностью, архитектура просто очень хорошо продуманна, что выливается в огромное удовольствие при работе с любой его составляющей. Например:
Перед тем, как открыть спойлер с кодом остановитесь на минутку и подумайте, как бы вы пропатчили незнакомую библиотеку, если бы захотели добавить туда новый кастомный метод. Подумали? Теперь открывайте ответ:
У меня есть большие претензии к команде Angular. Даже не побоюсь сказать, что они фактически убили Angular, создав два совершенно разных продукта и назвав их одним именем. Даже у Vue больше общего с Angular и 1 и 2, чем у этих версий между собой. Возникла огромная путаница в документации, которая ещё не скоро прекратится. Но дело даже не в этом, как гласит один из канонических принципов создания хорошего ПО: делайте программы открытыми для дополнения, и закрытыми для изменения. Подобные радикальные изменения API Angular говорят о том, что продукт изначально был создан проблемным, идеальные программы не нуждаются в изменениях (например /bin/true в linux не переписывалась с 1984 года :)). Конечно Angular это не /bin/true, но реформы — всегда признак проблем.
В чём же причина? Я думаю в том, что как React — это проект для внутренних нужд Facebook, так и Angular 2+ — это проект для внутренних нужд Google. Конкретной компании не требуется поддерживать универсальность. Зачем поддерживать ES6, если в самой компании пишут на TypeScript? Зачем отделять React от зависимостей, если внутри компании он без зависимостей не используется? Конечно пользователи просят, и иногда им идут на встречу, чтобы они совсем не отвернулись, но всё же главная задача этих проектов — не наше с вами счастье, а облегчение найма в эти компании, когда приходит новичёк и уже знает основной стек технологий. Но стек конкретной компании, пусть даже очень крутой, не может являться стандартом для всей отрасли. Отсюда все проблемы с Angular и React. Vue, насколько мне известно, напротив, создавался именно для сообщества, поэтому получился модульным, универсальным, легко адаптируемым под нужные задачи.
В этой статье я проведу сравнение Vue.js с двумя наиболее популярными на данный момент фреймворками: Angular и React. Vue.js намного моложе, поэтому разговор будет прежде всего о нём, об Angular и React грамотные разработчики и так знают. Я бы не начинал этот разговор, если бы Vue не предлагал чего-то действительно стоящего. К счастью это так, и я утверждаю, что в большинстве случаев Vue.js может серьёзно снизить сложность ваших программ, сделать код более лаконичным и выразительным, а отладку — короче и проще. Подробности под катом. Поехали!
Если совсем кратко, то Vue.js — невероятно ненавязчивый фреймворк. Если Angular и React заставляют вас установить целый зоопарк зависимостей, то Vue в минимальной конфигурации не просит от вас абсолютно ничего, кроме собственного js-файла. За это он даёт custom controls, data binding, кастомные директивы и, фактически, все востребованные фишки основных фреймворков. Пример ненавязчивости:
Как выглядит простейшая программа на Vue
Достаточно просто подключить библиотеку, создать контейнер и вызвать конструктор, всё как в старом добром Angular 1, только без его тормозов:
<div id="app">{{ message }}</div>
<script src="https://unpkg.com/vue"></script>
<script>
new Vue({
el: '#app',
data: {
message: 'Hello Vue!'
}
})
</script>
Это действительно весь код, который вам нужен, это не шутка. Вы можете прямо сейчас скопировать его в редактор, сохранить как something.html и он будет работать. Без плясок с бубном, dependency hell и прочих артефактов современности. Не буду рассказывать как то же самое делается в React или Angular 2+. Про то, как вытащить JSX из React или как писать без TypeScript на Angular 2+ можно написать целую статью.
Почему бы не оставить всё как есть
Чем плох TypeScript? Хотя бы тем, что я его не заказывал. В 2005-м году мы боролись за каждый килобайт веса страницы, а сейчас сайты весят по 15 мегабайт и, как будто бы, так и нужно, но это неуважение к пользователю. Я не говорю, что в этом виноват TypeScript, или JSX, или 100500 других побочных технологий, но я хочу сам выбирать, что использовать, а что нет. И чтобы не пришлось платить за этот выбор часами на stackoverflow.
Что касается конкатенации и минификации кода, то для Vue доступно много решений с готовыми сборщиками на том же yeomen (например github.com/birdgg/generator-vuejs), так же как и для React или Angular. Разница в том, что у вас есть право выбора, использовать их, не использовать, или самому создать сборщик под особенности конкретного проекта.
Custom Controls
Распространённый сценарий развития большинства веб-приложений — увеличение плотности функционала:
- у вас была обычная кнопка, а стала кнопка со индикатором состояния запроса
- была обычная таблица, а стала таблица с сортировкой и фильтрами
- было обычное меню, а стало меню с многократной вложенностью
Если такие компоненты встречаются в приложении один раз — ничего страшного, но чаще бывает, что они раскиданы по разным страницам и в большом количестве. Без custom control такие задачи решаются через боль, мучения и большие затраты времени, с custom controls это делается быстрее в несколько раз. Если вы не сталкивались с такой проблемой — значит у вас не было более-менее серьёзных проектов. Custom controls — это абсолютно must have в современном frontend-программировании. В Angular 1 custom controls отсутствовали (если не считать директивы, которые изначально предназначались совсем для других вещей). В Angular 2+ и React они есть, но достаются довольно дорого. Синтаксис Vue.js очень похож на Angular 2+, но без его ограничений. Немного модифицируем код, представленный выше:
<div id="app">
<ol>
<todo-item v-for="item in list" :todo="item"></todo-item>
</ol>
</div>
<script src="https://unpkg.com/vue"></script>
<script>
Vue.component('todo-item', {
props: ['todo'],
template: '<li>{{ todo }}</li>'
});
new Vue({
el: '#app',
data: {
list: ['first item', 'second item']
}
});
</script>
Получилось чуть подлиннее, но у нас здесь custom controls. Custom controls в 20 строчках кода, Карл! При этом сам компонент занял всего 4 строчки. Что это значит на практике: что вы можете делить свой код на компоненты настолько мелко, насколько вам хочется, с минимальными издержками. Если в React создание отдельного компонента — целая история, с завязкой, кульминацией и развязкой, то в Vue это просто несколько секунд. И дело не в этих секундах, а в том, что с большим количеством компонентов у вас будут слабее зависимости и меньше багов.
Это синтетический пример компонента, но в реальных Vue.js раскрывает себя ещё лучше. Мы можем, например:
- вынести весь код компонента в отдельный *.vue файл, включая html, css и javascript
- использовать css-препроцессоры прямо в коде файле компонента, просто указав lang=«scss» или другое
- использовать любые глобальные объекты или получать объекты через import (в React, кажется, на это есть ограничения)
- использовать компоненты только внутри других определённых компонентов, без объявления в глобальной области видимости. Использовать компонент под другим именем, без изменения самого компонента (удобно в случае коллизии имён сторонних компонентов)
и многое другое. Для большинства этих функций нужно подключать сборщик (в документации описан webpack), однако вам дают выбор, использовать Vue на 10%, 50% или на все 100%. Плюс, на мой взгляд, они выбрали самый стабильный и прозрачный сборщик из существующих, но вы можете поменять и его. Вообще Vue поражает своей модульностью и слабосвязанностью, архитектура просто очень хорошо продуманна, что выливается в огромное удовольствие при работе с любой его составляющей. Например:
Создание своих плагинов
Перед тем, как открыть спойлер с кодом остановитесь на минутку и подумайте, как бы вы пропатчили незнакомую библиотеку, если бы захотели добавить туда новый кастомный метод. Подумали? Теперь открывайте ответ:
Как это делается в Vue.js
Vue.prototype, Карл! Вам даже не нужно знать документацию, вы её и так знаете большую её часть на уровне подкорки. Больше никаких странных конфигов, магических свойств, которые нужно указать, чтобы всё заработало. Просто Vue.prototype и имя вашего метода, почему все фреймворки не используют это? Если хотите устанавливать плагин через Vue.use(MyPlugin), то нужно определить метод MyPlugin.install, но это, как и многое в Vue, по вашему желанию.
Vue.prototype.$myMethod = function (methodOptions) {
// something logic ...
}
Vue.prototype, Карл! Вам даже не нужно знать документацию, вы её и так знаете большую её часть на уровне подкорки. Больше никаких странных конфигов, магических свойств, которые нужно указать, чтобы всё заработало. Просто Vue.prototype и имя вашего метода, почему все фреймворки не используют это? Если хотите устанавливать плагин через Vue.use(MyPlugin), то нужно определить метод MyPlugin.install, но это, как и многое в Vue, по вашему желанию.
Общая обстановка
У меня есть большие претензии к команде Angular. Даже не побоюсь сказать, что они фактически убили Angular, создав два совершенно разных продукта и назвав их одним именем. Даже у Vue больше общего с Angular и 1 и 2, чем у этих версий между собой. Возникла огромная путаница в документации, которая ещё не скоро прекратится. Но дело даже не в этом, как гласит один из канонических принципов создания хорошего ПО: делайте программы открытыми для дополнения, и закрытыми для изменения. Подобные радикальные изменения API Angular говорят о том, что продукт изначально был создан проблемным, идеальные программы не нуждаются в изменениях (например /bin/true в linux не переписывалась с 1984 года :)). Конечно Angular это не /bin/true, но реформы — всегда признак проблем.
В чём же причина? Я думаю в том, что как React — это проект для внутренних нужд Facebook, так и Angular 2+ — это проект для внутренних нужд Google. Конкретной компании не требуется поддерживать универсальность. Зачем поддерживать ES6, если в самой компании пишут на TypeScript? Зачем отделять React от зависимостей, если внутри компании он без зависимостей не используется? Конечно пользователи просят, и иногда им идут на встречу, чтобы они совсем не отвернулись, но всё же главная задача этих проектов — не наше с вами счастье, а облегчение найма в эти компании, когда приходит новичёк и уже знает основной стек технологий. Но стек конкретной компании, пусть даже очень крутой, не может являться стандартом для всей отрасли. Отсюда все проблемы с Angular и React. Vue, насколько мне известно, напротив, создавался именно для сообщества, поэтому получился модульным, универсальным, легко адаптируемым под нужные задачи.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Поделиться с друзьями
rumkin
Нельзя сравнивать библиотеки хеловордами и туду листами. Соглашусь, что React и Angular требуют много зависимостей и тяжеловесны. Но в больших приложениях (даже начинающихся с легковесных библиотек), которые состоят из множества маленьких модулей рано или поздно наступает такой момент, когда вес страницы начинает зашкаливать из-за того, что каждая библиотека тянет за собой множество дублирующих друг друга вспомогательных библиотек (как пример одновременное подключение lodash и underscore). Это неприятно, но на данный момент неизбежно. Так, что давайте сравнивать по срезу проектов и по нескольким показателям.
Для меня главным ресурсом является время на разработку, все остальное я могу оптимизировать.
rboots
Полностью согласен, но в рамках статьи показать что-то сложнее hello world и todo затруднительно. На Vue я пару месяцев назад начал первый production-проект, и пока ощущения лучше, чем от Angular и React, которые тоже использовал в production. Вот и решил поделиться.
rumkin
С чего вы взяли?
Так дело не пойдет. Переименуйте тогда статью в "Почему я считаю vue лучшим фреймворком 2017" ну или как-то так.
rboots
Ну видите, у нас на простых вещах разногласия, а вы хотите, чтобы я здесь сложные описывал. У меня не хватает таланта. Напишите свою статью про то, как надо писать статьи)
antonksa
Вам говорят о том, что вы поймали хайп.
Мы за вас конечно рады, но вам предложили написать, что это ВАШЕ СУГУБО ЛИЧНОЕ МНЕНИЕ, а не безаппеляционное заявление, как сейчас выглядит заголовок.
rboots
Все оценочные утверждения это лишь мнения. Или вы думаете, что где то на планете есть великий мудрец, объявляющий «А на этот год лучший фреймворк такой-то». Естественно это мнение, странно, что можно решить иначе. К этому мнению я привожу список агрументов, так сказать, доказательств теоремы. Ваше право указать на неверные тезисы или согласиться.
rumkin
Все оценочные суждения должны быть помечены как таковые, иначе подтверждены фактами или раскрыты. Лучший по мнению экспертов, по показателям скорость/качество, по мнению моей мамы. По-умолчанию подразумевается лучший вообще, а не "по моему мнению". Иначе у вас получается кликбейт или, по-русски, желтый заголовок.
И это стандарт принятый в журналистике и научной публицистике, так что доводы из разряда "не знаю что вы там подумали" здесь не работают. Поэтому советую воздержаться от перепихивания вины на читателя.
raveclassic
Вы что, серьезно?
Тоже пару месяцев?
rboots
С учётом того, что Vue начал набирать реальную популярность только в 2016 и многие до сих пор боятся использовать его в production — абсолютно серьёзно. Сколько вам надо, 5 лет? На Angular наверное наберётся, но Vue в принципе моложе. Плюс документация осваивается за пару вечеров, а косяки которые не всплыли за первые два месяца, вряд ли могут иметь критическое значение, всё серьёзное проявляется очень рано.
staticlab
Как раз архитектурные недостатки начинают проявляться на довольно сложных приложениях, которые пишутся дольше, чем пару месяцев.
rboots
Vue придумал очень мало нового, всё кроме слотов уже было в том или ином фреймворке, только в менее удобном виде, поэтому архитектурные вопросы прекрасно оцениваются. Просто посмотрите из каких частей он состоит.
staticlab
Ниже я уже показал, что концепция слотов не так уж и уникальна, если то же самое можно и в Реакте повторить.
Что касается архитектуры, то это вопрос не множества возможностей фреймворка, а, скорее, их взаимодействия между собой и с бизнес-логикой.
TimTowdy
Концепция слотов не придумана Vue. Достоинство Vue как раз в том, что вместо придумывания своих велосипедов они взяли за основу уже существующую спецификацию W3C: http://w3c.github.io/webcomponents/spec/shadow/#shadow-tree-slots
staticlab
А в чём, собственно, достоинство?
ncix
Никому не нужен новый инструмент, который нужно осваивать дольше пары недель. Или в котором через два(!) месяца чувствуешь себя новичком. Серьезно.
mariner
с Vue вам понадобится два-три дня ;) там банально нет столько функционала, что бы изучать.
TheShock
Может проблема во фреймворке? Или еще в чем-то?
Я в своих статьях описывал даже создание небольших игрушек. Конечно, это не очередной хелло-ворлд, но ничего особо затруднительного не вижу. Если есть знания и материал, то вполне себе описывается.
Areso
Написал игру на чистом JS, причем используя очень старые вещи. Ничего, работает)
Даже jQuery пока нет в зависимостях.
TheShock
Ну и где статья? Мы ведь о статьях говорим, а не о игрушках?
В рамках статьи о Vue сложно написать что-то сложнее Hello World, но в рамках статьи о других фреймворках и даже без фреймворков пишут вещи, которые значительно сложнее.
Следовательно может быть проблема во фреймворке, что с ростом сложности читаемость падает слишком быстро и для статьи такой код не подходит.
Areso
Вы всерьез хотите увидеть статью об очередной ферме на JS, написанной любителем? Я ведь зарабатываю деньги совсем другими вещами. Причем написанной без новых, модных фич JS? К тому же код демонстрирует значительное количество непоследовательных решений, которые точно нельзя назвать best practice (к примеру, рендер в Canvas, а поверх просто расположение картинки со своими функциями или анимации, чтобы не мучаться с разделкой анимации и вставкой анимации покадрово в Canvas). Т.е. мне непонятно, чему бы я мог научить других людей такой статьей, а пиарить поделку-на-коленке тоже я смысла особого не вижу.
Так-то написать можно, был бы положительный выхлоп.
Tynnopet
Писал по небольшому компоненту, с большим количеством перерисовок на react и vue. Из-за встроенного observable и computed свойств vue обошел реакт в 3 раза по фпс. Помимо этого кода было на порядок меньше, из-за тех-же computed свойств. Как я ни старался react по lifecycle хукам оптимизировать — vue без оптимизаций был быстрее.
Reon
Откуда у вас такая информация, что именно по этим причинам?
RubaXa
Tynnopet
Достаточно посмотреть на области перерисовки при одной архитектуре компонента
justboris
Не может такого быть, чтобы Реакт не смог сделать перерисовку только изменившихся частей.
Покажите код, и может быть, я укажу, что было там не так.
vintage
Может. Там довольно дубовый реконцилятор. Достаточно перенести элемент в другого родителя и он сделает полную его перерисовку.
justboris
А зачем вам переносить элемент в другого родителя?
Сколько разных интерфейсов ни писал, но этого делать не пришлось.
vintage
Дрегендроп, фуллскрин, да и просто динамический лейаут.
justboris
Пользователь не сможет провести столько драгендроп операций в секунду, чтобы это сказалось на производительности, разве нет?
Про фуллскрин и динамический лейаут я не понял пример, расскажите подробнее
vintage
Достаточно перетащить тяжёлую панель из левого дока в правый.
Листаете ленту, наткнулись на видос, решили тут же глянуть о чём он, заинтересовало, решили открыть его в попапе, чтобы покрупнее.
Смотрели список задач плоским списком, а потом решили сгруппировать их по ответственному.
mariner
использую с октября прошлого года. скорость разработки высокая, нехватка функционала (например, http клиент), быстро решается интеграцией того же axios через плагин к Vue. в общем, все круто там. не хочется возращаться к ангулару или реакту.
экосистема развивается — https://github.com/vuejs/awesome-vue
и да, single file components это просто бомба!
franzose
http-клиент есть: https://github.com/pagekit/vue-resource
mariner
Его больше не рекомендуют использовать (в блоге разрабов вью). Советуют axios.
franzose
Хм, спасибо, не знал. Надо будет в своём репозитории (https://github.com/franzose/symfony-ddd-wishlist) переделать на axios тогда, чтобы не вводить людей в заблуждение.
s256
По какой причине? Для простых вещей вроде довольно удобный
Fragster
По той, что есть axios. Это официальная позиция :)
franzose
Хотя это тоже отдельный плагин)
j_wayne
Vue мне хорошо подошел в проекте, т.к. уже есть фронтенд на jquery, целиком переписывать я не хочу, но с поддержкой уже есть проблемы и для новых фич нужна реактивность.
Vue я могу применять точечно, для новых фич и постепенно переписывая старые.
«Чистые» Elm и React/Redux не осилил, слишком много обычных сторонних либ.
Vue не мешает «срезать углы» и сделать грязный хак, если надо.
P.S. Также, я вынужденный фулл-стек программист и изучать большие фреймворки нет ресурсов.
rboots
Так же не мешает вместо грязного хака сделать чистое архитектурное решение, например делегировать часть функционала другому модулю/библиотеке, который справляется с ней лучше. По мне так это плюс, что Vue «не мешает», а как пользоваться полученной свободой — уже ответственность программиста.
friday
Вот так всегда и бывает: сначала срезают углы и делают грязные хаки, а потом жалуются на проблемы с поддержкой.
j_wayne
А проблемы с поддержкой уже были и более серьезные — легаси лапшекод на jquery.
Я пробовал внедрить ограниченно (в рамках новой фичи ) react/redux, потом Elm.
Концептуально красиво, безусловно. Особенно Elm.
Но у меня просто нет ресурсов взять и переписать все эти уже используемые календари, чарты, пикеры и прочие сторонние библиотеки на redux/elm.
В частности, jquery draggable/droppable. На redux я еще худо бедно сделал, вроде даже и в рамках концепции, но выглядело в коде это не ахти.
На Elm drag/drop я просто не осилил (был глючный пример для старой версии, но как раз вышла новая где этот API прибили). Я думаю, что в принципе это возможно, но лично у меня заняло слишком много времени и непонятно, зачем такие сложности. Done is better than perfect. Это не значит, что к совершенству не надо стремиться. Но иногда компромисс неизбежен.
justboris
Если и история, то очень короткая:
rboots
Это со статическим содержанием, а попробуйте хотя бы аналог компонента из примера, с одним свойством, отображаемым в содержании. Сколько строк получится?
andy128k
Столько же
rboots
Неплохо, но длина строк тоже имеет значение. 221 символ против 98 в пользу Vue. Хотя это не суть, суть в простоте и удобстве.
Alex_ME
Почему не JSX?
Согласитесь, так гораздо нагляднее и компактнее, без всякого синтаксического шума, как выражались некоторые комментаторы.
TheShock
Кстати, с es6 импортами вполне можно было сделать довольно изящно на функциях без всяких синтаксических дополнений:
Или более развернуто:
В аргументах функции объект — это свойства, а массив или строка — чилдрены.
Как по мне — вполне соответствует JSX по наглядности и компактности.
Alex_ME
Не могу с Вами согласиться. Все-таки JSX — по-сути привычный всем HTML, а этот синтаксис необычен и более многословен (все эти скобки и прочее). Есть ли плюсы у такого подхода? Всегда считал JSX одной из сильных черт реакта.
TheShock
На счет многословности не соглашусь: xml в принципе более многословен за счет закрывающего тега и кучи угловых скобок. По сути для крайнего случая это:
Для самого простого:
И т.к. мы пишем на JS, то всем кто это пишет это настолько же привычный JS, как и HTML.
Лично мне нравится jsx, я просто описал, что такая альтернатива есть.
Из плюсов — такой подход не нужно собирать (для браузеров с es6 и nodejs), это нативный JS (слабый плюс, конечно, но все-же). Ну и код слегка короче получается. Либы, которые хотят сделать «так же легко как в реакте, но без jsx» — могут использовать именно этот подход, он не сильно отличается.
sshikov
Ну исли этот синтаксис и необычен — то только для вас. Его полно везде, и уже давно.
Да, фактор непривычности всегда существует, но тут вы его явно преувеличиваете. Это просто javascript, если на то пошло.
Да. Такой синтаксис лучше компонуется. Если вы генерируете свой компонент из какой-то структуры данных, то так обычно удобнее.
Mox
Эта штука хорошо бы сработала с CoffeeScript — получился бы HAML по сути
Fragster
ну а в vue просто используем pug
vintage
Добавляем интерактив с пользователем и получаем куда более увлекательный сюжет.
justboris
Не больше чем в аналогичном todo-list на Vue
И вот работающий JSFiddle
dom1n1k
Гораздо больше, если так можно выразиться, синтаксического шума.
justboris
Согласен, причесал немножко: https://jsfiddle.net/nwtmq49k/1/ Стало лучше?
Ну и не стоит забывать о JSX. Если проект намечается большим, то тут уже можно и JSX подключить и писать верстку нормально.
rboots
Неплохо, но хитрость с map обернётся слабой выразительностью кода. И в целом javascript получилось не меньше, в изначальном примере его всего 11 строчек javascript, остальное — html, импорт библиотеки, теги script и т.п… Если сравнивать Fiddle, то вот: https://jsfiddle.net/km8jug2f/2/
В целом соглашусь, что практически равные результаты, но Vue всё же читается и пишется проще.
raveclassic
Почему хитрость? Обычное преобразование
Почему? Разве стандартная языковая конструкция хуже чем кастомный dsl?
Какая разница чего сколько, если все — исходники?
justboris
Ну вот, видите, не так уж страшно на React писать. А в статье много необоснованного хейта
Не надо так.
rboots
Официальная документация просит зоопарк устанавливать. Даже самый простой вариант с single html запрашивает babel и делает преобразование из jsx, что увеличивает время отрисовки страницы, по моим замерам, до 1.5 секунды. Кто же знал, что вы познали Дао React и можете написать Hello world лучше, чем основатели React. К вам претензий нет, к ним — есть, в том числе за документацию.
raveclassic
Так вы в рантайме его зачем гоняете?
rboots
Это не я, это официальная документация) Упаковка это хорошо, но я хочу иметь выбор. Почти любой фреймворк на чистом JavaScript прекрасно работает и в рантайме, а babel и typescript — нет. При этом преимущества такой надстройки абсолютно не очевидны, а минусы на ладони.
Alex_ME
Чтобы использовать более удобные вещи, которые еще не поддерживаются всеми браузерами (es6, 7, что там еще), совсем не поддерживаются браузерами (typescript, jsx, sass/less).
rboots
Они ещё остались? На мой взгляд async await была последней, если только вы программируете на для гос учреждений, не обновляющих браузеры.
staticlab
Object rest/spread, например
rboots
1. конструкция очень спорная и может породить кучу багов
2. если очень хочется — можно использовать apply
3. проблемы с параметрами как таковой нет. С асинхронностью есть, с разбиентием на компоненты — есть, с параметрами — нет
staticlab
Простите, но что вы несёте?
raveclassic
Банально es6-модули
rboots
Есть сотни инструментов для этого, не тянущих за собой столько лишнего, как babel. Webpack, requirejs, ещё в 2012 мы самописные инструменты писали на 50 строчек, штука нужная, но очень простая
raveclassic
Вы какой-то странный хейтер бабеля. То есть дополнительные инструменты в проект тащить ок, но только не бабель?
staticlab
Очевидно же, потому что бабелем можно транспилировать JSX.
Alex_ME
Если уж у нас есть всякие инструменты преобразования кода
то какая проблема добавить еще один для трансляции js?
justboris
А вот и нет. По указанной вами ссылке страница с тремя опциями: Try React, Create a New App, Add React to an Existing App
Первая дает ссылку на codepen с примерно таким же контентом, как я написал в JSFiddle.
Тут скорее проблема в том, что в сообществе, в том числе и на Хабре, сложился шаблон React — это Redux, Webpack, Babel и никак иначе. Так теперь и кочует из статьи в статью.
rboots
В примере на codepen тоже используется babel
staticlab
И что? При транспиляции babel превратит его в такой:
JSX не используется в рантайме.
lega
rboots
Что за гибкие шаблоны? Гугл не знает, по ссылкам понятный, но ничем не примечательный код. Какую задачу вы хотите решить? Может быть вам нужны слоты, они помогают сделать шаблоны гибче.
lega
Просто вы там выше меряетесь объемом кода:
Вот вам пример где vue проиграет, так же vue тут может поиметь проблем с миксом контекстов на одном шаблоне.rboots
Так что за гибкие шаблоны то? И почему вы решили, что Vue обязательно проиграет?
lega
Я вам ссылку на статью кинул, там подробнее об этом. Дак от вас стоит ждать аналога на vue? для сравнения сложности и объемов вариантов.
rboots
Понял, вы хотите менять шаблон компонента в зависимости от его параметров. Архитектурно это не правильный подход, так как шаблон для каждого типа компонентов компилируется один раз и сделать его динамическим — придётся платить за это тормозами, в любом фреймворке. Правильным подходом будет создать фабрику компонентов, где сгенерировать для каждого шаблона отдельный компонент со общими настройками логики. На практике же как правило достаточно того, что вам предложили в конце статьи, или внести все варианты шаблона в один и разрешить классами, или разрешить в шаблоне через if else. Код переписывать не буду — слишком много букв.
raveclassic
Не шаблон и не менять. Мне (и не только мне) нужен инструмент для проброса компоненту класса другого компонента для внутреннего использования в качестве параметра. Ну, проще говоря, компонент высшего порядка. TS/flow тут еще и помогает описать интерфейс этого нужного компонента.
Я не собираюсь на каждый чих лазать в базовый компонент и накручивать в нем дополнительные флаги/аттрибуты. Мне нужен должный уровень абстракции, и не один движок со статическими шаблонами мне этого не даст.
JSmitty
Не очень вникал, но то, что вы описываете — очень похоже на механизм scoped slots во Vue.js — доступный с 2.1 версии.
raveclassic
Спасибо за наводку. Подходит скорей dynamic components из ссылки.
s256
Что касается custom controls я бы упомянул одну из мощнейших, на мой взгял фич Vue — слоты. Они привносят наследование в шаблоны, и в идеале я могу переопределять разметку чужих компонентов не затрагивая логику!
staticlab
В реакте прямой аналог неименованных слотов — это this.props.children, а именованных — другие кастомные пропы:
app-layout:
parent-container:
Результат:
indestructable
Vue использует глобальный объект для регистрации компонентов.
В результате переименование — проблема, появляется зависимость от порядка объединения файлов, ну и узнать, где какой компонент, можно только поиском.
Реакт, при всех его расписываемых недостатках, имеет одно большое преимущество — это джаваскрипт, а не кастомный язык шаблонов. Причем джаваскрипт современный, использующий новые возможности, а не борющийся с ними, как первый Ангуляр.
rboots
В любом компоненте можно определить свой локальный список components, дать им любые псевдонимы и не зависеть от имён компонентов (самый правильный пусть).
React безусловно крут, иначе его не было бы в этом сравнении, но JSX это не JavaScript. На JavaScript без JSX можно, но тогда уж проще на VanillaJS, ещё быстрее будет. А шаблоны удобны тем, что их можно отдать верстальщику и снять с разработчиков 50% рутины, там шрифты не те, тут цвет и прочие не относящиеся к программированию вещи.
indestructable
Я не использовал Vue, не могли бы вы показать коротенький пример или ссылку на доку?
Я так понимаю, что в файлах определяется только конфигурация компонента (второй параметр
Vue.component), а регистрируются дочерние компоненты прямо в родительском?React — это далеко не только JSX, очевидно же. И JSX — это 10% его функционала максимум, просто самое запоминающееся.
avdept
Писать шаблоны в jsx ничем не сложнее обычного хтмл
TimTowdy
Писать — да. Но не читать.
Посмотрите на PHP — это язык-шаблонизатор. Но почему-то в подавляющем большинстве случаев в нем используют сторонние шаблонизаторы. Как вы думаете, почему?
VolCh
Прежде всего для изоляции кода шаблона от остального кода приложения с основной целью запретить или сильно усложнить мутации окружения шаблона из шаблона.
avdept
Не одним php едины. Я не пишу на пыхе, и не знаю как там все обстоит. Но я знаю ситуацию в других веб ориентированых ЯП — и там используют кому что нравится, ибо отличия только в синтаксисе.
А вот в чем проблема читать jsx я не пойму. Или религия не позволяет открывать файлы в которых намешана логика и вьюха? Да jsx это то, чего на протяжении десятилетий старались избегать в других ЯП\фреймворках. Но суть реактивного подхода — «каждая запятая» это отдельный компонент, и таким образом ваш компонент не должен быть больше чем пара десятков строк кода.
TimTowdy
Я тоже на PHP никогда не писал, привел просто для примера. В подавляющем большинстве шаблонизаторов используется свой DSL, а прямой вызов кода на GPL языке либо невозможен, либо не приветствуется.
Вы, похоже, не понимаете, откуда взялся JSX. Это не просто очередной шаблонизатор. И не просто смесь логики и вьюхи.
Для борьбы с нарастающей сложностью UI, ребята из FB решили реализовать идею «UI as function of state». Чтоб это не тормозило — использовали VirtualDOM. И все вроде бы хорошо: и сложность уменьшили, и работает быстро. Но оказалось что у такого подхода есть недосткток: разметка куда-то пропадает. Есть только код, генерирующий разметку. И, как вы понимаете, когда у вас возникает задача связанная с версткой, отсутствие разметки очень сильно сказывается на продуктивности. Для этого и придумали JSX — расширение JS, позволяющее использовать XML-подобный синтаксис написания JS-VirtualDOM кода. Идея, на то время, просто отличная.
И, Vue, если вы не в курсе, делает абсолютно то же самое. Точно также транслирует код шаблона в VirtualDOM вызовы. Но делает это более элегантно, в том числе не позволяя размазывать разметку по разным кускам компонента. Эта разница во Vue и React связана с их историей. Во Vue сначала был дизайн, а VirtualDOM лишь потом оказался деталью реализации. React же с самого начала был твердо завязан на VirtualDOM, и JSX — это просто костыль, созданный для облегчения работы с ним. На 2013 год — костыль просто великолепный. Но уже 2017 на дворе.
А про «реактивный подход» вы какую-то глупость написали. Он вообще-то ни к React, ни к компонентам не имеет никакого отношения.
avdept
Мой посыл был что писать шаблоны в jsx ничем не сложнее чем на хтмл, и довода обратно я не увидел.
PS React — это и есть реализация паттерна реактивного программирования
vintage
Я бы так не сказал.
vasIvas
angular стал знаменитым благодаря архитектуре.
react стала знаменитым благодаря агрессивному маркетингу.
vue стал знаменитой благодаря laravel.
И независимо от того, кто и что любит и у кого какое мнение, пока лидирует angular.
Да и выбор, на мой взгляд, обуславливается уровнем.
rboots
Никогда не пользовался laravel. Vue стал знаменитым, потому что делает те же вещи проще и быстрее
Apathetic
Лидирует в чем?
vasIvas
В моем понимании он лидирует в нише, которой ещё только предстоит зародится. Он относительно молод, но на нем уже очень много приложений написано. Сам google на нем тоже пишет https://www.madewithangular.com/categories/google
А когда я слышу о его сравнении, то в голову приходит сравнить уровень авто bmw и ваз по количеству экземпляров в России. Это Вы об таком сравнении меня спрашиваете? Или Вы хотите знать, в чью сторону посмотрят пришедшие из java или c# программисты? Или Вы хотите сравнить по скорости разработки приложения за 10 т.р. на fl.ru с приложениями google? Или может с десктоп приложениями сравнивать jQ?
justboris
Очень интересно рассказываете. И что же это за ниша?
raveclassic
Ух ты, назревает что-то интересненькое!
Apathetic
Ангуляр относительно молод? Относительно чего? GWT?) И да, странно, что google пишет на angular, они же его создали)
Вы перечислили в своем исходном комментарии три инструмента: ангуляр, реакт, вью. И сообщили, что ангуляр лидирует. При чем тут jquery? При чем тут c#? Я задал конкретный вопрос — в чем ангуляр-то лидирует? В популярности? В количестве написанных приложений? В количестве разработчиков, желающих с ним продолжать работать? Приведите статистику, пожалуйста.
teux
Ангуляр 1 лидирует в силу древности. Вряд ли на нем начинают много новых проектов
Angular — 9.4%
React — 1,8%
Vuy 0,3% подрастает
YemSalat
Изначально плохо продуманной архитектуре и маркетингу со стороны Гугла
Скорее как альтернатива Ангуляру и на том что «это просто вьюха» (т.е. гораздоо более «легкий» фрэймворк)
На пыхе не пишу, про Ларавел знаю только название.
Vue выехал на разрабах которым нужен был легкий (во всех смыслах) фреймворк, плюс на идее фронт-энд фрэймворка без патронажа крупной организации
В каком смысле «лидирует»?
grimalschi
Vue.js — это песня. Делаю проект с использованием Hot Module Reload — невероятно удобно.
Радует, что есть Vuex, и инструменты для его отладки, встраиваемые в DevTools.
raveclassic
HMR и в react есть.
dev-tools и для react/redux есть
Расскажите лучше, чем действительно больше нравится
grimalschi
Single File Components, например.
Позволяет в 1 файле хранить HTML, JS и CSS компонента.
raveclassic
Забавно слышать, как то, от чего все раньше плевались ядом на старте Реакта, теперь приводят как преимущество.
Single File Components с самого начала пропагандировались в Реакте: html/css/js — все в одном флаконе. Только на одном языке (js) со всей вытекающей мощью.
grimalschi
JSX слабоват, но это дел вкуса.
А CSS предлагается в inline-style описывать всегда?
raveclassic
Чем же?
Уже полно инструментов, которые автоматом экстрактят стили в файл.
grimalschi
Условиями. Какой вариант читается проще?
Vue/Angular/что-угодно:
React:
Когда таких конструкций становится много, шаблон читается сложнее.
С HMR оно все работает?
raveclassic
Ну по мне языковая конструкция воспринимается проще, чем сторонний dsl. Плюс, когда таких конструкций становится много, шаблон бьется на вспомогательные функции.
Прекрасно работает. Даже с SSR и critical css.
grimalschi
Ну и ладно.
Если бы не React не было бы snabbdom, а он сейчас лежит в основе Vue.js.
Что на счет Inferno.js? В репозиторие цитируют, что один из разработчиков ядра React писал следующее:
Но Vue все-таки милее и приятнее. Это дело выбора, сами понимаете. Я с ним еще с 0.7 версии, уже несколько лет.
React у меня не получилось запустить с Redux, HRM, DevTools. Было ощущение, что пазл собираю, тогда как в Vue все части четко подогнаны друг под друга.
raveclassic
Одно время засматривался, но потом взял себя в руки. Все-таки "React-like", а совместимость и поддерживаемость важнее, в продакшн не возьмешь.
Ну чего уж лукавить, для хот-реплейса компонентов и редьюсеров там действительно поколдовать надо. Но можно начать с
create-react-app, потом сюда или сразу сюдаgrimalschi
Спасибо за ссылки.
YemSalat
Кто вам мешает писать по-человечески?
На вьюхи Реакта надо смотреть как на обычный JS. Если вы такие конструкции в обычном коде будете выдавать — на вас будут косо смотреть, в шаблонах то же самое.
TheShock
В функциональном ретурне ИФ не вставится.
vintage
Вставится:
Но самый тру вэй — это, конечно, подключить модуль
composable-js:TheShock
И станет еще более нечитабельно) Я простые условия допускаю именно такие (
{second && <Second />}), а что-то последнее когда комбинировать нужно, то просто выношу в методvintage
А когда JSX разбивается на маленькие кусочки, то он теряет последние остатки смысла:
raveclassic
Если перестать воспринимать JSX как HTML, то окажется, что XML-нотация — просто способ инстанцирования компонентов. И способ работы с SecondA будет варьироваться в зависимости от того, что она возвращает. Если компонент — JSX, если инстанс — return.
vintage
Так зачем нам несколько способов делать одно и то же?
raveclassic
В смысле? Функция и ее результат — не одно и то же. Класс и его инстанс — тоже не одно и то же. Другое дело, что new или просто вызов функции тут не спасают, нужен вызов createElement.
vintage
Я привёл два кода — они полностью равнозначны.
YemSalat
У вас некорректный второй пример, должно быть:
vintage
raveclassic
Этот трюк сработает только, если SecondA и SecondB — SFC.
vintage
С классами его тоже не трудно подружить.
raveclassic
И как же?
Вы не подумайте, меня самого xml бесит
vintage
Что-то типа:
raveclassic
Интересно. А зачем стейт держать в GlobalStore?
vintage
Чтобы он не сбрасывался при каждом создании экземпляра.
raveclassic
Вот сейчас я подвис.
Стейт же локален для компонента. Это какой-то конкретный случай или вы всегда так делаете?
vintage
Это пример как можно сделать без React.createElement. При каждом рендеринге создаются новые экземпляры компонента. Если состояние хранить локально, то оно будет теряться, вместе со старыми экземплярами.
raveclassic
И зачем тогда классы? Состояние сбоку можно доставать и из SFC
vintage
Можно, но не удобно. А с классами — отнаследовался и работаешь с this.state не парясь о том, где его хранить.
TimTowdy
Вот в этом и беда JSX. Легко писать, трудно читать.
Рано или поздно разметка расплывается по коду. Становится невозможным окинуть взглядом кусок файла и понять, а что же там отрендерится. Потому что внутри JSX у вас неизбежно появляются методы которые возвращают JSX, да еще и с условиями внутри.
raveclassic
Казалось бы и в чем проблема? Отрендерится то, что вы вернете из render или из SFC-функции. Вся мощь языка в ваших руках. Полный контроль без выкрутасов с DSL.
TimTowdy
Я вам про читаемость, а вы мне про мощь языка и контроль :)
Это зачастую противоположные вещи. Когда у вас есть четко определенная доменная область (а разметка таковой является), от мощи языка нужно избавляться.
SQL, например, потому и популярен, что вместо «мощи» языка общего назначения позволяет писать запрос на более ясном, лаконичном и читаемом языке.
Что происходит в голове у программиста (и не дай бог вместо программиста будет верстальщик/дизайнер), который пытается понять, а что же будет в итоговой разметке?
Ищем render(), читаем выражение которое он возвращает… Оппа, вызов метода — сохраняем прочитанную часть шаблона в «мозговой стэк», скроллим до renderSecond() читаем его, вычисляем, прыгаем назад по стэку, читаем дальше…
А если у вас там такое выражение?
Три раза скроллить будете? Голова не начнет болеть?
И не надо рассказывать что так на React не пишут. Пишут, да еще и гордятся этим.
TheShock
Люди не зря придумали понятие абстракции. Вам достаточно знать имя метода и понимать: «Он отрендерит second». Нету необходимости знать детали реализации всей пирамиды при работе с определенным методом.
TimTowdy
В том-то и дело. Я не хочу знать детали реализации. У меня четкая задача: понять какой будет итоговая разметка. Затратив на это минимум усилий. И чем больше джаваскрипта в разметке, тем больше понадобится усилий для понимания.
Скажете задача надуманная? Вот вам пример из жизни, юзер репортит баг: «не смог купить т.к. кнопка оплаты куда-то уехала». Естествнно предполагаем что в каких-то случаях едет верстка. Ну и что толку с вашей великолепной абстракции? Сильно она кому-то поможет?
Предложите забить т.к. юзер не привел шаги для воспроизведения? Извините, позволить конверсии просесть на неизвестную величину на неизвестный срок для бизнеса это не вариант.
Вы мыслите с позиции программиста: делаю фичу, пишу код, ввожу абстракцию…
А я мыслю с позиции жизненного цикла проекта: ввести в команду нового человека, пофиксить баг, добавить новую фичу не повысив ментальную нагрузку, позволить членам команды с разным уровнем опыта продуктивно работать в команде, продолжить работу если важный разработчик попал под автобус, минимизировать технический долг… И с этой точки зрения я зачастую предпочту именно Vue, а не React.
TheShock
Смотрим итоговую разметку и правим CSS, у нас ведь не 90-ые, когда стилизация делалась кучей вложенных дивов. Верстка — исключительно семантическая. Или у вас не так?
raveclassic
А вы, встречая в маркапе кастомный компонент, каждый раз переходите в него и смотрите, а что же он там рендерит? Ну чушь же. Компонент определяет свое предназначение своим именем, точно так же и с методами.
Можно подумать, подшаблоны и зоопарк v-if/ng-if/что-угодно-if-switch-unless выглядят лучше. Голова болит еще хуже, так как приходится переключаться между языками.
Бейте на подкомпоненты. Пять экранов html точно так же не вызывают ничего кроме изжоги.
Вас просто бесит, что вместо привычного html вы видите какую-то инопланетную js-угрозу. А сказки про неперевариваемость верстальщиками из команды JSX — так совсем полная чушь, убедился на личном опыте. Даже обезьянка поймет, как использовать методы/подкомпоненты для разбиения разметки. Еще и в восторге потом будет.
TimTowdy
Привел пример выше, совсем не чушь.
Да, выглядят лучше т.к. читаем специализированный DSL, а не мегаязык который умеет все.
Это просто смешно. Придумываем надмножество JS, чтоб не формально не переключаться между языками. Больше не нужно переключаться, ведь наш мегаязык теперь включает в себя абсолютно все!
Напоминает аргументацию креационистов: религия лучше чем наука, потому что религия может объяснить абсолютно все, а наука — нет!
Любой условный рендеринг разбивать на подкомпоненты? Нет, спасибо.
Да, я использовал JS более 10 лет, и считаю его плохим языком (даже с учетом ES6). Поэтому замену JS+HTML+CSS на JS+JS+JS считаю вредной. Но это тема отдельного разговора.
В науке личный опыт — самый слабый аргумент.
raveclassic
То есть вы серьезно, когда видите что-то вроде
<div><avatar/>{user.name}</div>ходите в avatar чтобы посмотреть, из чего он состоит? Мне вас жаль, абстракциями совсем не пользуетесь?Это не мегаязык, который умеет все, а, эм… просто язык, привычный, стандартный. Зачем мне учить что-то новое для решения проблемы, если мой инструмент и так ее решает? Еще и хорошо. Или у вас унаследованная от пхп паранойя по поводу хождения в базу из шаблонов?
Мои предположения о вашей паранойе крепнут.
Что-то вы мечетесь. Я говорю вам, что нужно разбивать 5-страничные портянки, а не ветки условий.
Ну вот и сложился пазл.
Вы уж простите, но промышленное производство, а именно этим занимаются команды разработки, в случае верстки далеко от науки. И в этом случае выводы диктуются опытом.
TimTowdy
Вы пример-то прочитали? Есть баг, в каких-то (неизвестных) условиях ломается верстка. Чем тут поможет ваша абстракция avatar?
Представьте себе, возможно придется полезть и в него. Может аватар, загруженный из фейсбука, рендерится с неправильными размерами и смещает форму оплаты? Или у юзеров без аватара placeholder рендерится два раза вместо одного? И, в зависимости от размера экрана (или браузера) на мобильном девайсе, это смещает форму.
Да, придется открывать разные файлы, и скроллить туда-сюда. Но ради абстракции с этим можно смириться. А вот ради условных операторов — вряд ли.
Когда у вас есть только молоток, все вокруг кажется гвоздями.
У вас аргументация демагога, причем тут промышленное производство? «Это полная чушь, потому что я убедился на личном опыте».
В общем, я вижу что вы слишком эмоционально реагируете на критику своего золотого молотка и начинаете переходить на личности. Надеюсь в дальнейшем будете способны на конструктив.
raveclassic
Так может это проблема аватара, как отдельного элемента интерфейса? Может, он плохо оттестирован, плохо изолирован, раз так сильно влияет на свое окружение? В любом случае, вы первым делом открываете инспектор и ищите причину сдвига формы. Границы компонентов достаточно хорошо прослеживаются. Найдя дефект, вы знаете внутри какого компонента он находится. Разница между vue и react тут нулевая.
Дальше, это все не имеет никакого отношения к условиям. Отдельный метод под ветку ничем не отличается от отдельного компонента под ветку. Если вы не хотите терять контекст при работе с разным блоками (родителем и разметкой ветки), пожалуйста — используйте && или тернарники. Без выкрутасов, без тройного сальта назад, без dsl.
Как же уже заколебала эта фраза, лезущая из всех щелей. Вы ребятам из команды kotlin тоже самое скажете? "Вы с ума сошли! Зачем вам один язык под все? Есть же такой клевый зоопарк на все случаи жизни"
Да где там эмоционально. Да и где там молоток. Нету ничего. Просто с одной стороны забавно наблюдать такую инертную позицию, а с другой грустно.
Ну и если вам тут мерещатся переходы на личности, то давайте тогда действительно не будем продолжать.
TimTowdy
Вы все еще не поняли? Баг вам воспроизвести не удалось. Дефект не найден. Но он есть. Толку от вашего инспектора, если не можете его ни воспроизвести, ни даже узнать как конкретно он проявляется? Все что вам сказал юзер: «не видно кнопку оплаты». Потенциальных причин — миллион.
Моя позиция — чем проще вам охватить взглядом разметку и удержать ее в голове, тем легче будет найти чем этот баг вызван.
В случае с React это 100% будет сделать сложнее — просто потому что он позволяет (и разработчики очень этим пользуются) сильнее размазать разметку. Просто потому, что удержать в голове разметку, которая генерируется языком широкого назначения — сложнее.
Но поскольку для вас React — венец творения, золотая пуля, а любая критика — богохульство, ввожу вам объективную метрику: средняя удаленность кусков разметки компонента помноженная на количество этих кусков. Очевидно, что чем ниже этот показатель, тем проще понять разметку компонента. Очевидно, что по этому показателю, React проигрывает Vue. Насколько это критично — каждый решает сам.
Причина нашего несогласия: для меня этот показатель более важен, чем для вас.
TheShock
Ну, очевидно, по такой странной «объективной метрике» Vue вам ровно так же не подходит, а необходимо писать html без всяких компонентов для каждой страницы, где все в одном файле. Ну, то есть, вы, по сути, просите php 3.
TimTowdy
Не нужно передергивать. Я нигде не сказал что это единственная метрика которой стоит руководствоваться. Я привел ее для примера человеку, который, похоже, наивно полагает, что React в абсолютно любой ситуации превосходит Vue.
Ну и кстати в php3 тоже запросто можно разбросать разметку по разным частям файла. Так что тут вы ошиблись.
Если уж следовать вашей демагогии, то я прошу чистый HTML без какой-либо логики. Потому что это именно то, что будет отображено на странице. И в какой-то момент вам нужно понимать, как ваш код на языке общего назначения, преобразуется в разметку. Чем дальше вы от этого уходите, тем сложнее будет работать с версткой. В React этим пожертвовали, не дав, на мой взгляд, никаких весомых преимуществ.
Причины, как я уже писал, скорее всего в истории этих библиотек:
Vue — очередная попытка создать удобный JS-фреймворк, с учетом ошибок предшественников.
React — попытка создать быстрый реактивный JS-фреймворк основанный на VirtualDOM.
Оба со своими задачами справились прекрасно. Но Vue около года назад просто взял и добавил себе скорость React как одну из деталей реализации (VirtualDOM). А React не может сделать то же самое со своим дизайном. Именно поэтому вокруг Vue сейчас тот же хайп, который в 2015 был вокруг React.
TheShock
Вы ошибаетесь. Я никогда не пользовался Vue и не знаю, какой он. Если вы внимательно почитаете мои комментарии, то увидите, что я никогда не сравнивал Реакт с Vue и вообще не давал оценку Vue. Ибо, как я уже сказал, я понятия не имею, что там творится в Vue (хотя лично я тоже крайне не люблю разметку на псевдоязыке а-ля Ангулар)
Я как раз говорю, что вынос кода в метод — это благо, а не наказание, без контекста Vue. То есть именно в Реакте то, что я могу вынести код в метод — это очень круто и помогает разработке, код становится читабельным, метод Рендер меньше и это хорошо.
От тут не согласен. Вы говорите логичные вещи, а потом бац — делаете из них не совсем связанный вывод. Тоже классический прием демагогии.
У нас есть готовая верстка в браузере, у нас есть даже для браузера Реакт тулы, которые покажут, какой именно компонент рендерит этот кусок ДОМа.
Но лично я никогда не пользовался этими тулами, ибо… не было необходимости.
У меня Реакт рендерит логичную семантическую верстку и, пожалуй, не бывает момента когда ее нужно править ради баг-фикса. Баг или в JS-логике или в CSS.
TimTowdy
Я ведь не вам отвечал, когда привел свою метрику, а raveclassic. Пример метрики привел для именно для него.
Я же специально для этого привел пример с багом: верстка в браузере есть, но абсолютно никак не помогает решить задачу.
Верстка в браузере этого лишь один из возможных вариантов интерпретации шаблона/кода. Добавьте 5 условий — получите +32 варианта верстки.
Браузеры вот уже почти 25 лет интерпретируют HTML. От этого никуда не уйти. Теперь вам нужно придумать некоторую абстракцию, которая описывает как состояние преобразовывается в HTML. Чем ближе ваша абстракция (template/JSX) к конечному результату (HTML), тем проще ею пользоваться.
Вот вам банальная задача: отобразить список имен из массива. Т.е. преобразовать это:
в это:
Решение на Vue:
Решение на React (взял из официальной документации):
Просто помедитируйте на эти три куска кода пару минут. Подумайте, какую ментальную нагрузку на разработчика несет преобразование из кода на React/Vue в конечный результат.
И я даже не упоминаю о том, что даже такую простую задачу как вывод списка, на React можно сделать несколькими разными способами. Еще больше способов найдется для условных операторов.
Не вспоминаю про className, inline-стилях, убогом setState вместо привычного присваивания, boilerplate коде…
У React была отличная концепция: components, unidirectional data-flow, functional UI, VirtualDOM. Прекрасные вещи. И все они есть во Vue. И реализованы на порядок лучше (просто потому, что у Vue была возможность учесть недостатки React).
TimTowdy
Раз уж я упомянул условные операторы, просто оставлю здесь для будущих поколений варианты из этого треда.
Итак, задача в голове программиста звучит так:
«рендерить компонент Second, только если second равно true».
React (ваоиант 1):
React (ваоиант 2):
React (ваоиант 3):
React (ваоиант 4):
Vue:
Абстрактный щаблонизатор:
vintage
Вы бы хоть поправили в 3 варианте лишний закрывающий тег, который я не успел удалить :-)
Ну и вариант на view.tree тогда:
raveclassic
Видимо, вы наивно видите то, что хотите видеть.
Какая к черту метрика? Размазанность маркапа по методам? Ну что за ахинея, вы так же размажете маркап по компонентам и будете прыгать из файла в файл. Не хотите — не размазывайте. Не надо только говорить, что возможность декомпозиции это минус и "vue тут явно выигрывает". Повторюсь, вы видите то, что хотите видеть.
Постеснялись бы хоть.
Вот в том то и дело, что любой порядочный разработчик знает, что преобразование над элементами массива выполняется через
map. Везде и всегда. Нужно из массива имен сделать массив элементов списка. Вуаля —map!Пока что я не услышал ни одного аргумента в пользу vue кроме лютой субъективщины. Окей, один аргумент — с реактом надо потратить один день (я знаю, что говорю), чтобы научить верстальщика jsx. "Vue тут явно выигрывает"
TimTowdy
Вы делите мир на черное и белое: «верстальщик умеет в JSX» и «верстальщик не умеет в JSX». Я же утверждаю, что верстальщик знающий JSX все равно будет менее продуктивен, чем если бы ему пришлось работать с языком, более близким к реальной разметке. Измерить ментальную нагрузку конечно сложно, но по-моему в приведенных мною примерах это довольно очевидно (если смотреть на них без фанбоизма и эмоций).
raveclassic
Ну вы же давите на "излишнюю разнесенность", специально тогда пишите пример с дополнительной переменной?
Я делю мир на "нужно учить стандартные вещи" и "нужно учить нестандартную отсебятину". Невозможно знать все, мы постоянно учимся. Вопрос стоит в том, что учить — язык или еще один шаблонизатор
Я же вам с уверенностью утверждаю, что это не так, так как прямо сейчас целая команда, ранее не знакомая с jsx, работает на таком уровне производительности, который им раньше и не снился. Попутно выучив JS. Одни плюсы.
Очевидно, что очевидно это только вам.
Ну и конечно, я все ждал, что меня обзовут фанбоем когда "поток аргументации" иссякнет.
TimTowdy
Еще раз говорю, пример взят из официальной документации React. В программировании бывает вводят дополнительную переменную чтобы код сделать проще для понимания. И посколько к JSX разработчики относятся именно как к коду (ведь он по сути им и является), то и подход используют точно такой же. Они таким упрощают понимание алгоритма генерирующего разметку, но усложняют понимание самой разметки. Это tradeoff, в большинстве случаев не осознанный. И далеко не всегда полезный.
Во Vue же, к разметке относятся именно как к разметке. Несмотря на наличие условных операторов, циклов, и последующего преобразования в VirtualDOM.
В React разметка становится кодом на этапе написания приложения. А во Vue — на этапе компиляции. Вы можете сколько угодно с этим спорить, но разметку всегда читать проще, чем код. И программисту, и верстальщику. А код, в 2017 году, пишется именно для того чтоб его читали.
YemSalat
Ну тут опять же сводится к поддержке кода и аргументу автора статьи (столько-то символов против стольки-то).
В данном примере я бы вынес в отдельную переменную или функцию, или на худой конец в «ternary expression»:
Тут возврат к моему начальному аргументу: «На вьюхи Реакта надо смотреть как на обычный JS...»
serf
Это как раз плохой тон все пихать в одни файл, как по мне. Однако это опциональная возможность тк можно подключать шалон + js/css как внешние файлы.
Virviil
Если компонент уровня TableRowCell или TableControllPanelButton — почему бы и нет?
serf
Потому что это принципиально неправильно все смешивать в один файл, это можно сделать при сборке если нужно, но не на уровне исходников.
VolCh
По разному бывает. Когда для минорных изменений нужно минимум три файла править — тоже как-то не очень правильно. Как по мне, то система должна быть достаточно гибкой, чтобы легко поддерживать разные варианты (де)композиции в зависимости от проекта/команды. Грубо, если в команде в целом "фуллстэк" разработчики, а изменения в проекте в основном локальные, но затрагивающие все элемента "большой триады фронтенда", то компонент в одном файле имеет слишком много плюсов, чтобы от него отказаться лишь из-за того, что один из кандидатов на роль основного фреймворка этот способ не работает.
serf
Я не призываю отказаться, Vue как раз позволяет использовать оба подхода.
SPAHI4
https://github.com/zeit/styled-jsx
trueClearThinker
Vuex хорош лишь тем, что он встроен в инфраструктуру (тот же devtools). На самом деле есть вопросы к vuex, которые, похоже, разработчик не собирается решать.
kellas
https://github.com/alexstep/create-riot-app-ejected/
Akuma
Уж не знаю какую по счету статью про Vue vs React читаю, но никак не пойму на что напирают сторонники Vue?
1. Хватит гнобить JSX. Это дело вкуса, но мне, как и многим людям, он нравится.
2. Мне, как и многим людям, НЕ нравятся шаблоны в строках. По большому счету из-за отсутствия поддержки в IDE. Поправьте, если ошибаюсь и они уже работают так же «ровно» как JSX.
3. Дайте четкое определение Custom Controlls. То, что в статье — просто отдельный компонент и он на Vue ничем не отличается от остальных.
4. Создание компонентов в React — история? Скорее четверостишье. Просто функция в самом простом варианте. Впрочем, класс с render() не слишком сложнее.
В общем, кроме расширения через прототип (вряд ли когда-нибудь понадобится, ну да ладно) плюсов вы не привели.
Так вот: не надоело еще? Я имею ввиду писать статьи уровня «смотрите, мой ХеллоуВорлд круче, чем на Реакт». Напишите что-нибудь сложнее вывода {{message}}, используя фичи, которые есть только в Vue и тогда это будет сравнение преимуществ. А пока это больше похоже на реферат по информатике.
raveclassic
На то что не react и не angular.
К сожалению это закоренелое убеждение, что все кончается html'ем
Или, еще лучше, TSX
Я правильно понял, что тут патчинг глобального прототипа приводится за преимущество? Эм...
rboots
Что за деление на сторонников того и другого фреймворка? Посмотрите голосование, среди тех, кто пробовал Vue довольных более чем в 5 раз больше. Есть те, кто ещё не пробовал, и, собственно, «сторонники». Поэтому ждём вас в наших рядах. А шаблоны в строках я тоже не люблю, это для демонстрации, а типичный компонент выглядит как-то так:
Akuma
Вы вкурсе, что в этом опросе можно выбрать только один вариант?
Я вот например выбрал «Не планирую использовать». И нравится/ненравится не выбирал.
Причем, я не говорю, что он мне не нравится. Я говорю, что это уже 100500-я статья про «Почему Vue лучше» и в 100500-й раз в ней НЕ написано о том почему Vue лучше.
Давайте проще. Основная фича React — это отсутствие собственных обязательных выдумок. Все делается на чистом JS. Абсолютно все.
У Vue же болячки первого Angular: выражения в шаблонах ограничены, присутствуют собственные атрибуты, собственные изобретения. Первый Ангуляр явно показал чем это плохо. Он показал, что все эти ng-if заставляют разработчика бороться с фрейморком. То же будет и с Vue, я вас уверяю.
Простой пример. У меня есть обычный JS Array:
Мне нужно вывести список, который будет в зависимости от type рендерить разные компоненты.
React:
Vue:
Видите разницу? В первом случае это просто JS, который вернет список. Во втором это HTML с кастомными атрибутами.
Скажете, что не слишком явное преимущество? А если нужно в каждый компонент передать разные props и еще и вычислять их по разному для каждого компонента?
React удобен тем, что он простой как помидор. Vue напоминает первый Ангуляр без DI и с некоторыми упрощениями, но не более того. Сначала все радуются, потом начнут с ним бороться.
taujavarob
Akuma
Читаю в коментах через строку и так понимаю сам себе:TimTowdy
Рендеринг списка динамических компонентов это стандартная задача, и во Vue уже есть готовое решение. Вам не нужно решать каждую проблему написанием JS — подавляющая часть проблем уже решены.
Вот как на самом деле будет выглядеть рендеринг списка динамических компонентов (пишу по памяти т.к. я не фронтэндщик):
Видите разницу? В вашем случае, чтоб понять что рендерится динамический компонент нужно прочитать несколько строк JS перемешанного с html.
В случае DSL от Vue сразу видно что происходит. Никаких swtich/case/return <JSX>. Одна строка.Этим он и подкупает — ментальная нагрузка на разработчика гораздо ниже.
Akuma
Эм. Вот я далеко не первый год в веб-разработке и с ходу я не скажу, что делает ваш код.
Даже при том, что я очень активно использовал Angular 1 когда тот появился.
Он возьмет имя компонента из item.type? Т.е. оно должно 100% совпадать.
Что будет, если не совпадет?
Как мне передать props в эти компоненты?
«Какие» компоненты он будет использовать?
IDE покажет использование этих компонентов этим кодом?
Как мне скрыть некоторые компоненты в зависимости от props?
И я не прикалываюсь. Реально при многолетнем опыте я не знаю как это сделать на Vue без чтения документации. А вот как это сделать на JS — поймет даже школьник.
Это все болячки первого Ангуляра, я еще раз повторюсь.
Vue этим подкупает, согласен. Если выучить синтаксис конечно. Но потом вы начнете бороться с фреймворком, т.к. Vue не позволяет «ходить на лево».
У React безусловно тоже есть свои болячки, но они обычно связаны со сторонними библиотеками. А «чистый» React полностью выполняет свои задачи.
TimTowdy
Суть в том, какую ментальную нагрузку несет фреймворк уже после того, как вы его изучили.
Ваш пример как раз очень наглядный: Vue-разработчику, для того чтоб понять что рендерится динамический компонент достаточно увидеть :is. Потому что для типовой задачи сделали типовое решение. А вот в случае React придется прочитать кучу (по сравнению с 3 символами) кода: вызов map(), стрелочная функция, switch/return… Более того, дайте эту задачу трем реакт-разработчикам, и они выдадут три РАЗНЫХ решения (вы сделали map, кто-то сделает функцию с for, кто-то заведет отдельный object с маппингом имени в компонент...). В случае с React у вас всегда будет JS, который разные разработчики напишут по-разному. А иногда даже один и тот же разработчик напишет это по-разному в зависимости от настроения или понимания (например для трех компонентов сделает switch, а для 20 — отдельный объект).
В этом большая проблема современного фронтэнда — любую задачу вы привыкли решать написанием нового JS-кода. Когда у вас есть только молоток, вам везде мерещатся гвозди.
Да. Точно также как оно должно на 100% совпадать в вашем <ComponentOne />. Только у вас теперь еще неявное отображение
"one" -> ComponentOne, которое тоже нужно держать в голове, увеличивая ментальную нагрузку.Динамические props? Элементарно:
А что в React? Опять куча JS?
Насколько я понимаю (пусть знатоки поправят, если ошибаюсь), либо глобальные, либо заданные в родительском компоненте, если вы хотите ограничить их набор. Опять-таки Vue выигрывает: типовая задача «ограничить доступные родительскому компоненты» во Vue уже решена: компонент может принимать набор доступных ему дочерних компонентов. А что в React? Опять кастомный JS, который разные разработчики напишут по-разному?
Не понял вопрос. Но если честно, аргумент насчет IDE всегда слаб. Когда-то IDE и JSX не отображали. Кому нужно — тот настроит. В случае с Vue, насколько я знаю, настраивать обычно приходится меньше.
Если «скрыть» — это поведение компонента, то возможно его стоит вынести в сам компонент.
Ну, а для простых случаев есть директива v-show (либо v-if, если компонент нужно не скрыть, а вообще не создавать):
Видите в чем прелесть? Вы сейчас спрашиваете как решить какие-то стандартные задачи, и во Vue они уже решены. Ответы в документации, а не на stackoverflow. И решение одно, и с ним уже знакомы все разработчики. Вам не нужно выбирать из десятка модулей, а потом объяснять каждому новому члену команды как на вашем проекте задаются стили компонентов, и почему это отличается от того, что он делал в другой компании.
indestructable
Что может быть стандартнее Javascript на фронте? Уж точно не DSL Vue.
raveclassic
Я уже молчу про годами складывающиеся функциональные паттерны (а мы понимаем, что реакт со всей своей декларативностью это про фп). Компоновка интерфейса следует знакомым и понятным законам. Компоненты высшего порядка, букет всевозможных Maybe/Either, совершенно другой уровень абстракции, совершенно другой уровень переиспользуемости.
TimTowdy
Вы немного путаете контекст. «Стандартность» JS на фронте нужна браузерам, т.е. среде исполнения. Но никак не программистам. Им этот «стандарт» нужно читать, а не исполнять. И читать всегда проще именно DSL. В конце концов, именно для этого DSL и создаются.
Стандарт — это не просто «один язык, один фреймворк, один фюрер». Стандарт — это в первую очередь ограничения. И строгий DSL как раз эти ограничения задает. В отличие от динамического JS, который наоборот, дает слишком большую свободу.
К сожалению Javascript/React никак не способствуют написанию кода в стиле «There should be one-- and preferably only one --obvious way to do it». Поэтому ваша абстрактная «стандартность» разбивается о реальность разработки.
Пример: во Vue один способ вывести список компонентов: директива v-for. А знаете сколько различных способов вывода списка компонентов я видел в React? Пальцев рук не хватит, чтоб посчитать.
Akuma
Ммм… один? Отдать массив компонентов. Это такой стандартный элемент JS со времен динозавров. Его все знают и не нужно читать документацию :)
TimTowdy
Возьмите 10 разработчиков, попросите каждого написать код, который выведет список компонентов, и сравните результаты. Везде «отдать массив компонентов» будет сделано по-разному. for, for of, map, _.each, стрелочные функции vs обычные, итерация внутри JSX либо снаружи… Нет, вы конечно во всем этом разберетесь довольно быстро, в конце концов это просто генерация массива. Но ментальная нагрузка будет выше.
Честно, я не понимаю зачем вы спорите. Хороший DSL всегда проще читать чем GPL. React-сообщество почему-то категорически отрицает разметку как отдельную область, аргументируя это тем, что в 201х году нельзя не знать JS, поэтому разметка через JS это ок. Не ок. Подход «все — джаваскрипт» конечно можно проглотить. Но подход «мухи отдельно, котлеты отдельно» работает лучше.
Реакт, продавая реактивность, VirtualDOM и UI as a function of state незаметно подсунул всем JSX. Многие проглотили, и даже сказали что им нравится. В общем-то тут не было злого умысла: фокусируясь на VirtualDOM в 2013 году, придумать JSX было хорошим решением. JSX действительно улучшал читаемость. Vue (в текущем его виде), тогда был просто невозможен.
Но сейчас не 2013 год. И Vue, и React реализуют идею "UI is a function of state". Вот только и UI, и state во Vue сделаны лучше. Это очевидно каждому, кто сравнивает эти две библиотеки.
Попробуйте задуматься, кто быстрее разберется: Vue-разработчик в чужом Vue коде, или React-разработчик в чужом React коде? На мой взгляд, это должно быть основным критерием выбора библиотеки в 2017 году. И Vue здесь однозначно побеждает.
VolCh
Как по мне, то именно сейчас во фронтенде основным критерием должна быть скорость, с которой незнакомый с фреймворком разработчик сможет выполнять реальные задачи в проекте, где он уже есть.
TimTowdy
Не согласен.
Проекты ведь не две недели длятся. Время знакомства с фреймворком обычно на порядки меньше, чем длительность участия разработчика в проекте. Грубо говоря, 1% времени разработчик не знаком с фреймворком, 99% времени — знаком. Мне важно насколько эффективен разработчик (и команда в целом) будет в течение этих 99%.
Ваш критерий, мне кажется, применим только если у вас жуткая текучка кадров.
VolCh
По разному длятся. И не текучка может быть в привычном смысле, а ротация по проектам (вариант — эпикам) на разных стэках внутри одной компании. И я даже не про аутсорс.
TimTowdy
Если уж и брать ваш критерий, то сравнение Vue vs React явно будет не в пользу последнего.
Не зная фреймворк, и Vue и React код разработчику будет казаться сплошной магией.
Но Vue можно освоить за пару часов, в отличие от React. Это на самом деле очень показательно, учитывая что большая часть концепций у Vue и React одинаковые.
Akuma
Я вроде и не спорю :) Давайте тогда на этом остановимся. Выбор фрейморка в какой-то степени дело вкуса. Vue — на мой вкус не очень, т.к. я сбежал от первого Angular. Возможно именно это дает свой отголосок.
indestructable
Это все проходили во времена первого Ангуляра. На нем легко писать простые приложения, но очень сложно писать сложные вещи и библиотеки.
Попробуйте написать хороший drag and drop, хороший грид (с настраиваемыми ячейками, редактированием, заголовками и т.д.).На реакте это написать довольно легко (с учетом, конечно сложности самого решения) — Реакт не будет мешать, а будет только помогать — всей мощью Джаваскрипта.
На Vue вы будете бороться с шаблонизатором — я это понял, как только прочитал про "слоты", которые, как я понимаю, являются аналогом трансклюдов Ангуляра.
В реакте у вас нет слотов, а есть функции и объекты, из которых вы можете создавать другие функции и другие объекты. Поэтому в Ангуляре (да и скорее всего в Вью) никогда не будет, например, декораторов для компонентов, при помощи которых можно сделать, например, редактирование по маске для любого input, даже из third-party component set.
Вместо этого будут кастомные атрибуты, которые кажутся простыми, когда ты читаешь примеры, или пишешь проект в одиночку. Но которые начинаешь ненавидеть, когда проект делается впятером, и каждый их делает и использует.
indestructable
Посмотрите, как сделаны гриды для первого Ангуляра, тот же Кендо. Там компонентностью и не пахнет даже. Огромный объект конфигурации, строковые шаблоны на DSL шаблонов от Кендо, это просто страх и ненависть. И по-другому не сделаешь.
Есть ли во Вью какой-нибудь прогресс с этим?
DarthVictor
Справедливости ради гриды от кендо написаны на чистом jQuery, для AngularJS там только обертка. Что не мешает им быть функциональнее абсолютно всех гридов для ангуляра / реакта, а также рискну предположить, что и для Vue.js/Elm/любой фреймворкнейм
rboots
Заказывали? Получайте . Первое что нашлось в google. Десяток готовых гридов, инпуты и прочее. А на Ангуляре 1 со сторонними компонентами плохо было потому, что он плохо приспособлен под это был.
TheShock
Иронично, но я не видел на современных фреймворках (ни в одном) такие же клевые штуки, которые столь же легко подключались бы, как возможности, например JQuery UI. Тот же select в Реакте значительно хуже, чем в JQuery UI.
vintage
Чем именно хуже?
TheShock
Признаюсь честно — не помню. Вы пользовались и тем и другим?
vintage
Нет, мы пилим своё решение. Вот и интересуюсь, что именно вам не хватает в существующих.
s256
Я сейчас скажу страшное — в Vue тоже есть render-функции и тоже можно использовать vanilla.js для написания чистых компонентов. То есть вы в праве не использовать шаблонизатор и если возникает потребность в действительно сложной логике — на Vue это можно сделать в React-like стиле.
raveclassic
Ну и зачем тогда vue?
Fragster
потому что в 99.753% случаев эти рендер функции не нужны?
denismaster
https://github.com/eastbanctechru/right-angled
Очень удобный грид(список) для ангуляра(4) Работает на директивах и нескольких компонентах(по сути управляют отображением). Разметка любая может быть.
Что касается кастомных атрибутов, то они очень даже пригождаются. Например, когда вижу в коде подобное:
То сразу становится понятно, что передо мной компонент для выбора даты.
А вот другой пример кода, который управляет отображением:
И сразу видно, что здесь добавляем дополнительный атрибут — и блок отображается только, если роль пользователя «администратор».
Редактирование по маске?) Можете рассказать подробно, зачем вообще такая задача?)
Но, в любом случае, можно написать директиву, которая берет first или third-party input-ы, которые являются детьми блока, к которой директива применяется, после чего их функция writeValue(интерфес ControlValueAccessor, реализуется чем угодно и всеми стандартными инпутами) декорируется с учетом маски и логики редактирования. А разметка остается та же.
alek0585
Покажите, пожалуйста, хорошую библиотеку drag-n-drop на vue. Которая была бы не оберткой над другой библиотекой.
zenkz
Спасибо. Своим комментарием вы только что меня убедили, что Vue.js удобнее реакта.
То, что на реакте занимает 7 строчек js-кода, в которые нужно вчитаться и понять что там происходит, на Vue решается простейшим и понятным аттрибутом.
По поводу ограниченности выражений в шаблонах. Не могу сказать как это работало в ангуляре, но в knockout.js достаточно было сделать computed переменную и поместить логику в неё. А внутри переменной уже чистый js.
rboots
С React без JSX, если честно, возникала мысль: «А какую ценность он вообще добавляет?», так как эти React.createElement очень напоминают просто обёртку над document.createElement с небольшим API для установки атрибутов и вложенности, которая пишется за 50 строчек. Ценность как раз и состоит в DSL, но JSX во-первых очень самобытный и не совместимый ни с какими другими DSL, а во-вторых очень сложно извлекается из React. А главная проблема всей этой конструкции, вместе или по отдельности — сильная связанность всего со всем. Ощущение будто его просто выдрали из реального проекта с многолетней историей и даже не стали особо рефакторить. Писать на JavaScript я и на VanillaJS могу, и это не такой уж плохой путь, кстати. Он ещё проще. А React слишком много всего просит за ту простоту функционала, или скажете у него низкий порог входа?
Vue добавляет сложности, но самую малость, не больше чем обычная библиотека. Шаблоны там стандартные, знакомые ещё с Angular, Knockout и похожие на многие серверные. А самое главное он эффективно отделяет логику от представления, шаблон можно целиком переверстать не затрагивая основную логику, можно начать разработку до этапа дизайна, просто по ТЗ, и заранее иметь готовую логику, можно органично проводить А/В тесты, опять же не трогая основной код. Много чего можно, что с концепцией «всё в js» становится сложнее. HTML это отличный инструмент для создания View и не нужно от него отказываться.
Akuma
React предоставляет быстрый рендеринг за счет сравнения DOM в памяти + shouldComponentUpdate. Это шаблонизатор и ничего более.
JSX и не должен быть совместим с чем-то другим. Он создавался для React и нечего его использовать отдельно. Впрочем, там «нового» ничего и нет, лишь пара фигурных скобок. Остальное HTML и JS.
Где вы видели шаблонизатор из которого потом нужно что-то извлекать? Это маразм. Хватит. Вы пишите шаблон под конкретный шаблонизатор. Всегда, везде и в любом языке.
Да, его выдрали из ядра Facebook, по сути. И у них это неплохо получилось.
Да, у него низкий порог входа. Куда ниже чем у Vue. Потому что react — шаблонизатор, а не фреймворк.
Кстати Babel вы все равно будете использовать ради ES6, а если нет, то продолжайте мучить себя.
Зачем отделять логику шаблона от самого шаблона? Где вы нахватались этих «умных» выражений про отделение логики? Логика шаблона — это не логика приложения. А если вы всю логику приложения пихаете в React компонент, то либо делайте это осознано, либо не делайте вообще, либо не жалуйстесь. v-if это тоже логика, давайте ее выделим в отдельную библиотеку?
И все же, давайте вернемся у статье: в чем преимущества и уникальность Vue? В статье лишь избитый Todo-list, который скоро встроят в Хром и он будет запускаться просто тегом <todo-list />, т.к. уже всех достал.
Некоторые пишут про некие «слоты». Я уверен, у Vue есть и другие уникальные фичи, которые будут интересны. Я не пытаюсь холиварить о том, что лучше, я пытаюсь выяснить что умеет Vue. В документации я не нашел дял себя ничего интересного, а лишь переделанный Angular 1 от которого убежал давным-давно.
rboots
Я «нахватался» этого из 15-тилетней практики, это сильно облегчает работу и если вы этого не используете — вы себя обкрадываете. Да, он очень похож на Angular 1, с той разницей, что сделан по человечески, скоупы изолированны, отладка стала информативной, производительность выше. Из нового появились custom controls, которые для реакта не новость и вообще тренд последние 7 лет, но наконец их сделали удобными, совместив синтаксис а-ля polymer, который а-ля нативный, с шаблонизацией через свойства html. Это значит, что когда поддержка нативных custom controls станет мейнстриомо в браузерах — от половины Vue можно будет избавиться, либо она будет работать с бешеной производительностью на нативном рендеринге, да и все другие фреймворки будут двигаться в этом направлении. Решение от Facebook неплохое, но не живучее, о нём забудут так же, как забыли про ExtJS, который предлагал много всего хорошего, но не стал доминирующим, так как сильно отличался от стандартов. Я привожу эти аргументы, так как бесполезно спорить что лучше, шаблоны в js или html, у каждого свои вкусы. Но W3 решили, что нативные custom controls будут на шаблонах в html, а поддержки jsx в браузерах нет даже в проекте. Vue по сути придумали очень мало нового, они как и jQuery, как и babel, как и polymer, просто ускорили будущее.
Про низкий порог входа React, это иллюзия вследствие большого опыта, видимо. Для меня, например, чистый JavaScript проще любых фреймворков, но 90% программистов так не считают, видимо они правы и это просто деформация от долгого использования. Общепринято, что React осваивается тяжелее, я например первые 2 недели только и и делал, что гуглил проблемы. А Vue до практического уровня освоился за 2 часа, правда после polymer и angular, у которых он многое взял.
Про уникальные фичи, всё придумано до нас, и вряд ли найдётся что-то совсем революционное. Мой тезис про другое, они просто сделали работу с UI простой и удобной, ориентируясь не на субъективное мнение, а на стандарты отрасли и сильные стороны JavaScript. React, на мой взгляд, создавали люди, у которых первый язык был всё таки не JavaScript, отсюда эта любовь к классам где надо и не надо и прочему, без чего серверники жить не могут. Только JavaScript гораздо глубже и богаче, почему классы, а, например, не монады? Концепция ничем не хуже, весь jQuery на них построен, express активно применяет, а React — нет, потому что его создатели, хоть и талантливые, но JavaScript знают поверхностно.
А babel я применять не буду, синтаксического сахара не так много даёт. Единственное что хочется использовать это async await, но под Node он уже и так доступен, а в браузере вот-вот начнёт быть мейнстримом, пока промисов хватает.
raveclassic
SFC?
Теплое и мягкое? При чем тут монады?
Потрясающее заявление!
Вы ишака поддерживаете?
staticlab
Да, на первый взгляд так и кажется. А затем попробуйте вывести массив элементов как в
v-for, поменяйте местами любые два элемента массива и добейтесь минимального обновления DOM в 50 строчек.rboots
Если такая логика есть, её лучше кастомно делать, обёртка здесь не при чём.
Вот, аж одна строчка, и с минимальными обновлениями DOM.
staticlab
Только вы забыли найти movingNode и prevNode
raveclassic
Еще и с RAF синхронизироваться
Virviil
Во Vue можно писать на JSX. А можно писать на html с атрибутами. Чтобы "побороть" Vue надо написать компонент на JSX. Зато если не надо бороть — можно не писать на JSX.
Поэтому компонент Table пишем на JSX, а компонент SignInUp пишем на атрибутах.
В результате лэйаут может сделать верстальщик (то самое рекламируемое преимущество ангуляра), а компоненты вроде d3 графиков или всплывающих от вебсокета нотификаций — программист.
И в отличие от Ангуляра, у Vue под капотом тот самый "простой как помидор" реактивный рендер цикл. Просто его присыпали "ангулярным" сахарком, и ещё сделали быстроразвёртываемое дев-окружение.
И пользуясь полученным опытом расширили redux наработанными essentials вроде thunk — получили vuex.
Так что vue — это причёсанный react. В котором с помошью сахара можно "писать в стиле ангуляр".
JSmitty
Ой, классный пример, спасибо. Прелесть современного Vue.js в том, что он умеет и JSX тоже (и той же ценой). И именно ваш пример (рендер компонента в зависимости от типа в массиве объектов) в одном из проектов именно через JSX на Vue.js реализовывали. Да, это проще, чем городить огород из условного рендеринга в шаблоне или использовать ":is". Логика более очевидная.
Vue.js 2+ позволяет писать компоненты с рендер-функцией, ровно как в React, и поддерживает как JSX, так и нативный интерфейс для создания объектов vnode для Virtual DOM.
raveclassic
Но если вы на vue пишете как на реакте, то зачем тогда vue?
JSmitty
Понимаете, он позволяет писать низкоуровнево, но не принуждает к этому. Есть выбор — привычно/удобно так — пиши как нравится, никто не принуждает.
Это существенный плюс, когда в команде есть люди, знакомые с HTML и слабо знающие JS — то синтаксис темплейтов им ближе, чем типовые конструкции React() для достижения того же.
Наши пара проектов (большие и долгосрочные) на Vue.js используют в основном темплейты, но в паре критичных мест используются напрямую рендер-функции.
И потом, стоит понимать, что внутри себя Vue.js 2 компилирует темплейты в рендер-функции. Этот механизм также доступен через API. Т.е. для Vue.js 2 темплейты — это сахар поверх рендер функций, и кмк не особо проблематично сделать аналог для реакта (а, может быть, он уже и существует).
Опять же, с точки зрения использования — магия отслеживания изменений во Vue.js проще в использовании, чем работа с состоянием в React — никаких this.setState() или dispatch(). По мере роста приложения это достоинство нивелируется, но на старте оно сильно облегчает вход (буду откровенен, местами эта магия встает-таки поперек горла).
vintage
Вот за что я не люблю html шаблоны — в них зачастую очень сложно проследить намерения. Семантики не хватает и разработчики фигачат кто во что горазд. Я попробовал переписать ваш код на $mol, надеюсь правильно угадал всю скрытую семантику.
bano-notit
Ну здрасте) Опять вы со своим $mol мелькаете в глазах...
vintage
А когда люди со своим Реактом мелькают в глазах — вас не смущает?
Odrin
От чтения React кода хотя бы не вытекают глаза.
vintage
Почитайте комментарии в этой теме — у многих вытекают.
bano-notit
Честно? Смущает. Но у них хотя бы ники разные, а Вы один такой неповторимый)
raveclassic
del
xlenz
Лично мне vue.js понравился тем, что проще реакта и ангулара на средних приложений.
Во времена ангулара 1, мне он нравился, потом перешёл на реакт, понравилось больше. Не так давно попробовал ангулар 2 и вернулся на реакт. А потом, без энтузиазма, попробовал vue.js и мне очень понравилось.
За счёт каких-то определённых вещей не скажу, понравилось всё в целом, отсутствие боли, как с другими фреймворками.
Фреймворк не идеален, просто хотел поделиться впечатлением. Пока остаюсь с vue.js.
raveclassic
del
ju5tify
Vue.js > Angular > Говно > Моча > React
Sirion
Вы чудовищно неправы, моча лучше говна.
raveclassic
может просто поменять
>на<?Metus
Скажите пожалуйста, а ember мёртв?
grimalschi
Жив, но фокус сместился сначала на Angular, потом на React. Сейчас вот Vue мелькает все чаще.
В «тренде» виртуальный DOM, его использует и React и Vue, и многие новые библиотеки (Preact, Inferno, Snabbdom, Mithril...).
s-kozlov
Как странно вы пишете слово «хайп».
prostofilya
Да нет, помаленьку развивается, вроде как собираются переходить на модульную основу, хотите роуты — качайте эмбер-роут, хотите модели — качайте эмбер дату. Помаленьку развивается движок glimmer, он вроде не такой шустрый как fiber, но на месте не стоит. Оптимизируют, худеет помаленьку. У авторов есть roadmap на офсайте, бросать не собираются.
alist
Отпишусь.
Используем Vue в продакшене, начали с 1.0.x, планировали перейти на 2.0, но сразу же переход сделать времени не было — и хорошо: вышел 2.2, который по честному нужно было бы назвать 3.0, отличий много. Недавно таки перевели приложение на 2.4.
В целом фреймворк действительно очень хороший, приятный в использовании. Недостаток — сторонние библиотеки и плагины. Те, что пишутся командой самого Vue — vue-router, vuex, и тд — отличные, все там хорошо. А вот шаг вправо — шаг влево, и все становится грустно.
Мы взяли одну библиотеку компонентов — Keen UI, которая прошлым летом была супер-популярной и по фичам обгоняла все остальные так, что народ сворачивал свои проекты и шел контрибьютить туда. И буквально на первых же контролах оказалось, что Keen то не умеет, этого не умеет, мы стали компоненты расширять, баги исправлять, засылали пул-реквесты и тд. Какие-то принимали быстро, какие-то медленно. В общем, как обычно. Но проблема и Keen, и других UI-библиотек под Vue, что пишут их реально криво. В самом Vue есть слоты из Web Components, про которые уже выше упоминали, но по факту ребята-авторы видимо пришли с Реакта или других фреймворков, где такого API нет, и им почти не пользуются. И на каждый чих вместо того чтобы просто расширить компонент слотами, приходиться форкать, допиливать и засылать пулреквесты, которые тоже народ не торопится принимать, тк часто доработки довольно специфичные, и никому почем зря раздувать API компонента не хочется.
Ну а сейчас Keen UI заглох — последний коммит в январе, а все остальные библиотеки компонентов либо только-только начинают, либо пишутся китайцами для сингапурцев, и чуть что доки и коммиты на мандарине, и когда вопрос задаешь, тебе никто толком ответить не может.
В результате у нас как почти у всех — свои кастомные UI-элементы. И Вот кажется, что вот он прогресс — Angular, React, Vue, так сильно фронтенд скакнул со времен IE6 и jQuery, — а на деле сидим мы в 2017 году и как лохи делаем свои списки, аккордеоны и модалки.
serf
Vuestrap ?
negasus
http://element.eleme.io/ не пробовали? Интересно мнение
xlenz
Пробовал vue-bulma, тоже что и с keen. Сейчас вот начал работать с элемент, пока не могу ответить однозначно.
s256
Использовал для написания навороченной админки — в целом впечатления очень положительные. Да над некоторыми компонентами приходится посидеть с напильником, но в целом очень и очень не плохо
Fragster
http://bootstrap-vue.js.org/ пилится активно, к выходу 4 бутстрапа. не всё мне нравится, например то, что они сделали с table. Но в остальном — терпимо.
teux
Год назад узнал про Vue, почитал и понял, что он должен быть.
Хотя посыл статьи не разделяю (личные симпатии выдаются за реальное состояние) и сам надеюсь никогда на vue не писать, но…
Технологии фронта очень резко развернулись. Не буду детализировать в какую сторону, суть не в этом. Главное, есть много людей, которых jQuery приучил к плагинам, а фреймворки типа Angular 1, Marionette, Ext, Knockout и пр. – к паттерну MVC.
На мой взгляд, для этих людей подходы React/Redux с фактическим отрицанием MVC кажутся непривычными и неудобными. Однако пользу от виртуального дома они хотят получать. И что греха таить, действительно полноценная экосистема React очень сложна. Angular не сильно проще, да еще и "вещь в себе".
Так в нише между React и Angular появился Vue. Он и с виртуальным домом, и с привычным MVC, и не сильно сложный. Такая буферная зона для небольших проектов, или на период изучения React, или просто чтобы не забивать голову "ерундой". Не думаю, что у него есть шансы сравниться с React, но почитателей он должен был найти.
vintage
teux
Fluxxor такой источник непререкаемой информации ) Давайте посмотрим на более авторитетный источник
Здесь есть связь store > view, но нет store < view
vintage
В редаксе эта связь есть (mapStateToProps). В любом случае до "фактического отрицания" тут как до луны.
teux
А поконкретнее, пожалуйста. Что есть mapStateToProps? В какую сторону эта связь?
vintage
https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options
teux
Ну так не интересно. Я ожидал аргументацию вокруг заведомо ложного тезиса )
mapStateToProps, как следует из названия, передает данные о состоянии приложения (хранится в store) в props компонента. То есть это связь store > view
Вроде мелочь, есть ли обратная связь или нет. Но это то, почему загнулся (т.е. не популярен) упомянутый fluxxor, иже с ним reflux и прочие ранние реализации flux, цеплявшиеся за паттерн MVC.
В отсутствии прямой связи store < view приложение вынужденно превращается в систему обмена сообщениями. По сути, передача Action в store через dispatch это и есть отправка сообщения тому редьюсеру, который может сообщение обработать.
Видите разницу? Либо визуальный компонент сам что-то меняет в сторе. В этом случае он непременно реализует императивный подход, т.е. напрямую решает конкретную задачу конкретной предметной области. Вьюха перестает быть вьюхой. В ней смешивается уровень визуализации и работы с данными.
Либо в случае react/redux компонент реализует некую событийную модель. Он просто отправляет сообщения "у меня произошло то или другое событие". А потом получает из стора обновленные данные.
TheShock
View запрашивает данные у Store, а не Store решает, какие данные передать View, вот о чем эта стрелочка на диаграмме.
Флакс — самый обычный MVC, но в силу целевой аудитории переименовал понятия, иначе кто бы захотел пользоваться мерзкими корпоративными подходами?
Даже я писал по MVC односторонние потоки за пару лет до фласка, что уж говорить о значительно более умных людях?
teux
Протест ) Понятие "запрашивает" означает действие. У действия есть инициатор, и в вашей схеме это view. По факту в Redux все наоборот: view ничего не запрашивает, а только отправляет сообщения о событиях в Redux. Потому во флаксе нет обратной стрелочки.
Тогда давайте подведем под MVC и паттерн глобального неймспейса. В нем можно нарисовать те же стрелочки. Вьюха пишет данные в window.MyStore и читает оттуда же. Чем не MVC? Нет контроллера? Так долго ли вынести пару функций из вьюхи в отдельный модуль.
teux
Не знаю, есть ли правильно название у паттерна redux. Я бы охарактеризовал его как "глобальное хранилище с общей шиной сообщений". Это не сильно похоже на MVC
staticlab
Конечный автомат же
teux
В принципе, в паттерне MVC модель тоже может слушать события на вьюхе. Но есть у MVC другие негативные черты.
Во-первых часто не очевидно, как распределить бизнес-логику между моделью и вьюхой. И часть ее все равно попадает во вьюху.
Во-вторых, чтобы собрать состояние приложения, надо свести данные всех инстанов всех моделей. Это практически непосильная задача. Кто работал c Redux DevTools, тот понимает удовольствие, когда состояние приложения как на ладони.
В-третьих, рано или поздно возникает необходимость обмениваться данными между моделями. Тут сразу две проблемы:
Это особенности превращаю архитектуру MVC в страшного монстра, развивать и поддерживать который — только время терять. Проще переписать. Конечно, для маленьких приложений надежды на лучшее больше.
Vue от MVC-подхода не ушел. Поэтому, на мой взгляд, это нишевый продукт для маленьких проектов.
Riim
У вас какое-то очень странное понимание MVC (ну или у меня). Модель слушающая события въюхи, бизнес логика распределяемая между моделью и въюхой, обмен данными между моделями и тд., видимо меня всю жизнь обманывали рассказывая про какой-то другой MVC.
teux
Не знаю, какое у вас, но понимание тех парней, лапшакод которых я не раз разбирал, мне не сильно импонирует.
Это еще одна проблема MVC: в многообразии его трактовок можно потеряться.
Riim
То есть вы разбирали лапшакод людей не научившихся готовить MVC, как следствие не научились сами и в результате плохим остался именно MVC?
teux
Возможно. Но такой поворот дискуссии — это разговор "в пользу бедных". Или вы демонстрируете свой единственно правильный взгляд на MVC и мы приходим к чему-то общему, или нет смысла продолжать.
При обилии спецификаций MVC понимание зависит от опыта применения. У меня он в целом негативный, причем не на одном фреймворке. Проблемы встречал одни и те же, о чем и написал.
Я считаю, это базовые проблемы паттерна MVC, которые проявляются на практике. В теории, даже прямо здесь, вы наверняка сможете доказать превосходство идеальной модели MVC. Но практика не теория. Вам это известно
Riim
мой взгляд полностью совпадает с общепринятым.
те проблемы, которые вы описали, их как бы вообще не должно быть. Скажем вы решаете проблему обмена данными между инстансами модели, но зачем? Вам нужно не решать эту проблему, а понять какого она вообще появилась?
teux
Потому что одна модель берет данные из одного эндпоинта, другая – из другого. При этом они процессят данные и сохраняют результат. Все хорошо, пока какой-то новой вьюхе не потребуются данные обоих эндпоинтов (какая капризная).
Что делать? Создать новые интсансы двух моделей и подключить к капризной вьюхе? Но у нас уже есть эти инстансы и возникнут дубли запросов, память будет расходоваться вдвойне.
Значит надо подключить существующие инстансы к этой вьюхе, значит делать хранилище инстансов.
А если капризная вьюха начнет менять данные в общих моделях, останутся ли данные консистентными для других вьюх?
А если другие вьюхи отмонтированы и делают destroy моделей, что произойдет с остальными вьюхами, подключеным к тем же инстансам?
А если вьюха не дестроит модель, то кто это делает?
А если вьюха отмонтирована, снова подмонтирована, получила живой инстанс модели и пытается провести начальную инициализацию...
… если, если. И получается безопаснее не переиспользовать инстансы моделей.
Тогда остается дублирование или хитрые заходы сбоку в существующие инстансы моделей, чтобы капризная вьюха получила/поменяла данные. Отсюда возникает лапша.
Повторяю, в мире идельной архитектуры такая схема невозможна. Но почему-то плохие парни в жизни об этом не знают )
Вы скажете "Так ведь можно попросить бек сделать подходящий эндпоинт для капризной вьюхи". Согласен, часто так и делается. Но это уже архитектурная связанность даже не на уровне компонентов, а на уровне API
Riim
так в чём проблема-то? Вполне нормально когда въюха показывает данные нескольких моделей. Может данные зависимы друг от друга?
teux
Важно, сколько усилий тратится на решение проблем с подходом MVC и Reac/Redux, насколько эффективно получается решение изначально.
За функциональной сложностью растет сложность архитектуры, отладки, поддержки. При использовании MVC сложность растет быстрее, чем в случае React/Redux.
В теории мы можем разобрать любой спорный случай MVC, и вы покажете, что было изначально сделано не так, почему возникли проблемы потом. Но на деле невозможно представить всю архитектуру приложения заранее. Очень может быть, что казавшееся правильным решение потом потребовало хаков.
Бывает так в React/Redux? Конечно. Но вопрос в трудоемкости рефакторинга. Когда изначально все данные хранятся в одном месте, разработчик сразу понимает, что общие данные надо хранить в нормализованном виде, не делать кастомный препроцессинг под потребности конкретной вьюхи. Если такая обработка нужна, она выносится в компонент-контейнер (обертка над вьюхой). Применяются селекторы для оптимизации производительности. Код получается гранулярным и тестируемым.
И такой подход универсален в React/Redux. Один раз освоить, и можно использовать для решения любой задачи. В MVС, по моему опыту, как только получаешь гладкую архитектуру, как появляется новая задача, которая вносит противоречия, и нужно перестраивать отдельные модели и вьюхи.
Поэтому MVC для меня лично (никому не навязываю) — это антипаттерн в отношении архитектуры фронта.
teux
Еще добавлю, что когда-то данные хранились в глобальном нейспейсе. Это было всем удобно и привычно. Потом взошла звезда MVC, данные растащили по моделям. Появились неудобства в интроспекции общего состояния приложения.
Redux, по-сути, вернул подход единого хранилища. Данные хранятся как раньше — в едином дереве. Появились прекрасные инструменты итроспекции типа Redux DevTools.
vintage
И где вы тут видите неудобства интроспекции?
teux
А как вам такая картинка (Redux DevTools визуализирует стейт)?
vintage
Эти красивые картинки бесполезны при числе моделей более 100.
teux
Ахм… ну ладно, закончим на магическом числе 100 )
JSmitty
А vuex вы во внимание не принимаете? Он, конечно, сильно проще чем Redux — но тоже местами жизнь сильно упрощает.
CodeViking
Мне одному кажется что данный холивар бессмысленный?
SbWereWolf
Видимо всем всё понятно и ни кто примеров из статьи не запускал, у меня второй пример не взлетел. Был список, то есть элементы , но у элементов не было .InnerText.
Я попытался на авось поменять код тут и там — не помогло, в консольке был варнинг со ссылкой https://vuejs.org/v2/guide/list.html#key и вот там в примере вместо «todo.text» было просто «todo», я подставил как в примере и у меня заработало.
вопрос к автору, почему не работает todo.text? я что то упустил?
c01nd01r
В проперти todo компонента <todo-item> приходит item — элемент массива list. Никого свойства text у него нет.
rboots
Исправил
Valery4
Дочитал до момента, чем плох TypeScript и дальше не стал читать. Мне кажется плохим тоном преподносить даже что-то хорошее, за счёт очернения другого, которое тут ещё и не к месту приплели.
В общем статья для меня возымела противоположный эффект, к моей симпатии к Vue.js и потенциальным желанием как нибудь попробовать, теперь осадочек мутный.
ArVaganov
Ребята давайте будем откровенны, статья – так себе и несет много необоснованного хейта. Человек даже 2 месяца не проработал на фреймворке и на волне хайпа просто набрал текст и выложил его сюда. Не нужно выплескивать негатив в комментарии и серьезно тут устраивать холивар.
У меня уже есть небольшой опыт использования Вью, мы с командой пишем проект на Laravel + Vue, (до этого не знал ни одного фронтенд фреймворка).
Могу вам сообщить действительно отличное преимущество у Вью – это возможность включать его в проект точечно. Это очень полезно когда нужно переписывать и улучшать легаси код. Подключил на страничке скрипт весом несколько килобайт, написал парочку vue компонентов, и вот уже то — что на JQuerry и ванилле было лапшой навешано (и невозможно поддерживать) теперь аккуратно, компактно лежит, реактивное, а главное при этом еще и работает быстро.
Лично я хочу делать карьеру именно во фронтенде, поэтому параллельно работе с вью учу и реакт. И я хочу вам сказать, что у этих двух фреймворков просто разный подход к рендеренгу шаблонов, всю бизнес логику можно написать на них обоих. И по сути конечный результат зависит от прослойки между стулом и монитором без разницы при помощи чего вы будете создавать свой код.
Теоретически большие одностраничные приложения можно делать как с использованием Vue, так и с Реактом. Поддерживать легаси, писать какую-то небольшую динамику на странице проще однозначно на Vue. Порог входа очень легкий и документация классная! Так что не бойтесь, пробуйте. В любом случае от «лишних знаний» хуже не станет, т.к. и вью и реакт нужны для специализации по фронту.
rboots
У вас логическая ошибка. 2 месяца я проработал на Vue, и до этого лет 5 на Angular, а так же 15 лет во фронтенде в целом. По идее, раз так, я наоборот должен был бы хейтить Vue, так как старые технологии всегда кажутся более понятными, а новые вызывают много непонимания, но здесь наоборот. Хейтить Ангуляр я имею полное право, точнее не хейтить, а аргументированно указывать на недостатки. По Реакту мне подсказали, что компоненты можно создавать проще, если отключить JSX, в этом я не прав, но даже с учётом этого их размер всё равно больше, чем на Vue, поэтому моих знаний React вполне хватило для обоснованной аргументации.
Давайте будет откровенны, ваш пост несёт в себе много много необоснованного хейта, и я только что пояснил, в чём именно. Ваш же пост такой агрументации не содержит, только предположения о человеке, второй снизу уровень на пирамиде Грэма. Поэтому повышайте культуру общения, и удачи вам с вашими собственными статьями.
rboots
Если бы прочитали одно предложение дальше — узнали бы, что ничем. А теперь у вас осадочек мутный. Мне кажется плохим тоном критиковать то, что не прочитал.
Fragster
Мне только одно непонятно, зачем в vuex выделили мутации и запретили менять state из action напрямую?
JSmitty
Action — это такая калька с actionCreator-ов в React (точнее redux-thunk по сути), соответственно мутации как бы эквивалентны action+reducer. Дизайн делался с оглядкой на Flux/Redux, и это видно во всём.
Fragster
Общий смысл мне понятен. Но непонятно, почему в компоненте я пишу this.var = value и всё работает, а в vuex я вынужден для каждой переменной store писать функцию по установке значения и в action'ах писать context.commit('setVar', value)?
indestructable
Вью — это то, каким должен был быть первый Ангуляр. С ним легко начать, и легко делать простые приложения, но для сложных вещей его DSL недостаточно гибкий.
Вью позволяет использовать привычный и более легко воспринимаемый компонентный подход со стейтфул компонентами.
Реакт требует пересмотра самого подхода к проектированию. Использовать стейтфул компоненты можно, но Реакт этого не поощряет (я имею ввиду не стейт самого компонента, а бизнес данные в стейте).
С Реактом и, например, редаксом, тяжело начинать (особенно первые несколько раз), потому что подходы к архитектуре кардинально отличаются от подходов, например, Ангуляра.
Одно только редактирование форм после Ангуляра может заставить человека бросить Реакт и вернуться к Ангуляру :)
Однако, сложные вещи делать проще, расширять приложение проще, приложение более гибкое, и изменения применять проще.
Я приведу свой опыт с Реактом — я Реакт практически не замечаю. Потому что вся сложность — она в app state. Компоненты разрабатывать проще — потому что думаешь про функционал самого компонента — какие свойства ему нужны и как они повлияют на отображение компонента.
Да, этот подход можно использовать и в Ангуляре — но стал бы я его использовать там, если бы не попробовал раньше? Уверен, что нет, ведь проще сделать двусторонний байндинг, а не разнести потоки данных.
vintage
Одно другому не мешает, вполне можно разносить потоки данных и через двусторонний биндинг.
dos
Вопрос к знатокам React/Vue — если бы была задача реализовать компонент грида, обладающего хотя бы основными возможностями грида от ExtJS то на каком бы из фреймворков бы вы это делали и почему?
raveclassic
Вы понимаете, что только подливаете маслеца в огонь? :)
Половина скажет React, половина — Vue.
Starche
Я б делал на втором ангуляре. Просто потому что я уже его делал на втором ангуляре. Сортировка, фильтрация, нормальная пагинация/бесконечный скролл, прибитая к верху шапка, подгрузка с сервера/подготовленные заранее данные, кастомно оформленный скроллбар (перетащил логику из nanoscroller.js), выделение чекбоксами. Мне пока не были нужны фичи типа группировки строк, но я представляю, что мне надо дописать в существующий код, чтобы их получить. И это будет не очень много возни.
Ну а ячейки я могу оформить как угодно, потому что это пишется прямо в шаблоне, могу хоть компоненту графика туда подгрузить, хоть редактируемую ячейку сделать.
Аналогично и с оформлением шапки/футера: любые кнопки можно вкинуть, это не проблема.
Ну и количество кода, конечно, смехотворное на это уходит.
jakobz
Писать что-то серьезное на нетипизированном языке — нельзя. Как следствие, все фреймворки со своими шаблонами — сразу выкидываются в помойку, без попыток в них разобраться.
staticlab
А как же TypeScript?
jakobz
Речь про DSL шаблонов, в котором строгой типизации нет, и как ее приделать — непонятно.
JSmitty
Пишите рендер-функции, и будет типизация как и в остальном коде.
vintage
Кроме тех, что компилируют шаблоны в тайпскрипт.
VolCh
JSX — это XML по сути со вставками JS/JS+Flow Type/ Typescript (то, что лично пробовал) со всеми вытекающими.
JSmitty
Сам фреймворк, AFAIK, написан с использованием Flow. Для желающих есть поддержка Typescript от коммьюнити.
raveclassic
Речь идет не о фреймворке, а о проектах его использующих.
G-M-A-X
Я хз, может я баран.
Но мне проще писать на jQuery как я хочу, а не вникать в эти новые веяния, которые быстро умирают, в отличии.
При этом учитываем, что:
а) старые ресурсы нету особого смысла переписывать на что-то другое
б) есть куча заготовок, которые упрощают жизнь
В чем их преимущество над jQuery? :)
TimTowdy
В том, что разваливаться от сложности ваш проект на jQuery начнет через 3 месяца, на React через 6, а на Vue через 9.
<sarcasm>А на Angular — еще до начала проекта.</sarcasm>
kellas
Меня удивляет что все как-то обходят стороной Riotjs
Fen1kz
Давно присматриваюсь к vue, но статья вообще не убедила. Автор, прости, она, мягко говоря ужасна.
Чем? Цель этой статьи — убедить использовать "лучший фреймворк на 2017 год". Как она убеждает?
Я прошелся по статье и собрал все плюсы vue которые вы написали
Что бть? Серьезно, не шутите? Давайте в автожурналах писать "Хендай — лучшая машина 2017" и первым пунктом там ставить "у нее пепельница вынимается быстрее чем в других машинах". И это первый мать его реальный плюс. Не надо так, пожалуйста.
I see what you did there… Вы думаете что лучший фреймворк как UI — чем меньше тем лучше? Ну, ваше право.
В Реакте такой компонент занимает 1 строчку и 91 символ (я видел вы в комментах считаете и символы):
export default ({todo}) => (<li>{todo}</li>)Ну, неужели пошли какие-то реальные плюсы?
Ну как бы это стандартный import todo from
Воу, воу, вы уже сказали что первый и главный плюс, цитирую "Это действительно весь код, который вам нужен, это не шутка." То есть в начале сказали что отсутствие сборщиков — плюс к vue, а сейчас — присутствие сборщика — плюс к vue?
Карл, ты когда пишешь в плюсах "не засирает глобальную область", ты как бы в прототип-то не лезь, Карл.
Фейспалм.
В общем, я расстроен, у меня были такие надежды на vue и на вашу статью (из-за провокационного заголовка), а получился какой-то hello world =\
VladVR
И я об этом же написал. За парой нюансов — мне не нравятся анонимные функции, в стектрейсе если что хочется видеть имя, и я не использую export default, потому что навигация в VsCode не так срабатывает. Чтобы перейти на имплементацию надо два клика вместо одного. И я готов ради таких удобств жертвовать краткостью. Что сразу же подразумевает, что краткость для меня — не первый приоритет.
В ангуляре же(что первый, что второй/четвертый), как и во Vue(если не ошибаюсь), речи про навигацию вообще не идет. нужно скопипастить строчку и ctrl-shift-f.
raveclassic
Кстати, если совместить именованные экспорты и TS, то большинство IDE/редакторов смогут помочь автоимпортом.
Fen1kz
На самом деле плевать сколько там строчек, лично для меня, в отличие от автора, это будет приятный бонус, нежели один из основных пунктов что этот фреймворк — "лучший в 2017"
VladVR
вот это
на реакте пишется вот так
Существенно проще, не правда ли?
Если говорить о простоте в терминах «понять как оно работает», и «понять как на этом писать», то получается, что у реакта jsx являет собой некоторую сложность, конечно, но сложность несравнимо меньшая, чем некоторый template engine, в котором, как и в ангуляре, свой ужасный микро-язык (я вот об этом v-for=«item in list», не хватает только любимого хака track by $index), с кучей всяких деталей и конвенций, которые нельзя понять, можно только простить. И вот мы все успешно это изучили, а теперь с приходом второго ангуляра это надо как то из головы выбросить и начать вталкивать другой микро-язык, который стал еще хуже(box-of-bananas-syntax [()] ). И еще одна альтернатива, которая взяла из ангуляра худшее, и переиначила на свой лад ради более краткого синтаксиса — просто идет в топку.
И да, не стоило «отвергать» typescript. На типизованном языке настолько проще поддерживать код, что на чистый js возвращаться уже не хочется. Вот тут, кстати я посмотрю, некоторые люди ui фреймворки отвергают, и пишут на jquery. Какой уж там typescript.
VolCh
https://www.npmjs.com/package/@types/jquery :)
franzose
Во Vue можно использовать "локальные" компоненты. Будет примерно то же самое:
sitev_ru
На данный момент не использую для веба ни Vue, ни Angular, ни React, обхожусь пока Javascript/JQuery). Поэтому сильно не бейте). Решил попробывать Ваш примерчик.
Меня напрягает сразу же следующее: появляется надпись {{ message }}, которая держится целую секунду! Потом надпись меняется на «Hello Vue!»
Как сделать, чтобы сразу выводилось «Hello Vue!»?
vintage
Стандартный костыль ко кривому дизайну: https://vuejs.org/v2/api/#v-cloak
TimTowdy
Не нужно дезинформировать людей. К кривому дизайну это отношения не имеет. Эта проблема возникает только в случае когда шаблон берется из DOM, а не из строки, что не рекомендуется делать т.к. браузер может зарезать некоторые тэги. Подозреваю что возможность брать шаблон из DOM сделана исключительно для упрощения туториала, в продакшене это никем не используется.
sitev_ru
Решается проблема очень просто: вместо того чтоб шаблон брать из DOM, его стоит передавать в компонент напрямую через template (передавать туда либо строку шаблона, либо #id <script> тэга с шаблоном).
vintage
Даже получение шаблонов из дом можно сделать куда прямее.
TimTowdy
Например как? Мне правда, очень интересно.
vintage
https://developer.mozilla.org/en/docs/Web/HTML/Element/template
restyler
и что, по-вашему, Vue так не умеет? :) https://jsfiddle.net/coligo/fjpqz387/
vintage
Речь не о том, что он умеет, а о том, что позволяет и рекомендует и для чего даже везёт с собой костыли.
TimTowdy
Речь о том, что вы не разобрались во Vue, но спешите его критиковать.
Во Vue есть два понятия: mount element (el) — элемент, внутри которого будет рендериться ваше Vue приложение, и template — собственно шаблон разметки вашего приложения.
Задача Vue — реактивно рендерить шаблон внутри mount element.
В исключительном случае, когда приложению передан только mount element, без template, Vue делает следующее:
1. генерирует template из DOM-содержимого mount element
2. замещает содержимое mount element отрендеренным template
Именно в этом причина проблемы sitev_ru.
Элемент <template> ничем не помогает: Взять шаблон из конечно него можно, а вот использовать его как mount element, по понятным причинам — нет.
Ну и судя по тому, что в предоставленной вами ссылке стоит No Support у IE, и вопрос — у части мобильных браузеров, я не вижу ничего удивительного в том, что Vue нигде не рекомендует использовать такой способ передачи шаблона.
vintage
Вы молодец, что разобрались, как маунтятся все ангуляроподобные фреймворки, но мой тезис о том, что это кривая логика, которой вообще не должно было быть, это не отменяет.
В чём проблема преобразовать
<template>в<script type="template">поддерживающийся всеми браузерами?TimTowdy
Кто будет преобразовывать? Vue работает в том числе и без транспиляторов.
Да и зачем? Если можно сразу использовать <script type=template>?
Вы свою аргументацию вообще слышите?
«логика кривая потому что этого вообще не должно быть»
«вместо <script> нужно использовать <template> и преобразовывать его в <script>»
vintage
Ну пишите вручную
<script type="template">какие проблемы?Логика кривая потому, что отображение неинтерполированного шаблона никому не нужно. Вообще никому. Но в документации мы видим именно такие примеры. От чего каждый разработчик ходит по одним и тем же граблям.
TimTowdy
Так я и пишу <script>, это вы зачем-то рассказываете что «правильнее» использовать <template>, хотя потом выясняется что это не так.
В документации этот случай описывается неоднократно. Но я согласен что магия двойного использования mount element скорее вредит новичкам, чем помогает. Предполагаю что это сделано по большей части для маркетинга (легче рекламировать Vue). Лично мне эта магия не нравится, но жить совсем не мешает (я всегда указываю template). Разводить из-за этого истерику и кричать о «костылях» я точно не собираюсь.
JSmitty
Вариант такой:
А вообще проблема типовая, для Angular.js 1 даже название придумали — FUC (Flash of Uncompiled Content). И да, в случае полноценно собираемого SPA приложения проблемы не будет.
Akuma
Ахаха, я все ждал когда появится этот комментарий, но к сожалению уехал.
Вернулся — а тут оно самое :)
Добро пожаловать в мир Vue (Angular 2017).
Совсем скоро вы познакомитесь с «track by $index» и другими модными костылями :)
erlyvideo
ну вы серьезно? Не, так не надо продавать то, что вам нравится.
riky
vue выстрелит за счет низкого порога входа. его киллер фича в этом.
думаю скоро его будут пихать как jquery на каждый сайт.
serf
Он еще довольно легкий по размеру и с хорошей документацией.
KirEv
не холивара ради, но почему не использовать технологию\язык исходя из:
а) я владею и разбираюсь
б) решение быстрее и удобнее
Посмотрел пример модального окна: https://vuejs.org/v2/examples/modal.html
Чтобы сделать подобное на яквери:
1. подключить jquery ui
2. написать 4 html-тега для окошка
3. и одна строчка js-кода, одна строчка Карл!
Мне не понятно в каком месте vuejs что упрощает.
Но самое интересное начнется при необходимости нетривиального решения.
JSmitty
Вы сравниваете несравнимое. Попробуйте реализовать этот контрол на чистом JS + HTML.
Ну и для полноты — есть такая библиотека, vueStrap, там модалка реализуется фактически в 0 строк JS:
Areso
https://unpkg.com/vue
259 килобайт
staticlab
https://unpkg.com/preact
20,3 кб
Fragster
vue.common.esm.js 50кб gzip
vue.esm.js 70кб gzip (это если зачем-то на клиенте нужно шаблоны «компилировать»)
Areso
Вы в страницу в соурс скрипта будете gzip вставлять? Это работает?
Просто я прошелся по ссылке на скрипт из примера и слегка огорчился.
Примерно также меня огорчает jQuery UI в половину мегабайта ради настраиваемых надписей на модальном окне с предупреждением.
staticlab
В любом случае сервер скорее всего передаст и html, и js гзипованными.
TimTowdy
Вы сейчас шутите? Посмотрите на заголовки HTTP-запроса вашего браузера. «Accept-Encoding: gzip» ни о чем не говорит?
Пожатый Vue весит ~20KB, в 2 раза меньше React и в 5-6 раз меньше Angular.
https://gist.github.com/Restuta/cda69e50a853aa64912d
teux
Хром недавно поддержал параметр ?react_perf и теперь можно профилировать react-компонеты на Timeline.
Интересно, будет в хром параметр vue_perf?
vintage
Хром тут ни при чём, это возможность самой библиотеки.
teux
Да, вы правы. Я не точно выразился. Просто порадовался новому удобству в Хроме
alek0585
Статья ни о чем, конечно, но и комментаторы сплошь гении. Так может быть кто-нибудь сможет ответить на вопрос заголовка статьи?
TimTowdy
Почему Vue.js — лучший фреймворк для front-end разработки на 2017 год?
Просто потому что Vue моложе и воспользовался возможностью учесть ошибки своих предшественников. Взял от них лучшее, избавился от худшего. Получилось крайне удачно.
indestructable
Вынесу вопрос в корневой комментарий.
При чтении комментариев неоднократно натыкался на утверждение, что Vue использует virtual DOM, и на самом деле, неявно работает похожим на React (а точнее, на JSX) образом, а именно преобразует шаблон компонента в построение виртуального дерева, и на самом деле шаблоны можно не использовать, а можно использовать render функции (то есть практически аналог функции
render()в Реакте, как я понял).У меня в связи с этим несколько вопросов:
Спасибо
staticlab
Не специалист во Vue, но Virtual DOM в нём действительно есть: https://github.com/vuejs/vue/blob/dev/src/core/vdom/patch.js
Это как раз то, что автор данной статьи предлагал легко написать в 50 строк.
indestructable
Частично отвечу на свой вопрос:
https://vuejs.org/v2/guide/render-function.html
Действительно, вместо шаблона можно использовать функцию, которая возвращает виртуальный DOM, есть даже JSX для Vue (сюрприз-сюрприз). Шаблоны компилируются в нее же.
Судя по беглому изучению документации, все это очень сильно завязано на внутреннюю кухню Вью, элегантности Реакта (все есть или функция или ее параметры, все: свойства, события, дочерние элементы (которые могут быть опять же чем угодно)) здесь нету.
Меня больше удивило другое: во Вью присутствуют элементы самых разных концепций: change tracking + dependency graph, вычисляемые свойства со встроенной мемоизацией (тут я могу ошибаться), встроенная шина сообщений.
Делается это, насколько я понимаю, для оптимизации генерации virtual DOM (зачем еще это может понадобиться, ума не приложу).
Если проводить аналогии с Реактом, то Вью — это Реакт + MobX для стейт менеджмента локальных данных компонента + свой язык шаблонов для описания рендер-функций, более близкий к HTML, чем JSX.
Для себя я сделал предварительные выводы:
тот, кто говорит что Вью проще Реакта — говорит в первую очередь о языке шаблонов (и противопоставляя его JSX). Внутренняя кухня имеет на порядок больше концепций, чем Реакт, и изучать ее гораздо сложнее.
Попробуйте, не заглядывая в доку, сказать, что делает этот кусок кода:
(создает двустороннюю привязку)
, это не Ангуляр с произвольно расширяемым набором атрибутовесть кастомные директивы. Однако, для Реакта ничего не мешает сделать то же самое, первый же найденный пример — http://wix.github.io/react-templates/TimTowdy
indestructable
Спасибо за ответ.
1, 2 — сам разобрался
3. Зачем они нужны? Работают ли они с виртуальным ДОМ или с реальным? Правильно ли я понимаю, что директивы — это способ работы с ДОМ элементами?
4. Можно пример функциональной композиции ангуляровской директивы или компонента?
TimTowdy
3. Предназначены для работы с реальным ДОМ, но доступ к виртуальному есть.
4. С ангуляром у меня отношения не сложились, поэтому пример не приведу. Композицию контента можно посмотреть в ссылке про слоты. Обычно композицию компонентов во Vue все же делают более стандартными extends/mixins. Но функциональная композиция вполне возможна, просто потому что она не привязана к какому-то фреймворку. Хотя до идиоматичности во Vue ей конечно пока далеко.
indestructable
А как считаете, помимо языка шаблонов (который можно прикрутить и к Реакту), и скорости (которая достигается через observable data, и может быть использована в Реакте через сторонние либы), какие преимущества у Вью?
На мой неискушенный взгляд в нем слишком много концепций со своими ограничениями: наблюдаемые данные, шина сообщений, ограничение на вычисляемые данные в шаблоне, встроенная мемоизация — нужно ли это? Не приводит ли это к странным неинтуитивным багам типа когда не вызвал apply в Ангуляре, или явно борешь ленивость логических выражений, чтобы затрекались зависимости в Нокауте?
vintage
Боюсь там всё не так просто. Чтобы реакт увидел изменения нужно в любом случае перередеривать всех предков до корня, что может быть весьма не быстро.
Это вы о чём?
indestructable
В Нокауте зависимости между observable трекаются так:
aа), считаются зависимостямиа. При их измененииасчитается измененным.Проблема заключается в следующем. Пусть есть observable (вернее, computed, в терминологии KnockoutJS), который вычисляется следующим образом:
Для того, чтобы
a,bиcбыли помечены как зависимости, они должны быть выполнены при выполненииareAllTrue. Однако, еслиa() === false, тоb()иc()вызваны не будут (т.к. результат логического выражения уже известен), и, значит, они не будут помечены как зависимости, а значит, неareAllValidне будет пересчитан при измененииb()илиc().В общем-то, это не большая проблема, если фреймворк строит граф зависимостей при каждом вызове (а не один раз при первом).
vintage
Так нокаут при каждом вызове и трекает же. С чем вы там боретесь-то?
VladVR
Если говорить о проблемах в нокауте, то мы натолкнулись вот на такую:
есть массив объектов, у которых observable свойство isChecked. Мы делаем фичу selectAll. Чтобы отобразить значение чекбокса над гридом пишем примерно такой код
далее по нажатию на этот чекбокс нужно все элементы поставить в новое значение чекбокса над гридом
при изменении каждого из этих observable пересчитывается вышеозначенный computed, то есть мы получили на пустом месте O(n в квадрате)
vintage
В нокаут уже давно завезли отложенное обновление, но по умолчанию оно выключено для совместимости.
TimTowdy
Не думаю что у Vue есть хоть одно серьезное преимущество в плане каких-то уникальных фич. Многие расхваливают слоты, но это конечно далеко не killer-фича.
Для меня Vue это просто SPA-framework с хорошим интерфейсом. Умеет абсолютно все то же, что и остальные фреймворки, но делает это чуточку лучше.
Переписывать существующие React/Angular приложения на Vue смысла не вижу. Как и не вижу смысла начинать новое приложение на React, если есть Vue. Как чтение, так и написание кода приложений лично мне кажется более интуитивным по сравнению с React. Когда я смотрю на код React-приложений, у меня постоянно возникает мысль «ну неужели это нельзя было сделать лучше?!». Vue в этом плане как глоток свежего воздуха.
Подводные камни конечно встречаются и внутренняя магия может дать о себе знать. Одно только отслеживание зависимостей computed свойств чего стоит (элегантное, но жутко неочевидное решение). Новички вероятно столкнутся с проблемами, вызванными непониманием внутренностей. Но это будет в любом фреймворке. C другой стороны сообщения об ошибках и warnings у Vue очень информативные.
Часть проблем вызвана недостатками самого языка, например в Javascript до сих пор невозможно сделать getter/setter/deleter на индексы (даже с учетом транспиляторов, спасибо IE). Т.е. возникает такая ситуация:
В целом, неинтуитивные баги конечно встречаются, но (субъективно) реже чем в других фреймворках. YMMV.
vintage
Абстрагировать от асинхронщины не умеет. Ленивый рендеринг не умеет. Детальную кастомизацию любого компонента не умеет. Двусторонние каналы не умеет. Автоматически вставлять индикатор ожидания не умеет. Не падать, из-за одного сбойного компонента не умеет. Выносить локализуемые тексты из шаблонов не умеет.
franzose
Немного странные претензии.
vintage
Ну и знаете, аргумент "этого нет в моём фреймворке, поэтому это не нужно, а значит в нём есть всё, что нужно" — так себе.
franzose
vintage
Мало сделать компонент, в большинстве фреймворков нужно ещё создать развесистый конфиг и написать кучу кода по его интерпретации.
franzose
Ну, про программерскую ошибку. Или вы имели в виду ошибки типа отвалившегося запроса по таймауту или чего-то подобного?
vintage
Вам нравится с горящей задницей фиксить баг в каком-нибудь датапикере, который сбоит на сегодняшней дате, от чего у половины пользователей приложение перестало открываться? Особенно весело, когда это сторонний компонент, написанный в лучших традициях говнокода.
franzose
В таком случае я бы просто заменил компонент на другой. Ну, а если в наличии ничего более адекватного нет, то либо сделал бы pull request авторам, либо своё б написал на худой конец.
vintage
Суть не в том, какой плохой компонент, а в том, как фреймворк реагирует на исключительные ситуации.
raveclassic
Кстати в React 16 наконец-то запилили адекватный механизм обработки ошибок
franzose
Любой фреймворк выдаст вам ошибку и упадёт. Серверные поступают ровно так же.
vintage
Не обобщайте. Например: http://mol.js.org/#demo=mol_app_files_demo/current=http%3A%2F%2Fajaxexplorer.com%2FUser5df12c6
bano-notit
-_-
А ещё какой-нибудь пример можно?
vintage
А этот чем не нравится? Впрочем, пожалуйста: http://mol.js.org/#demo=mol_app_habhub_demo/gist=21423554
raveclassic
Мне бы вашу невозмутимость :)
bano-notit
Просто Эту фичу Вашего фреймворка Вы уже Много где рекламировали, а я бы хотел узнать, какие ещё фреймворки там умеют.
vintage
Мне о таких не известно. Скорее всего больше никакие.
lega
В alight можно прикрутить обработку ошибок, можно вывести трейс, скоуп, обработать проблемный элемент и т.п. пример.
vintage
К сожалению работает не везде: https://jsfiddle.net/gkrzztrb/4/
Всё приложение тем не менее не падает, да. Но без реактивности оно в общем случае не сможет восстановить свою работу и будет глючить до перезагрузки, даже если причина исключения устранена.
franzose
В итоге всё равно ошибки необходимо будет обрабатывать самостоятельно.
lega
Работает везде (где нужно), просто баги в разных местах могут иметь нюансы, напрмер в вашем примере ошибка возникает до «объявления» обработчика, а обрабочик дожен быть привязан заранее (до ошибки) если нужно что-б он был вызван, поправил пример
Но даже без обработчика, все «приложение» работает за исключением этого багового биндинга на кнопке.
vintage
Классный стектрейс, сразу понятно, где ошибка :-)
Без реактивности более-менее сложное приложение может начать глючить вплоть до невозможности использования.
lega
Как раз наоборот, сложное приложение состоит из изолированных компонентов которые никак не влияют друг на друга побочными эффектами.
Можно даже заморочится и делать разные компоненты на разных версиях фреймворка (кстати — идея, для плавного апргрейда).
vintage
Исключение возникает не в выражении, а в коде, который из него вызывается.
Ещё как влияют. Пользователь изменил своё имя — оно должно поменяться везде.
lega
Ключевое слово «побочными эффектами», если один компонент поменял имя, он отразил изменения в сервисе, другие компоненты получили это изменение из сервиса (как вариант архитектуры). Если в каком либо компоненте что-то сломалось, оно никак не повиляет* на другие компоненты.
lega
Хотел поправить, а там все в порядке, проблема в примере, throw строки трейса не дает, при настящей ошибке трейс есть, пример.
vintage
Блин, точно, извиняюсь.
lega
Да и я не позиционирую это как какую-то супер фичу, просто вызываю одну и ту же функцию при возниконовении исключений, ничего сверхестественного.
Странно, что подобной мелочи нет во многих вреймворках.
vintage
Ну, стектрейс-то хотябы не надо проглатывать.
TimTowdy
Большая часть перечисленных вами вещей уж слишком opinionated, и просто по определению должна быть не в core фреймворка, а в стороннем модуле. Тот, кто потащит все это в core имеет очень низкие шансы попасть в мейнстрим.
И тут все верно, по количеству сторонних модулей, Vue, из-за своей молодости проигрывает. Но если руководствоваться только этим показателем, то нужно всегда выбирать jQuery.
franzose
Ну, лично я за компонентность, а не монолиты)
vintage
TimTowdy
Предлагаю фанатам React провести мысленный эксперимент: представьте, что в 2013 году Facebook выпускает не React, а Vue (версии 2). А сам React (в текущем виде) выходит в 2016. Как вы думаете, смог бы React набрать хоть какой-то значимый вес? Простили бы ему в 2016 году JSX?
taujavarob
VladVR
Абсолютно ничего бы не изменилось. Vue — всего лишь «еще один фреймворк», по крайней мере если судить по тому как его презентовал автор. React предлагает принципиальное отличие. Там где «все остальные фреймворки» тащат javascript в разметку, react затащил разметку в javascript. Совместно с typescript, это еще и дает то, что весь рендер типизован.
А это в свою очередь дает то, что если человек опечатался где то, то он получит исчерпывающее сообщение об ошибке на этапе сборки приложения. А не типичную ситуацию «обычного порошка», когда ты собрал приложение, запустил, и получил пустое место, там где должен быть какой то текст. Или не вставилась директива/компонент. И сиди догадывайся что не так. Ибо возможностей для отладки около нуля, нормальных сообщений об ошибках примерно столько же, валится по совершенно непонятным причинам.
И опять даже если использовать реакт без типизации, и допущена ошибка, во первых с наибольшей вероятностью будет стектрейс с указанием компоненты, строчки и позиции, где эта ошибка случилась, во вторых, если оно не упало, а просто «не работает», то можно поставить брейкпоинт и посмотреть содержимое всех переменных, а не догадываться, чему они могли бы быть равны в тот момент когда ошибка случилась, а не тогда, когда открыл батаранг, но уже поздно.
Еще один концептуальный шаг вперед, это redux и PureComponent вместо обычного Component. Также как и в случае с Flux, cостояние полностью отрывается от представления, и вся концепция приложения разрывается на 3 части, но в отличие от Flux, две части из трех становятся чистыми (pure).
1) новое состояние = чистая функция от двух параметров — предыдущего состояния и «возбудителя»
2) разметка = чистая функция от состояния
3) сервисы, в них смещен весь «нечистый» код, в частности асинхронный.
Конечно команду надо сильно попинывать, чтобы не нарушали концепцию, но возможность иметь две трети приложения написанными чистым кодом того стоят.
Второй ангуляр кстати очень неплохо ударил по этому фронту, даже свою реализацию redux написали, хоть и не по феншую совершенно. Однако если на нее не смотреть, а взять обычный, православный redux, и stateless компоненты, то можно достичь близкого результата. Терпимого я бы сказал, в условиях того, что заказчик уперся и хочет второй ангуляр хоть ты тресни.
raveclassic
до слез
babylon
Согласен с комментом. Есть ещё jsonnet
staticlab
просто говорили бы, что ФБ тупо скопировал всё у Гугла.
Fen1kz
deletedcdrw3
Эх, помнится на заре моей юности такие холивары устраивали по вопросу, на чем лучше писать — на delphi или с++))
Только не бейте меня сильно (react в своих проектах не использую), но нас раньше учили отделять код от верстки, а сейчас JSX позиционируется чуть ли не как панацея от всех бед. Что изменилось?
indestructable
Нужно отделять бизнес-логику от верстки, код управления состоянием от верстки, служебный код (логгирование, замеры производительности) от верстки.
Но код, управляющий версткой, от верстки отделять не нужно.
vintage
Нужно отделять всё, что отделяется. В частности программный код и декларативную композицию.
raveclassic
Что мешает в декларативной композиции использовать возможности языка вместо кастомных DSL?
vintage
Теряется собственно декларативность.
raveclassic
Теряется, если ее намеренно терять. Вам точно так же в code-behind классах для XAML компонентов (типичный представитель view) никто не запретит ходить в базу. Так какой смысл в этом параноидальном отделении кода для view от шаблона для view?
А если не плодить сайд-эффектов, то декларативность остается.
vintage
Как вы думаете, почему конфиги пишут на ini/yaml/xml/json, а не на js/php/c#/java?
raveclassic
Не знаю, я обычно на js пишу :) Тот же вебпак вспомнить…
Не представляю, какая жесть писать конфиг к нему в виде json. К нему и так писать конфиг жесть, но json…
Только если с кастомной шаблонизацией внутри — привет DSL.
vintage
Попробуйте MAM — там вообще никаких конфигов не надо писать.
raveclassic
MAM?
vintage
MAM
VladVR
Вероятно потому что конфиг это сериализуемые данные. Какой правильный ответ то?
К слову мне в мире C# всегда было непонятно, почему build-процедуры пишутся на каком то левом языке msbuild (поверх xml).
В мире JS, как оказалось его легко писать на том же языке, что и основной проект. Берешь Gulp и вперед.
И, внезапно, в последнее время начали появляться build системы, где можно писать на C#, слышал на дотнексте про fake и cake (т.н. f-sharp make и c-sharp make).
Тоже можно было задавать пространные риторические вопросы, типа «а угадай почему билд скрипты пишут на xml» намекая на то, что существует в природе какая то логическая связь и собеседник должен о ней догадаться и склониться к твоей точке зрения. Однако, внезапно оказалось, что причина то банальна, «вчера» сделали как смогли, а «сегодня» делают, как правильно/удобно, а логическая связь — неверна.
vintage
Правильный ответ: возможность различного анализа без исполнения. Простой пример: из view.tree благодаря декларативности очень легко достать информацию о классах, свойствах, типах, связях компонент. Сейчас я пилю абстрактный редактор, который может взять любой компонент и как угодно его изменить. А сделать такое с JSX, например, не получится.
VladVR
«Такое» можно сделать даже в компилируемой среде .Net. А в мире скриптов такое заявлять совсем кощунственно. Именно так работают фиддлеры. Человек в браузере пишет jsx или, к примеру, typescript, нажимает кнопку, написанный код уезжает на сервер, там транспайлер его жует, и результат выдается обратно в браузер. Останется прикрутить поверх jsx свой редактор, и «такое» будет отлично работать.
babylon
Многое из того что потом кодируется напрямую зависит от формата данных.
Давайте лучше обсудим apache avro vs MsgPack
Быстрее это всё в текстовом редакторе набрать в JSON схемах.
vintage
Вы не забыли, что JSX — это не XML, а JS, с "мощностью" которого не каждая IDE-то толком может совладать?
VladVR
Взамен на типизацию, возможности отладки, вменяемые сообщения об ошибках.
Ну и широкоизвестный язык, который лет 20 живет вместо узкоспециализированного DSL, который умрет через пару лет.
VolCh
Утверждения с универсальными квантификаторами редко бывают истинны, если касаются практических задач. В данном случае, отделять нужно то, что повышает читаемость, поддерживаемость и прочие "хорошие" метрики кода, но не более, а не всё, что можно отделеить в теории.
VolCh
В нормальном JSX кода не больше чем в вёрстке шаблона на любом, ну, почти любом, шаблонизаторе. А императивного кода и того меньше из-за невозможности использовать if/else, for и т. п. внутри разметки.