Создание эффективных веб-компонентов

Перейти в репозиторий / Перейти в демо / Прочитать на Github

Иногда кажется, что мы ходим по кругу ...

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

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

efficiency = value / cost

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

| Values        | Costs             | 
| --------------|-------------------|
| Accessibility | A lot to learn    | 
| Performance   | More to code      | 
| Usability     | Hard to debug     | 
| Security      | High maintenance  |
| Etc...        | Etc...            |

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

Подход

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

Требования

Компонент формы

Отображает 3 поля с настраиваемыми значениями.
Имеет два действия для отображения данных и для изменения данных.
Вызывает компонент таблицы и передает значения полей.

Компонент таблицы

Принимает параметры из компонента формы.
Вызывает внешний API для получения данных.
Отображает полученные данные в табличной форме.

Компонент ячейки

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

Поддержка всех современных браузеров и IE11 :)

Правила честной игры

Решение должно включать как минимум 2 файла app.js или app.html и index.html.

Не минифицировано.
Используйте аналогичную структуру HTML.
Используйте похожие стили кодирования с комментариями.

Все решения включают общие файлы:

common.js с конфигурациями, API и аналитикой.
Минимизированный загрузочный CSS и style.css с базовыми стилями для метрик будут загружены позже и исключены из метрик.

Решение может использовать неограниченное количество внешних библиотек.

Внешние библиотеки можно минимизировать.
Не используйте CDN. Все файлы решений должны обслуживаться из одного места.

Избегайте оптимизации визуализации таблиц.

Отображение ячеек строка за строкой, столбец за столбцом.
Мы не хотим повторять тест JS framework
И здесь мы всегда можем использовать аналогичные оптимизации для каждого решения.

Загляните на демонстрационную страницу с решениями и тестами.

Полученные результаты

Я тестировал нативный JS, JQuery, X-Tag, Polymer и bBlocks. Мои показатели включают критический путь рендеринга, скорость отображения и скорость изменения для 1500 элементов. Я могу выполнить столько итераций, сколько нужно. Результаты сохраняются в хранилище локали, и вы можете видеть средние значения для каждого решения. Таким образом, он становится очень гибким. И вы можете попробовать разные браузеры и режимы.

Chrome (режим без кеширования).

IE11 (режим без кеширования).

Хром (с кешем).

Chrome (без кеша, хороший режим троттлинга 3G).

Размер кода решения

Размер зависимостей (уменьшен)

Мнения

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

Собственный Javascript

Это может быть основой для сравнения других решений.
Я не использовал никаких новых API-интерфейсов браузера, таких как Custom Elements.
Я использовал наблюдатель мутаций для обнаружения изменений атрибутов компонента ячейки.
Он показал лучшую производительность с 1 КБ дополнительных зависимостей.
Спорно, это решение было не самым быстрым для меня в IE11: ¯ \ _ (ツ) _ / ¯.
Как и ожидалось, собственный Javascript требует написания большего количества кода, что увеличивает затраты.
Но это не увеличит кривую обучения.

jQuery

Старый друг и сильный соперник.
Самое медленное решение из-за накладных расходов при использовании методов jquery вместо собственных.
Стабильная, простая в освоении, богатая экосистема.
Последняя тонкая версия имеет относительно небольшой размер 68 КБ.
Может быть победителем, если он уже является частью приложения. Что может быть верно для ~ 70% Интернета. Таким образом, это не требует дополнительных затрат.

Полимер

Я использовал микропакет Polymer v1.
По скорости он приближается к родному Javascript. Но тяжелее из-за полифиллов и размера библиотеки.
Polymer предлагает использовать все новые API, такие как Custom Elements, HTML Imports, Shadow DOM, Templates. У каждого есть несколько предостережений.
Это вносит некоторую двусмысленность при использовании многих нестабильных технологий. В конечном итоге вы платите более высокие затраты, тратя больше времени и включая более тяжелые полифиллы и библиотеки.

X-Tag

Меньшая библиотека, построенная на основе Custom Elements API.
Предоставляет помощники DOM и API для определения свойств и наблюдения за атрибутами. Как раз то, что нам нужно.
Тяжелее, чем могло бы быть, в основном из-за лишних полифиллов.
Показал лучшую производительность и меньший размер раствора по сравнению с Polymer.

bБлоки

Можем ли мы сделать лучше? Я постарался создать наиболее эффективный.
Легкий. Минимизировано только 4 КБ. Чрезвычайно модульный и гибкий. Всего 2 основных API для создания компонентов и функций, которые я могу поддерживать вечно.
Я смог добиться лучших результатов с меньшим количеством кода и минимумом обучения.
Для этого требуется всего несколько легких полифиллов для IE11 и лучший полифил Custom Elements. Только 14 КБ в зависимостях.
Он не требует транспиляции и может работать с классами или прототипами.
Я создал модуль с помощниками DOM. Пример того, как мы можем сделать наши решения компактными.

Согласен или не согласен, все мнения приветствуются! ✌️