Angular, React, Vue как самые популярные в настоящее время фреймворки JavaScript, здесь мы обсуждаем только Angular 1.x, Angular 2/4, React 15+ (Redux) и Vue 2+. Нет Angular 3, если вы раньше не замечали.

Клиентская сторона - это поле битвы

За последние 6–8 лет Restful API был принят в качестве одного из стандартных веб-интерфейсов для большинства веб-приложений, архитектор решения может просто добавить REST API поверх существующего веб-уровня или бизнес-уровня, чтобы предоставить REST API и поддерживать несколько клиентских устройств. . Таким образом, разработчики могут продолжать разрабатывать или поддерживать систему с помощью своего любимого языка программирования, фреймворка или технических стеков.

Напротив, на стороне клиента это совсем другая история: за последние 10 лет появилось множество различных фреймворков JavaScript. Хорошо иметь больше возможностей, но это кошмар для веб-разработчиков, которые работают на таком поле битвы, потому что им нужно попробовать много разных вещей, чтобы принять решение, особенно когда график проекта плотный, это заставляет ведущий или архитектор весьма подчеркнуты. Что-то становится намного хуже, когда команда разработчиков пытается принять новую структуру для нового проекта, нелегко решить, какой фреймворк нам следует выбрать.

Не забывайте, что есть еще один большой риск, связанный с внедрением нового языка программирования (ES 6 или Typescript) с новым фреймворком, а также с новым инструментом разработки, сборки и тестирования, если у команды недостаточно навыков или опыта. Как архитектор решений, они должны продумать это для команды разработчиков, а также подумать, действительно ли команда сможет быстро это решить. Вот почему мы должны сравнить эти структуры здесь, прежде чем мы примем решение.

Производительность не является приоритетным или решающим критерием при выборе платформы

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

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

Отличия этих фреймворков

Давайте посмотрим на фреймворки и перечислим различия между ними.

Базовые технические наборы

Крутые вещи - не всегда лучшее

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

Язык программирования по-прежнему является препятствием

Если нам нужно использовать новый язык программирования, мы должны провести оценку с существующей командой разработчиков. Даже ES6 или TypeScript (TS) заявляют, что они совместимы с Vanilla JS, но когда вы начинаете изучать новый фреймворк или образец проекта, которые кодируются с помощью ES6 или TS, это все равно сбивает вас с толку, если вы не знакомы с таким синтаксисом. . Это существенно повлияет на эффективность изучения нового фреймворка. Так что всегда есть кривая обучения, которую мы не можем игнорировать, чтобы кодировать что-то на новом языке программирования.

Кто-то жалуется, что все эти JS-фреймворки делают процесс сборки намного сложнее, чем старые веб-фреймворки, из-за нового языка программирования. Это действительно важно? Короткий ответ - да, но мы не будем здесь подробно обсуждать преимущества. Если ваша команда имеет опыт работы с .Net Web Form или Java MVC, для команды было бы круто выбрать ES6 или TypeScript и платформу на основе компонентов, не говоря уже о новых инструментах сборки и тестирования.

Неудивительно, что некоторые команды .Net испытывали трудности с интеграцией стека Node в Visual Studio, особенно когда члены команды не имели опыта работы с Node.js. Поэтому нам нужна вся команда, чтобы обсудить трудности, прежде чем мы примем новую технологию и фреймворк. Полезно убедиться, что команда придерживается того же мнения, а также важно спланировать наше обучение и решить, как шаг за шагом преобразовать команду разработчиков.

С чего начать

Для команды, которая поставляется с веб-формой, с фоном Vanilla JS, мы можем начать с Angular 1.x (до 1.4) на некоторых небольших проектах, или мы можем создать что-то обучающий проект, потому что шаблон MVC очень похож на их предыдущий опыт программирования.

Еще одна вещь, о которой я должен упомянуть, это то, что приложение Angular 1.x может быть создано без каких-либо инструментов Node.js, таких как Gulp, Grunt, Webpack и т. Д. Это дает команде возможность принять его без предварительного опыта. Кроме того, это дает команде некоторый буфер для организации обучения по использованию инструментов Node.js в будущем.

Команда, имеющая опыт работы с Angular 1.2 ~ 1.4, может выбрать более позднюю версию Angular 1.x, например. Angular 1.5+, и они могут начать преобразование шаблона кодирования из MVC в компонентный. После этого, если команда планирует перейти на Angular 2/4, лучше пройти обучение TypeScript. На мой взгляд, пока что экосистема для Angular 2/4 все еще находится в стадии разработки. Использовать Angular 2/4 для создания реальной продукции немного рискованно. Есть довольно много подводных камней, с которыми вам придется разобраться самостоятельно.

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

Поддержка библиотеки адаптивного пользовательского интерфейса

Чтобы создать реальное приложение, нам нужно интегрировать некоторые популярные адаптивные библиотеки пользовательского интерфейса вместо того, чтобы создавать все стили самостоятельно. Давайте посмотрим на поддержку Bootstrap или Material-Design для разных фреймворков.

Из того, что мы видим сейчас, Bootstrap 4 похож на Material-Desgin. Так что это хорошие новости для разработчика. Им просто нужно выбрать свою пользу, и они всегда будут получать аналогичный эффект.

На самом деле на Github доступно множество UI-библиотек / CSS-фреймворков, поэтому многие из них являются платформенно-нейтральными фреймворками, то есть их можно интегрировать с Angular, React или Vue. Честно говоря, интеграция всегда непростая, она потребует от вас или вашей команды дополнительных усилий. Имейте это в виду, чтобы интегрировать платформенно-нейтральную платформу, вам необходимо позаботиться о зависимостях и создать собственные инструменты тестирования, такие как webpack или yarn.

Стабильный API

По сравнению с Angular 1.x, Angular 2 - совершенно новое животное. В Angular 4 внесены некоторые критические изменения, которые нарушают некоторые зависимости Angular 2 (сторонние). Поскольку API Angular 4 все еще находится в стадии активной разработки, мы не можем использовать его в продакшене. Согласно заявлению команды Angular, они хотят исправить все ошибки и проблемы Angular-2 в Angular 4 и сохранить синхронизацию всех встроенных библиотек с Angular 4. Подготовка займет много времени. Если в вашем проекте используется Angular 1.2–1.4, я предлагаю вам сохранить его до завершения разработки Angular 4.

React-Redux в последнее время намного популярнее, чем React-Flux, но это не значит, что он лучше, чем шаблон React-Flux. На мой взгляд, React-Flux намного прямее и близок к оригинальному дизайну React. Если вы готовы использовать React-Flux, вам лучше его придерживаться.

Vue 2 содержит несколько критических изменений. Есть руководство по переходу с Vue 1.x на Vue 2. Не похоже, чтобы он сильно отличался. Vue 2 готов к производству.

Как сравнить

Чтобы правильно сравнить эти фреймворки, я использую эти фреймворки для создания небольшого реального веб-приложения, которое имеет встроенную поддержку аутентификации для серверной службы API и интегрировано с некоторыми адаптивными UI-фреймворками, например Бутстрап или Материальный дизайн.

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

С другой стороны, Angular 1.x построен с использованием Vanilla JS, т.е. вам не нужен транспилятор для создания приложения Angular 1.x, поэтому немного несправедливо сравнивать его с фреймворком, который написан на ES 6 или TypeScript, потому что инструмент сборки и настройка для Angular 1.x проще, чем другие. Я упоминаю здесь Angular 1.x, чтобы напомнить им, что на самом деле у команды есть другой вариант, основанный на традиционных стеках MVC. Это был бы правильный способ плавно трансформировать команду.

Ниже приведены проекты и соответствующие скриншоты.

Сравнение проектов для разных фреймворков

Вернемся к проектам выше и посмотрим. В основном в них реализованы почти те же функции, что и в реальном простом приложении CRM.

Возможности

  • Поддержка аутентификации и токенов для Restful API
  • Клиентские функции CRUD
  • Заказать функции CRUD
  • Панель инструментов, включая две диаграммы (Бар / Линия / Пончик)
  • Интеграция с Material Design (проект Angular включает бутстрап)

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

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

Vue.js использует Virtual DOM, что позволяет избежать множества грязных проверок в Angular 1.x и сложного шаблона кодирования (Observable & ReactiveJs, IMO) в Angular 2/4.

Vue.js значительно упрощает обработку неизменяемых и изменяемых переменных, чем React. Его шаблон очень удобный и прямой. Это то же самое, что и обычный HTML, очень легко преобразовать макет HTML в шаблон Vue, особенно когда вам нужно настроить стили. Шаблон и директива Vue похожи на Angular.

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

Как правило, библиотеки Material-Design для React не удобны, как другие адаптированные версии для Angular или Vue. Специальный стиль кодирования JSX требует преобразования всего CSS и HTML в формат JSX. Честно говоря, меня не так уж убеждает React JSX, потому что он не такой простой, как окончательный HTML или CSS. По сравнению с другими фреймворками, это немного многословно и неудобно. Мы не можем просто скопировать код стиля из инструмента разработчика браузера при его отладке в браузере. т.е. вам нужно приложить больше усилий, чтобы ваша страница выглядела красивой.

Библиотека Angular Material-Design имеет очень ограниченное количество компонентов. Чтобы создать реальное приложение, вам нужно добавить еще одну библиотеку пользовательского интерфейса, чтобы дополнить отсутствующие ранее компоненты. И последнее, но не менее важное: Vuetify - лучший Material-Design, который мы нашли и протестировали.

Репозитории

Обновлять:

27/01/2018

  • Angular 4 CRM больше не поддерживается в соответствии с последней версией Angular. Появился новый репозиторий Angular Material Starter App - https://github.com/harryho/ng-md-app, созданный с помощью Angular 5+ и Материал без Bootstrap.
  • Наконец-то выпущен Bootstrap 4. Пора попробовать с помощью Ng-bootstrap

Резюме

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

  • Команда, имеющая опыт работы с веб-формами и Vanilla Js, должна начать с Angular 1.4 и потратить некоторое время, чтобы познакомиться с инструментами Node.js.
  • Команда, имеющая опыт работы с Vanilla Js, должна начать изучать ES 6 или TypeScript, поскольку рано или поздно все браузеры, включая мобильные устройства, будут поддерживать ES 6 или TypeScript.
  • Команда, имеющая опыт работы с ES6 / TypeScript, может выбрать любую структуру, которую вы предпочитаете, интеграция с другой библиотекой пользовательского интерфейса займет у вас некоторое время, чтобы принять решение.
  • Команда с React-Flux может продолжить или перейти на React-Redux. Возможно, это сокращает часть кода котла, но я не думаю, что это имеет большое значение.
  • Новичку в React я рекомендую React-Redux, потому что он имеет лучшую поддержку сообщества.
  • На мой взгляд, если вы продолжите вкладывать что-либо в Angular 2, это будет немного напрасно, потому что команда Angular надеется, что вы перейдете на Angular 4 как можно скорее, как только Angular 4 будет готов к производству, и они планируют исправить Angular 2. проблемы в Angular 4.
  • Angular 4 и его экосистема находятся в стадии активной разработки, но будьте осторожны, если хотите использовать их в своей работе.
  • Фреймворк Vue.js очень хорош. Начните свой следующий проект.