В своем предыдущем посте я показал, что Polymer имеет значительное преимущество в производительности перед Angular. Если вы пытаетесь сделать свое приложение быстрым (так и должно быть), вы, вероятно, задаетесь вопросом, имеет ли смысл создавать его с помощью Polymer.

Потенциальная проблема с созданием приложения с помощью Polymer заключается в том, что Polymer изначально не был разработан для создания приложений. Это библиотека, помогающая разработчикам работать с API-интерфейсами веб-компонентов (например, jQuery для API-интерфейсов веб-компонентов).

К счастью, модель разработки на основе компонентов, предлагаемая Web Components, достаточно гибкая, чтобы вы могли создавать сложные приложения, используя браузер в качестве основы. Но хотя с помощью Polymer можно создавать сложные приложения, ему по-прежнему не хватает структуры и рекомендаций, которые дает вам фреймворк.

В этом посте я сравню опыт разработки при создании одного и того же приложения как в Angular, так и в Polymer.

Инструменты и языки

И Angular, и Polymer поставляются с инструментами командной строки (CLI), которые помогают разработчикам настраивать и создавать проекты. Инструменты CLI скрывают большую часть сложности процесса сборки: заботятся о таких вещах, как транспиляция, оптимизация и объединение кода для производства. Angular CLI дополнительно (и необязательно) выполняет этап компиляции с опережением времени (AOT), чтобы уменьшить объем обработки JavaScript, необходимой в браузере.

полимер

Поскольку Polymer основан на веб-стандартах, компоненты создаются с использованием HTML и JavaScript. В Polymer 2 и более поздних версиях уровень языка по умолчанию — ES6, который будет преобразован CLI в ES5 для поддержки старых браузеров.

Polymer по-прежнему довольно ограничен в плане поддержки IDE. Команда Polymer работает над улучшением этого с помощью плагина Polymer IDE, который можно использовать с такими редакторами, как VS Code и Atom. Плагин Polymer IDE помогает разработчикам избежать распространенных ошибок и предлагает некоторую помощь по автозаполнению. Поскольку Polymer использует простой ES6, проверки типов отсутствуют.

Угловой

Angular поддерживает разработку на TypeScript, JavaScript и Dart. Большинство документации и примеров, доступных в Интернете, используют TypeScript, который де-факто является языком для создания приложений Angular. TypeScript — это надмножество JavaScript, в которое добавлена ​​проверка типов. Проверка типов дает разработчикам дополнительный уровень проверки кода и может быть полезна для обеспечения правильного использования API, особенно при работе в больших командах или при использовании сторонних библиотек.

Использование TypeScript в Angular также упрощает для IDE предоставление справки и проверок во время разработки. Visual Studio Code и WebStorm имеют хорошую поддержку TypeScript, последний даже помогает разработчику включать импорт, что ускоряет разработку Angular в IDE, несмотря на количество шаблонов.

Отладка

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

Чаще всего отладка приложения Angular сводилась к серии операторов console.log.

Angular гораздо сложнее отлаживать из-за шагов сборки между вашим кодом и кодом, который выполняется в браузере. Сборка Angular CLI создает исходные карты, которые должны позволить вам отлаживать код TypeScript в браузере. На практике это не сработало, так как исходные карты не соответствовали работающему коду, а точки останова не работали. Существует также плагин Chrome для отладки приложений Angular под названием Augury, который позволяет вам проверять иерархию и статус ваших компонентов. Я не нашел плагин очень полезным для выявления проблем. Чаще всего отладка приложения Angular сводилась к серии операторов console.log. Сообщения об ошибках в консоли браузера были загадочными, а трассировка стека редко включает идентифицируемый код, только внутренние вызовы Angular.

Структура приложения и маршрутизация

Поскольку и Angular, и Polymer основаны на компонентах, общая структура приложения схожа. Пользовательский интерфейс состоит из компонентов, которые последовательно объединяются в более сложные компоненты, вложенные друг в друга до тех пор, пока не появится приложение. В Angular вы можете дополнительно объединять связанные компоненты в модули, которые используются для определения области зависимостей и могут загружаться лениво при необходимости.

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

Angular поставляется с несколько сложным, но многофункциональным маршрутизатором, который поддерживает произвольно глубоко вложенные маршруты. Это помогает разработчику контролировать размер JavaScript-приложения, лениво загружая код для модулей, которые не нужны на более поздний срок. Это также позволяет оборудовать маршруты Guards, кодом, который запускается до или после активации представления, чтобы условно предотвратить навигацию. Маршрутизатор настраивается в файле TypeScript через вложенные объекты.

Polymer поставляет дополнительный маршрутизатор, который можно использовать для сопоставления URL-адресов и компонентов. Использование маршрутизатора требует нескольких шагов и большого количества повторяющегося кода. Вам нужно добавить элементы app-location и anapp-route в ваше приложение, чтобы прослушивать изменения URL. Используя эту информацию, вы можете решить, какие компоненты отображать, и при желании (вручную) подключить отложенную загрузку этих компонентов.

По умолчанию компоненты Polymer только лениво загружаются в DOM, но не удаляются. Это приводит к тому, что DOM со временем увеличивается в больших приложениях, что может привести к проблемам с производительностью, особенно на устройствах с ограниченным объемом памяти.

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

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

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

Работа с данными

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

Angular также поддерживает как одностороннюю, так и двустороннюю привязку данных. В дополнение к привязке данных он также поставляется с системой внедрения зависимостей (DI), которая упрощает подключение сервисов, особенно при тестировании. Angular в значительной степени опирается на RxJS и Observables для обработки данных, особенно для асинхронной связи HTTP. Модель реактивного программирования потребует некоторого привыкания, если у вас нет предыдущего опыта, но позволяет создавать элегантный код пользовательского интерфейса.

Редактирование данных в формах несколько отличается в Polymer и Angular. Polymer имеет элемент формы, который расширяет HTML-форму. Вся проверка выполняется самими элементами формы, что иногда немного ограничивает. В Angular проверка выполняется фреймворком, что упрощает объединение различных компонентов, но при этом обеспечивает постоянную проверку.

Чтобы это выглядело красиво

Когда дело доходит до настройки внешнего вида вашего приложения, с Angular работать намного проще, чем с Polymer. Angular работает вместе с существующими библиотеками CSS, такими как Bootstrap или Semantic UI, и вы можете легко написать глобальный CSS, чтобы придать вашему приложению целостный вид.

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

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

Мобильная поддержка: прогрессивные веб-приложения, нативные приложения или и то, и другое?

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

Для Polymer PWA — единственная мобильная стратегия. Это соответствует цели Polymer — опираться на веб-стандарты, чтобы расширить ваши возможности в Интернете.

Ремонтопригодность и стабильность

У Angular и Polymer далеко не блестящий послужной список, когда дело доходит до стабильности API. У Polymer был очень трудный переходный период от версии 0.5 до 1.0. Точно так же Angular 2 претерпел длительный период изменений API во время разработки, продолжающийся на протяжении всех версий-кандидатов. В «стабильной» версии 2.x даже были внесены небольшие критические изменения.

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

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

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

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

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

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

Первоначально опубликовано на vaadin.com.