Сегодня мы поговорим о React.js и Vue.js. Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub. И та, и другая обладают впечатляющими возможностями и служат для создания пользовательских интерфейсов. Работать с ними довольно просто, главное – сразу понять, что к чему, сделать правильный первый шаг. Собственно говоря, этому вот первому шагу в разработке с использованием React и Vue и посвящён данный материал.
На первый взгляд, эти библиотеки очень похожи. Действительно, они служат для одной и той же цели. Сходства этим не ограничиваются. В частности, в документации к Vue.js есть раздел, посвящённый сравнению с другими фреймворками. Особое место, именно по причине множества общих черт, в нём занимает сравнение с React. Однако, нас больше интересуют различия, причём, касающиеся практических аспектов работы. А именно, речь идёт о том, как именно с использованием этих библиотек описывают пользовательский интерфейс приложения.
Позволим себе процитировать документацию к Vue, которая, кстати, была подготовлена при участии сообщества React: «В React все компоненты описывают свой UI посредством render-функций, используя JSX — декларативный XML-подобный синтаксис, работающий внутри JavaScript.» Фактически, речь идёт о том, что механизмы React помогают внедрять HTML-разметку прямо в код на JavaScript. В Vue же, в основном, применяется другой подход. Здесь используются шаблоны, которые и располагаются в HTML-файлах, и похожи на обычную HTML-разметку. В то же время, JSX-описания на веб-страницы не попадают.
Для того, чтобы разобраться с основами React и Vue, рассмотрим решение простой задачи по выводу на страницу списка. Сначала – пара слов о том, как это делается, так сказать, вручную.
HTML и больше ничего
Наша задача заключается в том, чтобы вывести на веб-страницу (добавить в DOM) список имён недавно принятых на работу сотрудников некоей компании.
Если делать это, используя исключительно HTML, то сначала надо создать обычный HTML-файл (назовём его index.html), в котором, помимо служебных тегов, будет такая вот конструкция:
<ul>
<li> John </li>
<li> Sarah </li>
<li> Kevin </li>
<li> Alice </li>
<ul>Тут нет ничего примечательного, это – обычный HTML-список. До тех пор, пока в нём всего несколько элементов, ручная правка кода труда не составит. Но что, если речь идёт о списке в несколько сотен или тысяч элементов, даже не учитывая то, что такой список может нуждаться, например, в динамическом обновлении? Без специализированных инструментов, таких, как React и Vue, справиться с таким объёмом данных очень непросто.
Взглянем теперь на то, как решить ту же самую задачу средствами React.
React JSX
Итак, выводим список средствами React.
Первый шаг – создание другого файла index.html. Но в него, вместо тегов, формирующих список, добавим обычный элемент
div. Он будет служить контейнером, в который выведется то, что будет сформировано средствами React.У этого элемента должен быть уникальный
ID для того, чтобы React смог его найти и работать с ним. В Facebook (если кто не знает – React родом именно оттуда) для идентификаторов подобных элементов обычно используют ключевое слово «root», поэтому мы поступим так же.<div id=’root’></div>Переходим к самому важному. Создадим JavaScript-файл, который будет содержать весь код React. Назовём его app.js. В нём и напишем то, что позволит вывести список новых сотрудников в DOM с использованием JSX.
Сначала надо создать массив с именами сотрудников.
const names = [‘John’, ‘Sarah’, ‘Kevin’, ‘Alice’];Теперь понадобится создать элемент React, который динамически выведет весь список имён. Вручную писать код для отображения каждого из них нет нужды.
const displayNewHires = (
<ul>
{names.map(name => <li>{name}</li> )}
</ul>
);Самое важное, на что надо обратить внимание, это то, что не нужно самостоятельно создавать отдельные элементы
<li>. Достаточно описать то, как они должны выглядеть, a React сделает всё остальное. Это – весьма мощный механизм, который отлично подходит для решения вышеупомянутой проблемы «многотысячного списка». С ростом объёма данных преимущества React перед ручной вёрсткой становятся совершенно очевидными. Особенно – если элементы <li> устроены сложнее, чем те, которые мы использовали здесь. Последний фрагмент кода, который необходим для вывода данных на экран – это функция ReactDom.render.ReactDOM.render(
displayNewHires,
document.getElementById(‘root’)
);Здесь мы сообщаем React о том, что надо вывести содержимое
displayNewHires в элемент div с идентификатором root.const names = [‘John’, ‘Sarah’, ‘Kevin’, ‘Alice’];
const displayNewHires = (
<ul>
{names.map(name => <li>{name}</li> )}
</ul>
);
ReactDOM.render(
displayNewHires,
document.getElementById(‘root’)
);Тут важно не забывать о том, перед нами – код React. То есть, перед исполнением, всё это будет скомпилировано в обыкновенный JavaScript.
‘use strict’;
var names = [‘John’, ‘Sarah’, ‘Kevin’, ‘Alice’];
var displayNewHires = React.createElement(
‘ul’,
null,
names.map(function (name) {
return React.createElement(
‘li’,
null,
name
);
})
);
ReactDOM.render(displayNewHires, document.getElementById(‘root’));Вот, собственно, и всё. Получилось React-приложение, которое выводит список имён сотрудников из массива. Ничего особенного, но этот простой пример должен дать вам представление о том, что умеет React. А как сделать то же самое средствами Vue?
Шаблоны Vue
Здесь, как и в прошлый раз, напишем приложение, которое позволяет сформировать веб-страницу со списком имён.
Создадим ещё один index.html. Внутри файла разместим пустой элемент
div с идентификатором root. Тут стоит отметить, что идентификатор элементу можно назначить какой угодно, особой роли это не играет. Главное – чтобы этот ID совпадал с тем, который будет использоваться в коде.Элемент
div будет играть ту же роль, что и в React-приложении. Он сообщит JS-библиотеке, на этот раз Vue, к какой именно части DOM обратиться, когда начнётся вывод данных на страницу.После того, как HTML-файл готов, пришло время создать JavaScript-файл, который будет содержать код Vue. Назовём его, как и раньше, app.js.
Теперь настало время поговорить о том, как именно Vue выводит данные на страницы.
Vue, когда дело доходит до манипуляций с DOM, использует подход с применением шаблонов. Это означает, что в HTML-файле элемент
div не будет совершенно пустым, как это было в случае с React. На самом деле, в HTML-файл будет вынесена немалая часть кода.Для того, чтобы лучше в этом разобраться, давайте вспомним о том, как создать список имён с использованием обычного HTML.
Список представлен тегом
<ul>, содержащим некоторое количество элементов <li>. В Vue нужно сделать почти то же самое, но с некоторыми изменениями. Итак, создадим элемент <ul>.<ul>
</ul>Теперь, внутри этого элемента, создадим один пустой
<li>.<ul>
<li>
</li>
</ul>Пока всё вполне привычно. Отредактируем
<li>, добавив к нему директиву Vue, которая выглядят как атрибут тега.<ul>
<li v-for=’name in listOfNames’>
</li>
</ul>Собственные директивы – это подход, который используется в Vue для добавления JavaScript-функциональности непосредственно в HTML. В начале директив располагаются символы
v-, за ними следует описательное имя, которое позволяет понять роли директив. В данном случае перед нами цикл for. Для каждого имени из listOfNames мы хотим скопировать элемент <li> и заменить его новым элементом <li>, содержащим это имя.Теперь, для того, чтобы сделать код работоспособным, осталась лишь самая малость. А именно, то, что уже написано, позволит сформировать элемент
<li> для каждого имени в списке. Но мы пока не сообщили системе о том, что в этом элементе должно содержаться имя из списка. Для того, чтобы это исправить, надо добавить в элемент <li> конструкцию, синтаксис которой похож на шаблоны Mustache. Возможно, вы такое уже видели в других JS-библиотеках.<ul>
<li v-for=’name in listOfNames’>
{{name}}
</li>
</ul>Элемент
<li> готов к работе. Теперь каждый из элементов списка, сформированного средствами Vue, будет выводить имя из listOfNames. Стоит помнить, что слово «name» в данном случае выбрано произвольно. С тем же успехом можно использовать любое другое, скажем, «item». Всё, что делает ключевое слово – это служит полем для подстановки, которое будет использоваться при обработке списка имён.Осталось лишь создать набор данных и инициализировать Vue в приложении. Для этого надо создать новый экземпляр Vue. Назначим его переменной
app.let app = new Vue({
});Объект Vue принимает несколько параметров. Первый, и, пожалуй, самый важный, это
el (то есть, элемент). Он сообщает Vue о том, где именно в DOM находится место, куда надо добавлять новые элементы. Это очень похоже на то, как работает React.let app = new Vue({
el:’#root’,
});Последний шаг – добавление в приложение Vue данных. В этой библиотеке передача данных приложению выполняется через параметр экземпляра Vue. Кроме того, у каждого экземпляра Vue может быть только один параметр каждого вида. Хотя параметров довольно много, в нашем примере основное внимание можно уделить лишь двум – это вышеописанный
el, и параметр data.let app = new Vue({
el:’#root’,
data: {
listOfNames: [‘Kevin’, ‘John’, ‘Sarah’, ‘Alice’]
}
});Объект
data теперь содержит массив listOfNames. А когда понадобится использовать этот набор данных в приложении, его нужно будет лишь вызвать, используя директиву. Всё довольно просто. Вот как выглядит готовое приложение.HTML:
<div id="root">
<ul>
<li v-for=’name in listOfNames’>
{{name}}
</li>
</ul>
</div>JavaScript:
new Vue({
el:"#root",
data: {
listOfNames: [‘Kevin’, ‘John’, ‘Sarah’, ‘Alice’]
}
});Заключение
Теперь вы знаете, как создавать простые приложения с использованием React и Vue. Надеемся, вы, с помощью наших простых примеров, сделали первые шаги в областях разработки с использованием React и Vue, и готовы двигаться дальше в поисках «своей» фронтенд-библиотеки.
В итоге хочется сказать, что обе библиотеки предлагают отличный набор возможностей. Обычно, хотя это, вероятно, вопрос привычки, Vue несколько проще в использовании. Стоит отметить, что Vue поддерживает JSX, но подобный подход к созданию Vue-приложений используют нечасто.
В любом случае, и React, и Vue – это мощные инструменты, любой из которых позволяет создавать отличные веб-приложения, и, что бы вы ни выбрали – точно не прогадаете.
Уважаемые читатели! А чем вы пользуетесь для фронтенд-разработки?
Комментарии (104)
Stronix
03.03.2017 14:15А как обстоят дела с индексацией поисковиками этих «реактивных» SPA?
ainu
03.03.2017 14:22Реакт можно компилировать на сервере и отдавать HTML.
nckma
03.03.2017 15:12-3А кто компилирует такое? Это какие-то php скрипты или что?
Я честно говоря не программирую веб, вот такие статьи читаю и пытаюсь понять что это вообще такое.
Такое впечатление, что чистого языка мало и придумывают язык в языке, как какое-то мета-программирование…
Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?sp1ne
03.03.2017 15:21Лень — двигатель прогресса.
nckma
03.03.2017 15:32Так а где же тут лень?
Знал бы только JS и радовался, но нет, нужно еще понять, что такое React, Vue, Angular, JQuery.
Получается работы по изучению в 5-10 раз больше. И можно ли стать хорошим специалистом если единая в общем веб технология растаскивается на разные подмножества языков, библиотек, компиляторов из мета-языков в другие языки…Yozi
03.03.2017 15:48+4Можно хоть на чистом JS, конечно. Но только в процессе создания большого продукта Вы фактически создадите свой микро (или даже не микро) фреймворк, а потом кому-то не вам его поддерживать.
Знал бы только React и радовался, но нет, нужно ещё понять, что такое MyAwesomeFoo, YetAnotherBar, CoolBaz. Получается работы по изучению в 5-10 раз больше.nckma
03.03.2017 17:06+1У меня просто по возникает такое ощущение, что есть языки, где время бежит не так быстро.
Например,
1) у железячников
Verilog/VHDL — все более или менее стабильно годами. Ну появился SystemVerilog, но как-то не быстро народ его берет на вооружение.
2) У микроконтрольщиков, там вообще только C редко C++. Микроконтроллеры плюс-минус одинаковые. То же время не быстро бежит. Ну наверное побыстрее, чем у ASIC-WORLD
3) C++ да появляются новые стандарты C++11, C++14, C++17 ну тут побыстрее жизнь идет, уже трудно идти в ногу со временем и приходится стараться.
4) Ну и апофеоз — это веб программирование JS/HTML/CSS и все эти фреймворки. Вот тут мне кажется началась полная вакханалия. Все бегут со скоростью ракеты изобретать новые фреймворки и мета языки.VolCh
03.03.2017 17:13Просто сложные приложения писать даже на современных JS/HTML/CSS сложно вдвойне.
JTG
05.03.2017 14:38Значит не нужно писать сложные приложения на JS/HTML/CSS.
bjornd
05.03.2017 14:45+1Расскажите бизнесу, что вы хотите лишить его единственной возможности мгновенно доставлять клиентам практически любой функционал и контент. Просто потому что вам сложно. Бизнес поржет, уволит вас и наймет того, кому не так сложно.
Apathetic
04.03.2017 00:47+1На самом деле всё просто. Последние годы веб переживает натуральный взрыв. Как у пользователей, так и у бизнеса, требования к вебу растут семимильными шагами. Лавинообразный рост количества фреймворков, библиотек и методологий — это не более, чем следствие растущих ожиданий от веба.
ainu
03.03.2017 15:22React и Vue компилирует сервер на node.js.
React также можно компилировать на сервере, написанном на Go (golang).
Почему не js?..
Ну, у каждого свои причины. Мне нравится, что каждый компонент — это независимая боевая единица. Сделал компонент «Карточка товара» — она доступна, куда бы её не воткнуть. Это даёт некую уверенность в коде. Например, можно сделать страницу с 50 компонентами, и сделать автотесты, которые проверяют, что ни один пиксель не поменялся при изменении кода, ничего не сдвинулось и так далее. Плюс реактовские плюшки вроде виртуального DOM значительно в некоторых кейсах ускоряют отклик и скорость работы фронтенд части (по сравнению с классическим подходом $('.js-element').html('3 товара')).
bjornd
03.03.2017 15:27Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?
Более-менее сложные SPA или web-компоненты, написаные просто на JS очень сложно поддерживать и практически невозможно развивать. React, Vue и дргуие инструменты позволяет применяет более-менее декларативный подход при написании front-end, что существенно сокращает затраты на развитие проекта, поддержку, тестирование.
wert_lex
03.03.2017 16:12Компилируется это на этапе сборки проекта перед публикацией. Т.е. в браузере работает уже "скомпилированная" версия. Не совсем скрипты, совсем не PHP.
Ну, в общем идея такая, что с языком (JS) все более-менее в порядке. Дело в том, что HTML и CSS слишком низкоуровневы для Rich Internet Applications. Поэтому логичным образом появились более высокоуровневые абстракции, который приближают решение проблемы к оперированию над объектами предметной области. В случае с React и Vue отдельно стоит упомянуть Virtual Dom и те проблемы, которые он решает (и создает, ага): https://habrahabr.ru/post/256965/
Отдалённо, связь такая же как и между языком ассемблера и си. На первом можно реализовать абсолютно всё, но долго и дорого.
Borz
03.03.2017 23:08IMHO, для RIA лучше использовать JS-фреймворки под это заточенные, тот же ExtJS например.
spaceseeker
05.03.2017 22:08сразу видно, что вы не писали веб приложения на клиенте. Если не использовать фреймворк, то единственный, кто сможет потом поддерживать всю та лапшу будет её автор, придется молится на него, чтобы он не ушел и весь проект не завалился
А с другой стороны я мог бы прийти в любой проект на реакте и легко в него внедрится потому что
- Весь код организован по некоторым соглашениям и втиснут в общепринятые рамки
- Есть документация и готовая экосистема решений
- Не нужно придумывать велосипед
В общем, надеюсь, идею вы поняли
Yozi
03.03.2017 14:30+1Оба поддерживают server-side rendering (самый настоящий). Немножко про варианты решения проблемы с индексацией можно прочитать тут http://vuejs.org/v2/guide/ssr.html
Stronix
03.03.2017 15:02-2Но тогда теряется преимущество рендеринга на стороне клиента — вместо передачи по сети только лишь данных, мы опять начинаем гонять странички.
ainu
03.03.2017 15:24+4Первое открытие страницы — html, остальные — клиентские. Всё нормально, преимущества на месте.
Yozi
03.03.2017 15:27+5Вы ж спросили про поисковики)
И так, как это делается в React: сервер отрисовывает полностью сформированную, готовую страничку и отдаёт её клиенту. Затем клиент получает эту страничку и иницилизирует SPA поверх уже отрисованного div'а, но так как данные на сервере и клиенте обязательно совпадают, то клиентский код получает точно такой же результат рендера, виртуальный дом видит что нет разницы, и перерисовки на самом деле не происходит. В результате этого клиент получает обычный SPA, очень красиво и незаметно
Spiritschaser
03.03.2017 16:50Мне кажется, значимость привязки server-side rendering к фреймворку переоценена.
У меня так получилось, что к angularjs SPA проще генерировать шаблоны на jinga2+pyjade, чем писать их целиком. В итоге, заполнить шаблон на сервере вместо форм данными модели или уже отдать заполненные формы — легче лёгкого.VolCh
03.03.2017 17:01+1Угу, хоть на PHP можно их генерировать, особенно если этот PHP является API-сервером.
wert_lex
03.03.2017 16:03Вполне пристойно обстоят, есть некоторые нюансы, но можно и без server-side рендеринга обойтись: http://andrewhfarmer.com/react-seo/
myrkoxx
03.03.2017 14:31Сейчас — Ember.js, еще Angular2 выглядит неплохо(сужу по опробованых мной туториалах). Как для бекендщика лучше на фронт нету (чисто мое ИМХО)
bjornd
03.03.2017 15:36+2Ember.js — пробовал и настоятельно не рекомендую. Можно быстро сделать типовой проект, но развивать и кастомизировать — сущее наказание. Взять к примеру ember-data, модуль htfkbpe.obq абстракцию доступа к данным. С первого взгляда все хорошо — следуем определенным стандартам API на сервере и все данные, даже связанные, у нас легко и просто доступны на клиенте. Но копнуть чуть глубже и оказывается, что даже такая простая вещь как откат изменения связи объекта реализуется костылями или monkey-patching'ом.
Kaer_Morchen
03.03.2017 21:02+2Как раз в Ember.js кастомизируется если не все, то почти все, через extend и reopen.
У ember-data по сути только и есть единственная существенная проблема это нет отслеживания изменений связи из коробки, и то отказаться от этого были причины.
Skycker
03.03.2017 21:57Возможно Ember не идеален, но он следует методологии "соглашения превыше конфигураций", за это имхо можно многое простить. Он навязывает структуру прокта и другие принятые в комьюнити конвенции. В случае больших проектов это дает бонус при поддержке и расширении, особенно ценно для пришедших в уже функционирующий проект разработчиков. Наверное, никто не любит поддерживать код, в котором предыдущие программисты пускались в творчество, полузуясь кучей слабосвязанных библиотек. Да и переживать за архитектуру почти не приходится.
До версии 2.0 документация была скудновата, очень многие моменты приходилось собирать по сторонним блогам. Из-за этого и порог вхождения повышался. Сейчас они вроде как исправились, больше деталей описывают в туториале, больше примеров дают, конференции организовывают, митапы
VolCh
03.03.2017 16:05+2Как по мне, то если бэкендщику (классический ООП, MVC, вот это вот всё и совсем немножко ФП) нужно лезть на фронт, то лучше React нет. Да ещё если MobX прикрутить.
Angular2 заточен, скорее, под верстальщиков, которые хотя начинать "настоящей" разработкой заниматься.
myrkoxx
03.03.2017 16:43VolCh я вот не соглашусь. Почему лучше Angular2? С ним проще писать следуя SOLID и DDD. Вот есть у тебя entity post. Написал модель, написал репозиторий, дал интерфейс. В реализации уже подтянул любимую либу для запроса на сервер (будь то RxJS или хоть чистый xhr). Отделно поставиш обработчики на actions, отдельно поставишь темплейт.
Похожая ситуация с Ember. Меня больше заботит то, как данные взаимодействуют. Отрисовать малая часть проблемы в SPA как по мне (если заботиться чисто о view то React подойдет лучше).
bjornd у Ember есть недостаток с тем что у него довольно высокий порог вхождения (как по мне). Наш первый проект был болью но последующие, мне сложно представить как бы мы изошрялись без Ember.
Думаю в каждом из фреймворков есть как + так и — , кому то что то пойдет сложно кому то легче. И еще, по одному проекту судить сложно, думаю для объективной оценки нужно сделать 2-3 проекта.VolCh
03.03.2017 17:00Я так и делаю. Пишу сущность, причём не тупую структуру с данными, а полноценный JS объект с методами изменения состояния, пишу стор/репозиторий с инжектированным шлюзом к серверу/локалстораджу/чемуугодно. Вызываю ReactDOM.render, передав в корневой элемент сторы. И всё. Компоненты реактивно отрисовывают изменения сущностей и репозиториев, обработчики событий дергают их методы.
RouR
03.03.2017 15:05+1В наших проектах в основном нужен viewmodel-databinding. В старом проекте используется knockout, в новом попробовал angularlight
Quilin
03.03.2017 15:30Для малых задач нокаут и правда вполне неплох. Между прочим, Vue.js позаимствовал некоторые концепции именно у нокаута, в частности, процессы привязки событий для реактивности.
werwolfby
03.03.2017 16:05+2Я как бекенд разработчик, тоже очень редко сталкиваюсь с фротендом.
И вот свой проект о котором уже писал тут, переписываю с Angular 1 на Vue. И всё получается очень красиво (на гитхабе можно следить за прогрессом).
До этого было в планах переписать на Angular 2, но в него действительно нынче порог вхождения больше чем в остальные фреймворки: Vue, React и Angular 1.
React имеет большой набор хороших преимуществ, но Vue оказался быстрее и менее многословным и фишку с jsx для Vue я уже тоже заиспользовал, вместо Redux там есть Vuex.
В общем я пока остановился на Vue как основном инструменте для фронт энда для своих проектов. А попробовал уже всё.
Но мой опыт это опты не больших (по не которорым меркам) своих проэктиков и никакого энтерпрайза (там у нас есть фронтендщики). И я доволен Vue так же как когда-то был доволен Angular :)
werwolfby
03.03.2017 16:08+2А ну и собственно попробовать Vue меня убедило вот это видео:
eshimischi
03.03.2017 19:08Есть так же проекты по связке Redux с Vue = revue и др
werwolfby
03.03.2017 19:29Просто vuex от автора vue, что как минимум подкупает, а для меня, как человека далёкого от фронтэнда, оказалось очень удобным.
Но спасибо, гляну на revue
eshimischi
03.03.2017 19:32Авторство это не панацея, если вы еще знакомы с redux-saga, то для vuex тоже есть биддинги vuex-saga или vuex-redux-saga
IL_Agent
03.03.2017 16:30+3Реакт отличается тем, что он не завязан на html, а дает абстракцию над ним. Т.е. теоретически можно юзать готовые компоненты и ничего не писать на html. А бэкендом компонент может быть и не html, и не веб вообще ( см. ReactNative)
werwolfby
03.03.2017 16:32Ну Vue вроде как тоже самое обещает https://weex-project.io/
На сколько я понял из то что знаю, а познакомился я с ним 2 недели назад всего
Crandel
03.03.2017 22:10+3Точно такие же компоненты в Vue. Создаешь файл компоненты с расширением .vue а в нем есть секции
<template></template>, <script></script> и <style></style>
Жаль автор не показал этого в статье. Потом вебпак это все собирает в стандартные js, css. Мне как бекендщику Vue очень понравился, легко и понятно все, от реакта отталкивает именно jsx, привык логику и отображение разделять.
SPAHI4
06.03.2017 19:19нет ничего плохого в смешении логики и отображения, если эта логика относится непосредственно к отображению, а не бизнес-логика
jacob1237
03.03.2017 16:49+2Самое главное забыли написать про Vue — их подход к компонентам.
Вы можете создавать и поставлять отдельные компоненты с расширением *.vue (подмножество XML). Внутри этого файла могут лежать шаблоны, скрипты и стили.
Кроме того, если не хочется все складывать в один
*.vueфайл, компонент можно разнести отдельно на .css, .js, а в *.vue просто подключить эти файлы через атрибутsrc:
<script src="./mycomponent.js"></script> <style src="./mycomponent.css"></script>
Все это потом прекрасно собирается либо browserify (через vueify), либо webpack.
Получается такой себе Яндекс БЭМ из коробки, плюс разделение скриптов и шаблонов.
werwolfby
03.03.2017 17:21Если честно, это не сильно отличается от Angular 2, но там это вынесено в проперти template и styles — причем последний коллекция, что позволяет несколько стилей объединять в один (общие стили например).
И подход к scoped стилям такой же в Angular 2.
А если что можно и по разным файлам разнести, а потом с помощью browserify или webpack собрать.
kopch
03.03.2017 17:24+1Меня, как дизайнера, больше устроил Vue. jsx — всё же больше для кодеров. Месиво из js и html, сразу отбило желание. Хотя уже, конечно, есть инструменты и для этого. Но как-то после NG — Vue привычнее. И компоненты там приятнее, спокойно разбил на 3 файла в папке и не отвлекаешься на сторонний код.
Quilin
03.03.2017 17:41+1Я кодер, но и у меня мешанина js и html отбивает все на свете. Впрочем, для адских поклонников jsx в Vue есть vue-loader для вебпака, с которым вполне можно писать на Vue темплейты на jsx.
werwolfby
03.03.2017 17:52vue-loader как раз доя обработки *.vue файлов, а для jsx нужен другой.
Мешанина html и js всегда плохо я согласен, но бывают задачи когда jsx удобен, я уже писал выше, что для одного случая заюзал именно jsx, так как он удобнее. Во всех остальных нормальные *.vue компоненты
Quilin
03.03.2017 18:45Я имел в виду, что используя vue-loader, вы можете использовать другие loader'ы для разных частей ваших компонентов. В числе которых может оказаться и jsx. Спасибо, что поправили!
bjornd
03.03.2017 18:03+3Не понимаю в чем критическая разница между:
<ul> <li v-for="(item, index) in items"> {{ parentMessage }} - {{ index }} - {{ item.message }} </li> </ul>
и
<ul> { items.map( (item, index) => <li>{parentMessage} - {index} - {item.message}</li> ) } </ul>werwolfby
03.03.2017 19:47+1А разница как раз не в этом, а в том что очень часто пересекаются много js кода с большим количеством html кода например как-то так:
let childrenComponents; if (this.state.someting) { childrenComponents = children.map(c => (<MyChildComponent {...myChildProps} v-for="c of children"></MyChildComponents>)); } else { childrenComponents = children.map(c => (<MyOtherChildComponent {...myChildProps}></MyOtherChildComponent v-for="c of children">)); } return (<div> <div class="layout-8"> {childrenComponents} </div> </div>);
И это очень простой пример, в реальности бывает и хуже. И не надо говорить про плохой код вынесение в компоненты и всё такое :) На самом деле такие вещи встречаются довольно часто. Не смотря на то что я для фронтенда считайте, что не пишу, очень часто видел такие конструкции. Они понятны, в них легко разобраться, но выглядят хуже чем например вот так:
<div> <div class="layout-8"> <MyChildComponent {...myChildProps} v-if="someting"></MyChildComponents> <MyOtherChildComponent {...myChildProps} v-else></MyOtherChildComponent > </div> </div>
И дивы все друг под другом и читать его проще и даже верстальщик может что-то в нём править (если таковые имеются).
И не забывайте что в vue можно использовать jsx без каких либо проблем (с небольшими тонкостями правда). Просто это не основной способ в отличии от React, и для некоторых ситуаций он как раз оптимальный. Я например как писал выше тоже в одном компоненте с радостью заиспользовал jsx, потому что это должно работать быстрее, хотя и обычный
<template></template>сv-if-elseработал бы нормально.bjornd
03.03.2017 21:03+3Они понятны, в них легко разобраться, но выглядят хуже чем например вот так: ...
Этот пример в моем коде выглядел бы вот так:
const ChildClass = this.state.something ? MyChildComponent : MyOtherChildComponent; return ( <div> <div class="layout-8"> {children.map(c => <ChildClass {...myChildProps} />)} </div> </div> );
Вообще правильное разделение логики представления и бизнес-логики позволяет оставить в render-методах компонентов только базовые if и for, что как раз соответсвует семантике vue-шаблонов, о чем и был мой первоначальный комментарий.
PS: условие if спрятанное где-то в центре блока кода читается просто ужасно.werwolfby
03.03.2017 23:08+1Ну вы же понимаете, что есть много примеров в которых так просто всё не перепишешь.
PS: условие if спрятанное где-то в центре блока кода читается просто ужасно.
Да, поэтому обычно я пишу спереди, это тут в примере написал плохо :)
Когда я бы читал эту разметку, я бы задумался, что за компонент у нас такой
ChildClass. И хорошо если бы я его сразу нашёл выше, а не пошёл искать по файловой системе в папкеcomponents.
Да и линтер должен ругаться на локальную переменную с большой буквы (а если не ошибаюсь компоненты и впрям должны быть с большой буквы).
А при разном наборе свойств вы бы не сократили код до тернарного оператора и всё равно оставили быif.
В общем, будь у меня достаточно опыта во фронтенде, я бы спорил более аргументировано. Но сейчас со стороны своего бэкэнда — это выглядит не очень. И из всех исходников/туториалов/статей, что мне попадались, было очень много кода похожего на тот, что я написал выше.
Я уверен, что его можно сократить до вашего примера (особенно если разные компоненты повыносить в переменные как у вас), но мало кто так пишет. И именно в этом я часто вижу проблему.
Хотя иногда это и удобно. Вот например как написал я.
И тут действительно jsx удобнее и быстрее, за счёт хеш-таблицы.
Но например на ангуляре 2 гораздо лучше бы смотрелся вот такой код:
<template choose="type"> <template case="text"> <Child1>...<Child1> </template> <template case="password"> <Child1>...<Child1> </template> <template case="number"> <Child1>...<Child1> </template> <template case="select"> <Child1>...<Child1> </template> </template>
Если бы у
vueбыло бы что-то подобное, то я бы лучше его заюзал чем jsx.
Quilin
03.03.2017 19:47Достаточно вырожденный пример, в котором нет никакой критической разницы, действительно. Но в проде вещи попадаются гораздо сложнее.
xadd
04.03.2017 03:37Разница внутренне. В первом случае мы уже имеем подготовленный скомпилированный шаблон и привязку данных. Во втором мы будем иметь постоянную регенерацию структуры элементов vdom для синхронизации и проверки изменений при каждом изменении.
noneim
03.03.2017 18:02+2React с его JSX более гибкий. Например сейчас используется виртуальный DOM, т.к. обход всего html дерева достаточно ресурсоемкая операция. Но, посмотрите diffHTML, судя по тестам он вполне себе быстрый, особенно на современных браузерах. Т.е. в скором времени можно будет выкинуть virtualDOM, а сравнивать сразу html дерево и jsx представление, затем патчить изменения в самом html. Есть также React Native, подтверждающий что не только web.
werwolfby
03.03.2017 19:50А ну и так же есть сравнение от самих авторов
react, и дажеbenchmarkи:
https://vuejs.org/v2/guide/comparison.html#React
И чуть ниже сравнение скорости.
baka_cirno
03.03.2017 22:06+3У меня немного накопилось желчи, оставлю ее здесь.
В общем, так вышло, что первое большое приложение на React я стал писать уже после давнего знакомства с Vue. Я был крайне удивлен, насколько у реакта все плохо с некоторыми аспектами.
Во-первых, еще не начав ничего писать, вы уже получаете огромный бандл, который можно уменьшить только с помощью какой-то странной магии, да и то, не существенно. И чем дальше в лес, тем жирнее этот бандл становится.
Больше всего меня разочаровал раутер. И старый, и новый. Он оказался настолько незрелым и неудобным по сравнению с vue-router, что я долго бродил по гуглу, пытаясь понять, что я делаю не так. Оказалось, так и задумано.
Я оценил красоту концепции в основе Redux, но для ее удобного использования приходится ваять огород из middleware и разных хелперов. И в конечном итоге все это выглядит крайне многословно и запутано. Теряется понимание того, что и куда мы посылаем, и как это «что» в процессе трансформируется.
Еще меня озадачило отношение разработчиков React к некоторым частям этой библиотеки. Например, они крайне не рекомендуют использовать mixins и context. Насчет последнего я понимаю, но миксины-то чем мешают? В Vue это простой и удобный инструмент, который не вызывает лишних вопросов. В React это страшилка, которой пугают детей. Это еще одна особенность React — разработчики тянут из года в год обратную совместимость, не решаясь отрезать лишнее.
Лично для себя я пришел к следующему выводу: люди, разрабатывающие React, больше озабочены красотой концепций и теорией, в то время как Иван Ю, создатель Vue, думает об удобстве разработки, поддерживаемости кода и минимальном размере конечного результата. В итоге Vue вышел не совсем концептуальным, зато чертовски удобным, быстрым и мощным. Точнее, у него просто концепция другая, ориентированная на разработчика.kanstantsin
03.03.2017 22:46-2приложение на React… Больше всего меня разочаровал раутер. И старый, и новый
В React нет роутера…
приходится ваять огород из middleware и разных хелперов
В React нет middleware…
но миксины-то чем мешают?
Их нельзя использовать с классами.
В React это страшилка, которой пугают детей. Это еще одна особенность React — разработчики тянут из года в год обратную совместимость, не решаясь отрезать лишнее.
Миксины, как раз кандидаты на отрезание, т.к. .createClass() рано или поздно станет атавизмом.baka_cirno
03.03.2017 22:54+2Это, скорее, был комментарий об экосистеме. Голый React в вакууме мало кого интересует.
VolCh
04.03.2017 12:27В экосистеме React много разных роутеров. Особенно если учитывать, что экосистема React лишь подмножество экосистемы JS. А роутер, как по мне, должен быть изолированным компонентом системы, который обеспечивает возможность подписаться на изменения текущего роута и собственно изменять его. Причём тут React?
baka_cirno
04.03.2017 17:26+1Я их все смотрел. По крайней мере самые популярные. И ни один из них не оставляет впечатления продуманности и допиленности. У каждого есть какие-то странные особенности. Хотя, конечно, любой из них мне видится предпочтительней, чем react-router, особенно V4.
В мире Vue есть один, но зато хороший раутер. Он умеет все на свете, хорошо интегрирован с Vue, но при этом простой и не прибит гвоздями.
http3
04.03.2017 12:38+4Выбор неверный.
Большинство использует jQuery и чихать хотело на эту ерунду, которая скоро умрет :)
Duke565
05.03.2017 11:12Сделал онлайн js редактор PLAYCODE.io на Vue.js — мне понравилось: минимум кода, быстро работает.
Большего всего мне нравится: можно начать с простого, а дальше легко расширить, т.е. архитектура легко масштабируется.
Beshanoe
05.03.2017 15:23Нравится подход vue в целом, но пока что связка TypeScript + React для меня решает, vs code подсказывает пропсы прямо в JSX(TSX), для vue проверки типов в шаблонах еще не придумали, да и для использования TS там придется использовать свои костыли, классы с декоратором
gvozd1989
05.03.2017 18:01Имеет ли смысл использовать Vue (или другой фреймворк) на сайтах не SPA типа? Например в обычных интернет-магазинах и др?
lega
05.03.2017 19:04Да, отдельные виджеты на странице могут быть сделаны с SPA фреймворком.
kuznetsovin
05.03.2017 20:11А зачем такое извращение? Не проще ли взять какой-нибудь jquery для этого?
lega
05.03.2017 20:38Чтобы сократить кол-во кода в разы (продуктивность), вот сравните пример с тостера, на jquery и на alight (функционал тот же*, а сложность и кол-во кода во 2-м примере, гораздо меньше).
Да и вообще некоторые SPA либы (фреймворки) весят меньше чем jquery* — можно немного сэкономить на весе клиентского js.kuznetsovin
05.03.2017 20:51А потом это все еле ворочиется на интернете 3g, пока пытаеся все эти бандлы загрузить. Просто все примеры которые я видел после переноса их с jquery на <выберите фрейворк> теряли в производительности. А так конечно гвозди можно с сковородкой забирать.
Мне как конечному пользователю глубоко фиолетово сколько кода занимает функциональность, мне надо чтобы это работало и не тормозило хоть с мобильным инетом, хоть с ПК.lega
05.03.2017 21:03Ну вот вам пример выше, 14кб с alight и 100кб с jquery. С alight грузится и работает быстрее.
bjornd
Я бы рекомендовал смотреть на более объективные источники, например реальные опросы большого количества людей
ainu
Вот спасибо большое.
idze
«Есть три вида лжи: ложь, наглая ложь и статистика» — Бенджамин Дизраэли
bjornd
Глупая фраза с указанием неверного авторства — лучший аргумент в любом споре.
gorodnev
В.И. Ленин?
Alendorff
Джейсон Стетхем ведь.
Rastishka
По статистике цитирования её чаще приписывают именно Бенджамину Дизраэли.
И в этом есть какой то глубокий смысл…
Senyaak
«Однако этой фразы нет в работах Дизраэли. Также она не была известна ни при его жизни, ни вскоре после смерти.»
Ктото не прав, либо википедия, либо вы… А по статистике сказалбы что чаще присваивают её Марку Твену
idze
Шутеечка отличная вышла, я бы и сам плюсанул!
Однако, не смотря на то что я с автором не точен, сути это не меняет. Я не считаю опросы реальных людей репрезентативнее GitHub'а. А вы?
bjornd
Мое отношение простое. Разработчиков на и на React то днем с огем не сыщешь, а уж на Vue и подавно.
altai2013
Опрос по ссылке говорит, что из всех популярных JS-фреймворков только у React и Vue низкие антирейтинги («used it before, would not use again»). В случае всех остальных, включая популярный Angular, число людей, не желающих повторно использовать опробованный в работе фреймворк, примерно равно числу удовлетворенных, что очень плохо. Получается, что по степени успешности в среде программистов, React и Vue, и правда, в числе лидеров.
bjornd
А теперь попробуйте найти разработчиков в свой проект на React/Angular/Vue.
teemour
а где вы их ищете?
bjornd
Лично я их не ищу, я только работаю с результатами поиска. И результаты эти удручают даже для Angular и React, не говоря уже о Vue.
vintage
тут всё дело в том, что вью — начинает хайпиться, реакт на вершине хайпа, а все ослальные в постхайповой стадии. Со вью никто ещё никуда не успел уйти.
kode_krendel
Ну и к чему ссылка? Она только подтверждает приведенную цитату. У вас логика поломалась.