Главная » Статьи » Точка зрения на сравнение фреймворков: Angular обречен, с React все хорошо – мы заслуживаем лучшего

Точка зрения на сравнение фреймворков: Angular обречен, с React все хорошо – мы заслуживаем лучшего

Точка зрения на сравнение фреймворков: Angular обречен, с React все хорошо – мы заслуживаем лучшего

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

Вкратце

Кое-что про сравнение фреймворков.

Angular создал раздутое, сложное для изучения, слишком абстрактное и многоликое создание, страдающее от множества проблем.

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

Vue.js – правильный инструмент для проектов любого масштаба, используйте его, живите долго и процветайте.

Предисловие

В 2010 у нас был Angular.js. Это был замечательный фреймворк, который помогал строить и обслуживать огромные приложения (и маленькие). Но у NG1 была (так называемая) неизлечимая болезнь: чем больше становилась страница (показывала больше информации), тем быстрее она становилась медленнее.

Тогда в 2014 NG1 анонсировали, что собираются полностью переписать новый фреймворк Angular2. Они много пообещали, много чего изменилось, а фреймворк до сих пор в разработке.

2015 стал рассветом React и Redux. React — это идеалистическая ограниченная библиотека UI, а Flux — как древняя идея, но разработчики отчаялись найти то, что не «заболеет» по мере роста сложности. Поэтому он принял на себя бремя скрепления, попал в неизменяемый javascript и написал эти бесконечные switch кейсы и шаблоны.

Тогда еще бывший разработчик из группы NG1 обнаружил, что у ES5 есть функция (getter-setters), которая позволяет решить основную задачу сложного UI — обнаружение изменений другим способом, не требующим усилий (отслеживание зависимостей) и сохраняющим все хорошие идеи от NG1. Он назвал его Vue.js.

Итак, это история о том, когда танцуешь с фреймворками Angular и React, но ночь проводишь с прекрасным VueJS.

Почему я должен тебя слушать?

У меня очень большой (20+ лет) технологический опыт. В нем нашлось место С, С++, мэйнфреймам, Java, и последние 10 лет я остановился на веб-платформе.

Я возглавляю консалтинговую компанию — misterBIT - настоящие веб-эксперты. Большую часть прошедших 10 лет занимаюсь наставничеством разработчиков, обучением и консалтингом в области веб-технологий и архитектур.

Почему я пишу это?

Как консультанту, мне надоело слышать вопросы о том, какие фреймворки выбрать. Ты рекомендуешь VueJS, и заканчивается это тем, что ты становишься наставником их проектов React/Angular, ищешь время в жестком графике, чтобы помочь им, зачастую жертвуя качеством. А качество — это причина, по которой используют эти фреймворки в первую очередь.

Почему же React and Angular популярнее Vue.js?

Никого не увольняют за выбор Google или Facebook

Я часто слышу: «за React стоит Facebook, за Angular стоит Google, Vue независим – поэтому он безопаснее.»

Это не так:

Правда в том, что компании выбрасывают технологии в окно по мере развития (Flash, GWT, Silverlight, AngularJS), в то время как проекты, созданные сообществом, живут дольше.

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

У Vue.js несколько разработчиков на полной ставке и поддержка большого сообщества с энтузиазмом.

Путаница (AKA: Усталость JavaScript) за последние годы привела к тому, что выбор JS фреймворка стал решением, которое принимают менеджеры, но не обязательно очень технологичные.

React / Angular — это более простой выбор для менеджеров высокого уровня (никого не увольняют за выбор технологий Facebook / Google).

Для остальных из нас — тех, кто хочет быстро создавать отличные продукты и идти пить пиво, я уточню причины, по которым мы выбрали Vue для всех текущих проектов.

Angular

Ну, хорошо, мы до сих пор учим его время от времени, но кажется, что спрос и тяга снижаются. Я считаю, что есть несколько причин для этого:

Множество шаблонов – предназначено для крупных проектов с множеством разработчиков и страниц, поэтому это всего лишь небольшая часть приложений, которые мы должны настроить. И много кода — OMG — большой след и много церемоний.

Платформа wanna-be — В то время как Vue.js вырезает поддержку Ajax, так как ее лучше сделать специализированной библиотекой, такой как Axios, Angular хочет охватить все это.

Плохая, разрозненная, докучливая документация и океан сломанных советов, старые курсы, вводят в заблуждение angular.js и материалы release candidates (им действительно удалось убить интернет, назвав совершенно другой фреймворкс тем же именем)

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

Observables над Promises  — даже простой вызов AJAX дает вам возможность наблюдать. Я вижу, что многие разработчики игнорируют дополнительную цену, которую они только что заплатили, проглотили свою гордость и сразу же вызвали Promise (). RxJS Observable находятся в любом уголке Angular и учатся играть с ними, предотвращают множественные подписки, делают их горячими, очищают и учатся использовать операторов, становясь еще одной жесткой кривой обучения.

Неблагоприятный подход к обнаружению изменений: для каждого события async (пользователь что-то щелкнул, некоторые данные только что прибыли и т. Д.) сравните каждую привязку (привязка Model-Dom) с ее старым значением, чтобы решить, нужно ли проводить повторный рендер. — В AngularJS (NG1) было слишком медленно переносить > 2500 наблюдателей на странице. — В Angular (NG2 +) остается та же проблема, но у вас есть долгое усталое обходное решение: переключитесь на неизменяемые и распространяйте ChangeDetectionStrategy.onPush во всем приложении, чтобы отключить стандартную стратегию по умолчанию

Angular ядро по-прежнему резко меняется (!) В NG4 (чтобы убрать вес), компиляция шаблона полностью изменилась с вывода в основном сгенерированного изоморфного кода на единственную структуру данных, используемую суперполиморфным кодом. И кажется, что он скоро снова изменится.

Только Typescript (практически невозможно использовать чистый JS) — Typcript полезен, если вы разрабатываете библиотеку, но иногда это раздувается до небольших / средних приложений.

На самом деле я большой поклонник команды, но, к сожалению, Angular — печальная история.

React

React — простое решение для компонентных представлений, не более того.

Есть много способов сделать что-то одно: разные API, разные библиотеки, всякий раз, когда я вступаю в проект React, я не знаю, чего ожидать и куда идти, сочетание компонентов пользовательского интерфейса и компонентов более высокого порядка, различные идеи и библиотеки, проводки, привязки и boiler-plating.

Сейчас многие команды используют черный ящик под названием create-react-app (даже базовая конфигурация Webpack скрыта и неприкосновенна), надеясь на лучшее, но обнаруживая, что EJECTING из CLI, а затем начинают свой собственный путь.

Многие используют Redux неправильно или по неправильным причинам.

Люди говорят: «React native — большой плюс», когда я заглянул в него, я был удивлен, обнаружив, что он не о повторном использовании кода вашего веб-приложения умным способом, компилируя материал на native. Я понял, что он не имеет ничего общего с React и web-mobile (прогрессивными) приложениями, что мы и делаем теперь, не так ли?

При кодировании React-Native вы не используете HTML для рендеринга приложения, но вам нужно учиться и работать с альтернативными компонентами

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

Прощай анимация CSS, с помощью React-Native вам нужно будет изучить совершенно новый способ анимации

React API или Vue API

React — это идеалистическая библиотека UI, и поэтому она приносила клятву во избежание использования языка шаблонов и просто использовала javascript (Pete Hunt: «выражение пользовательского интерфейса с полной мощью JS, а не искаженный язык шаблонов»).

Vue.js — с другой стороны, представляет собой сбалансированную подборку компромиссов.

React Higher Order Components — это способ добавления общих компонентов к компонентам, это громоздкий и тесно связанный механизм; С Vue у вас есть директивы, миксины и фильтры.

Для встраивания (то есть преобразования) содержимого внутри компонента разработчики React используют props.children. Vue.js имеет это, но предлагает свои мощные слоты: default, named и scoped, что значительно упрощает сбор / использование библиотек компонентов Ui.

React разработчикам нужно думать о привязке. Vue автоматически свяжет все правильно.

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

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

В Vue.js есть хуки жизненного цикла с хорошими именами (-:

Заключение

Vue.js — лучший выбор; он зарекомендовал себя в крупномасштабных продакшен проектах и становится все более привлекательным. Используйте его сегодня — и идите пить пиво.

Автор: Yaron

Источник: https://medium.com/

Редакция: Команда webformyself.