React или Vue? Выбираем библиотеку для фронтенд-разработки

https://medium.freecodecamp.com/reacts-jsx-vs-vue-s-templates-a-showdown-on-the-front-end-b00a70470409#.b5u4tvraf
  • Перевод
На чём делать фронтенд? Самый верный способ найти ответ – попробовать лучшие библиотеки самостоятельно. В идеале, хорошо бы начать с самого простого и понять, как таинственные для непосвящённого конструкции превращаются в готовые к выводу страницы. Дальше же, вооружившись пониманием основ, можно осмысленно читать документацию и усложнять собственные эксперименты до тех пор, пока ответ не покажется очевидным.



Сегодня мы поговорим о 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 – это мощные инструменты, любой из которых позволяет создавать отличные веб-приложения, и, что бы вы ни выбрали – точно не прогадаете.

Уважаемые читатели! А чем вы пользуетесь для фронтенд-разработки?

RUVDS.com

983,00

RUVDS – хостинг VDS/VPS серверов

Поделиться публикацией
Комментарии 109
    +5
    Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub.

    Я бы рекомендовал смотреть на более объективные источники, например реальные опросы большого количества людей
      0
      Вот спасибо большое.
        0
          +11
          Глупая фраза с указанием неверного авторства — лучший аргумент в любом споре.
            +4

            В.И. Ленин?

              +3
              Джейсон Стетхем ведь.
              +1
              По статистике цитирования её чаще приписывают именно Бенджамину Дизраэли.
              И в этом есть какой то глубокий смысл…
                +1
                «Однако этой фразы нет в работах Дизраэли. Также она не была известна ни при его жизни, ни вскоре после смерти.»
                Ктото не прав, либо википедия, либо вы… А по статистике сказалбы что чаще присваивают её Марку Твену
                +1
                Шутеечка отличная вышла, я бы и сам плюсанул!
                Однако, не смотря на то что я с автором не точен, сути это не меняет. Я не считаю опросы реальных людей репрезентативнее GitHub'а. А вы?

                  +1
                  Мое отношение простое. Разработчиков на и на React то днем с огем не сыщешь, а уж на Vue и подавно.
              +2
              Опрос по ссылке говорит, что из всех популярных JS-фреймворков только у React и Vue низкие антирейтинги («used it before, would not use again»). В случае всех остальных, включая популярный Angular, число людей, не желающих повторно использовать опробованный в работе фреймворк, примерно равно числу удовлетворенных, что очень плохо. Получается, что по степени успешности в среде программистов, React и Vue, и правда, в числе лидеров.
                0
                А теперь попробуйте найти разработчиков в свой проект на React/Angular/Vue.
                  +3
                  а где вы их ищете?
                    +1
                    Лично я их не ищу, я только работаю с результатами поиска. И результаты эти удручают даже для Angular и React, не говоря уже о Vue.
                  +3

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

                  0
                  Ну и к чему ссылка? Она только подтверждает приведенную цитату. У вас логика поломалась.
                  0
                  А как обстоят дела с индексацией поисковиками этих «реактивных» SPA?
                    0
                    Реакт можно компилировать на сервере и отдавать HTML.
                      0
                      Да и Vue умеет это делать ничуть не хуже.
                        –3
                        А кто компилирует такое? Это какие-то php скрипты или что?
                        Я честно говоря не программирую веб, вот такие статьи читаю и пытаюсь понять что это вообще такое.
                        Такое впечатление, что чистого языка мало и придумывают язык в языке, как какое-то мета-программирование…
                        Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?
                          0
                          Лень — двигатель прогресса.
                            0
                            Так а где же тут лень?
                            Знал бы только JS и радовался, но нет, нужно еще понять, что такое React, Vue, Angular, JQuery.
                            Получается работы по изучению в 5-10 раз больше. И можно ли стать хорошим специалистом если единая в общем веб технология растаскивается на разные подмножества языков, библиотек, компиляторов из мета-языков в другие языки…
                              +4

                              Можно хоть на чистом JS, конечно. Но только в процессе создания большого продукта Вы фактически создадите свой микро (или даже не микро) фреймворк, а потом кому-то не вам его поддерживать.
                              Знал бы только React и радовался, но нет, нужно ещё понять, что такое MyAwesomeFoo, YetAnotherBar, CoolBaz. Получается работы по изучению в 5-10 раз больше.

                                +1
                                У меня просто по возникает такое ощущение, что есть языки, где время бежит не так быстро.
                                Например,
                                1) у железячников
                                Verilog/VHDL — все более или менее стабильно годами. Ну появился SystemVerilog, но как-то не быстро народ его берет на вооружение.
                                2) У микроконтрольщиков, там вообще только C редко C++. Микроконтроллеры плюс-минус одинаковые. То же время не быстро бежит. Ну наверное побыстрее, чем у ASIC-WORLD
                                3) C++ да появляются новые стандарты C++11, C++14, C++17 ну тут побыстрее жизнь идет, уже трудно идти в ногу со временем и приходится стараться.
                                4) Ну и апофеоз — это веб программирование JS/HTML/CSS и все эти фреймворки. Вот тут мне кажется началась полная вакханалия. Все бегут со скоростью ракеты изобретать новые фреймворки и мета языки.
                                  0

                                  Просто сложные приложения писать даже на современных JS/HTML/CSS сложно вдвойне.

                                    0

                                    Значит не нужно писать сложные приложения на JS/HTML/CSS.

                                      +1
                                      Расскажите бизнесу, что вы хотите лишить его единственной возможности мгновенно доставлять клиентам практически любой функционал и контент. Просто потому что вам сложно. Бизнес поржет, уволит вас и наймет того, кому не так сложно.
                                    0

                                    Справедливости ради, библиотеки и фреймворки и на С++ есть. За ними так же нужно поспевать.

                                      –2

                                      Нет, не нужно.

                                      +1
                                      На самом деле всё просто. Последние годы веб переживает натуральный взрыв. Как у пользователей, так и у бизнеса, требования к вебу растут семимильными шагами. Лавинообразный рост количества фреймворков, библиотек и методологий — это не более, чем следствие растущих ожиданий от веба.
                                0
                                React и Vue компилирует сервер на node.js.
                                React также можно компилировать на сервере, написанном на Go (golang).
                                Почему не js?..
                                Ну, у каждого свои причины. Мне нравится, что каждый компонент — это независимая боевая единица. Сделал компонент «Карточка товара» — она доступна, куда бы её не воткнуть. Это даёт некую уверенность в коде. Например, можно сделать страницу с 50 компонентами, и сделать автотесты, которые проверяют, что ни один пиксель не поменялся при изменении кода, ничего не сдвинулось и так далее. Плюс реактовские плюшки вроде виртуального DOM значительно в некоторых кейсах ускоряют отклик и скорость работы фронтенд части (по сравнению с классическим подходом $('.js-element').html('3 товара')).
                                  0
                                  Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?

                                  Более-менее сложные SPA или web-компоненты, написаные просто на JS очень сложно поддерживать и практически невозможно развивать. React, Vue и дргуие инструменты позволяет применяет более-менее декларативный подход при написании front-end, что существенно сокращает затраты на развитие проекта, поддержку, тестирование.
                                    0

                                    Компилируется это на этапе сборки проекта перед публикацией. Т.е. в браузере работает уже "скомпилированная" версия. Не совсем скрипты, совсем не PHP.


                                    Ну, в общем идея такая, что с языком (JS) все более-менее в порядке. Дело в том, что HTML и CSS слишком низкоуровневы для Rich Internet Applications. Поэтому логичным образом появились более высокоуровневые абстракции, который приближают решение проблемы к оперированию над объектами предметной области. В случае с React и Vue отдельно стоит упомянуть Virtual Dom и те проблемы, которые он решает (и создает, ага): https://habrahabr.ru/post/256965/


                                    Отдалённо, связь такая же как и между языком ассемблера и си. На первом можно реализовать абсолютно всё, но долго и дорого.

                                      0

                                      IMHO, для RIA лучше использовать JS-фреймворки под это заточенные, тот же ExtJS например.

                                      0
                                      сразу видно, что вы не писали веб приложения на клиенте. Если не использовать фреймворк, то единственный, кто сможет потом поддерживать всю та лапшу будет её автор, придется молится на него, чтобы он не ушел и весь проект не завалился
                                      А с другой стороны я мог бы прийти в любой проект на реакте и легко в него внедрится потому что
                                      1. Весь код организован по некоторым соглашениям и втиснут в общепринятые рамки
                                      2. Есть документация и готовая экосистема решений
                                      3. Не нужно придумывать велосипед

                                      В общем, надеюсь, идею вы поняли
                                        0

                                        Немного утопично. Видел я на реакте такой шлак что ни пером описать....

                                    0
                                    --deleted--
                                      +1

                                      Оба поддерживают server-side rendering (самый настоящий). Немножко про варианты решения проблемы с индексацией можно прочитать тут http://vuejs.org/v2/guide/ssr.html

                                        –2
                                        Но тогда теряется преимущество рендеринга на стороне клиента — вместо передачи по сети только лишь данных, мы опять начинаем гонять странички.
                                          +1
                                          хтмл отдают поисковику, а не клиентам)
                                            +4
                                            Первое открытие страницы — html, остальные — клиентские. Всё нормально, преимущества на месте.
                                              +5

                                              Вы ж спросили про поисковики)
                                              И так, как это делается в React: сервер отрисовывает полностью сформированную, готовую страничку и отдаёт её клиенту. Затем клиент получает эту страничку и иницилизирует SPA поверх уже отрисованного div'а, но так как данные на сервере и клиенте обязательно совпадают, то клиентский код получает точно такой же результат рендера, виртуальный дом видит что нет разницы, и перерисовки на самом деле не происходит. В результате этого клиент получает обычный SPA, очень красиво и незаметно

                                              0
                                              Мне кажется, значимость привязки server-side rendering к фреймворку переоценена.
                                              У меня так получилось, что к angularjs SPA проще генерировать шаблоны на jinga2+pyjade, чем писать их целиком. В итоге, заполнить шаблон на сервере вместо форм данными модели или уже отдать заполненные формы — легче лёгкого.
                                                +1

                                                Угу, хоть на PHP можно их генерировать, особенно если этот PHP является API-сервером.

                                              0

                                              Вполне пристойно обстоят, есть некоторые нюансы, но можно и без server-side рендеринга обойтись: http://andrewhfarmer.com/react-seo/

                                              0
                                              Сейчас — Ember.js, еще Angular2 выглядит неплохо(сужу по опробованых мной туториалах). Как для бекендщика лучше на фронт нету (чисто мое ИМХО)

                                                +1
                                                Angular 2 действительно хорош, особенно на фоне первого
                                                  +2
                                                  Ember.js — пробовал и настоятельно не рекомендую. Можно быстро сделать типовой проект, но развивать и кастомизировать — сущее наказание. Взять к примеру ember-data, модуль htfkbpe.obq абстракцию доступа к данным. С первого взгляда все хорошо — следуем определенным стандартам API на сервере и все данные, даже связанные, у нас легко и просто доступны на клиенте. Но копнуть чуть глубже и оказывается, что даже такая простая вещь как откат изменения связи объекта реализуется костылями или monkey-patching'ом.
                                                    +2
                                                    Как раз в Ember.js кастомизируется если не все, то почти все, через extend и reopen.

                                                    У ember-data по сути только и есть единственная существенная проблема это нет отслеживания изменений связи из коробки, и то отказаться от этого были причины.
                                                      0

                                                      Возможно Ember не идеален, но он следует методологии "соглашения превыше конфигураций", за это имхо можно многое простить. Он навязывает структуру прокта и другие принятые в комьюнити конвенции. В случае больших проектов это дает бонус при поддержке и расширении, особенно ценно для пришедших в уже функционирующий проект разработчиков. Наверное, никто не любит поддерживать код, в котором предыдущие программисты пускались в творчество, полузуясь кучей слабосвязанных библиотек. Да и переживать за архитектуру почти не приходится.


                                                      До версии 2.0 документация была скудновата, очень многие моменты приходилось собирать по сторонним блогам. Из-за этого и порог вхождения повышался. Сейчас они вроде как исправились, больше деталей описывают в туториале, больше примеров дают, конференции организовывают, митапы

                                                      +2

                                                      Как по мне, то если бэкендщику (классический ООП, MVC, вот это вот всё и совсем немножко ФП) нужно лезть на фронт, то лучше React нет. Да ещё если MobX прикрутить.


                                                      Angular2 заточен, скорее, под верстальщиков, которые хотя начинать "настоящей" разработкой заниматься.

                                                        0
                                                        VolCh я вот не соглашусь. Почему лучше Angular2? С ним проще писать следуя SOLID и DDD. Вот есть у тебя entity post. Написал модель, написал репозиторий, дал интерфейс. В реализации уже подтянул любимую либу для запроса на сервер (будь то RxJS или хоть чистый xhr). Отделно поставиш обработчики на actions, отдельно поставишь темплейт.
                                                        Похожая ситуация с Ember. Меня больше заботит то, как данные взаимодействуют. Отрисовать малая часть проблемы в SPA как по мне (если заботиться чисто о view то React подойдет лучше).

                                                        bjornd у Ember есть недостаток с тем что у него довольно высокий порог вхождения (как по мне). Наш первый проект был болью но последующие, мне сложно представить как бы мы изошрялись без Ember.

                                                        Думаю в каждом из фреймворков есть как + так и — , кому то что то пойдет сложно кому то легче. И еще, по одному проекту судить сложно, думаю для объективной оценки нужно сделать 2-3 проекта.
                                                          0

                                                          Я так и делаю. Пишу сущность, причём не тупую структуру с данными, а полноценный JS объект с методами изменения состояния, пишу стор/репозиторий с инжектированным шлюзом к серверу/локалстораджу/чемуугодно. Вызываю ReactDOM.render, передав в корневой элемент сторы. И всё. Компоненты реактивно отрисовывают изменения сущностей и репозиториев, обработчики событий дергают их методы.

                                                      +1
                                                      В наших проектах в основном нужен viewmodel-databinding. В старом проекте используется knockout, в новом попробовал angularlight
                                                        0
                                                        Для малых задач нокаут и правда вполне неплох. Между прочим, Vue.js позаимствовал некоторые концепции именно у нокаута, в частности, процессы привязки событий для реактивности.
                                                          0
                                                          ангуларлайт интересная тема, но жутко не хватает проекту коммьюнити. =(
                                                          с ангуларлайта перешел на vue.js.
                                                            +2

                                                            Вот и получается, что комьюнити нет, потому что нет комьюнити.

                                                          +2

                                                          Я как бекенд разработчик, тоже очень редко сталкиваюсь с фротендом.


                                                          И вот свой проект о котором уже писал тут, переписываю с Angular 1 на Vue. И всё получается очень красиво (на гитхабе можно следить за прогрессом).


                                                          До этого было в планах переписать на Angular 2, но в него действительно нынче порог вхождения больше чем в остальные фреймворки: Vue, React и Angular 1.


                                                          React имеет большой набор хороших преимуществ, но Vue оказался быстрее и менее многословным и фишку с jsx для Vue я уже тоже заиспользовал, вместо Redux там есть Vuex.


                                                          В общем я пока остановился на Vue как основном инструменте для фронт энда для своих проектов. А попробовал уже всё.


                                                          Но мой опыт это опты не больших (по не которорым меркам) своих проэктиков и никакого энтерпрайза (там у нас есть фронтендщики). И я доволен Vue так же как когда-то был доволен Angular :)

                                                            +2

                                                            А ну и собственно попробовать Vue меня убедило вот это видео:



                                                            Там добротно рассматривается "что не так" с современными фреймворками.
                                                            После просмотра и реального использования Vue я готов подтвердить слова автора.


                                                            Ну и ещё раз, как бекэнд разработчик моё мнение не совсем объективно.

                                                              0
                                                              Есть так же проекты по связке Redux с Vue = revue и др
                                                                0

                                                                Просто vuex от автора vue, что как минимум подкупает, а для меня, как человека далёкого от фронтэнда, оказалось очень удобным.


                                                                Но спасибо, гляну на revue

                                                                  0
                                                                  Авторство это не панацея, если вы еще знакомы с redux-saga, то для vuex тоже есть биддинги vuex-saga или vuex-redux-saga
                                                              +3
                                                              Реакт отличается тем, что он не завязан на html, а дает абстракцию над ним. Т.е. теоретически можно юзать готовые компоненты и ничего не писать на html. А бэкендом компонент может быть и не html, и не веб вообще ( см. ReactNative)

                                                                0

                                                                Ну Vue вроде как тоже самое обещает https://weex-project.io/
                                                                На сколько я понял из то что знаю, а познакомился я с ним 2 недели назад всего

                                                                  +3

                                                                  Точно такие же компоненты в Vue. Создаешь файл компоненты с расширением .vue а в нем есть секции


                                                                   <template></template>, <script></script> и <style></style>

                                                                  Жаль автор не показал этого в статье. Потом вебпак это все собирает в стандартные js, css. Мне как бекендщику Vue очень понравился, легко и понятно все, от реакта отталкивает именно jsx, привык логику и отображение разделять.

                                                                    0
                                                                    нет ничего плохого в смешении логики и отображения, если эта логика относится непосредственно к отображению, а не бизнес-логика
                                                                  +2

                                                                  Самое главное забыли написать про Vue — их подход к компонентам.


                                                                  Вы можете создавать и поставлять отдельные компоненты с расширением *.vue (подмножество XML). Внутри этого файла могут лежать шаблоны, скрипты и стили.


                                                                  Кроме того, если не хочется все складывать в один *.vue файл, компонент можно разнести отдельно на .css, .js, а в *.vue просто подключить эти файлы через атрибут src:


                                                                  <script src="./mycomponent.js"></script>
                                                                  <style src="./mycomponent.css"></script>

                                                                  Все это потом прекрасно собирается либо browserify (через vueify), либо webpack.


                                                                  Получается такой себе Яндекс БЭМ из коробки, плюс разделение скриптов и шаблонов.

                                                                    0

                                                                    Если честно, это не сильно отличается от Angular 2, но там это вынесено в проперти template и styles — причем последний коллекция, что позволяет несколько стилей объединять в один (общие стили например).


                                                                    И подход к scoped стилям такой же в Angular 2.


                                                                    А если что можно и по разным файлам разнести, а потом с помощью browserify или webpack собрать.

                                                                      +1
                                                                      Субъективно, Ангуляр как-то более громоздким кажется
                                                                        0

                                                                        Я согласен, и чуть выше я описал свое отношение ко всем фреймворкам. И vue для меня оказался самым удобным.

                                                                        0
                                                                        Да, общий подход есть, но у Vue это гораздо лаконичнее получается.
                                                                      +1
                                                                      Меня, как дизайнера, больше устроил Vue. jsx — всё же больше для кодеров. Месиво из js и html, сразу отбило желание. Хотя уже, конечно, есть инструменты и для этого. Но как-то после NG — Vue привычнее. И компоненты там приятнее, спокойно разбил на 3 файла в папке и не отвлекаешься на сторонний код.
                                                                        +1
                                                                        Я кодер, но и у меня мешанина js и html отбивает все на свете. Впрочем, для адских поклонников jsx в Vue есть vue-loader для вебпака, с которым вполне можно писать на Vue темплейты на jsx.
                                                                          0

                                                                          vue-loader как раз доя обработки *.vue файлов, а для jsx нужен другой.


                                                                          Мешанина html и js всегда плохо я согласен, но бывают задачи когда jsx удобен, я уже писал выше, что для одного случая заюзал именно jsx, так как он удобнее. Во всех остальных нормальные *.vue компоненты

                                                                            0
                                                                            Я имел в виду, что используя vue-loader, вы можете использовать другие loader'ы для разных частей ваших компонентов. В числе которых может оказаться и jsx. Спасибо, что поправили!
                                                                            +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>
                                                                            

                                                                              +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 работал бы нормально.

                                                                                +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 спрятанное где-то в центре блока кода читается просто ужасно.
                                                                                  +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.

                                                                                0
                                                                                Достаточно вырожденный пример, в котором нет никакой критической разницы, действительно. Но в проде вещи попадаются гораздо сложнее.
                                                                                  0
                                                                                  Разница внутренне. В первом случае мы уже имеем подготовленный скомпилированный шаблон и привязку данных. Во втором мы будем иметь постоянную регенерацию структуры элементов vdom для синхронизации и проверки изменений при каждом изменении.
                                                                              +2
                                                                              React с его JSX более гибкий. Например сейчас используется виртуальный DOM, т.к. обход всего html дерева достаточно ресурсоемкая операция. Но, посмотрите diffHTML, судя по тестам он вполне себе быстрый, особенно на современных браузерах. Т.е. в скором времени можно будет выкинуть virtualDOM, а сравнивать сразу html дерево и jsx представление, затем патчить изменения в самом html. Есть также React Native, подтверждающий что не только web.
                                                                                0

                                                                                Так в vue тоже virtual dom и native есть

                                                                                  0

                                                                                  А ну и так же есть сравнение от самих авторов react, и даже benchmarkи:
                                                                                  https://vuejs.org/v2/guide/comparison.html#React


                                                                                  И чуть ниже сравнение скорости.

                                                                                  0
                                                                                  А разве «data» в VueJs не должна быть функция?
                                                                                    0
                                                                                    Только в компонентах.
                                                                                    +3
                                                                                    У меня немного накопилось желчи, оставлю ее здесь.
                                                                                    В общем, так вышло, что первое большое приложение на React я стал писать уже после давнего знакомства с Vue. Я был крайне удивлен, насколько у реакта все плохо с некоторыми аспектами.
                                                                                    Во-первых, еще не начав ничего писать, вы уже получаете огромный бандл, который можно уменьшить только с помощью какой-то странной магии, да и то, не существенно. И чем дальше в лес, тем жирнее этот бандл становится.
                                                                                    Больше всего меня разочаровал раутер. И старый, и новый. Он оказался настолько незрелым и неудобным по сравнению с vue-router, что я долго бродил по гуглу, пытаясь понять, что я делаю не так. Оказалось, так и задумано.
                                                                                    Я оценил красоту концепции в основе Redux, но для ее удобного использования приходится ваять огород из middleware и разных хелперов. И в конечном итоге все это выглядит крайне многословно и запутано. Теряется понимание того, что и куда мы посылаем, и как это «что» в процессе трансформируется.
                                                                                    Еще меня озадачило отношение разработчиков React к некоторым частям этой библиотеки. Например, они крайне не рекомендуют использовать mixins и context. Насчет последнего я понимаю, но миксины-то чем мешают? В Vue это простой и удобный инструмент, который не вызывает лишних вопросов. В React это страшилка, которой пугают детей. Это еще одна особенность React — разработчики тянут из года в год обратную совместимость, не решаясь отрезать лишнее.

                                                                                    Лично для себя я пришел к следующему выводу: люди, разрабатывающие React, больше озабочены красотой концепций и теорией, в то время как Иван Ю, создатель Vue, думает об удобстве разработки, поддерживаемости кода и минимальном размере конечного результата. В итоге Vue вышел не совсем концептуальным, зато чертовски удобным, быстрым и мощным. Точнее, у него просто концепция другая, ориентированная на разработчика.
                                                                                      –2
                                                                                      приложение на React… Больше всего меня разочаровал раутер. И старый, и новый

                                                                                      В React нет роутера…

                                                                                      приходится ваять огород из middleware и разных хелперов

                                                                                      В React нет middleware…

                                                                                      но миксины-то чем мешают?

                                                                                      Их нельзя использовать с классами.

                                                                                      В React это страшилка, которой пугают детей. Это еще одна особенность React — разработчики тянут из года в год обратную совместимость, не решаясь отрезать лишнее.

                                                                                      Миксины, как раз кандидаты на отрезание, т.к. .createClass() рано или поздно станет атавизмом.
                                                                                        +2
                                                                                        Это, скорее, был комментарий об экосистеме. Голый React в вакууме мало кого интересует.
                                                                                          0

                                                                                          В экосистеме React много разных роутеров. Особенно если учитывать, что экосистема React лишь подмножество экосистемы JS. А роутер, как по мне, должен быть изолированным компонентом системы, который обеспечивает возможность подписаться на изменения текущего роута и собственно изменять его. Причём тут React?

                                                                                            +1
                                                                                            Я их все смотрел. По крайней мере самые популярные. И ни один из них не оставляет впечатления продуманности и допиленности. У каждого есть какие-то странные особенности. Хотя, конечно, любой из них мне видится предпочтительней, чем react-router, особенно V4.
                                                                                            В мире Vue есть один, но зато хороший раутер. Он умеет все на свете, хорошо интегрирован с Vue, но при этом простой и не прибит гвоздями.
                                                                                      0
                                                                                      На чём делать фронтенд?
                                                                                        –2

                                                                                        На $mol конечно же.

                                                                                        +4
                                                                                        Выбор неверный.
                                                                                        Большинство использует jQuery и чихать хотело на эту ерунду, которая скоро умрет :)
                                                                                          +1
                                                                                          Хватит выбирать, используй Angular.
                                                                                            0
                                                                                            Сделал онлайн js редактор PLAYCODE.io на Vue.js — мне понравилось: минимум кода, быстро работает.

                                                                                            Большего всего мне нравится: можно начать с простого, а дальше легко расширить, т.е. архитектура легко масштабируется.
                                                                                              0

                                                                                              Нравится подход vue в целом, но пока что связка TypeScript + React для меня решает, vs code подсказывает пропсы прямо в JSX(TSX), для vue проверки типов в шаблонах еще не придумали, да и для использования TS там придется использовать свои костыли, классы с декоратором

                                                                                                0

                                                                                                Если вы про проверку типов пропсов — она есть.

                                                                                                  0
                                                                                                  А для всего остального есть Flow
                                                                                                0
                                                                                                Имеет ли смысл использовать Vue (или другой фреймворк) на сайтах не SPA типа? Например в обычных интернет-магазинах и др?
                                                                                                  0
                                                                                                  Да, отдельные виджеты на странице могут быть сделаны с SPA фреймворком.
                                                                                                    0
                                                                                                    А зачем такое извращение? Не проще ли взять какой-нибудь jquery для этого?
                                                                                                      0
                                                                                                      Чтобы сократить кол-во кода в разы (продуктивность), вот сравните пример с тостера, на jquery и на alight (функционал тот же*, а сложность и кол-во кода во 2-м примере, гораздо меньше).

                                                                                                      Да и вообще некоторые SPA либы (фреймворки) весят меньше чем jquery* — можно немного сэкономить на весе клиентского js.
                                                                                                        0
                                                                                                        А потом это все еле ворочиется на интернете 3g, пока пытаеся все эти бандлы загрузить. Просто все примеры которые я видел после переноса их с jquery на <выберите фрейворк> теряли в производительности. А так конечно гвозди можно с сковородкой забирать.
                                                                                                        Мне как конечному пользователю глубоко фиолетово сколько кода занимает функциональность, мне надо чтобы это работало и не тормозило хоть с мобильным инетом, хоть с ПК.
                                                                                                          0
                                                                                                          Ну вот вам пример выше, 14кб с alight и 100кб с jquery. С alight грузится и работает быстрее.
                                                                                                  0
                                                                                                  Год назад я бы выбрал Vue. Он прекрасен.
                                                                                                  Но сейчас твердо убежден, что ClojureScript + Re-frame (Reagent)

                                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                Самое читаемое