Angular vs. React vs. Vue: Сравнение 2017

https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

Выбор JavaScript-фреймворка для вашего веб-приложения может быть невыносим. В настоящее время очень популярны Angular и React, и есть также выскочка, получающий много внимания в последнее время: VueJS. Кроме них, лишь эти несколько новичков.



Итак, как же нам выбрать? Список плюсов и минусов никогда не повредит. Проделаем это в стиле моей предыдущей статьи, “9 шагов: выбор технологического стэка для вашего веб-приложения”.


Прежде чем начнем — SPA или нет?


Сперва вы должны принять четкое решение, нужно ли вам одностраничное веб-приложение(SPA), или вы предпочли бы многостраничный подход. Больше на эту тему в моем посте “Одностраничные веб-приложения(SPA) против Многостраничных веб-приложений(MPA)”(скоро выйдет, следите за обновлениями в Twitter).


Участники сегодняшнего состязания: Angular, React and Vue


Сначала я хотел бы обсудить жизненный цикл и стратегические соображения. Затем мы перейдем к возможностям и идеям всех трех JavaScript-фреймворков. Наконец, мы придем к выводам.


Вопросы, которые мы сегодня рассмотрим:


  • Насколько зрелые эти фреймворки/библиотеки?
  • Будут ли эти фреймворки существовать еще какое-то время?
  • Насколько велики и полезны сообщества вокруг них?
  • Насколько легко найти разработчиков под каждый из этих фреймворков?
  • Каковы основные идеи этих фреймворков?
  • Насколько просто использовать эти фреймворки для небольших и крупных веб-приложений?
  • Какова кривая обучения для каждого из фреймворков?
  • Какую производительность вы ожидаете от этих фреймворков?
  • Где вы можете подробнее узнать, что у них под капотом?
  • Как начать разрабатывать с выбранным фреймворком?

На старт, внимание, марш!


Жизненный цикл и стратегические соображения



React vs. Angular vs. Vue


1.1 Немного истории


Angular — это JavaScript-фреймворк, основанный на TypeScript. Разработанный и поддерживаемый Google, он описывается как “Супергеройский JavaScript MVW фреймворк”. Angular(известный также как “Angular 2+”, “Angular 2” или “ng2”) — переписанный, по большей части несовместимый преемник AngularJS(известный как “Angular.js” или “AngularJS 1.x”). Хотя AngularJS(старый) был впервые выпущен в октябре 2010-го, он до сих пор получает багфиксы и т.д. Новый Angular(без JS) был представлен как версия №2 в сентябре 2016. Последний мажорный релиз — версия 4, так как версию 3 пропустили. Angular используется Google, Wix, weather.com, healthcare.gov и Forbes(в соответствии с madewithangular, stackshare и libscore.com).


React характеризуется как “JavaScript-библиотека для создания пользовательских интерфейсов”. Впервые выпущенный в марте 2013-го, React разработан и поддерживается Facebook-ом, который использует React-компоненты на нескольких страницах(однако, не являясь одностраничным веб-приложением). В соответствии с этой статьей Криса Кордла, React в Facebook применяется значительно шире, чем Angular в Google. React также используют в Airbnb, Uber, Netflix, Twitter, Pinterest, Reddit, Udemy, Wix, Paypal, Imgur, Feedly, Stripe, Tumblr, Walmart и других(в соотв. с Facebook, stackshare и libscore.com).


В данный момент Facebook работает над выпуском React Fiber. Это изменит React под капотом — в результате, рендеринг должен значительно ускориться — но обратная совместимость сохранится после изменений. В Facebook рассказывали об этих изменениях на их конференции для разработчиков в апреле 2017-го, также была опубликована неофициальная статья о новой архитектуре. Предположительно, React Fiber будет выпущен вместе с React 16.


Vue — один из самых быстроразвивающихся JS-фреймворков в 2016-м. Vue описывает себя как “Интуитивный, Быстрый и Интегрируемый MVVM для создания интерактивных интерфейсов”. Впервые он был выпущен в феврале 2014-го бывшим сотрудником Google Эваном Ю(кстати, Эван тогда написал интересный пост про маркетинговую деятельность и цифры в первую неделю после старта). Это был неплохой успех, особенно учитывая, что Vue привлекает столько внимания будучи театром одного актера, без поддержки крупной компании. На данный момент, у Эвана есть команда из дюжины основных разработчиков. В 2016 была выпущена вторая версия. Vue используют Alibaba, Baidu, Expedia, Nintendo, GitLab. Список более мелких проектов можно найти на madewithvuejs.com.


И Angular, и Vue доступны под лицензией MIT, в то время как React — под BSD3-license. Есть много обсуждений по поводу патентного файла. Джеймс Аид(бывший инженер Facebook) объясняет причины и историю, лежащую за этим файлом: Патент Facebook касается распространения их кода при сохранении возможности защитить себя от патентных исков. Файл патента обновлялся единожды и некоторые люди утверждают, что React можно использовать, если ваша компания не собирается подавать в суд на Facebook. Можете ознакомиться с обсуждением вокруг этого Github issue. Я не являюсь адвокатом, поэтому вы сами должны решить, создает ли лицензия React проблемы для вас или вашей компании. Есть еще много статей на эту тему: Дэннис Уолш пишет, почему вам не стоит бояться. Рауль Крипалани предостерегает от использования в стартапах, у него также есть обзор в формате “изложение мыслей”. Также существует недавнее оригинальное заявление от Facebook на эту тему: “Разъяснение лицензии React”.


1.2 Core development


Как было отмечено ранее, Angular и React поддерживаются и используются крупными компаниями. Facebook, Instagram и Whatsapp используют их на своих страницах. Google использует их во многих своих проектах: например, новый пользовательский интерфейс Adwords был реализован с помощью Angular и Dart. Опять же, Vue разрабатывается группой лиц, чья работа поддерживается через Patreon и другие средства спонсирования. Решайте сами, хорошо это или плохо. Маттиас Гёцке считает, что небольшая команда Vue — это плюс, потому что это ведет к более чистому коду / API, и меньшему оверинженерингу.


Посмотрим на статистику: на странице команды Angular перечислено 36 человек, у Vue — 16 человек, у React страницы команды нет. На GitHub-е у Angular больше 25 000 звезд и 463 контрибьютора, у React — больше 70 000 звезд и 1000 контрибьюторов, и у Vue почти 60 000 звезд и лишь 120 контрибьюторов. Можете также проверить страничку “Github Stars History for Angular, React and Vue”. Опять же, Vue, похоже, очень хорошо развивается. В соответствии с bestof.js, за последние три месяца Angular 2 получал в среднем 31 звезду в день, React — 74 звезды, Vue — 107 звезд.



A Github Stars History для Angular, React и Vue (Источник)


Апдейт: Спасибо Полу Хеншелю за то, что указал на npm trends. Они показывают количество скачиваний для данных npm-пакетов и даже полезнее, как чистый взгляд на звезды GitHub.



Количество скачиваний для заданных npm-пакетов в течение двух лет


1.3 Жизненный цикл на рынке


Angular, React и Vue сложно сравнить в Google Trends из-за их разнообразных имен и версий. Одним из способов получить приблизительные значения может быть поиск в категории “Internet & technologies”. Вот результат:



Ну, что ж. Vue до 2014 года не существовало — значит, тут что-то не так. La Vue по-французски — “вид”, “взгляд”, или “мнение”. Может быть, дело в этом. Сравнение “VueJS” с “Angular” или “React” несправедливо, так как у VueJS почти нет результатов, которые можно сравнить с остальными.


В таком случае, попробуем кое-что другое. Technology Radar от ThoughtWorks дает хорошее представление о том, как технологии эволюционируют в течение времени. Redux находится на стадии принятия(принятия в проектах!) и он был бесценен на ряде проектов ThoughtWorks. Vue.js на стадии испытаний(испытайте!). Его описывают, как легковесную и гибкую альтернативу Angular с более низкой кривой обучения. Angular 2 находится на стадии оценки — он успешно используется командами ThoughtWorks, но пока не имеет настоятельных рекомендаций.


В соответствии с последним опросом StackOverflow 2017, React любят 67% опрошенных разработчиков, а AngularJS — 52%. “Отсутствие интересу к продолжению разработки” регистрирует большие значения для AngularJS(48%) в сравнении с React(33%). Vue не входит в первую десятку ни в одном из случаев. Далее, есть опрос statejs.com, сравнивающий “front-end фреймворки”. Самые интересные факты: React и Angular обладают 100%-й известностью, Vue незнаком 23%-м опрошенных людей. Касательно “удовлетворенности”, React набрал 92% для варианта “использовал бы снова”, Vue — 89%, Angular 2 — только 65%.


Как насчет другого опроса об удовлетворенности пользователей? Эрик Элиотт запустил один в октябре 2016-го, чтобы оценить Angular 2 и React. Лишь 38% опрошенных людей использовали бы Angular 2 снова, в то время как 84% использовали бы снова React.


1.4 Долгосрочная поддержка и миграции


API React-а достаточно стабилен, как заявляет об этом Facebook в своих принципах проектирования. Существуют также скрипты, помогающие мигрировать с вашего текущего API на новый: попробуйте react-codemod. Миграции достаточно просты и здесь нет такой вещи(и необходимости в ней), как LTS версии. В этом посте на Reddit люди отмечают, что апгрейд на самом деле никогда не был проблемой. Команда React написала пост об их схеме версионирования. Когда они добавляют предупреждение об устаревании, они оставляют его для остальной части текущей релизной версии до того момента, пока поведение не будет изменено в следующей мажорной версии. Планов выпустить новую мажорную версию нет — v14 выпущена в октябре 2015-го, v15 опубликована в апреле 2016-го, а у v16 пока нет даты релиза. Обновление не должно стать проблемой, как недавно заметил один из основных разработчиков React.


Что касается Angular, есть пост о версионировании и релизах Angular начиная с релиза v2. Будет одно мажорное обновление каждые шесть месяцев и период устаревания(deprecation period), как минимум шесть месяцев(два мажорных релиза). Существуют экспериментальные API, помеченные в документации более коротким периодом устаревания. Официального анонса нет, но в соответствии с этой статьей, команда Angular анонсировала LTS версии начиная с Angular 4. Они будут поддерживаться как минимум год после следующего мажорного релиза. Это значит, что Angular 4 будет поддерживаться багфиксами и важными патчами как минимум до сентября 2018-го. В большинстве случаев, обновление со второй до четвертой версии Angular также просто, как обновление зависимостей Angular. Angular также предоставляет руководство с информацией о том, какие понадобятся изменения в дальнейшем.


Процесс обновления с Vue 1.x до 2.0 должен быть простым для небольшого приложения — команда разработчиков утверждает, что 90% API осталось без изменений. Имеется приятный инструмент для диагностики обновления и помощи во время миграции, работающий из консоли. Один из разработчиков отметил, что обновление с v1 до v2 до сих пор не приносит особого удовольствия на больших приложениях. К сожалению, roadmap-а для следующего мажорного релиза или информации о планах создания LTS версий нет.


Еще кое-что: Angular — это цельный фреймворк, предлагающий кучу вещей в комплекте. React гибче, чем Angular, и вы, вероятно, столкнетесь с использованием более независимых, неустаканенных, быстроразвивающихся библиотек — это означает, что вам придется самостоятельно заботиться о соответствующих обновлениях и миграциях. Это может нанести вред, если определенные пакеты больше не поддерживаются или если какой-то другой пакет в определенный момент становится стандартом де-факто.


1.5 Кадровые ресурсы и найм


Если у вас есть HTML-разработчики, которые не хотят углубляться в JavaScript, вам лучше выбрать Angular или Vue. React повлечет за собой увеличение количества JavaScript-а(позже мы поговорим об этом).


У вас есть дизайнеры, работающие в непосредственной близости с кодом? Пользователь “pier25” отмечает в своем Reddit-посте, что выбирать React имеет смысл, если вы работаете в Facebook, где каждый разработчик — супергерой. В реальном мире, вы не всегда найдете дизайнера, способного модифицировать JSX — по существу, работать с HTML-шаблонами будет намного проще.


Хорошая новость относительно Angular это то, что новый Angular 2-разработчик из другой компании сможет быстро ознакомиться со всеми необходимыми соглашениями. Каждый проект на React отличается в плане архитектурных решений и разработчикам нужно будет знакомиться с настройками конкретного проекта.


Angular также хорош, если у вас есть разработчики с ООП-бэкграундом или те, кто не любят JavaScript. Чтобы заострить на этом внимание, цитата Манеша Чанда:


“Я не JavaScript-девелопер. Мой бэкграунд — создание крупномасштабных корпоративных систем с использованием “настоящих” платформ для разработки ПО. Я начинал в 1997-м, разрабатывая приложения на C, C++, Pascal, Ada и Fortran. (...) Я могу точно сказать, что JavaScript для меня просто белиберда. Будучи MVP в Microsoft и экспертом, я хорошо понимаю TypeScript. Я также не рассматриваю Facebook, как компанию-разработчика ПО. Однако, Google и Microsoft уже крупнейшие инноваторы в этой сфере. Я чувствую себя более комфортно, работая с продуктом, у которого есть хорошая поддержка от Google или Microsoft. Также (...) с моим бэкграундом, я знаю, что у Microsoft даже большие планы для TypeScript”

Ну… Видимо, я должен упомянуть, что Манеш Чанд является региональным директором в Microsoft.


Сравнение React, Angular и Vue


2.1 Компоненты


Все обсуждаемые фреймворки основаны на компонентах. Компонент получает что-то на вход и после внутренних вычислений возвращает отрендеренный шаблон UI(область входа / выхода с сайта или элемент списка to-do) на выходе. Определенные компоненты должно быть легко переиспользовать на веб-странице или в других компонентах. Например, у вас мог бы быть компонент сетки(состоящий из шапки и нескольких компонентов для рядов) с разнообразными свойствами(колонки, информация о шапке, data rows, и т.д.) и возможностью переиспользования этого компонента с разными данными на другой странице. Вот всеобъемлющая статья о компонентах на тот случай, если вам захочется изучить их получше.


И React, и Vue превосходно подходят для работы с “тупыми” компонентами: небольшие функции, не имеющие состояния, которые получают что-то на вход и возвращают элементы на выходе.


2.2 TypeScript vs ES6 vs. ES5


React фокусируется на использовании JavaScript ES6. Vue использует JavaScript ES5 либо ES6.


Angular зависит от TypeScript. Это дает большую консистентность в примерах и в опенсорсных проектах(примеры React можно найти в ES5 или в ES6). Это также вводит такие понятия, как декораторы или статическая типизация. Статическая типизация полезна для инструментов для анализа кода, типа автоматического рефакторинга, перехода к определению и т.д. — они должны уменьшить количество багов в приложении, хотя консенсус по поводу их использования, определенно, не достигнут. Эрик Элиот не согласен с этим в своей статье “Шокирующий секрет статических типов”. Дэниэл С Вонг говорит, что использование статических типов не вредит и что хорошо иметь разработку через тестирование(TDD) и статическую типизацию одновременно.


Вам, вероятно, следует знать о том, что вы можете использовать Flow, чтобы включить проверку типов в React. Это инструмент для статической проверки типов, разработанный Facebook для JavaScript. Flow также можно интегрировать в VueJS.


Если вы пишете код на TypeScript, вы уже не пишете стандартный JavaScript. Несмотря на рост, у TypeScript до сих пор крошечное число пользователей, по сравнению со всем языком JavaScript. Один из рисков может заключаться в том, что вы будете двигаться в неверном направлении, поскольку TypeScript может — хотя и вряд ли — исчезнуть со временем. Помимо того, TypeScript создает приличный оверхед на проектах(на обучение) — можете больше почитать об этом в Сравнении Angular 2 и React от Эрика Элиотта.


Апдейт: Джеймс Рейвенскрофт написал к этой статье комментарий о том, что у TypeScript первоклассная поддержка JSX — компоненты можно легко проверить на соответствие типу. Так что, если вам нравится TypeScript и вы хотите использовать React, это не должно быть проблемой.


2.3 Шаблоны — JSX или HTML


React нарушает устоявшиеся best practices. Десятилетиями разработчики пытались разделить шаблоны и встроенную джаваскриптовую логику, но в JSX они опять перемешаны. Может быть, это звучит ужасно, но вам следует послушать речь Питера Ханта “React: Переосмысление best practices”(от октября 2013-го). Он указывает на то, что разделение шаблонов и логики — это просто разделение технологий, а не ответственности. Вы должны создавать компоненты вместо шаблонов. Компоненты переиспользуемы, интегрируемы и удобны для unit-тестирования.


JSX — это опциональный препроцессор с HTML-подобным синтаксисом, который затем компилируется в JavaScript. Отсюда некоторые странности — например, вам нужно использовать className вместо class, потому что последний является в JavaScript зарезервированным ключевым словом. JSX — большое преимущество для разработки, так как у вас все будет в одном и том же месте, а также быстрее будут работать автокомплит и проверки на стадии компиляции. Когда вы допускаете ошибку в JSX, React не компилирует код и выводит номер строки, в которой допущена ошибка. Angular 2 тихо падает в рантайме(возможно, этот аргумент некорректен, если вы пользуетесь AOT с Angular).


JSX подразумевает, что все в React = JavaScript — он используется и для JSX-шаблонов, и для логики. Кори Хаус указывает в своей статье от января 2016-го: “Angular 2 продолжает внедрять ‘JS’ в HTML. React внедряет ‘HTML’ в JS”. Это хорошо, потому что JavaScript мощнее, чем HTML.


Шаблоны в Angular представляют собой усовершенствованный HTML со специальным языком Angular(штуки, вроде ngIf или ngFor). В то время, как React требует знания JavaScript, Angular заставляет вас учить специфичный для Angular синтаксис.


Vue предлагает “однофайловые компоненты”. Это похоже на компромисс относительно разделения ответственности — шаблоны, скрипты и стили в одном файле, но в трех различных, упорядоченных секциях. Это значит, что вы получаете подсветку синтаксиса, поддержку CSS и возможность легко использовать препроцессоры типа Jade или SCSS. Я прочитал в других статьях, что JSX проще дебажить, потому что Vue не показывает синтаксические ошибки в HTML. Это не так, поскольку Vue конвертирует HTML в render-функции — поэтому ошибки показываются без проблем(Спасибо Винициусу Рейзу за комментарий и поправки!).


Примечание: Если вам нравится задумка с JSX и вам хочется использовать его в Vue, вы можете использовать babel-plugin-transform-vue-jsx.


2.4 Фреймворки против библиотек


Angular — больше фреймворк, чем библиотека, так как предоставляет убедительные предложения о том, как ваше приложение должно быть структурировано, а также имеет больше функционала из коробки. Angular — это “цельное решение” — включены “батарейки” и вам предоставляется возможность удобного старта. Вам не нужно проводить анализ библиотек, решать вопрос с роутингом и т.п. — вы можете просто начать работать.


React и Vue, с другой стороны, универсально гибки. Их библиотеки можно совмещать с любого рода пакетами(их достаточно много для React в npm, но у Vue пакетов меньше, так как он еще достаточно молод). Используя React, вы можете даже заменить саму библиотеку на ее API-совместимую альтернативу, такую как Inferno. С большей гибкостью, однако, появляется большая ответственность — для React не существует правил и и ограничительных рекомендаций. Каждый проект требует принятия решения относительно его архитектуры, и все может легко пойти не так, как планировалось.


С другой стороны, Angular поставляется с запутанным клубком систем для сборки, бойлерплейтов, линтеров и других пожирателей времени, с которыми придется иметь дело. Это верно и для React в случае использования стартер-китов или бойлерплейтов. Конечно, они очень полезны, React работает из коробки, и это, может быть для вас способ его изучить. Иногда разнообразие инструментов, необходимых для работы в JavaScript-окружении называют “усталостью от JavaScript”. Вот статья Эрика Клеммонса, который сказал следующее:


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

Vue кажется самым чистым и легким из трех фреймворков. У GitLab есть пост о принятии решения в пользу Vue.js(октябрь 2016-го):


Vue.js прекрасно поставляется отлично сбалансированным в плане того, что он может сделать для вас и того, что вам нужно делать самостоятельно. (...) Vue.js всегда находится в пределах досягаемости; прочная, но гибкая сетка готова помочь сохранить эффективность вашего программирования и свести связанные с DOM страдания к минимуму.

Им нравится простота и легкость использования — исходный код очень читабелен и документация или внешние библиотеки не нужны. Все достаточно просто. Vue.js “не делает далекоидущих предположений о большей части чего-либо”. Имеется также подкаст о решении GitLab.


Другой пост о переходе на Vue от Pixeljets. React “был большим шагом вперед для мира JS в плане state-awareness, и он показал множеству людей реальное функциональное программирование хорошим, практичным способом”. Одним из серьезных минусов React по сравнению с Vue является проблема разбиения компонентов на более мелкие компоненты из-за ограничений JSX. Вот цитата из статьи:


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

На Hacker news и Reddit есть интересные дискуссии об этом посте — в наличии аргументы от недовольных и дальнейших сторонников Vue.


2.5 Управление состоянием и связывание данных


Разрабатывать UI сложно, так как состояния присутствуют везде — данные меняются с течением времени, что влечет за собой увеличение сложности. Определенные способы работы с состоянием оказывают большую помощь, когда приложение разрастается и становится более сложным. Для небольших приложений это может быть перебор, и что-то типа Vanilla JS было бы достаточно.


Как это работает? Компоненты описывают UI в определенный момент времени. Когда данные изменяются, фреймворк перерисовывает UI-компонент целиком — отображаемые данные всегда актуальны. Мы может назвать эту идею “UI как функция”.


React часто работает в паре с Redux. Redux описывает себя в трех фундаментальных принципах:


  • Единственный источник правды
  • Состояние доступно только для чтения
  • Изменения делаются с помощью чистых функций

Другими словами: состояние приложения целиком находится в дереве объектов внутри единого хранилища. Это помогает отлаживать приложение и кое-какая функциональность становится проще для реализации. Состояние в read-only режиме и может быть изменено только через “экшены”, чтобы избежать состояния гонки(также полезно для отладки). “Редьюсеры” пишутся, чтобы указать, как “экшены” могут трансформировать состояние.


Большая часть туториалов и бойлерплейтов включают в себя Redux, но вы можете использовать React без него(или вам может быть вообще не нужен Redux в вашем проекте). Redux добавляет сложность и достаточно серьезные ограничения для вашего кода. Если вы изучаете React, вам стоит подумать об изучении чистого React перед тем, как вы перейдете к Redux. Вам определенно стоит прочесть “Вам может быть не нужен Redux” Дэна Абрамова.


Некоторые разработчики предлагают использовать Mobx вместо Redux. Можете думать о нем, как о “автоматическом Redux”, который упрощает использование и понимание с самого начала. Если хотите посмотреть, вам стоит начать с введения. Вы можете также почитать это полезное сравнение Redux и MobX от Робина. Тот же автор также предлагает информацию о переходе с Redux на MobX. Этот список полезен, если вы хотите проверить другие Flux-библиотеки. И, если вы пришли из мира MVC, вы захотите прочесть статью “Философия Redux (если вы уже знаете MVC)” Михаила Левковского.


Vue можно использовать с Redux, но он предлагает Vuex как свое собственное решение.


Большое отличие между React и Angular — одно- или двустороннее связывание. Двустороннее связывание в Angular меняет модель состояния, когда элемент пользовательского интерфейса(к примеру, поле ввода) обновляется. React идет только одним путем: сначала обновляет модель и затем отрисовывает элемент. Подход Angular чище в коде и проще для реализации разработчиком. Подход React позволяет получить лучшее понимание о том, что происходит с данными, потому что поток данных течет лишь в одном направлении(это делает отладку проще).


Оба подхода имеют плюсы и минусы. Вам нужно понять эти идеи и определить, влияют ли они на ваше решение о выборе фреймворка. И статья “Двустороннее связывание: Angular 2 и React”, и этот вопрос на StackOverflow предоставляют хорошие объяснения. Здесь вы можете найти интерактивные примеры кода(возрастом в 3 года, только для Angular 1 и React). Последнее, но тем не менее важное: Vue поддерживает и одностороннее, и двустороннее связывание(одностороннее по-умолчанию).


Если хотите почитать больше, имеется длинная статья о различных типах состояния и управлении состоянием в Angular-приложениях(от Виктора Савкина).


2.6 Другие концепции программирования


Angular включает в себя dependency injection, паттерн, в котором один объект(сервис) предоставляет зависимости другому объекту(клиенту). Это дает большую гибкость и более чистый код. Статья “Понять dependency injection” в деталях объясняет эту идею.


Паттерн Модель-Вид-Контроллер(MVC) делит проект на три части — модель, вид и контроллер. У Angular, как у MVC-фреймворка, имеется поддержка MVC из коробки. У React есть лишь V — что будет M и C нужно решить вам самим.


2.7 Гибкость и переход к микросервисам


Вы можете работать с React или Vue просто добавляя JavaScript-библиотеку к исходникам. Это невозможно с Angular, потому что он использует TypeScript.


Мы все больше движемся в сторону микросервисов и микроприложений. React и Vue предоставляют вам полный контроль над размером приложения, позволяя включить только те вещи, которые действительно нужны. Они дают больше гибкости при переходе от SPA к микросервисам, используя части бывшего приложения. Angular лучше подходит для SPA, так как для использования в микросервисах он, вероятно, слишком раздут.


Как отмечает Кори Хаус:


JavaScript быстро развивается, и React позволяет вам заменять небольшие фрагменты вашего приложения более подходящими библиотеками вместо того, чтобы ждать и надеяться на то, что ваш фреймворк обновят. Философия маленьких, интегрируемых, узкоспециализированных инструментов никогда не выйдет из моды.

Некоторые люди также используют React для не-SPA вебсайтов(например, для сложных форм или мастеров). Даже Facebook использует React не для главной страницы, а, скорее, для определенных страниц и возможностей.


2.8 Размер и производительность


Обратная сторона функциональности: Angular довольно-таки раздут. Размер сжатого gzip-ом файла — 143кб, по сравнению с 23кб Vue и 43кб React.


И у React, и у Vue есть Virtual DOM, который должен увеличивать производительность. Если вам интересно, можете почитать об отличиях между Virtual DOM и DOM, а также о реальных преимуществах Virtual DOM в React. Один из авторов Virtual DOM также отвечает на вопросы, связанные с производительностью на StackOverflow.


Чтобы проверить производительность, я посмотрел великолепный js-framework-benchmark. Вы можете сами скачать и запустить его или посмотреть на интерактивную таблицу с результатами. Перед тем, как проверить результаты, вам нужно знать, что фреймворки обманывают бенчмарки — такие замеры производительности не должны быть основой принятия решений.



Производительность Angular, React и Vue (Источник)



Выделение памяти в Мб (Источник)


Чтобы подытожить: у Vue прекрасная производительность и лучшее распределение памяти, но все фреймворки действительно довольно рядом друг с другом, по сравнению с особенно медленными или особенно быстрыми фреймворками(типа Inferno). Еще раз: тесты производительности следует рассматривать как побочные данные, не для вынесения вердикта.


2.9 Тестирование


Facebook использует Jest, чтобы тестировать свой код на React. Здесь есть сравнение Jest и Mocha, и есть статья о том, как использовать Enzyme с Mocha. Enzyme — библиотека для тестирования, написанная на JavaScript, используемая Airbnb(в сочетании с Jest, Karma и другими тест-раннерами). Если вы хотите почитать побольше, имеются старые статьи про тестирование в React(здесь и здесь).


Далее, существует Jasmine, как тестовый фреймворк для Angular 2. В статье Эрика Элиотта говорится о том, что Jasmine “приводит к миллионам способов написания тестов и утверждений, нуждающихся в тщательном прочтении каждого из них, чтобы понять, что он делает”. Вывод также раздут и труден для чтения. Есть несколько информативных статей про интеграцию Angular 2 с Karma и Mocha. Также есть старое видео(от 2015-го) о тестовых стратегиях в Angular 2.


У Vue есть недостатки в тестировании, но Эван написал в своем превью от 2017-го, что команда планирует поработать над этим. Они рекомендуют использовать Karma. Vue работает с Jest, также есть тестовая утилита avoriaz.


2.10 Универсальные и нативные приложения


Универсальные приложения внедряются в веб, на десктопы, а также в мир нативных приложений.


И React, и Angular поддерживают нативную разработку. У Angular есть NativeScript(при поддержке Telerik) для нативных приложений и Ionic Framework для гибридных приложений. С React вы можете попробовать react-native-renderer, чтобы разрабатывать кроссплатформенные приложения для iOS или Android, или react-native для нативных приложений. Большое число приложений(включая Facebook; за подробностями на Showcase) сделаны с помощью react-native.


JavaScript-фреймворки рендерят страницы на клиенте. Это плохо для воспринимаемой производительности, пользовательского опыта в целом и SEO. Серверный рендеринг — это плюс. У всех трет фреймворков имеются библиотеки, чтобы помочь с этим. Для React это next.js, у Vue есть nuxt.js, и у Angular есть… Angular Universal.


2.11 Кривая обучения


У Angular, определенно, крутая кривая обучения. Он обладает всеобъемлющей документацией, но иногда это может вас расстраивать, потому что ряд вещей сложнее, чем кажется. Даже если вы глубоко понимаете JavaScript, вам нужно изучить, что происходит под капотом фреймворка. Вначале установка магическая, предлагает большое число встроенных пакетов и кода. Это можно рассматривать, как минус из-за большой, сразу существующей экосистемы, которую вам нужно со временем изучить. С другой стороны, это может и хорошо в определенных ситуациях, поскольку многие решения уже приняты. С React вам, скорее всего, придется принять множество внушительных решений относительно использования third-party библиотек. Существует 16 различных flux-пакетов для управления состоянием, которые можно выбрать для React.


Vue довольно прост для изучения. Компании переходят на Vue из-за того, что он кажется значительно более простым для начинающих разработчиков. Тут вы сможете почитать, как некто описывает переезд своей команды с Angular на Vue. По информации от другого пользователя, приложение на React в его компании было таким сложным, что новые разработчики не поспевали за сложностью кода. С Vue разрыв между младшим и старшим разработчиком сокращается, и они могут взаимодействовать проще и с меньшим количеством багов, проблем и времени на разработку.


Некоторые люди утверждают, что то, что они сделали на React было бы написано лучше с использованием Vue. Если вы — неопытный JavaScript разработчик — или в последние 10 лет работали в основном с jQuery — вам стоит подумать об использовании Vue. Сдвиг парадигмы более выражен при переходе на React. Vue выглядит больше как чистый JavaScript в тоже время привнося некоторые новые идеи: компоненты, событийная модель и однонаправленный data-flow. Также у него небольшой размер.


Тем временем, у Angular и React свой собственный подход к вещам. Они могут мешать вам, потому что вам нужно приспосабливаться под них, чтобы заставить их работать. Это может быть вредно из-за меньшей гибкости и крутой кривой обучения. Это также может быть и полезно, поскольку вас заставляют изучать правильные подходы в процессе изучения технологии. С Vue вы можете работать в стиле старомодного JavaScript. Это может быть проще вначале, но может стать проблемой в долгосрочной перспективе, если все сделать не верно.


Когда речь заходит об отладке, плюс React и Vue в меньшем количестве магии. Охота на баги проще, потому что есть лишь несколько мест, куда нужно смотреть, и у стектрейсов лучше видны отличия между собственным кодом и исходниками библиотеки. Работающие с React сообщают, что им никогда не требовалось читать исходный код библиотеки. Однако, отлаживая ваш код вашего приложения на Angular, вам часто нужно отлаживать внутренности Angular, чтобы понять лежащую в его основе модель. С другой стороны, сообщения об ошибках должны стать более чистыми и информативными начиная с Angular 4.


2.12 Под капотом Angular, React и Vue


Хотите проверить исходники самостоятельно? Хотите увидеть, как все складывается?


Возможно, вам стоит сначала проверить вот эти GitHub-репозитории: React(github.com/facebook/react), Angular(github.com/angular/angular) и Vue(github.com/vuejs/vue).


Как выглядит синтаксис? ValueCoders сравнивают синтаксис Angular, React и Vue.


Хорошо бы также увидеть все на продакшене — вместе с исходным кодом, на котором все основано. На TodoMVC есть список из десятков вариантов одного и того же Todo-приложения, написанного на различных JavaScript-фреймворках — можете сравнить решения на Angular, React и Vue. RealWorld разрабатывает реальное приложение(клон Medium) и у них есть готовые решения для Angular(4+) и React(с Redux). Для Vue работа в процессе.


Также есть некоторые реальные приложения, на которые вы можете посмотреть. Решения на базе React:



Приложения на Angular:



А также решения на Vue:



Заключение


Выберите фреймворк сейчас


И React, и Angular, и Vue достаточно круты, и никого из них нельзя поставить сильно выше остальных. Доверьтесь своему нутру. Эта последний кусочек развлекательного цинизма может помочь вам принять решение:


Грязный маленький секрет — “современная JavaScript-разработка” не имеет ничего общего с созданием веб-сайтов — это создание пакетов, которые могут использоваться людьми, создающими библиотеки, которые могут использоваться людьми, создающими фреймворки, которым люди, пишущие туториалы и ведущие курсы могут обучать. Не уверен, что кто-то действительно что-то создает для настоящих пользователей.

Это преувеличение, конечно, но в нем возможно есть доля правды. Да, в экосистеме JavaScript есть много лишнего шума. Может быть, вы найдете множество более привлекательных альтернатив во время ваших поисков — постарайтесь не быть ослепленным новейшим блестящим фреймворком.


Что я должен выбрать?


  • Если вы работаете в Google: Angular
  • Если вы любите TypeScript: Angular(или React)
  • Если вам нужно руководство, структура и рука помощи: Angular
  • Если вы работаете в Facebook: React
  • Если вам нравится гибкость: React
  • Если вы любите большие экосистемы: React
  • Если вам нравится выбирать из десятков пакетов: React
  • Если вы любиле JS и подход “все-есть-JavaScript”: React
  • Если вам нравится действительно чистый код: Vue
  • Если вы хотите простейшая кривую обучения: Vue
  • Если вы хотите самый легковесный фреймворк: Vue
  • Если вам хочется разделения ответственности в пределах одного файла: Vue
  • Если вы работаете один или в небольшой команде: Vue(или React)
  • Если ваше приложение имеет тенденцию разрастаться: Angular(или React)
  • Если вы хотите иметь большой пул девелоперов: Angular или React
  • Если вы работаете с дизайнерами и вам нужны чистые HTML-файлы: Angular или Vue
  • Если вам нравится Vue, но пугает ограниченная экосистема: React
  • Если вы не можете решить, изучите сначала React, затем Vue, затем Angular

Итак, вы приняли решение?



Дааа, вы его приняли!


Отлично! Читайте о том, как начать разрабатывать с Angular, React или Vue (скоро, подписывайтесь на меня в Twitter для обновлений).


Дополнительные ресурсы


React JS, Angular & Vue JS — Quickstart & Comparison (восьмичасовое введение и сравнение трех фреймворков)
Angular vs. React (vs. Vue) — the DEAL breaker (короткое, но превосходное сравнение от Доминика Т)
Angular 2 vs. React — the ultimate dance off (неплохое сравнение от Эрика Элиотта)
React vs. Angular vs. Ember vs. Vue.js (сравнение трех фреймворков в форме заметок от Гекана Сари)
React vs. Angular (понятное сравнение двух фреймворков)
Can Vue fight for the Throne with React? (приятное сравнение с большим количеством примеров кода)
10 reasons, why I moved from Angular to React (еще одно неплохое сравнение от Робина Вируча)
All JavaScript frameworks are terrible (большая заметка обо всех основных фреймворках от Мэтта Берджесса)

Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 362
  • +2

    Понеслась!

    • +3
      В статье, походу, Vue вчехляют.
    • +9
      Вы что не понимаете? Джикверю всех их победил еще в 2006 году
    • 0
      Мне не хватает головы понять как изменятся реакт и ангулар с широкой поддержкой Shadow DOM и HTML templates броузерами. Angular поддерживает Shadow Dom но непонятно как с HTML templates. Если кто-то добавит свои соображения по этому пункту к статье — буду благодарен.
      • 0
        HTML темплейты скорее всего скоро задепрекейтят в пользу JS-импортов. См. примеру это, а они чуть ли не известнейшая команда, широко использовавшая эту фичу.

        Как изменится Angular уже и так видно, включаешь флаг — получаешь нативную инкапсуляцию(пока толком не работает). React с его ультракостылями типа CSS-in-JS вроде не особо-то пока и стремиться дружить с веб-компонентами.
        • 0
          Речь про HTML imports, конечно. HTML template почти везде работает и какой-то особой погоды не делает.
          • –1
            Вижу что Polymer задеприкейтил External stylesheets в компонентах, но это не тоже самое что HTML templates и мнение что JSимпорты могут заменить HTML templates — не вполне убедительно (статический html все же кажется непоколебимым столпом). Если я правильно Вас понял.

            Но мнение — что Shadow Dom и HTML Template могут устареть быстрее react звучит убедительно. Спасибо.
            • 0
              Не совсем, там речь не про стайлшиты, а про HTML Imports, это когда <link rel="import" href="my-tag.html">. А уже в «my-tag.html» могли быть и стайлшиты и что угодно.

              Так вот похоже, так делать будет нельзя, придется импортировать HTML-темплейты в JavaScipt-модули тамошними импортами. Все бы ничего, но нативно сделать это сейчас невозможно, в том то и прикол HTML Import-ов — автоматический парсинг HTML при импорте. Но есть надежда на фичу импорта HTML в JS как DocumentFragment, типа как в вебпак, но нативно.

              До остального, Shadow DOM вряд ли устареет, остальное думаю тоже в том или ином виде доделают. Просто это небыстро, но никто и не спешит.
          • 0
            Мои соображения таковы, что к моменту поддержки указанных технологий в браузерах выйдет такое количество новых JS фреймворков, что анугляр с реактом будут сметены с повестки дня, и таким образом проблема поддержки в них чего либо будет решена.
          • +1

            Основная мысль — в конце статьи:


            И React, и Angular, и Vue достаточно круты, и никто из них нельзя поставить сильно выше остальных.

            Можно выбрать любой, но как именно? Обычно в моей работе это решалось так:


            1. Уже написан какой-то код, продолжаем писать на чем досталось
            2. Знаем хорошо технологию, берем ее, чтобы получить предсказуемые сроки и качество
            3. Намечается маленький проект — пробуем что-то новое, все равно не сложно будет переписать
            • +9
              По моему опыту(3,5 года с различными SPA), такие выводы:

              • На чем писать без разницы, но лучше на том, за что платят и чтобы удовлетворяло начальным требованиям(сразу сужает круг, особенно кроссбраузерность)
              • Если и платят, и выбор есть, выбирать то, что лучше знаешь/больше нравится(мало кто знает на хорошем уровне несколько фреймворков, еще сильнее сужаем круг)
              • Проблемы будут хоть с jQuery-лапшой, хоть с космическими технологиями, точно также будешь сидеть писать код и править баги. Где-то чуть дольше, где-то чуть меньше,
                но по сути компонентный подход вырисовывается все равно.
              • Если маленький проект или самому побаловаться, брать то, что не пробовал. Запилил даже маленький проект — повысил свою цену на рынке за счет знания еще одного инструмента.

              Так что похоже на ваши.
              • +2
                Прекрасный пример Resume Driven Development!
                • +1
                  Прекрасный пример совмещения приятного с полезным.
                  • 0
                    Отличное определение сути вопроса с т.з. разработчика! :)
              • +4
                Если вы не можете решить, изучите сначала React, затем Vue, затем Angular
                А мне кажется, лучше изучать именно в хронологическом порядке — A, R, V. Не обязательно супер-глубоко, но хотя бы в общих чертах. Тогда на третьем шаге станет понятно:
                а) как шло развитие идеи;
                б) сколько шелухи отбрасывает Vue и насколько он прозрачнее.
                Как в анекдоте про козла в квартире — сначала нужно создать себе трудности, потом избавиться от них и почувствовать счастье.
                • +1
                  <цитата>Вы можете работать с React или Vue просто добавляя JavaScript-библиотеку к исходникам. Это невозможно с Angular, потому что он использует TypeScript.</цитата> Вам стоит лучше изучить ts и angular прежде чем делать такие заявления.
                  • –2
                    Еще один пункт в пользу выбора Angular. Я пришел с backend, конкретно с .NET. Typescript+Angular самые близкие ко мне по привычной идеологии.
                    • +1
                      вообще не ощутил сложности ни с А ни с R. Vue не пробовал) мне хватает этих двух головняков)
                      з.ы.
                      Работая одновременно с back и front+back (R+Node или A+Node) почему-то больше понравилось всетаки работа с R =)) Видимо мозг переключается с одного на другое и ему легче, нед однотипности во всем)
                      • 0

                        Хм, а у меня ровно наоборот впечатление. Реакт — тупо шаблон без всякой магии.

                    • 0
                      Перед тем, как проверить результаты, вам нужно знать, что фреймворки обманывают бенчмарки
                      И vue тут тоже отличился, без читинга он бы попал в нижнуюю половину списка (хотя там видимо многие читирят), но как минимум был бы ниже (медленее) ангуляра 2+.
                      • 0
                        А можно поподробнее, чем именно отличился?
                        • 0
                          Например когда другие фреймворки делают «click» биндинг на каждую строку, строк там где-то до 11к, семпл с vue — хитрят, делают один биндинг (сверху), что значительно экономит время (и память).
                          Впрочем тоже самое можно сделать и для других фреймворков, но это какбы срезать путь по лесу, вместо того чтобы бежать по трассе.

                          Это то что на поверхности, если копнуть глубже, думаю можно ещё что-нибудь найти, выше есть ссылка на статью о хаках некоторых фреймворков, так же я находил «хак» в ангуляре 2 альфа версии где вместо удаления строк они вставляют их обратно на второй интерации, хотя это спорный пункт — можно считать просто оптимизацией.
                          • +1
                            Так и делегацию обработки событий родителю ведь тоже можно отнести к оптимизации. Это ведь не специально ради бенчмарков делается, а как раз для реальной оптимизации. Т.е. это не читинг, а реально полезная фича: код «среднестатистического» разработчика работает быстрее.
                            • 0
                              Это ведь не специально ради бенчмарков
                              Это не в фреймворке, а в бенчмарке сделано. Чтобы повыше позицию занять.

                              Если такую «оптимизацию» считать валидной, то тогда добавте $mol в тест с его lazy списками, и он порвет всех и даже нативный JS в 10 раз*.
                              • +1

                                А что плохого в подобных оптимизациях, если они происходят на уровне фреймворка, а не прикладного кода?

                                • 0
                                  Конекретно lazy список — совсем другой компонент, нужен другой подход (врапер, спец. разметка), он имеет некоторые ограничения и отличия, по сравнению с обычным списком, его нужно в тест ленивых списков, а не в этот. Тем более большинство веб-приложений это не просто списки.
                                  если они происходят на уровне фреймворка
                                  Тогда хорошо, но заточка заложенная в фреймворк под конкретный тест выглядит некрасиво.
                                  • 0
                                    Конекретно lazy список — совсем другой компонент

                                    Это не "lazy" список, а "вертикальный лэйаут", который может содержать элементы любых типов. Применяется всякий раз, когда надо расположить элементы вертикально (даже если всего 2 элемента, как в $mol_expander). Есть ещё "горизонтальный лэйаут с переносом" и прочие. Бонусом к ним идёт учёт видимой области при рендеринге, так что в них можно выводить произвольное число элементов, не боясь, что страница станет рендериться минуту.


                                    нужен другой подход (врапер, спец. разметка)

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


                                    он имеет некоторые ограничения

                                    Если речь про "браузерный поиск по странице", который не работает с неотрендеренными данными, то это ограничение всего фреймворка, который поощряет (и упрощает) использование внутристраничного поиска, который в подавляющем большинстве случаев работает лучше и который всё-равно необходим в случае больших объёмов данных и разбиения его на страницы.


                                    и отличия

                                    Возможное подёргивание скроллбара при дорендеривании опять же не особенность конкретного компонента, а компромис на уровне фреймворка. Все компоненты предоставляют свои минимальные размеры, а $mol_scroll учитывает их, задавая высоту скроллящейся области.


                                    его нужно в тест ленивых списков

                                    Если для пользователя не видно разницы (в случае todomvc — точно не видно), для разработчика не вино разницы (кроме небольших опциональных хинтов, уточняющих размеры, чтобы скроллбар не дёргался), то к чему эта дискриминация на основании внутренней оптимизации?


                                    Тем более большинство веб-приложений это не просто списки.

                                    Вот смотрите, огромная статья, содержащая параграфы, заголовки, таблицы, картинки, исходные коды. Открывается мгновенно, потому что рендерится лениво.


                                    Тогда хорошо, но заточка заложенная в фреймворк под конкретный тест выглядит некрасиво.

                                    Конкретный тест должен отражать реальный юзкейс, иначе грош цена такому тесту.

                                    • 0
                                      Вот смотрите, огромная статья, содержащая параграфы
                                      Если честно, то скролл ведет себя не по человеческий не только при скроле вниз (если тащить скрол мышкой), но и вверх (зачем удалять уже отрендеренные итемы?)

                                      то к чему эта дискриминация на основании внутренней оптимизации?
                                      Тест создан, чтобы можно было прикинуть/сравнить производительность на будущих проектах, и вероятнее всего это будет не просто список.
                                      Тест тестирует список, потому что это простейший способ создать «нагрузку/объем», поэтому урезание этого объема будет отражать неверные затраты, т.к. с отложенным отображением вы можете сократить список на 95%, когда реальные приложения можно «урезать» только на 5%*. Т.е. вы скрывате как фрейморк работает с большим кол-вом html-элементов.

                                      Конкретный тест должен отражать реальный юзкейс, иначе грош цена такому тесту.
                                      Согласен, но имеем что имеем, и многие на него ориентируются.
                                      • –1
                                        Если честно, то скролл ведет себя не по человеческий не только при скроле вниз (если тащить скрол мышкой)

                                        Такова цена ленивости. Не сильно большая как по мне. В основном его таскают пальцем/колёсиком/тачпадом. Да и если курсором таскать — не такое уж прям сильное неудобство. Кроме того, основной сценарий — постепенное пролистывание, а не мотание взад-вперёд.


                                        зачем удалять уже отрендеренные итемы?

                                        Чем меньше единовременно на странице элементов, тем быстрее браузер с ней работает (reflow, layout size, styling, animations, memory usage).


                                        реальные приложения можно «урезать» только на 5%

                                        Моя практика говорит об обратном. Приведёте пример тяжёлого приложения, которое можно урезать лишь на 5%. Ну вот даже то приложение для чтения статей позволяет урезать гораздо больше. Тут даже важно не на сколько урезать, а асимптотика. Логарифмическая против линейной. В идеале — рендерить только то, что попадает в видимую область и больше ничего. Ленивый рендеринг $mol очень близок к этому идеалу на старте, когда все ползунки скроллинга наверху. Собственно, когда данных столько, что они все помещаются на экран, то все фреймворки достаточно быстры, чтобы пользователь не замечал тормозов (ну кроме совсем отбитых, конечно). Ну вот, если в todomvc бенчмарке поставить 10 задач, влезающих в экран, то все фреймворки дают 60-100мс (ну кроме тормозного Реакта, да, который даёт от 120 :-)), что неотличимо на глаз, да и вообще соразмерно с погрешностью. Но уже при 100 задачах ситуация резко меняется: $mol почти не замедлился выдавая 250мс, а остальные просели на порядок выдавая 500мс в лучшем случае (внезапно, Knockout), что уже является заметным пользователю подтормаживанием. "Быстрые" Реакты так вообще за 1000мс перевалили.

                                        • 0
                                          Чем меньше единовременно на странице элементов, тем быстрее браузер с ней работает
                                          Тогда в добавок можно удалять блоки сверху, оставляя пустышки того же размера.

                                          Приведёте пример тяжёлого приложения, которое можно урезать лишь на 5%.
                                          У нас в компании большое веб-приложение, везде пагинаторы, вкладки и т.п., скролы не желательны т.к. это не «веб страничка с текстом» — желательно что-бы приложение помещалось в экран.

                                          Только в одном проекте мне нужна была ленивая загрузка «строк», делается в 5-10* строк кода — просто определяю что скрол добежал до конца — добрасываю ещё 10-20 элементов в массив.

                                          В одном проекте нужна была ленивая загрузка блоков, по несколько блоков в ряд, все блоки разной высоты, должны были красиво подстраиваться (менять позицию) что-бы лента была краисвая (без дыр), но на это $mol из коробки не способен.
                                          • 0
                                            Тогда в добавок можно удалять блоки сверху, оставляя пустышки того же размера.

                                            К сожалению тут есть сложности. Если меняется ширина контейнера или состояние скрытых сверху блоков, то пустышки не знают на сколько надо изменяться в размерах. В результате при скроллинге вверх будут неприятные скачки при замене пустышек на реальные блоки. Но я экспериментирую сейчас с бесконечной в обе стороны лентой, в которую можно было бы подкладывать/удалять блоки с обеих сторон без скачков. С кроссбраузерностью, к сожалению, пока беда.


                                            У нас в компании большое веб-приложение, везде пагинаторы, вкладки и т.п., скролы не желательны

                                            Пагинаторы не от хорошей жизни придуманы. Зачем они, если можно проскроллить?


                                            Только в одном проекте мне нужна была ленивая загрузка «строк», делается в 5-10* строк кода

                                            Добавьте иерархию и зашьётесь с отладкой. Может оказаться, что на 3 уровне глубины у вас окажется 100500 элементов.


                                            В одном проекте нужна была ленивая загрузка блоков, по несколько блоков в ряд, все блоки разной высоты, должны были красиво подстраиваться (менять позицию) что-бы лента была краисвая (без дыр), но на это $mol из коробки не способен.

                                            Ну, опишите подробней задачу, может и запилим стандартный компонент на это дело. У нас пока для этого есть лишь $mol_row.

                                            • 0
                                              Но я экспериментирую сейчас с бесконечной в обе стороны лентой
                                              Отображать только «видимое» +120% от вьюпорта сверху снизу для плавного скроллинга, и независимый скрол с равномерной шкалой (1 ед. скрола = 1 элемент массива любой высоты)

                                              Пагинаторы не от хорошей жизни придуманы.
                                              Чтобы не вываливать весь список, и высота приложения была не большая. Вон гугл-поиск, gmail и др. используют пагинацию вместо автоподгрузки.

                                              Ну, опишите подробней задачу
                                              Это было в очень старом проекте, сейчас нет смысла тратить на это время.
                                              • 0
                                                независимый скрол

                                                Он будет отставать от прокрутки, ибо асинхронный.


                                                1 ед. скрола = 1 элемент массива любой высоты

                                                Тогда при наличии разновысотных блоков будет меняться скорость прокрутки.


                                                У меня идея с изменением flex-direction при прокрутке вверх/вниз. Крутим вниз — дорендериваем вниз. Крутим вверх — дорендериваем вверх. Ну и оцениваем высоту скроллящейся области по контенту, как сейчас. То есть пригодно может быть и для вполне ограниченного списка.


                                                Вон гугл-поиск, gmail и др. используют пагинацию вместо автоподгрузки.

                                                Ну не осилили, бывает. УткаУткаПошла и Я.Почта, например, осилили.


                                                Это было в очень старом проекте, сейчас нет смысла тратить на это время.

                                                Ну может пригодится ещё.

                                                • 0
                                                  Ну может пригодится ещё.
                                                  Пример тут, блоки разной высоты и автоподгрузка.
                                                  • 0

                                                    Понял о чём вы. На мой взгляд такую раскладку сложнее воспринимать, так как человеку приходится бегать слева-направо прескакивая колонки. В результате он глазами будет попадать либо на то, что уже отсмотрел, либо будет что-то пропускать перескакивая не туда. Ну и в целом смотрится хаотично. Если привести размеры карточек к одному размеру в строке — получится и опрятней и удобней.


                                                    Впрочем, реализовать такую раскладку тривиально:


                                                    Создаём колонки в виде экземпляров $mol_list:


                                                    Galery $mol_row
                                                        items <= cols /
                                                    -
                                                    Col!index $mol_list
                                                        rows <= col_items!index /

                                                    Балансируем на них карточки:


                                                    col_items( index : number ) {
                                                        const items = this.items()
                                                        const col_items = [] as typeof items
                                                        const col_count = this.col_count()
                                                        for( let index = index % col_count ; index < items.length ; index += col_count ) {
                                                            col_items.push( this.Card( index ) )
                                                        }
                                                        return col_items
                                                    }
                                              • 0
                                                Пагинаторы не от хорошей жизни придуманы. Зачем они, если можно проскроллить?

                                                Не спора ради, но разве пагинаторы не придуманы чтобы иметь возможность перейти на конкретную страницу, а не круть колесико с неистовой силой?
                                                • 0

                                                  Откуда пользователю знать на какой странице располагается интересующая его информация?

                                                  • 0
                                                    Откуда пользователю знать на какой странице располагается интересующая его информация?

                                                    Откуда вам знать, что он не может знать? Банальный пример — информация отсортирована по убыванию, известно кол-во элементов на странице, известен номер последнего элемента. Даже самый не далекий юзер сможет примерно прикинуть на какой странице располагается элемент под номером N. И даже если он не угадает с первого раза, это все равно быстрее и понятнее, чем скролить 20 банчей, чтобы добраться туда.

                                                    Теперь посмотрим со стороны сервера: 20 запросов против 1-2х запросов с указанием оффсета.
                                                    • –1

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

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

                                                          У меня есть номер 373. На страницу выводится 15 элементов. Какая страница мне нужна?


                                                          Откуда пользователь знает "примерно где это"? Ну а если знает, то что мешает ему проскроллить до примерно этого места?

                                                          • +1
                                                            Откуда пользователь знает «примерно где это»? Ну а если знает, то что мешает ему проскроллить до примерно этого места?

                                                            Потому что это дольше. Потому что больше запросов к серверу. Потому что это больше рендаринга на клиенте. Много еще почему. А вы привите хотя бы один довод, почему удобне скролить?
                                                            У меня есть номер 373. На страницу выводится 15 элементов. Какая страница мне нужна?

                                                            Я бы сперва сходил на страницу 20, потому что 300 легко визульно делится на 15. Ну а дальше еще пару кликов, на 24 и 25 в итоге. Считаем статистику: 3 запроса к серверу, 45 элементов загружено и отрендарино. Потрачено 3 клика и примерно 2 секунды времени.
                                                            Смотрим статистику по скроллу: 25 запросов к серверу, 375 элементов загружено и отрендарино. Потрачено хренова-туча кролирующих движений мышкой и примерно 10-15 секунд времени.
                                                            Статистика на лицо.

                                                            А вот вам пример, такой же «заточенный» как и ваш:

                                                            У меня есть номер 1000. На страницу выводится 10 элементов. Какая страница мне нужна?

                                                            Ответ пагинации очевиден. Ответ скролинга: «да ну нафиг, пойму кофе пить» ))))
                                                            • 0

                                                              PaulMaly почему вы пишите "рендер" как "рендар". Вам так слышится или вы пальцем не туда попадаете? Реализация зависит от того что человек себе представляет. Вы так себе представляете vintage по другому. Совместите свои взгляды и вы подружитесь.
                                                              Относительно вашей задачи. Асинхронные события произошли, а караван из операций идёт своим путем, (он же конвейер).

                                                              • +1
                                                                PaulMaly почему вы пишите «рендер» как «рендар». Вам так слышится или вы пальцем не туда попадаете?

                                                                Это так важно?
                                                                Вы так себе представляете vintage по другому. Совместите свои взгляды и вы подружитесь.

                                                                Вообще-то это не я писал что:
                                                                Пагинаторы не от хорошей жизни придуманы. Зачем они, если можно проскроллить?

                                                                Я то как раз за то, чтобы разные подходы использовались там, где это наиболее соответствует ситуации. И не разделяю подход «всегда скроллинг! нет пагинации!», вот и все.
                                                                Относительно вашей задачи. Асинхронные события произошли, а караван из операций идёт своим путем, (он же конвейер).

                                                                Про какую задачу речь?
                                                              • 0
                                                                Потому что больше запросов к серверу.

                                                                Проблемы сервера пользователя не касаются. Впрочем, запросов будет 2-4: список идентификаторов всех элементов и данные по тем идентификаторам, что надо отрендерить.


                                                                Потому что это больше рендаринга на клиенте.

                                                                Меньше. Пользователь тыкнул в середину скроллинга а далее дорендеривает соседние элементы, а не целые страницы.


                                                                Потрачено хренова-туча кролирующих движений мышкой и примерно 10-15 секунд времени.

                                                                Вы по страницам тоже только последовательно ходите?


                                                                У меня есть номер 1000.

                                                                Давайте опустимся с небес на землю. У пользователя нет номера 1000 в подавляющем большинстве случаев.

                                                                • 0
                                                                  Проблемы сервера пользователя не касаются.

                                                                  Т.е. вы мыслите узко, чисто фронтенд-ориентировано? В этом ваше отличие от fullstack-программистов. Ну и конечно же серверники вам спасибо не скажут. Не удивлюсь если это станет ключевой причиной почему кто-то откажется от вашего компонента в реальном проекте.
                                                                  Впрочем, запросов будет 2-4: список идентификаторов всех элементов и данные по тем идентификаторам, что надо отрендерить.

                                                                  Ого, вы теперь еще и о деталях реализации серверной части предположения строете? Не слишком ли много на себя берет никому не известный фронтенд-фреймверк?
                                                                  Меньше. Пользователь тыкнул в середину скроллинга а далее дорендеривает соседние элементы, а не целые страницы.

                                                                  Предположим, а если не ткнул? Я вот так никогда не делаю, к примеру, хотя я конечно не показатель. Зато я часто «тащу» скролл вниз, а эта фича как я понял у вас плохо работает. И кстати, как вы вообще вычисляете середину, если у вас нет общего количества элементов?
                                                                  Вы по страницам тоже только последовательно ходите?

                                                                  А разве скроллинг в основе своей не последовательная штука? Всякие ваши предположения, что пользователь куда-то там тыкнет в середину — это не более чем предположения об определенных кейсах. Базовый кейс скроллинга — это последовательная смена позиции контента.
                                                                  Давайте опустимся с небес на землю. У пользователя нет номера 1000 в подавляющем большинстве случаев.

                                                                  Такой же «притянутый за уши» пример как и ваш. Только вы привели число, которое типа сложно посчитать, чтобы поддержать свою точку зрения, а я то, которое просто. Вот и вся разница. Не понимаю, чего вы теперь жалуетесь.
                                                                  • 0
                                                                    • 0
                                                                      вы зря спорите что лучше, на самом деле всё просто и очевидно:

                                                                      Согласен, именно об этом я и твержу — каждой задаче свое решение. Уважаемый vintage более котегоричен:
                                                                      Пагинаторы не от хорошей жизни придуманы. Зачем они, если можно проскроллить?

                                                                      Я с этим также категорически не согласен. Вот и все.
                                                                      • 0

                                                                        Мы тут не бесконечный скролл обсуждали, а самый обычный.


                                                                        Позволять возвращаться в прошлое необходимо в том числе и на развлекательных сайтах. Никогда не замечали проблемы вида "вчера в ленте проскакивала картинка, которая сейчас была бы кстати, но как её теперь найти?"?


                                                                        Даже если пользователь каким-то чудом запомнит страницы всех материалов, что он когда-то смотрел, спустя какое-то время скорее всего их на тех страницах уже не окажется.


                                                                        На этом давайте закончим обсуждение абстрактных паджинаторов. Если есть какой-то конкретный кейс, где без паджинатора никак — я бы с интересом послушал. К сожалению, всё, что обычно выдаётся за его "полезное применение" — это от кривого UX, который можно было бы исправить более прямым способом, а не использовать паджинатор не по назначению.

                                                                        • +1
                                                                          Позволять возвращаться в прошлое необходимо в том числе и на развлекательных сайтах. Никогда не замечали проблемы вида «вчера в ленте проскакивала картинка, которая сейчас была бы кстати, но как её теперь найти?»?

                                                                          Cудя по всему у вас лента маленькая))) У меня, если что-то было вчера, с помощью скрола уже не найти))) Как впрочем и пагинации.)))
                                                                          Если есть какой-то конкретный кейс, где без паджинатора никак — я бы с интересом послушал.

                                                                          Это вы сделали громкое заявление за которым не последовало никаких доказательств его подкрепляющих. Впрочем как и всегда.
                                                                          К сожалению, всё, что обычно выдаётся за его «полезное применение» — это от кривого UX, который можно было бы исправить более прямым способом, а не использовать паджинатор не по назначению.

                                                                          А, так вы еще и UX дизайнер? С каждым новым комментарием вы открываетесь новой стороны.))))

                                                                          Как и писал где-то ниже, уверен что ребята из гугла и яндекса, которые как последние придурки юзают пагинацию на своих поисковых страницах, стоят в очереди за вашим талантом. Браво!
                                                                          • 0

                                                                            Специально посмотрел приложение для Андроида от али. Нет там пагинации. Сплошной скролл с подгрузкой. Причем полагаю. что все ассеты и UX как им надо кэшируются и рендарятся:) То, что 99 процентов UX кривые то, тут за грибами не ходи. Правильный трансформер Tools для UX так никто и не сделал. Хотя с инструментария и надо было начинать. vintage на мой взгляд действительно трудолюбив талантлив и амбициозен. Так и надо. Я редко кого-то хвалю. Иначе мне бы не кидали столько "-" в карму. Но это для меня не показатель. У Потапенко ненамного меньше:) Я всё ещё здесь.

                                                                            • 0
                                                                              Специально посмотрел приложение для Андроида от али. Нет там пагинации. Сплошной скролл с подгрузкой. Причем полагаю. что все ассеты и UX как им надо кэшируются и рендарятся:)

                                                                              А мы тут разве о мобильной версии беседы ведем? На мобилках свой UX, там пагинация в своем классическом виде не работает как правило, но там есть другие альтернативы. К тому же, раз уж речь зашла о мобильных — не знаю как у остальных, но демо сайт магазина игрушек (если есть те, до кого vintage еще не добрался: toys.hyoo.ru) у меня не телефоне работает не адекватно. Совершенно банальная навигация не фурычит. Может конечно он банально не оптимизирован под мобильные, не знаю. Хотя это было бы странно. Зато скролл работает хорошо, потому как там ползунок никто мышкой не таскает.)))))
                                                                              То, что 99 процентов UX кривые то, тут за грибами не ходи.

                                                                              Знаете, вот я привык как-то доверять специалистам. Сам я спецом по UX/UI себя не считаю, поэтому понимаю что все это субъективно и не делаю громких заявлений, аля «пагинация фуфло, скролл — рулит».
                                                                              vintage на мой взгляд действительно трудолюбив талантлив и амбициозен. Так и надо. Я редко кого-то хвалю.

                                                                              Да, вопросов нет. Я бы может даже его фреймверк посмотрел, будь у него человеческий апи и синтаксис. Еще раз всем пишу банальную вещь — я не согласен со столько категорическими заявлениями:
                                                                              Пагинаторы не от хорошей жизни придуманы. Зачем они, если можно проскроллить?

                                                                              Только и всего. Каждому инструменту свое место. Бездумный максимализм не признак профессионализма. Увы.

                                                                              • 0
                                                                                К тому же, раз уж речь зашла о мобильных — не знаю как у остальных, но демо сайт магазина игрушек (если есть те, до кого vintage еще не добрался: toys.hyoo.ru) у меня не телефоне работает не адекватно. Совершенно банальная навигация не фурычит.

                                                                                Спасибо за багрепорт, поправлено.

                                                                                • 0
                                                                                  Пожалуйста. Подтверждаю исправлено. Всегда интересно потестить реальные демки. )))
                            • +1
                              Заглядывая в будущее делаю выводы, что оно точно не за комбайнами «все в одном» вроде Angular. Фронтэнд сталкивается с проблемами, решает их и многие решения становятся в последствии прекрасными opensource проектами которые становятся для многих де-факто стандартами. В экосистеме вокруг этих проектов так-же рождается множество прекрасных решений для тех или иных задач. Для меня это Webpack, React, Redux, Redux Saga, Styled Components, ESLint, Flow, так как эти вещи позволяют делать работу быстро, эффективно, масштабируемо и понятно, при этом оставляя свободу в организации архитектуры под особенности тех или иных проектов, порог входа для новых разработчиков совсем не высок, а рефакторинг и миграции в целом безболезненны. Писать огромный комбайн покрывающий максимальное количество разных по сути задач, на мой взгляд, большая ошибка, с кучей вытекающих проблем с дальнейшей поддержкой развитием, как самих фреймворков, так и написанных на них проектов. Будущее там куда идет opensource сообщество, ведь оно пытается решить конкретные задачи наилучшим способом.
                              • 0
                                >>громный комбайн покрывающий максимальное количество разных по сути задач
                                .NET и Java. QT говорят об обратном
                                Фреймворки очень востребованы, чем велосипедоделание.
                                • 0

                                  Успешное существование Electron как бы намекает, что и в desktop-разработке есть спрос на более гибкие решения.


                                  Только с производительностью проблемы, поэтому либо скорость разработки, либо скорость работы

                                  • 0
                                    >>Electron
                                    Сколько ему лет?
                                    Вот когда перевалит за 2-3 десяток, как в случае с JAVA или .NET, тогда и поговорим:)
                                    • 0

                                      Причем здесь возраст технологии?


                                      Я его привел как пример альтернативы монолитным UI-фреймворкам. Если бы всех устраивал QT и ко, Electron не появился бы в принципе.

                                      • +1
                                        >>Если бы всех устраивал QT
                                        Видимо они в нем нашли «фатальный недостаток»
                                        >>Electron не появился бы в принципе
                                        А так если серьезно, за 10 лет, я столько повидал библиотек по работе с desctopом, но выжили лишь только единицы. Поэтому судить о необходимости того или иного фреймворка можно только после испытанию временем
                                        • 0

                                          И этим фатальным недостатком является сложная кастомизация монолитного UI, о чем и сказано в первом комменте треда.

                                          • +2
                                            >>сложная кастомизация монолитного UI
                                            Вот уж не знаю, QML мне всегда больше нравился чем реакты и ангулары. Жалко его в ВЭБе нельзя применять
                                          • +1
                                            Фатальным недостатком является то, что нужно писать код на чём-то кроме JS.
                                  • 0
                                    Я имел ввиду частный случай фронтенда, странно, что вы не уловили этого из моего комментария. Безусловно для решения задач бэкенда в больших и средних проектах в большинстве случаев лучше и даже нужно использовать фреймворки. Но фронтэнд это совсем другая песня и другой круг задач. В комментарии выше вы писали, что пришли во фронт с бэкенда и ваш выбор в пользу Angular понятен. Я сам fullstack с бэкграундом Java и Ruby. Когда я думал куда уходить с морально устаревшего Backbone, я какое-то время писал на Angular и даже на Angular2, но поработав в проектах на React я больше никогда к нему не вернусь. Свою точку зрения о проблемах таких комбайнов, я в двух словах изложил выше. Советую вам познакомиться с другими технологиями(React, Vue, Redux, о самой архитектуре Flux, CSS in JS) и почитать о мотивации их создания. Опенсорс, на мой взгляд, движется в правильном направлении. Столкнувшись с большинством задач и проблем в больших проектах во фронтэнде, я думаю, вы и сами со мной согласитесь.
                                    • 0
                                      >>проблем в больших проектах во фронтэнде
                                      Большая проблема frontenda это то, что слишком много игроков. Отсюда просто зверинец часть которого погибает/обновляется/устаревает. В этом вся и проблема, я получил огромный опыт на бэкэнде и он мне говорит, что как раз технологии «все в коробке» живут дольше всего (.NET, JAVA, QT), а остальное шелуха и меняется очень часто.
                                      Другой отличительной особенностью долгоживущих проектов являются именно майнтейнеры. Google +Microsoft (Angular+typescript) уж я думаю куда более живучие, чем Facebook.
                                      • +1
                                        То что вы подразумеваете под «большой проблемой» фронтенда, вовсе не проблема, а лишь следствие его быстрого развития. И чтобы не делать неверных выводов вам лучше изучить историю этого «зверинца» решений: предпосылки к появлению, мотивацию, недостатки. Тогда и придет понимание почему одни канули в небытие, а на их место пришли другие, какие проблемы они признаны решить и какие преимущества и недостатки несет тот или иной путь решения.
                                        • 0
                                          >>историю этого «зверинца» решений:
                                          Т.е. вы утверждаете, что десктоп отличается от вэба не только в инструментах и средах работы?
                                          Я вижу пару очень существенных преимуществ вэба — кросплатформенность и легкость деплоя. Обладало хоть что-то на десктопе подобным, все уже были бы на этой технологии.
                                          • 0
                                            >>Т.е. вы утверждаете, что десктоп отличается от вэба не только в инструментах и средах работы?
                                            Простите, но что это за логический кульбит? Я ничего подобного не писал. Ткните пальцем, пожалуйста, где я это утверждаю, не переиначивая смысл изложенного.
                                            • 0
                                              Ткните пальцем, пожалуйста, где я это утверждаю

                                              Вот здесь
                                              изучить историю этого «зверинца» решений: предпосылки к появлению, мотивацию, недостатки

                                              Отсыл к истории обособленности вэба, таким образом я понимаю, что Вы утверждаете, что у него задачи совершенно разные от того же десктопа.
                                        • 0
                                          Соглашусь про мейнтейнеров — когда в проект закидываются тоннами ресурсы — это минимум не дает ему утонуть. Безотносительно его объективного качества.

                                          Сколько ресурсов потратила MS на свой дотнет — вообще невероятная величина. К ангуляр+ts есть масса вопросов, как технического, так и идеологического характера. Vue.js очень удачно зашел еще и именно на том, что он переосмыслил Angular.js.

                                          QT — давайте будем честны, очень нишевый продукт, с претензией на всё, и по факту низкой популярностью вне линукс.

                                          Java — с момента покупки ораклом движения вокруг стало сильно меньше. И про «все из коробки» — ну ок, в дотнете есть какой-то LINQ (ничего в этом не понимаю), а в Java? JPA? Hibernate? JDBC? Где тут «искоробочность»?

                                          Лучшее, что в Java-мире (imho) происходит — происходит в языках на базе JVM, а не в самом языке Java.

                                          И про «живучесть» — где тот великий и ужасный DEC? Компьютеры от Xerox? Или хотя бы IBM PC? Много ли людей вспомнит огромную Nortel Networks?

                                          Гугл тот же вполне себе носитель славной традиции убивать «лишние» проекты (помните может, какой тут хайп на Google Wave нагоняли?). Упомянутый Oracle слил OpenOffice в Apache, где он потихоньку загибается, IBM выкинул на мороз (в опенсоурс) ворох всяких штук (Lotus Symphony — из того, чем я успел попользоваться). Так что размер корпорации: а) не гарантия её живучести; б) тем более не гарантия, что проект не будет выкинут.

                                          И еще про будущее ангуляра мелкий фактик — интерфейс ютуба переписан на Polymer.
                                          • 0
                                            QT — давайте будем честны, очень нишевый продукт, с претензией на всё, и по факту низкой популярностью вне линукс.

                                            С нишевостью Qt вопрос. Очень большая доля кросплатформенного софта с GUI это Qt. И даже часть Windows-only. Даже в мобильный мир потихоньку просачивается. Скорее надо читать: с низкой популярностью вне кросплатформенных приложений.

                                            Или хотя бы IBM PC

                                            Ну собственно подавляющее большинство машин в настоящее время и есть эволюция IBM PC. Или я не понимаю, что вы хотели сказать.
                                  • +8
                                    Тож немного копеек подкину в холивар. То, что ангуляр основан на бета-фиче тайпскрипта(декораторы) уже обсасывалось не раз. То, что rxjs для веб-запросов — лютый оверенжиниринг — тоже. Все равно что везде для своих переменных использовать массивы.
                                    Вместо let name = 'Вася', писать let name = ['Вася'] и т.п.
                                    И реально использующихся потоков в рабочих проектах я еще не встречал. Везде получали один единственный асинхронный ответ. У кого то может и есть реальный кейс, где это полезно, хз, не об этом я сейчас. А о том, что в связи с этим выплыло. Change Detection ангуляра основан на манки-патчах. библиотека zone.js. Когда первый раз про нее читал, вот прям как чувствовал, что даже если эта система будет абсолютно оттестирована и 100% безбажна, все равно где то найдется ситуация, где эта абстракция либо что то не покрывает, либо будет какая то концептуальная дыра. И я на такое наткнулся. Выбросив вышеозначенный rxjs, я стал писать на async/await. Асинхронный код намного приятнее и читабельнее. Но у него есть недостаток — сложно дебажить, потому что компилируется это либо в генераторы для es6, либо в state-machine для es5, и sourcemaps генерируются не лучшим образом, иногда брейкпоинты не ставятся вообще, иногда не на ту строку, на которую хочешь и т.д.
                                    И недавно я узнал, что оказывается V8 поддерживает async/await нативно. И хром и NodeJs. И я переключил typescript в es2017 для пробы. Дебажить стало супер-удобно, почти так же, как и синхронный код. Но обнаружилось то, о чем уже наверное можно догадаться. await срабатывает вне той зоны, в которой было начало функции. И zone.js в принципе никогда не сможет реализовать поддержку этого. Если конечно поддержку зон не внедрят прямо в js. И я искренне надеюсь что этого не будет.
                                    То что на антипаттерне основан какой то ui фреймворк, который умрет при следующем изменении моды, или просто с выходом новой версии, это как то плевать, но внедрять антипаттерны в язык это уже лютое зло.

                                    • 0
                                      >>И реально использующихся потоков в рабочих проектах я еще не встречал
                                      Реактивное программирование я еще использовал в 2009-2010 годах, то что оно еще живо — многое говорит. Другое дело, что перестроить мозги трудно (как это происходило между процедурным программированием->ООП->функциональным).
                                      • 0
                                        потоки удобны даже в HTTP запросах. Например, можно легко сделать повторные попытки запроса:
                                        this.http.post("api/endpoint").retry(3).subscribe(...)
                                        .
                                        Можно делать цепочки запросов, можно делать гонки запросов и т.п., и все декларативно и реактивно.

                                        • 0
                                          Наличие сахара для retry конечно неплохо, но в данном примере тоже потока нет, подписка будет вызвана единственный раз.
                                          Цепочки запросов на async/await пишутся лучше.
                                          И да, есть такой вопрос. Функция-подписка, передаваемая в subscribe представляет собой сайд-эффект. Это никак не противоречит тому, что все «декларативно и реактивно»?
                                          • 0
                                            Вообщем-то никто не мешает использовать yield для observable вместо await для промисов. Код в итоге точно такой же.
                                      • –1
                                        И еще один комент
                                        Если вам нравится действительно чистый код: Vue

                                        React+Redux это заведомо чистый код. В функциональном понимании — Pure.
                                        Код без состояния и сайд-эффектов. Состояние сдвигается в стор, сайд-эффекты соответственно в асинхронные сервисы.
                                        Что подразумевается под «действительно чистый», не совсем понятно, может ли он быть более чистым, чем то, что чисто по определению?
                                        • 0
                                          React+Redux это заведомо чистый код. В функциональном понимании — Pure.

                                          Ни язык, ни фреймворк не дают таких гарантий.


                                          А вообще там не pure, а clean.

                                          • –1
                                            А вообще там не pure, а clean.

                                            Как раз Pure, а не Clean. Хотя редакс — ни Pure, ни Clean.

                                            edit. Ох, простите, в статье действительно имеется ввиду Clean.
                                        • 0
                                          Есть мнение(не мое) в поддержку джейкыери для основы проекта — «Все библиотеки и фрайемворки уйдут в не бытиё, а jq останется». Насколько оно справедливо, покажет время, но пока почему-то у меня вызывает улыбку.
                                          • 0
                                            Да они все одинаковые в целом, выбирайте что больше нравится.
                                            • 0
                                              А почему среди всех вопросов в списке нет таких важных как:
                                              • какая работа с данными нужна нашему проекту
                                              • как быстро собирается разростатся проект
                                              • как много динамичных элементов в среднем вам надо на одной странице
                                              • для чего был задуман изначально тот или иной фреймворк


                                              Почему все сразу начинают с хайп проектов!?
                                              • 0
                                                Все эти вопросы тут в том или ином виде рассмотрены — про работу с данными есть секция про состояния и биндинги, про разрастание тоже прилично размазано по статье, да и в конце есть:
                                                Если ваше приложение имеет тенденцию разрастаться: Angular(или React)

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

                                                Что есть не хайп-проекты? Топ фреймворков приведен по ссылке в самом первом абзаце статьи. То, что тут нет популярных, но более узкоспециализированных вещей, типа ExtJS, d3.js, ну так речь тут и не о них.

                                                Ну а про сравнение фреймворков, поддерживаемых полутора гиками писать, очевидно никому не интересно.
                                                • –2
                                                  Потому что это хайповые фрейморки. :)
                                                  Кому не нужен хайп, тот использует jQuery.
                                                  • 0
                                                    jQuery — панацея?
                                                    • –1
                                                      А у вас болезнь какая-то? :)
                                                      От добра добра не ищут. :)
                                                      П.С.
                                                      Не судите строго. :)
                                                • +1
                                                  Не хочу ни с кем спорить, но попробовав все 3 вещи (правда не в реальных проектах), выбрал и сейчас изучаю Vue.js

                                                  Для меня важна работа из коробки, т.е. минимальное количество софта которое нужно установить и сконфигурировать чтобы начать проект. Также желательно как можно меньше зависимостей от кастомных решений.
                                                  Поэтому Angular мне не подходит из-за наличия TypeScript. (Да, писать на нём приятнее, но необходимость трансляции кода убивает все преимущества). Вернусь к этому вопросу, когда все современные браузеры будут поддерживать его из коробки.
                                                  Другой важный фактор, это удобные средства разработки (с подсветкой синтаксиса, подсказками и прочими плюшками). По этой причине не выбрал Реакт. Т.к. с моей точки зрения идея запихнуть всё в джаваскрипт — это плохая идея.
                                                  В этом плане компоненты Vue — просто идеальное решение. Все 3 части (HTML, JS, CSS) в одном файле и благодаря обёртками в HTML-теги с ними удобно работать.

                                                  Также благодаря простоте Vue будет проще для освоения новыми разрабочиками, а значит будет проще найти подходящих кандидатов. Опять-же это сугубо личное мнение, но может оно кому-нибудь поможет в выборе технологии.
                                                  • 0
                                                    Если есть некоторый запас терпения, то попробуйте Polymer. Я не работал с Vue. Но после всего, что видел — Polymer действительно крутая вещь. Вообще толком практически ничего лишнего, ни билд-тулов, ни зависимостей, ни своих велосипедов. Тоже при желании все в одном файле, но можно и разнести как хочется. У Vue как я понимаю все же есть дополнительные абстракции, все равно что-то куда то в JS компилится, Virtual DOM, прочие умные вещи. А Polymer — практически jQuery на стероидах, без его минусов(но пока со своими — кроссбраузерность- :().

                                                    А так, ставлю на него и готов терпеливо ждать, пока его перестанет колбасить.
                                                    • +4

                                                      Динамическая загрузка зависимостей — это очень медленно, поэтому для прода полимеры всегда вулканизируют. А это значит: билд-тулы, зависимости и прочие прелести.

                                                      • 0
                                                        а) на проде я не использовал, страшновато пока
                                                        б) медленно, когда их очень много, а это не всегда так
                                                        в) HTTP/2 можно настроить, по крайней мере это рекомендуют делать вместо вулканизации

                                                        И даже с вулканизацией есть разница — билдить под прод и не билдить во время разработки(билд тулы же во время разработки особо бесят), либо билдить всегда, потому что без билд-тулов не работает ничего.
                                                        • +2

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


                                                          http2 — не панацея, да и настраивать его — то ещё веселье.


                                                          Отлаживать лучше тот же код, что будет и на проде, так что лучше привыкать к билд-тулам во время разработки. А чем они вас так бесят? Вам же всё равно нужно локальный сервер запускать. Набрали npm start и работайте, а сервер сам всё соберёт по необходимости.

                                                          • 0
                                                            Ну лично я с продакшен кодом напрямую не работаю, кроме как когда надо чинить prod-specific проблемы, как то не фанат, и с тестами все неплохо.

                                                            Бесят собсно компиляцией, чем дальше в лес, тем дольше, для ангуляра до 20 секунд на крупных проектах ожидание бывает, для реакта тоже долго. Как я понял и для Vue тоже самое будет. Также бесят такой штукой как «еще одна вещь, которую надо знать». Ну ок, я уже со всеми детальками этого механизма разобрался, но это отняло много времени и осадочек остался.

                                                            Про локальный сервер туда же — разница между ng serve и polymer serve в том, что в первом случае на каждый чих что-то происходит, а во втором — ничего не происходит. Ощущение как от написания jquery-плагинов.

                                                            С HTTP2 пока ковыряюсь и надеюсь в какой-то момент родить статью о его настройке под этот конкретный кейс. С учетом получаемых плюшек, не так и много там настраивать.
                                                            • –1

                                                              Ангуляр не просто транслирует код, но и проверяет его на корректность благодаря typescript. Просто трансляция (как в случае всяких vue/react) проходит налету. Собственно и для TS можно выключить проверку типов и компиляция будет летать. У нас весь $mol на горячую билдится примерно 6 секунд (с проверкой корректности, конечно). Хочу в ближайшее время попробовать одну идею с инкрементальной компиляцией, которая теоретически должна сократить время горячего билда на порядок без потери проверки корректности.

                                                              • 0
                                                                Все это так. Неплохо бы иметь такое опционально и в том же Polymer, но именно что опционально. Ведь даже после отключения всего что можно в Angular, меньше 1-2 секунд компилиться он не будет.

                                                                В React можно обойтись без билд-тулов, но(не не тестил) есть серьезные сомнения, что производительность от трансляции на лету не загнется даже на среднего размера приложении(скажем, средненький шоп). В Polymer в этом плане проще так как там транслировать толком нечего.
                                                                • 0

                                                                  Ну, 1-2 секунды — вполне приемлемая скорость. Особенно в свете того, что крупное приложение на Ангуляре только запускаться будет 5 секунд :-D

                                                                  • 0
                                                                    В коде можно такого написать, что и чистый JS будет запускаться пару минут
                                                                    • 0

                                                                      В одних фреймворках это может получиться непреднамеренно, а в других — надо специально постараться.

                                                                      • 0
                                                                        AOT решит проблему в случае с ангуларом.
                                                                        • 0

                                                                          Не решит. Ну пример из жизни: запилили ребята табличку на Ангуляре. Набросали тестовых данных, потестили, всё ок. Выкатили. В течении месяца объём реальных данных вырос — опа страница открывается 10 секунд. И это в свете того, что интересуют как правило несколько верхних записей.

                                                                          • 0
                                                                            >>cтраница открывается 10 секунд
                                                                            Эм, я что-то не понимаю…
                                                                            Причем тут данные и открытие страницы.
                                                                            В моих SPA обычно происходит, так.
                                                                            Запускается приложение-> Отправляем запрос на данные->Показываем пользователю, что выполняется AJX запрос-> Данные приходят->Мы их отображаем.
                                                                            При таком раскладе, от количества данных ну никак не может зависеть время старта приложения.
                                                                            • 0

                                                                              А пользователю какой прок от того, что он вместо браузерного крутящегося колёсика видит ваше? Он пришёл к вам за данными.

                                                                              • 0
                                                                                >>А пользователю
                                                                                Так получается дело не в старте приложения, а в в большом времени получения/рендерига данных.
                                                                                В случае если Ajax запросы проходят долго, то дело вовсе не с ангуларом.
                                                                                А вот если отрисовывается долго, то нужно смотреть, сколько там данных и каковы шаблоны отображения. Но у меня проблем с rendering не было.
                                                                                Вангую — не был включен Prod режим у angular.
                                                                                • 0

                                                                                  Я же написал: данных было много — таблица долго рендерилась. Это первый ангуляр, какие ещё режимы? :-)

                                                                                  • 0
                                                                                    В ветке был упомянут TypeScript вот я и решил, что это про Angular2+
                                                                  • 0

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


                                                                    всмысле react-hot-loader, а не обычный HMR

                                                                    • 0
                                                                      Это лучше, но сравнению моментальностью в Polymer разница все равно существенная. Опять же, это лишнее место, где что-то может сломаться. Я стараюсь число таких мест сводить к минимуму.
                                                        • 0
                                                          А я как раз в polymer разочаровался, в виду выясненных багов с dom-repeat, и фризы при реализации конкретного проекта на нем. Позже весь проект переписал на vue(дабы вся логика была зашита в редакс), и теперь радуюсь — данные проблемы производительности ушли. Но хотя полимер по своему хорош, но vue все таки лучше.
                                                          • 0
                                                            А можете, хотя бы в двух словах по-подробнее, или может есть линки на ишуи?
                                                            Redux при желании можно прикрутить без проблем и к Polymer, хотя вы явно в курсе, у вас статья про это есть.
                                                            • +1
                                                              >>Redux при желании можно прикрутить без проблем и к Polymer, хотя вы явно в курсе, у вас статья про это есть.
                                                              А думаете почему я так относительно быстро перешел на vue? Потому что бизнес-логика была уже реализована, и оставалось обернуть ее во vue.

                                                              А так подробности здесь.
                                                              • 0

                                                                Вот чем мне нравится подход "берём библиотеки и склеиваем их" (вариант "берём склеенные кем-то библиотеки"), что всегда можно малой кровью заменить одну библиотеку на другую. С огромными фреймворками обычно такое не проходит, и даже если формально он компонентный, то очень часто ко мпоненты сильно связаны, типа компонент формы и компонент валидации.

                                                                • 0

                                                                  А в чём проблема подменить компонент валидации/формы на адаптер к другой библиотеке?

                                                      • –1
                                                        Ага, выбрал — Ractive и нет проблем с выбором фреймверка))))
                                                        • –1
                                                          Но у него же вообще нет преимушеств перед хайповыми фреймворками.
                                                          • –1
                                                            С чего вы взяли? ))) Vue вообще изначально с него слизывали, что сильно заметно на базовых примерах. После того как попробуешь Ractive проблемы возникающие при использовании React и даже Vue (при всем моем уважении) заставляют на него вернуться. Сколько не писал на других фреймверках, каждый раз ловлю себя на мысли, зачем я так мучаюсь.
                                                            • +1

                                                              А в чем основное преимущество?

                                                              • 0
                                                                Боюсь что дать ответ на столь объемлющий вопрос в рамках комментария мне будет не просто)) Если краткой — он просто работает так, как от него ожидается, без лишней «магии», «танцев с бубнами» и других шаманств, чего часто не хватает другим фреймверкам. При этом он умеет все тоже самое, что и остальные и даже больше. И когда дело доходит не до примеров из документации, а до реальных, не всегда тривиальных проблем, я всегда нахожу встроенное решение в Ractive, без костылей и установки дополнительных модулей.

                                                                На ходу более конкретно сложно придумать (можем обсудить более обстоятельно в личке), но например нам нужно прикрутить один из сотен тысяч крутых jquery-плагинов в нашему не менее крутому реактивному приложению, но вот незадача плагин меняет DOM, а реактивный фреймверк об это и не в курсе и наоборот. Задача ясна — нужно засинкать состояние плагина и реактивных данных. Реализации можно осуществить, с тем или иным успехом, на любом фреймверке, но если в Vue и React, нам понадобиться обернуть Jquery плагин в целый компонент, со всеми вытекающими (сразу представляем форму с 20-ю кастомными инпут полями, каждый из которых это компонент, внутри которого обернут jqeury плагин), то в Ractive это всего то написать одну функцию. Одну функцию, Карл!

                                                                Называется это Декоратором и внутри этой функции можно спокойненько сотворить любые нужные действия. При это Ractive заботливо пробросит внутрь не только нужную ноду, но еще и необходимые реактивные переменные, любые параметры, которые потребуются и текущий инстанс самого Ractive (точнее декоратор будет выполнен в его контексте). Выглядеть это будет примерно так (юзаем webpack):

                                                                // Пример декоратора
                                                                module.exports = (node, date) => {
                                                                  const $$ = this, 
                                                                        $el = $(node);
                                                                
                                                                  $el.datepicker({
                                                                    onSelect: (val) => {
                                                                      $$.fire('datepicker:selected', val); // проксируем любые ивенты, которые поддерживает сам плагин
                                                                    }
                                                                  });
                                                                
                                                                  return {
                                                                	teardown: () => {
                                                                		$el.datepicker('destroy'); // не забываем подчистить плагин когда он будет не нужен
                                                                	},
                                                                    update: (date) => {
                                                                		$el.datepicker('setDate', date);
                                                                    }
                                                                  };
                                                                
                                                                }
                                                                
                                                                // Регистрация в инстансе
                                                                const $$ = new Ractive({
                                                                    data: {
                                                                    	date: Date.now()
                                                                  	},
                                                                    decorators: {
                                                                		datepicker: require('./decorators/datepicker')
                                                                  	}
                                                                });
                                                                

                                                                // В шаблоне, так как включен twoway-binding значение date будет изменяться автоматом
                                                                <input as-datepicker="date" value="{{ date }}">
                                                                  

                                                                // Так тоже будет работать и плагин корректно отобразит установленную вручную дату
                                                                $$.set('date', Date.now());
                                                                


                                                                Можно выключить двойное связывание для всего инстанса или даже для конкретного инпута и использовать проксируемый ивент:
                                                                // Выключаем twoway-binding
                                                                <input as-datepicker="date"  value="{{ date }}" twoway="false">
                                                                  

                                                                // слушаем ивент и изменяем значение реактивной переменной в функции makeSomeNoice
                                                                $$.on('datepicker:selected', makeSomeNoice);
                                                                


                                                                Пример не самый сложный, но думаю раскрывает возможности.

                                                                Еще пример — хотим писать результат асинхронной операции прямо в реактивную переменную, со всеми вытекающими плюшками (напрямую так делать не хорошо, но мы все равно хотим), чтобы можно было сделать примерно так:
                                                                $$.set('products', $.getJSON('/api/products'));
                                                                

                                                                Нет проблем, берем или пишем сами (20 строк кода) Promise Adaptor и делаем.

                                                                // Регистрация в инстансе
                                                                const $$ = new Ractive({
                                                                  data: {
                                                                    products: []
                                                                  },
                                                                  adapt: [
                                                                    require('./adaptors/promise')
                                                                  ]
                                                                });
                                                                

                                                                И ведь это никакой не мега-магический-компонент, или дополнительный модуль аля react-{whatever}, это обычный js объект с 2-мя функциями. Все.

                                                                Или вот, еще двойное связывание. В React его нет, в Vue ужасный синтаксис:
                                                                // vue style
                                                                <select v-model="selected">
                                                                  <option v-for="option in options" v-bind:value="option.value">
                                                                    {{ option.text }}
                                                                  </option>
                                                                </select>
                                                                  
                                                                // ractive style 
                                                                <select value="{{ selected }}">
                                                                    {{#options}}
                                                                    <option value="{{ .value }}">{{ .text }}</option>
                                                                    {{/options}}
                                                                </select>
                                                                

                                                                Да и вообще увлеченность Vue ангуляроскими дерективами это капец. Иной раз такие длинющие выражения получаются в тегах. Про React вообще молчу, там и шаблонов то нет, поэтому верстальщики (да да, такие люди еще есть) страдают неимоверно, когда работают с JSX. А когда страдает верстальщик, он заставляет страдать программиста. Проверено на собственном опыте.

                                                                А вы что используете в работе? Не хотите устроить пари на эту тему?
                                                                • 0

                                                                  Мм, ну вы же все-равно пишете декоратор, а потом для него аттрибут. Какая тогда разница, если можно написать компонент с таким же пробросом всего во все стороны, а потом вместо аттрибута просто отрендерить его?


                                                                  Я просто не сторонник подмешивания логики через аттрибуты, слишком это по-ангуляровски. По мне так если есть какая-то конечная логика, она должна сидеть в конечном компоненте. А смешивание должно идти через композиции в компоненте, а не добавлением вороха аттрибутных директив в разметке.


                                                                  Но по поводу плагинов jquery, наверное, можно согласиться. Хотя я уже давно ими н пользуюсь и не припомню, чтобы мне какой-то из них понадобился.


                                                                  Про двойное связывание уже немало голосовых связок порвано. Я тут противник.


                                                                  По поводу рыданий верстальщиков от JSX — вот и нет :) Проверено на собственном опыте.


                                                                  А вы что используете в работе?

                                                                  В основном Реакт, как вы уже наверное догадались. Но есть оба (1 и 4) ангуляра, но они беспросветное днище.

                                                                  • 0
                                                                    Какая тогда разница, если можно написать компонент с таким же пробросом всего во все стороны, а потом вместо аттрибута просто отрендерить его?

                                                                    Потому что компонент это как правило «дороже» чем вызов функции. Не зря же я упомянул про форму с 20ю инпутами. Компонент это целый механизм и он не нужен для такой мелкой задачи как синхронизировать две либы.

                                                                    Я просто не сторонник подмешивания логики через аттрибуты, слишком это по-ангуляровски. По мне так если есть какая-то конечная логика, она должна сидеть в конечном компоненте.

                                                                    Ну как сказать по-ангуляровски. Вы же наверное не раз в жизни делали вот так:
                                                                    <input class="datepicker">
                                                                    

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

                                                                    С теоритической точки зрения верно. Однако на практике могут быть на первый взгляд не значительные особенности использования в каждом конкретном случае, которые либо придется разруливать внутри компонента (лишние условия и тп), либо писать его вариации для каждого случая. Простой пример с twoway:
                                                                    <date-picker></date-picker> // нужно toway
                                                                    <date-picker></date-picker> // не нужно toway
                                                                    

                                                                    Как будем решать? Вероятно вводим prop, но тогда в чем разница:
                                                                    <date-picker twoway="false"></date-picker>
                                                                    <input twoway="false">
                                                                    

                                                                    Про двойное связывание уже немало голосовых связок порвано. Я тут противник.

                                                                    Нет проблем, я также признаю что это не безопасная вещь и ее нужно использовать осторожно. Поэтому Ractive позволяет ее отключить как на уровне компонента, так и для каждого конкретного поля:
                                                                    <input twoway="false">
                                                                    

                                                                    const $$ = new Ractive({
                                                                      twoway: false,
                                                                      lazy: true // еще одна прикольная опция, которая работает как для всего инстанса, так и для конкретного инпута
                                                                    });
                                                                    

                                                                    По поводу рыданий верстальщиков от JSX — вот и нет :) Проверено на собственном опыте.

                                                                    Посмотрел бы я на верстальщиков, которым удобно работать с мелкими кусочками html-подобного «текста» внутри js, вместо нормального html файла без лишнего «шума» и с хорошей подсветкой )) Реально, таких надо по ТВ показывать, у Малахова, чтобы все о них знали. )))
                                                                    В основном Реакт, как вы уже наверное догадались. Но есть оба (1 и 4) ангуляра, но они беспросветное днище.

                                                                    Да, на 1-м писал, утомил. 4(2) даже пробовать не стал. На React тоже писал, но JSX и микро-компонентный подход, а также сложности с конфигурированием (ну чтобы работало нормально) не прижились у меня. Слишком много испытывал сложностей со слишком простыми вещами. Не могу писать на фреймверке, где иной раз приходится один компонент оборачивать в другой, чтобы решать примитивную задачу. Но это мое имхо, на вкус и цвет…

                                                                    • +1
                                                                      Потому что компонент это как правило «дороже» чем вызов функции.

                                                                      Компонент тоже может быть функцией — SFC. Ну и что, что сначала через vdom все прогоняется, ractive в кишках с этими декораторами тоже без дела не сидит. Так что совсем без разницы. Ну и на сколько там это все дороже? Спички


                                                                      Вы же наверное не раз в жизни делали вот так

                                                                      Ну было дело, где-то в универах. Сейчас я за такое больно по рукам бью. Класс отвечает за внешний вид.


                                                                      Однако на практике могут быть на первый взгляд не значительные особенности использования в каждом конкретном случае, которые либо придется разруливать внутри компонента (лишние условия и тп), либо писать его вариации для каждого случая

                                                                      Это не совсем так, я же не про атрибуты, а про логику сбоку, которая цепляется к компоненту, видя на нем этот атрибут. А если у вас два, три, десять таких атрибутов и они между собой конфликтуют? Привет angularjs и priority. В случае композиции HOC вы явно указываете порядок применения и всегда порождаете новый компонент.


                                                                      Реально, таких надо по ТВ показывать, у Малахова, чтобы все о них знали. )))

                                                                      Как там говорилось, "Видишь суслика?" :) Ну реально, целая команда сидит довольная. А раньше на hbs и первом ангуляре колбасили, сейчас нарадоваться не могут.


                                                                      один компонент оборачивать в другой, чтобы решать примитивную задачу

                                                                      Так это ж прелесть композиции. Вы собираете решение из примитивных переиспользуемых кусочков.

                                                                      • 0
                                                                        Компонент тоже может быть функцией — SFC. Ну и что, что сначала через vdom все прогоняется, ractive в кишках с этими декораторами тоже без дела не сидит. Так что совсем без разницы. Ну и на сколько там это все дороже? Спички

                                                                        Не думаю что stateless компонент это хороший пример в этом случае, а если писать полноценный компонент он будет «дороже», а уж на спички или нет, это надо смотреть. Опять же форма из 20-ти инпутов может превратиться в 100 не импутов, а чего-то сложнее. Тогда уже и на коробок наберется. Однако основная идея в другом — суть задачи лишь в том, что 2 либы друг с другом не дружат по умолчанию, ибо разные подходы и вендоры. Дружить их с помощью компонентов по меньшей мере странно. Компонент, в моем понимании, являются строительным материалом для приложения и ни как уж не должен служить таким мелким, чисто утилитарным целям. Однако дело ваше. Как я уже говорил, React стремиться к микро-компонентам, лично мне это претит.

                                                                        Ну было дело, где-то в универах.

                                                                        Видимо не давно вы универ закончили.))) Когда я заканчивал jquery был как раз на коне, а вместе с ним куча плагинов которые так и работали. Да и Bootstrap еще не умер и там такое сплошь и рядом.
                                                                        Сейчас я за такое больно по рукам бью. Класс отвечает за внешний вид.

                                                                        Вот именно, поэтому так делать нельзя. А декораторы как раз созданы для этого, так что натыкаясь на такую дерективу в шаблоне сразу понятно, что происходит.
                                                                        Это не совсем так, я же не про атрибуты, а про логику сбоку, которая цепляется к компоненту, видя на нем этот атрибут. А если у вас два, три, десять таких атрибутов и они между собой конфликтуют?

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

                                                                        Один мой друг показывал проект на React где он обернул вообще все в компоненты. У него даже иконка, которая ничего не умела делать была компонентом. Да композиция вероятно хорошая получилась, но для меня это ничто иное как components-hell (оцените иронию ;) ) Лично я не пытаюсь все запихнуть в компоненты, на мой извишняя композиция излишне усложняет код. Также я не пишу «сверх универсальные» компоненты, которые можно включить в любые другие компоненты. Как правило такое сделать не получается, либо получается, но не слишком прямо. Может скажу маргинальную вещь, но для меня компонент — это аналог класса, т.е. штука которую можно инстанциировать с разными входными параметрами и которая требует некоторой степени инкапсуляции (например решает явно обособленную задачу). Все = компонент, это не мой подход.

                                                                        • 0
                                                                          Опять же форма из 20-ти инпутов может превратиться в 100 не импутов, а чего-то сложнее.

                                                                          Так может стоит ее побить на подкомпоненты (филдсеты например) вместо портянки?


                                                                          Компонент, в моем понимании, являются строительным материалом для приложения и ни как уж не должен служить таким мелким, чисто утилитарным целям.

                                                                          Компонент — это логическая единица, строительный блок в рамках приложения. А то, что у него в кишках jquery плагин — это детали реализации. Ну тут действительно, чего спорить.


                                                                          Видимо не давно вы универ закончили.))) Когда я заканчивал jquery был как раз на коне, а вместе с ним куча плагинов которые так и работали. Да и Bootstrap еще не умер и там такое сплошь и рядом.

                                                                          jQuery тут вообще не причем. Такой фигней и до нее занимались, навешивание логики через селекторы по классам, атрибутам… Помним, скорбим. Ну и то, что написана куча говна плагинов и бутстрапов — еще не говорит, о том, что это правильно.


                                                                          А декораторы как раз созданы для этого, так что натыкаясь на такую дерективу в шаблоне сразу понятно, что происходит.

                                                                          Вообще не понятно, вам нужно помнить, что ваша "директива" вот так работает на инпуте, вот этак на кнопке, а на таблице вообще не работает. Вместо того, чтобы зашить эту логику в компоненте и забыть.


                                                                          Не согласен про логику сбоку — это всего лишь связка между двуми либами.

                                                                          Это слишком низкоуровнево. То, что часть логики лежит в либе, вообще знать не нужно.


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

                                                                          Крайне странный подход. Даже спорить не буду


                                                                          У него даже иконка, которая ничего не умела делать была компонентом.

                                                                          Разве иконка — это не компонент?


                                                                          Лично я не пытаюсь все запихнуть в компоненты, на мой извишняя композиция излишне усложняет код.

                                                                          Как раз упрощает. Интерфейс строится из компонентов, слой за слоем, от простых к сложным. Вместо лапши из атрибутов и копипасты маркапа для спорных библиотек.


                                                                          Также я не пишу «сверх универсальные» компоненты, которые можно включить в любые другие компоненты. Как правило такое сделать не получается, либо получается, но не слишком прямо.

                                                                          Вот и зря, теряете в переиспользуемости, либо проекты такие не попадались. Все там получается, вот только прямо — действительно только с реактом.


                                                                          (например решает явно обособленную задачу)

                                                                          Разве все не решает явно обособленную задачу?




                                                                          В общем, что тут. Преимущества Ractive особо-то не описаны, только лишь низкоуровневые утилики для связки с жквери. Но, все-равно, спасибо за развернутые ответы.

                                                                          • 0
                                                                            Так может стоит ее побить на подкомпоненты (филдсеты например) вместо портянки?

                                                                            А если не получится? Зачем вообще связку 2-х либ делать компонентом, я понять не могу?
                                                                            Компонент — это логическая единица, строительный блок в рамках приложения.

                                                                            Именно так, но если это строительная единица, причем тут jquery плагин, который просто делает ввод значение в инпут более удобным? Если бы в браузере был такой инпут встроен, вы бы его тоже в компонент обернули? Какая-такая бизнес-логика в нем присутствует, что требует писать компонент, который, как вы написали, есть строительная единица? Да блин, он всего лишь позволяет пользователю не вписывать «20/09/2017» в поле текстом и все!
                                                                            Ну и то, что написана куча говна плагинов и бутстрапов — еще не говорит, о том, что это правильно.

                                                                            Это не правильно, да. Но в целом конуепция деректив не плоха, если конечно не начинать делать абсолютно все с их помощью как это делают в Angular и, к сожалению, в Vue.
                                                                            Вообще не понятно, вам нужно помнить, что ваша «директива» вот так работает на инпуте, вот этак на кнопке, а на таблице вообще не работает.

                                                                            Вообще не надо помнить, читайте код:
                                                                            <input as-datepicker>
                                                                            

                                                                            Убираем <>, «input as datepicker», тут даже верстальщик догадается )))
                                                                            Вместо того, чтобы зашить эту логику в компоненте и забыть.

                                                                            А помнить что у вас в компоненте, как он принимает параметры, куда записывает значение вам не нужно что ли? Ну да. Смотрим взглядом стороннего наблюдателя:
                                                                            <my-datepicker></my-datepicker> <!-- что это вообще? куда значение пишется? как его получить? лезем в компонент смотреть -->
                                                                            <input as-datepicker> <!-- это инпут с виджетом выбора даты. значение можно получить через node.value -->
                                                                            

                                                                            Это слишком низкоуровнево. То, что часть логики лежит в либе, вообще знать не нужно.

                                                                            Так и я о том. Декораторы позволяют написать один раз связку с другой либой и забыть. А само приложение мы пишем на компонентах и решаем свои бизнес-задачи с их помощью.
                                                                            Разве иконка — это не компонент?

                                                                            Тяга к микро-компонентному подходу на лицо. React к этому склоняет, это факт.
                                                                            Как раз упрощает. Интерфейс строится из компонентов, слой за слоем, от простых к сложным. Вместо лапши из атрибутов и копипасты маркапа для спорных библиотек.

                                                                            Крайне странный подход. Даже спорить не буду, но подобного кода повидал не мало и он всегда сложее для понимания и правок.

                                                                            Вот и зря, теряете в переиспользуемости, либо проекты такие не попадались. Все там получается, вот только прямо — действительно только с реактом.

                                                                            Ну ну, а вы заметили что разговор перешел в разряд «веры», так может все же пари? Там глядишь и вы свои «сверх универсальные» компоненты покажете, ну и я смогу описать преимущества точнее. Было бы интересно))

                                                                            • 0
                                                                              А если не получится? Зачем вообще связку 2-х либ делать компонентом, я понять не могу?

                                                                              А что может не получиться? И где вообще связь между огромной формой и либами?


                                                                              Именно так, но если это строительная единица, причем тут jquery плагин, который просто делает ввод значение в инпут более удобным? Если бы в браузере был такой инпут встроен, вы бы его тоже в компонент обернули?

                                                                              Я же навешивую доп.логику на стандартный браузерный инпут? Значит, компонент.


                                                                              Какая-такая бизнес-логика в нем присутствует, что требует писать компонент, который, как вы написали, есть строительная единица?

                                                                              Да вот такая:


                                                                              Да блин, он всего лишь позволяет пользователю не вписывать «20/09/2017» в поле текстом и все!

                                                                              Я не любитель полумер. Это что значит, если логики кот наплакал, так и фиг с ней? Компонент можно не выделять?


                                                                              <input as-datepicker/>

                                                                              <input as-datepicker/>, <input type="email" as-datepicker/>, <input as-datepicker as-colorpicker/>, <textarea as-datepicker/> да полно примеров


                                                                              Декораторы позволяют написать один раз связку с другой либой и забыть.

                                                                              Чем это отличается от компонентов?


                                                                              Тяга к микро-компонентному подходу на лицо. React к этому склоняет, это факт.

                                                                              Эээ, как будто в этом что-то есть плохое. Как переиспользуемые куски кода уезжают в функции, так и куски разметки уезжают в компоненты. Еще и с логикой заинкапсулированной, если она есть. К этому склоняет не только Реакт, к этому склоняет вообще весь фронтенд на данный момент. Видимо только Ractive не склоняет =(


                                                                              Ну ну, а вы заметили что разговор перешел в разряд «веры»

                                                                              Вера, не вера, не в этом дело. Я вас спросил про преимущества изначально. Преимуществ, не увидел, к сожалению.


                                                                              так может все же пари? Там глядишь и вы свои «сверх универсальные» компоненты покажете, ну и я смогу описать преимущества точнее. Было бы интересно))

                                                                              Так давайте, я ж не против.

                                                                              • 0
                                                                                А что может не получиться? И где вообще связь между огромной формой и либами?

                                                                                Ну например по какой логике вы обернете 101 элемент в сеты? по 50 и 51 ?)))) Связь в том, что 101 компонент, со всей встроенной мишурой, life-cycle и тп априори «дороже» чем 101 вызов функции.
                                                                                Я же навешивую доп.логику на стандартный браузерный инпут? Значит, компонент.

                                                                                Я же вам пишу, что данный инпут будет стандартным, без jquery плагина. Прям бац и datepicker встроенный в браузер. Будем в компонент оборачивать?
                                                                                Я не любитель полумер. Это что значит, если логики кот наплакал, так и фиг с ней? Компонент можно не выделять?

                                                                                А в чем логика то? Инпут как принимал текстовое значение так и принимает. Вся доп. логика внутри уже обособленного компонента — jquery плагин называется. Какая такая логика будет в вашем компаненте-обертке? Только логика связывания плагина и реактивных данных, но это же не логика приложения, это просто низкоуровневая задача продиктованная тем, что плагин не умеет реактивность. Зачем тут компонент, который есть строительный материал приложения, а значит должен заниматься бизнес-логикой, а не мелкими утилитарными задачами.

                                                                                <input as-datepicker/>, <input type=«email» as-datepicker/>, <input as-datepicker as-colorpicker/>, <textarea as-datepicker/> да полно примеров

                                                                                Это что за бред? Зачем поле email делать пикером даты? Притянуто за уши не понятно к чему вообще.
                                                                                Чем это отличается от компонентов?

                                                                                А разве компонент — это строительный блок вашего приложения? Разве вы его создаете не чтобы решать задачи приложения? Разве связка с плагином jquery является задачей вашего приложения?
                                                                                Эээ, как будто в этом что-то есть плохое. Как переиспользуемые куски кода уезжают в функции, так и куски разметки уезжают в компоненты. Еще и с логикой заинкапсулированной, если она есть. К этому склоняет не только Реакт, к этому склоняет вообще весь фронтенд на данный момент. Видимо только Ractive не склоняет =(

                                                                                Не правда))) Только React (и его клоны) склоняют к микро-компонентному подходу. Ни Angular, ни Vue, ни Ractive.
                                                                                Вера, не вера, не в этом дело. Я вас спросил про преимущества изначально. Преимуществ, не увидел, к сожалению.

                                                                                Так давайте, я ж не против.

                                                                                Раз не увидели, давайте тогда посмотрим на ваш код, в реализации тех же задач:
                                                                                1. Интегрировать jquery плагин (любую другую dom либу)
                                                                                2. Зареактивить промис (любой другой класс)
                                                                                3. Отобразить select и обновить значение при изменение значения select

                                                                                go?
                                                                                • 0
                                                                                  Ну например по какой логике вы обернете 101 элемент в сеты? по 50 и 51 ?))))

                                                                                  Семантически.


                                                                                  Связь в том, что 101 компонент, со всей встроенной мишурой, life-cycle и тп априори «дороже» чем 101 вызов функции.

                                                                                  А вы замеряли? Инициализацию шаблона ractive, прогон по этим аттрибутам? Я не вижу смысла гоняться с микробенчмарками, так что спор тут бесполезен.


                                                                                  Я же вам пишу, что данный инпут будет стандартным, без jquery плагина. Прям бац и datepicker встроенный в браузер. Будем в компонент оборачивать?

                                                                                  99.9...% навороченных браузерных инпутов (те, которые бац и дейтпикер, бац и колорпикер и т.п.) непригодны к использованию, так что, да, оборачивать. Были бы они нормальные, не оборачивал бы.


                                                                                  jquery плагин называется

                                                                                  Это не компонент :) это манкипатчинг браузерного инпута в рантайме. Нет уж :)


                                                                                  а не мелкими утилитарными задачами.

                                                                                  А зачем делить на компоненты и плагины, когда можно просто использовать компоненты и забыть уже jquery.


                                                                                  Это что за бред? Зачем поле email делать пикером даты? Притянуто за уши не понятно к чему вообще.

                                                                                  Ой не бред, и, нет, не притянуто. Это узкий случай и просто пример. В большее общем случае, коих тысячи, вам нужно помнить что вот это с этим сочетается, а это нет. Когда можно просто использовать самодостаточный компонент. Как вы с вашими глобальным "декораторами", которые являются обычными директивами из ng1, сделаете разное поведение на разных базовых контролах? На кнопке одно, на инпуте другое? Флагом внутри декоратора? Ну привет, OCP.


                                                                                  А разве компонент — это строительный блок вашего приложения? Разве вы его создаете не чтобы решать задачи приложения? Разве связка с плагином jquery является задачей вашего приложения?

                                                                                  Нет, связка с jquery — не является. Задача приложения лежит на другом уровне абстракции, нежели связка с плагинчиками. Даже если они есть (было что-то, wysiwyg вроде), это все спрятано глубоко-глубоко в компоненте, у которого свой интерфейс, никак не завязанный на подключенную внутри либу.


                                                                                  Не правда))) Только React (и его клоны) склоняют к микро-компонентному подходу. Ни Angular, ни Vue

                                                                                  Аххахха, что?? :D


                                                                                  Интегрировать jquery плагин (любую другую dom либу)

                                                                                  type Props = {
                                                                                      onChange: (value: string) => any,
                                                                                      value: string
                                                                                  };
                                                                                  
                                                                                  class Wrapper extends Component<Props> {
                                                                                      private el: Element;
                                                                                      private plugin: any;
                                                                                  
                                                                                      componentDidMount() {
                                                                                          this.plugin = initPlugin(findDOMNode(this.el));
                                                                                          this.plugin.onChange(this.props.onChange);
                                                                                      }
                                                                                  
                                                                                      componentWillUnmount() {
                                                                                          this.plugin.destroy();
                                                                                      }
                                                                                  
                                                                                      componentWillReceiveProps(props: Props) {
                                                                                          this.plugin.setValue(props.value);
                                                                                          if (this.props.onChange !== props.onChange) {
                                                                                              this.plugin.resetOnChange(props.onChange);
                                                                                          }