Прошлое, настоящее и будущее компонентной разработки в Интернете
В двух предыдущих постах я сравнивал Polymer и Angular по производительности и опыту разработчика. В этом заключительном посте серии я хочу сделать шаг назад и посмотреть, как мы оказались в ситуации, когда у Google есть две модели создания компонентов для Интернета, что это означает для разработчиков сегодня и что может принести будущее. .
Краткий экскурс в историю
Polymer и Angular, возможно, больше похожи, чем вы думаете. Во-первых, оба являются проектами Google. Оба также используют компонентный подход к созданию приложений.
Проект Polymer был запущен в конце 2013 года как библиотека и полифилл браузера, чтобы помочь разработчикам начать использовать стандарты веб-компонентов, которые были введены двумя годами ранее. Работа над Angular 2 началась примерно через год после Polymer, в конце 2014 года. Среди целей Angular 2 были повышение производительности и более масштабируемая модель разработки на основе компонентов. Изначально команда Angular планировала построить компонентную модель на основе стандартных компонентов.
Angular 2 отлично взаимодействует с веб-компонентами, созданными с использованием других библиотек (Polymer, X-Tag и других), позволяя передавать в них данные так же просто, как если бы они были написаны на Angular. Компоненты Angular используют веб-стандарты (такие как теневой DOM и тег шаблона HTML5) в браузерах, которые их поддерживают.
— angular.io, март 2015 г.
Позже команда Angular изменила свою позицию и построила собственную компонентную модель, очень похожую на веб-компоненты, просто не привязанную к веб-платформе. Они сделали это, чтобы не зависеть от DOM. Из соображений производительности они хотели передать часть работы браузера Web Worker, выполнять предварительный рендеринг на сервере и поддерживать платформы, отличные от Web. Обратной стороной этого была добавленная сложность — как время выполнения, так и время разработки.
Хотя и у Polymer, и у Angular относительно схожие взгляды на роль компонента, они существенно различаются в том, насколько предписывающими они являются. Polymer — это небольшая библиотека, основанная на веб-стандартах. Его компонентная модель масштабируется от использования одного веб-компонента на статической странице до создания целых приложений. Он включает помощники для привязки данных, маршрутизации и локализации, но все они являются необязательными. Появляются некоторые передовые методы структурирования приложений, но Polymer не навязывает их разработчику.
Angular — это Java EE интерфейсных фреймворков.
Angular, с другой стороны, гораздо более самоуверен. Это также больше, чем просто структура; это собственная платформа. Angular — это Java EE интерфейсных фреймворков. Он предоставляет корпоративным разработчикам инструменты и шаблоны, к которым они привыкли при создании сложных приложений. Он поддерживает маршрутизацию, внедрение зависимостей, локализацию, предварительный рендеринг и тестирование. Это дает разработчикам четко определенный способ структурирования своих приложений и работы с потоками данных, устраняя большую часть неопределенности при создании приложения.
Почему Google создает и Polymer, и Angular?
Почему же тогда у Google есть эти два отдельных проекта по созданию веб-приложений на основе компонентов? Не будет ли Angular более разумным использовать веб-компоненты в качестве компонентной модели? В конце концов, именно это поначалу и пыталась сделать команда Angular 2, верно?
Я думаю, что конечная цель Google — сделать Интернет максимально привлекательным для разработчиков приложений. В конце концов, Интернет — это место, где они зарабатывают деньги.
Одно из препятствий, которое они выявили, заключалось в том, что Сеть нуждалась в компонентной модели для поддержки создания более сложных приложений. Им нужно было быстрое решение, поэтому Angular 2 был создан с собственной компонентной моделью.
Тем временем Google работал с W3C и другими поставщиками браузеров, чтобы принять стандарты для добавления модели компонентов к самой веб-платформе. Процесс стандартизации идет медленно, поэтому они создали полифиллы браузера и библиотеку Polymer, чтобы помочь разработчикам начать использовать новые функции.
Имея как Angular, так и Polymer, Google может предложить способ создания веб-приложений на основе компонентов в краткосрочной перспективе, одновременно работая над более элегантным решением в долгосрочной перспективе. Меня не удивит, если будущие версии Angular перейдут на использование (или, по крайней мере, поддержку) веб-компонентов, когда поддержка браузеров будет универсальной.
Взаимодействие с сообществом
Когда дело доходит до размера и вовлеченности сообщества, нет сомнений в том, какой из них более популярен среди разработчиков. Angular стал одним из самых популярных веб-фреймворков за последние пять лет, в то время как Polymer и веб-компоненты остались очень нишевыми технологиями.
Polymer в основном предназначен для разработчиков компонентов. Дело в том, что сами по себе веб-компоненты в большинстве случаев являются слишком низкоуровневой конструкцией при создании сложных приложений. Разработчикам нужна дополнительная структура и помощь, а это значит, что они ищут фреймворки при создании больших приложений.
Популярность Angular также означает, что существует гораздо больше документации, курсов и других учебных материалов, созданных сообществом. Вы также с большей вероятностью найдете ответы на свои вопросы по Angular на Stack Overflow и подобных сайтах. Для разработчиков, которые ищут хорошо зарекомендовавший себя инструмент для своего следующего проекта, особенно если им нужно получить поддержку от своего руководства, Angular выглядит более привлекательным на данный момент.
Прокладывая путь к следующему поколению веб-фреймворков
Глядя на принятие разработчиками Polymer и Angular, становится очевидным, что разработчики хотят использовать фреймворки при создании приложений. На мой взгляд, Angular представляет текущее поколение веб-фреймворков, а Polymer прокладывает путь для следующего поколения.
Опираясь на веб-компоненты, будущие веб-фреймворки можно создавать компактнее и быстрее, поскольку им больше не нужно создавать и запускать собственные модели компонентов в браузере. Модель общих компонентов также означает, что фреймворки можно сделать более модульными. Некоторым проектам нужен только маршрутизатор; другим может дополнительно потребоваться внедрение зависимостей, локализация или тестовая библиотека. Возможность выбирать только те части, которые вам нужны, упростит разработку и ускорит работу конечного пользователя.
Хотя веб-компоненты являются очень мощной концепцией, я думаю, что их самое большое влияние на большинство разработчиков заключается в том, что они прокладывают путь для нового поколения более быстрых и легких фреймворков и инструментов — будущее, в котором каждый новый фреймворк не должен построить собственный набор компонентов.
Первоначально опубликовано на vaadin.com.
