Почему мы выбрали Vue.js (а не React)27.12.2016 16:22

Недавно команда Qwintry начала активную миграцию на Vue.js во всех наших старых и новых проектах:

  • в legacy системе, работающей на Drupal (qwintry.com)
  • в нашей новой, полностью переписанной ветке qwintry.com (бекэнд на Yii2 / Node.js)
  • в наших B2B-системах (работающих на Yii2) (logistics.qwintry.com)
  • во всех наших мелких внутренних и публичных проектах (в основном использующих PHP и Node.js на бэкенде)


Почему наши программисты остановили выбор на Vue.js, рассказывает руководитель департамента разработки Qwintry LLC. Антон Сидашин ➔
Коротко о нас: проект Qwintry используется полумиллионом клиентов по всему миру, у нас работает два склада (в США и в Германии) на собственном облачном программном обеспечении, и мы являемся одним из крупнейших мейлфорвардеров в США с точки зрения трафика посетителей и отправлений. Мы помогаем людям покупать товары в интернет-магазинах США и управлять своими посылками в нашем личном кабинете, а также позволяем значительно сэкономить на международной доставке. Мы используем наши собственную IT-платформу и логистические цепочки, чтобы делать качественную международную доставку по хорошей цене.

1364161010e349708963fe1b40e68a04.jpg
Наша посылка в дверях у клиента — из отзывов покупателей

У Qwintry довольно большая кодовая база, в основном состоящая из PHP и JS (+Swift и Java для мобильных приложений).

Мы решили использовать Vue.js после того, как построили тестовое приложение c идентичным функционалом — наш калькулятор — на React, Vue.js и Angular2.
 

React.js


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

Мы запилили несколько SPA и динамических виджетов на React, мы тестировали React Native (под iOS) и Redux. Я думаю, что React был большим шагом для мира JS с точки зрения осведомленности о состоянии, и он показал многим людям, что такое реальное функциональное программирование в хорошем, прагматичном ключе. Также я думаю, что React Native велик — он буквально меняет весь ландшафт мобильной разработки.

Недостатки React для меня:

Зачастую чистота, иммутабельность и идеология доминирует над прагматичным подходом


Не поймите меня неправильно. Я ценю чистоту (purity) и простоту подхода render () — без сомнения, это отличная идея, которая работает в реальной разработке. Я говорю о других вещах.

Я думаю, вот этот уровень строгости и чистоты может быть полезным, когда у вас работает 1000 разработчиков в компании — примерно тогда же, когда вы решите разработать свой собственный синтаксис, чтобы перевести на статические типы весь ваш PHP код. Или когда вы являетесь разработчиком Haskell, который решил постичь JS. Но у большинства компаний гораздо меньше разработчиков, небольшие бюджеты и цели, отличающиеся от целей Facebook. Я остановлюсь на этом подробнее чуть дальше.

JSX — отстой


Подождите секундочку! Я знаю! Это «просто чистый Javascript со специальным синтаксисом» . Нашим ребятам, которые рисуют в скетче и фотошопе дизайн и потом конвертируют его в HTML, у которых жесткие дедлайны и которые прямо сейчас верстают вот эту форму, обернув ее в некоторое количество div’ов — прямо сейчас — совершенно по барабану чистота и «простота» ES6. Применение некоего дизайна к компонентам React — работа не фонтан, потому что JSX не хватает читаемости. Невозможность поставить старый добрый IF в какой-то блок HTML кода — это плохо, и, пожалуйста, не верьте поклонникам React, которые говорят что «if () — это прошлый век, а сейчас все нормальные программисты используют тернарные операторы». Позвольте мне заверить вас: JSX — это все еще мешанина HTML и JS в момент, когда вы читаете и редактируете его, даже если потом он будет скомпилирован в чистый JS.

    
       {items.map(item =>
         
  • {item.name}
    • 
       )}


Многие разработчики думают (и я какое-то время был с ними согласен), что такие ограничения синтаксиса сделают их сильнее помогут им писать более модульный код, потому что ограниченность JSX (из коробки) вынуждает класть куски кода в мелкие вспомогательные функции и использовать их внутри функции render (), как предлагает этот и многие другие ребята:

stackoverflow.com/a/38231866/1132016

JSX также вынуждает разбивать компоненты-в-15-строк-HTML в 3 компонента, 5-строк-HTML-в-каждом. Не думайте, что этот подход делает вас более качественным разработчиком.

Вот в чем штука:

Когда вы пишете относительно сложный компонент — который вы, вероятно, не собираетесь завтра выкладывать в публичный реп на GitHub, чтобы продемонстрировать его на HackerNews — этот подход разбивания компонентов на супертупые (dumb) компоненты из-за ограничений JSX всегда выдергивает вас из потока, в котором вы решаете реальную бизнес-задачу. Нет, я не говорю, что идея дробных компонентов плоха или не работает. Вы должны четко осознавать, что вам нужно делить функционал на составные части, чтобы держать ваш код в управляемом состоянии. Но вы должны делать это только тогда, когда вы думаете, что этой конкретной логической сущности в вашем коде лучше быть отдельным компонентом с собственными props –, а не на каждые два-три условия, которые были написаны с помощью тернарного оператора! Каждый раз, когда вы создаете новый компонент здесь и там, это стоит вам вполне конкретных усилий и нарушает ваш поток, потому что вам нужно переключиться от мышления архитектора (когда вы уже помните текущее состояние компонентной модели и вам просто нужно добавить HTML здесь и там, чтобы функционал заработал) на мышление менеджера: вам надо создать отдельный файл для компонента, подумать о props этого нового компонента, как они маппятся на state, как вы собираетесь пробрасывать коллбеки и т.д. В результате снижается скорость написания кода, потому что вы вынуждены тратить усилия на преждевременную модульность компонентов там, где вам это, вероятно, не понадобилось бы, будь синтаксис JSX более гибким. На мой взгляд, преждевременная модульность очень похожа на преждевременную оптимизацию. Для меня и нашей команды читаемость кода важна, но все еще очень важно и получение удовольствия от написания кода. Это не круто, когда простая форма калькулятора требует создать 6 компонентов, каждый со своими props.

Зачастую такая гипермодулярность плоха и с точки зрения технического обслуживания, модификации или применения нового дизайна, потому что чтобы обновить html в виджете, вам нужно прыгать по нескольким файлам / функциям и проверять каждый маленький кусок HTML отдельно.

Опять же я не предлагаю писать монолиты. Я предлагаю использовать компоненты вместо микрокомпонентов для ежедневного программирования. Речь про баланс и здравый смысл.

Работа с формами и Redux заставят вас печатать весь день напролет


React — он о чистоте и one-way flow, помните? Вот почему LinkedStateMixin стал персоной нон грата , и теперь вы должны написать 10 функций, чтобы получить входные данные из 10 полей формы. Нет, можно, конечно, написать одну функцию, которая будет проверять e.target, но в конечном итоге там будет такое дерево условий с нормализацией прилетающих из формы данных, что захочется плакать; поэтому так никто не делает. 80% из этих функций будет содержать одну строку с this.setState () или вызова Redux экшна. (Тогда вам, вероятно, придется создать еще 10 констант — по одному на каждый action). Я думаю, этот подход был бы приемлем, если вы могли бы генерировать весь этот код, просто подумав о нем… Но я не знаю ни одного IDE редактора, который мог бы значительно упростить написание такого боилерплейта. Почему вы должны печатать так много? Потому что большие парни решили, что двухстороннее связывание является опасным в больших корпоративных приложениях. Я могу подтвердить, что two-way binding иногда не так прост и не так читабелен, но большинство из этих страхов связаны с общим страданием людей от первой версии Angular, где двусторонняя привязка была, может быть, не самой лучшей. И все же… это, вероятно, не было самым большим просчетом даже в Angular. Посмотрите на мой быстрый редактор, который я накостылил недавно с Vue.js для нашей платформы на Drupal (заранее прошу прощения за дизайн, это бэкенд UI для наших операторов, а дизайнеры заняты, создавая интерфейсы для наших клиентов, так что этот кусок функционала ждет своего часа, чтобы стать красивым):

730e66f5a262468f8f04fec45f37a5a0.gif

Я не могу показать код по понятным причинам, но писать его в Vue было очень приятно, а код получился очень читаемым. И я точно знаю, что если бы я писал отдельную функцию для каждого поля формы, как в React, я бы, конечно, не прыгал от счастья.

Redux тоже многословен и требует много писанины. И в интернете легко найти высказывания разработчиков, которые обвиняют Mobx в превращении React в Angular только потому, что Mobx использует двухсторонню привязку данных (см. пункт№1 о «чистоте»). Похоже, что многие умные люди больше ценят «чистоту» своего кода, а не быстро и хорошо решенную бизнес-задачу (что, в принципе, нормально, если у вас нет дедлайнов).

При этом, я считаю саму концепцию Flux/Redux — очень крутой. Redux прост и дает невероятный уровень контроля за состоянием приложения, и отделение состояния от чисто интерфейсных штук — это сразу дает упрощение написания тестов. Но, к сожалению, это все дается очень большим количеством писанины. Да, time-travel дебаггинг как побочный эффект — это офигенно. Но лично я готов им пожертвовать ради скоростного написания кода, и подумайте, нужен ли вам time-travel, если ради него надо придумать константу для каждого поля в форме.

Чрезмерное излишество в инструментарии


React работает с изначальным прицелом на Babel. Вы не сделаете реальное приложение на React без приличной кучи npm пакетов, начиная с компилятора ES5. Простое приложение на основе официальной стартовой сборки в нагрузку получает около 75 МБ JS кода в node_modules. Это не критичная вещь и больше относится к миру JS в целом, чем к React, но все же добавляет расстройства и раздражения.

Мой вердикт по React — позволяет писать отличный, читаемый код, но писать его много и невесело. Ну и проблемы для верстальщиков не владеющих, и не желающих владеть ES6 внутри HTML — никуда не деваются.

Angular 1: Слишком много свободы — это тоже плохо


Angular 1 — неплохой для своего времени фреймворк, расположенный в противоположном углу (от React) воображаемой JS карты чистоты и читаемости кода. Angular позволяет стартовать быстро, позволяет получить удовольствие от написания первых 1к строк кода, и потом он практически заставляет вас писать код, который получается не очень. Вы, вероятно, потеряетесь в директивах, scopes, и двухсторонние потоки данных, пронизывающие насквозь все слои вашего приложения, будут завершающим аккордом лебединой песни вашего кода, который свеженанятые разработчики даже не захотят трогать, потому что обязательно что-нибудь сломается. Почему же так происходит? Angular.js был создан в 2009 году, когда мир фронтенд-разработки выглядел довольно просто и никто даже не задумывался о хорошем контроле за состоянием (state) приложения. Не стоит винить авторов — они просто делали конкурента Backbone с некоторыми новыми фишками и хотели поменьше печатать (и им все это удалось, другой вопрос какой ценой).

Angular2


Просто постройте hello-world приложение и посмотрите на количество файлов, которые лежат в итоге в репе. Придется использовать Typescript (а я не на 100% уверен, что я хочу делать каждый день — нет, ребят, статическая типизация в JS — это не панацея, зато попечатать в очередной раз придется, неплохие мысли от Eric Eliott на эту тему) и компиляторы, чтобы начать работать. Нам этого хватило, чтобы отложить Angular2 до лучших времен. Я ленивый, и для меня это слишком много бойлерплейта, прежде чем начнешь писать реальный код. На мой взгляд, авторы Angular 2 пытаются построить идеальную систему для энтерпрайза, которая будет побеждать React, вместо того, чтобы пытаться построить фреймворк, которая решает бизнес-задачи для обычного, среднестатистического пользователя. Может быть, я ошибаюсь, и мое мнение может измениться — у меня нет большого опыта работы в Angular2, мы только что построили тестовое приложение калькулятора, в конце концов. Замечательная страница сравнения на сайте Vue.js называет Angular2 хорошей системой, которую с Vue.js объединяет немало идей.

Vue.js


Vue.js — это штука, которую я ждал долго (здесь и далее я буду говорить о Vue.js 2, который получил немало улучшений по сравнению с первой версией Vue, и это текущая стабильная версия системы). Для меня, с точки зрения элегантности и лаконичности, а также фокусировке на решениях реальных задач, Vue.js является самым большим прорывом в JS с того дня, когда меня сразил наповал Jquery в 2007. Если вы посмотрите на графики популярности Vue.js, то заметите, что он порадовал в этом году не только меня:
Vue.js является одним из наиболее быстро растущих (с точки зрения комьюнити или, как минимум, количества лайков в гитхабе, и пользователей Vue Dev Tools в хром сторе) решений JS в 2016 году, и я уверен, что это не просто еще одна модная библиотека для хипстеров, которые переключаются на новый JS фреймворк каждые 3 месяца, или работа PR-отдела какой-нибудь большой компании.

Laravel добавил Vue.js в ядро, и это серьезная заявка.

Плюсы Vue.js


Vue.js выдерживает отличный баланс между читаемостью, ремонтопригодностью кода и удовольствия от его, этого кода, написания. Этот баланс находится на примерно равноудаленном расстоянии между React и Angular 1, и если вы посмотрите на гайдлайн vue.js, вы сразу же заметите, сколько полезных идей он позаимствовал из этих систем.

Из React Vue.js взял компонентный подход, props, односторонний поток данных для иерархии компонентов, производительность, возможность рендеринга на бэкенде и понимание важности надлежащего управления состоянием (state). Из Angular1 Vue.js взял похожие шаблоны с хорошим синтаксисом и двухстороннее связывание, но только там, где это вам действительно нужно и не позволит так сразу отстрелить себе ногу (внутри одного компонента). Начать писать код под Vue.js очень легко — я видел это в нашей команде. Vue.js не требует каких-либо компиляторов по умолчанию, так что очень легко добавить Vue.js к вашей legacy кодовой базе и начать переписывать jQuery мешанину на читаемый код.

Правильное количество магии


Vue.js очень прост в работе как в точки зрения HTML-centric подхода, так и с точки зрения JS разработчиков: вы можете сделать довольно сложные шаблоны, не теряя фокуса на бизнес-задаче, и получающийся HTML шаблон обычно неплохо читается даже тогда, когда он уже большой. К этому времени, как правило, вы достигли хорошего прогресса в решении бизнес-задачи и можете захотеть реорганизовать шаблоны и разделить их на более мелкие составляющие — в этот момент вы видите всю «картину» вашего приложения намного лучше, чем в самом начале. Мой опыт показывает, что это значительно отличается от подхода, который обычно используют программисты в React, и это различие экономит много времени и усилий программистам использующим Vue.js. В React вы вынуждены разбивать компоненты на микрокомпоненты и микрофункции прямо в момент написания первоначальной, «черновой» версии кода, иначе вы будете буквально погребены в мешанине фигурных скобок и хтмла между ними. В React я трачу много времени на полировку props и рефакторинг супермелких компонентов (которые, конечно же, никогда не будут повторно использованы) снова и снова, потому что не вижу так ясно, когда мне вдруг понадобится поменять логику кода в середине процесса.

Формы


Работа с HTML-формами в Vue.js — одно удовольствие. Это то место, где двусторонний байндинг реально выручает. Даже в сложных случаях нет никаких проблем, хотя watchers на первый взгляд могут напомнить Angular 1. Односторонний поток данных всегда к вашим услугам, когда вы дробите компоненты.

Технологии


Если вы хотите компиляцию, linting, PostCSS и ES6 — не проблема. Single-file компоненты, похоже, становятся основным способом написания публичных компонентов в Vue.js 2. Кстати, идея Scoped CSS, работающая в single-file компонентах из коробки — это то, что выглядит действительно красиво и может уменьшить необходимость в строгих правилах именования CSS классов и таких технологий, как BEM.

Управление состоянием


У Vue.js довольно простое и полезное управление состоянием через data () и props () методы — они отлично работают в реальной разработке. Если душа просит чего-то большего для менеджмента состояния, есть Vuex (который, по-моему, похож на Mobx в React — состояние там мутабельно). Я думаю, хорошему проценту Vue.js приложений управление состоянием через Vuex не понадобится, но альтернативу иметь приятно.

Минусы VueJS


Runtime ошибки в шаблонах


Самый большой: неприятные ошибки времени исполнения в шаблонах. Жертва в угоду удобству написания кода. Это очень похоже на Angular 1. Vue.js удается выдать много полезных предупреждений для JS кода: например, есть предупреждения, когда вы пытаетесь мутировать props или некорректно используете data () метод, положительное влияние React здесь очень хорошо заметно. Но runtime ошибки в шаблонах по-прежнему являются слабым местом Vue.js. Стэктрейсы исключений зачастую бесполезны и ведут во внутренние методы Vue.js. В этом случае и в этом классе ошибок и дебага JSX зачастую приятнее: за счет компиляции «из JS в JS» там клик на ошибке в консоли браузера обычно ведет именно туда, где эта ошибка произошла в коде.

Библиотеки


Инфраструктура Vue.js еще довольно молодая. По сути, стабильных компонентов от комьюнити можно по пальцам пересчитать, причем многие из них были построены для Vue.js 1, и зачастую новичкам не так просто разобраться, под какую версию Vue.js построена конкретная библиотека. Эта проблема нивелируется тем, что вы можете сделать крутые вещи в Vue.js, не испытав большой нужды в сторонних библиотеках. Вероятно, понадобится лишь библиотека для Ajax запросов (vue-resource будет хорошим выбором, если вы не заботитесь об изоморфных приложениях, в противном случае Axios) и, вероятно, Vue-router, который считается библиотекой с хорошей поддержкой авторов Vue.js.

Non-english speaking community


китайские комментарии в коде большинства публичных репозиториев, и это неудивительно: Vue.js становится очень популярным решением в Китае (автор Vue.js говорит по-китайски)

Проект одного человека.


Скорее, потенциальная проблема, чем реальная, но иногда хочется перестраховаться. Evan Vue — это парень, который построил Vue после того, как поработал в Google и Meteor. Laravel, конечно, тоже single-guy проект, но, тем не менее, он по-прежнему очень успешен, правда?

Vue.js в Drupal


Disclaimer: мы не планируем использовать Drupal 8 в ближайшее время в Qwintry, так как переходим на более современные, быстрые и простые PHP и Node.js фреймворки, но наш legacy код — это Drupal. Так как основной сайт qwintry.com работает на Drupal, для нас было очень важно проверить Vue.js в бою именно здесь. Честно скажу, я не горжусь многими участками нашего кода в этом репозитории, в некоторые выдающиеся места стараемся совсем не влезать, пока оно работает хоть как-то, но этот старый проект с историей сносно функционирует и генерирует наш доход, так что мы уважаем его, улучшаем его, и многие новые фичи выходят именно здесь. Вот список вещей, которые я построил на Vue в Drupal: форма быстрого редактора сущностей, который включает в себя формирование счетов-фактур для клиентов, а также быстрое редактирование списков товаров. Тут понадобилось построить простой JSON API для загрузки и сохранения сущностей — ничего особенного, просто несколько коллбеков. Два дешборда, через REST API от Saas продуктов, которые мы используем для нашей службы поддержки, чтобы операторам не нужно было бегать по админкам отдельных веб-сайтов для проверки информации, относящейся к конкретному клиенту. Теперь все это встроено прямо в профиль клиента на нашем сайте. Я знаю, многие бекэнд разработчики все еще застряли в 2010 году и Ajax системе ядра Drupal. Я хорошо знаю, насколько сложным может быть Drupal код, когда пытаешься построить сколько-нибудь сложную многоступенчатую форму с помощью Ajax функционала из ядра — такой код практически невозможно потом поддерживать. Да, я говорю про тебя, ctools_wizard_multistep_form (), и тебя, ajax_render!

В то же время этих разработчиков толкают вперед требования к современным интерфейсам, но сложность современной инфраструктуры JS вгоняет их в депрессию. Да, узнаю себя год назад. В общем, ребята, послушайте меня! Вы не найдете лучшего момента и способа улучшить свои интерфейсы, чем прямо сейчас взять Vue.js, положить его в в sites/all/libraries, добавить его с помощью drupal_add_js () в шаблон и начать писать код. Вы будете шокированы, насколько проще поддерживать систему, в которой Drupal отвечает только за выдаваемый JSON, когда весь клиентский код, в том числе формы, полностью работает на Vue.js.

Vue.js в Yii2


Забавный факт: Yii был создан китайскоязычным разработчиком Qiang Xue. Таким образом, можно назвать Yii + Vue.js стек не только стеком, название которого почти невозможно выговорить с первой попытки, но еще и стеком с китайским наследием (в хорошем смысле). Для новой версии Qwintry.com (еще не опубликованной) мы выбрали Yii2, который, как я считаю, является одним из лучших и самых быстрых PHP фреймворков. Он, определенно, не такой популярный, как Laravel, который захватил лидерство в мире PHP, но нас Yii2 стек вполне устраивает (хотя мы смотрим на Laravel время от времени, там разработчики жгут, и там, конечно, более зрелая инфраструктура в плане библиотек). Мы постепенно уменьшаем количество HTML, который генерирует Yii2 и PHP, концентрируясь больше на REST API, который генерирует JSON для клиентской части, работающей на Vue.js / Swift / Java. API-first подход используется для большинства наших Active Record моделей в проекте. Тут мы уже серьезно относимся к API и именно поэтому тратим много времени на хорошую API документацию, пусть этот API и не публичный. В участках кода, где часть HTML генерируется на уровне PHP, мы используем собственные решения и webpack для связки и удобного деплоя Yii2 виджетов, которые, в свою очередь, используют Vue single-file компоненты. С PHP7 & последним MySQL время отклика нашего Yii2 JSON бэкенда не сильно отличается от Node.js бэкендов (я говорю о скорости ответа порядка 15–20ms), это не космические цифры, прямо скажем, но это более чем достаточно для наших нужд, а, самое главное, это в 10–20 раз быстрее, чем то, что может выдать наш старый Drupal сайт. В то же время это старый добрый (и поднадоевший, может быть) PHP со всей силой библиотек композера и стабильной кодовой базой. Отзывчивость интерфейсов, построенных на Yii2 & Vue.js, очень приемлемая, и, с точки зрения читабельности кода, тут тоже все в порядке.

Мы также используем Vue.js в ряде внутренних и внешних проектов, где бекенд работает на Node.js — тут ничего нового к сказанному выше не добавлю, все работает нормально.

Заключение


Мы пишем Vue.js код каждый день в течение уже около 4 месяцев в различных проектах, и результаты нас впечатляют. 4 месяца — это ничто в мире бэкэнда, но для JS мира это приличный срок, за который рождаются и умирают пяток фреймворков :) Посмотрим, что будет дальше. Думаю, Vue.js станет основным решением под JS в ближайшие 16–24 месяцев, если Evan You сделает правильные шаги, по крайней мере, в среде бекендеров и небольших команд фронтендщиков. React стек будет мейнстримом в 2017 году, особенно если React Native продолжит взрослеть и улучшаться такими же темпами, как сейчас.

UPD: эта заметка попала в топ HackerNews, и там завязалось полезное обсуждение (250+ коментариев): news.ycombinator.com/item? id=13151317

В топе Reddit WebDev мы тоже побывали, 60+ комментариев здесь. Забавный комментарий-мнение про Angular2 оттуда:

All Google documentation is like reading Microsoft docs from the early 2000s.
«Setting up an Angular project is a piece of cake! Just make sure the stateless reference prototype mutator inherits from the base memory loader legacy object implementing the MODOK service provider (not part of core: see here for equally unreadable details). You’ll then be ready to compile your Angular kernel, being careful to use Webpack 2.3.9 (note: not 2.3.8 as supplied with the repository). This is all you need to know to get started on a great Angular project. Angular: making development simple and fun again!»

Вопросы от читателей:


JSX классный и правильный, а вы — не очень! Если вам так хочется условий — запрограммируйте свой компонент If, это три строки!

Неприятно выбирать фреймворк, а потом делать такие вещи ему наперекор, про такие решения у вас потом будет спрашивать каждый новый разработчик, пришедший в проект, а в чужих компонентах ваши глаза всегда будут спотыкаться о тернарность.
Более того, у If компонента написанного «в лоб» будут проблемы в том, что внутренние компоненты всегда исполняются. Но есть и решения поинтереснее: github.com/AlexGilleran/jsx-control-statements

Так что вы предлагаете, уважаемый, теперь надо срочно бросать React и все переписывать на Vue.js?

Да нет же! React — прекрасный фреймворк, и он позволяет писать читаемый и поддерживаемый код, а еще под него уже написано гигантское количество качественных библиотек (и микрокомпонентность и ограниченность JSX, которую я «поругал» выше — тут как раз играет уже положительную роль, для публичных библиотек это уже зачастую оправданно), которых нет ни под какое другое JS решение. Если вас и вашу команду все устраивает в JSX и вас не напрягает много печатать, пожалуй, нет никакого смысла переходить на Vue.js, игра просто не стоит свеч. Многие любители JS в последнее время любят скакать от фреймворка к фреймворку. Не надо этим злоупотреблять, на мой взгляд, лучше потратить это время на что-то более интересное, что заметят пользователи вашего проекта.

А вот если вы никак себя не могли заставить начать использовать React из-за массивного инструментария и других сложностей, а в вашем коде попадается невнятная каша из jQuery или Backbone, Vue.js может быть отличным вариантом, не академичным, простым и лаконичным.

Целиком статью я не читал, но в заголовке вы что-то там негативное сказали про иммутабельность, вы, наверное, не православный в силу своей неопытности и глупости не понимаете, как прекрасен функциональный подход!

Давайте разделять иммутабельность как функциональную парадигму (мы очень уважаем функциональный подход, концепцию иммутабельности и чистоту функций) и текущее состояние JS мира и его библиотек. Если разработчик, прочитав блог фейсбука, радостно хватает Immutable.js и впиливает его в продакшн, а потом понимает, что дока у него не очень, Lodash и весь остальной код, написанный предыдущим поколением разработчиков, с ним не работает (да, я в курсе про immutable обертки вокруг lodash, спасибо), и поэтому разработчик проваливает дедлайн — это значит, что разработчик купился не на функциональную парадигму, а скорее на хайп вокруг конкретной библиотеки. Не надо думать, что если у фейсбука встают реальные проблемы, которые они решают с помощью Immutable.js, то это значит, что и у вас в вашем лендинге или SPA возникнут проблемы похожего порядка. Скорее всего нет, скорее закончатся деньги у ваших инвесторов вам нужно будет максимально быстро выкатывать работающие фичи, а коду достаточно быть нормальным и не мутирующим где не надо, ему не обязательно для этого использовать Immutable.js (почитать мнение про Immutable.js можно, например, здесь). Отдельно отмечу, что большое количество JS разработчиков, чьи мнения я видел, как основную киллер-фичу Immutable.js называют не чистоту и надежность получающегося кода, а — внимание! — увеличивающуюся производительность (речь про быстрые сравнения структур)! Что-то в этом мире не так, если функциональную штуку такого уровня люди впиливают ради улучшенной производительности в свой проект. Кажется, в дело опять вмешалась мода…

Если вам хочется упростить себе жизнь, просто прекращайте мутировать состояние, переходите на props, и эти простые вещи прямо сейчас будут улучшать вам жизнь.

© Geektimes