За последние пару лет мы увидели бурный рост фреймворков. Каждый из них имеет больше чем нужно возможностей для построения отличных веб-приложений. Но как их сравнить и решить, какой использовать в вашем следующем проекте?
Прежде всего, чтобы сделать осмысленное сравнение, нам нужно несколько условий, касающихся приложения. Оно должно быть:
- Настоящим. Чем-то большим, чем «todo». Обычно «todo» не передают знания и перспективы для настоящего создания реальных приложений.
- Стандартизированным. Проект, который соответствует определенным правилам. Размещенный в одном и том же месте, обеспечивающий бэкенд-API, статическую разметку, стили и спецификацию.
- Написанным экспертом. Содержательный, настоящий проект в идеале создается экспертами в данной технологии. Чаще всего это правда (об этом ниже).
Так где нам взять такой проект? Хорошая новость: Эрик Симонс уже создал проект RealWorld. Это клон платформы для написания блогов Medium. Каждая реализация этого проекта имеет одну и ту же структуру HTML, CSS и спецификацию API, но разные библиотеки/фреймворки. Что касается экспертных знаний это чаще всего правда. Я написал реализацию в ClojureScript и re-frame, но я не считаю себя экспертом. Настоящий эксперт пересмотрел мой код – спасибо за это Дэниелу Комптону.
Теперь, когда у нас есть основная спецификация, нам нужен стандартный набор тестов/измерений для сравнения.
- Производительность. Сколько времени понадобится этому приложению чтобы отобразить содержимое и стать готовым к использованию?
- Размер. Насколько велико приложение? Мы будем сравнивать только размер скомпилированного JavaScript. CSS во всех вариантах будет общий, скачанный с CDN (Content Delivery Network). HTML тоже будет одинаковый. Все технологии компилируют или перекомпилируют на JavaScript, поэтому мы будем измерять только этот файл.
- Строки кода. Сколько строк кода понадобилось автору, чтобы создать приложение, соответствующее спецификации? Честно говоря, в некоторых приложениях есть немного больше причиндал, но это не должно иметь решающего значения. Единственная папка, которую мы принимаем во внимание в каждом приложении, это src/.
Во время написания этой статьи (декабрь 2017 года) проект RealWorld доступен для следующих фреймворков:
- React / Redux
- Elm
- Angular 4+
- Angular 1.5+
- React / MobX
- Crizmas MVC
- CLSJ Keechma
- AppRun
- CLJS re-frame (этот сделал я, его нет в списке проекта RealWorld).
Замер #1: Производительность
Тестируем параметр First meaningful paint (время, необходимое для отображения первого содержимого на странице) с помощью Lighthouse Audit, который поставляется с Chrome.
Чем быстрее отображаются элементы на странице, тем лучше будет пользовательский опыт человека, который запускает то приложение. Lighthouse также измеряет параметр First interactive (время, нужное, чтобы страница стала минимально интерактивна), но тут результаты были практически одинаковыми для большинства приложений.
Замер #2: Размер
Размер передачи осуществляется с вкладки сети Chrome. Сжатые заголовки ответа плюс тело ответа, доставленные сервером.
Чем меньше файл, тем быстрее загрузка и меньше нужно парсить.
Этот параметр зависит от размера вашего фреймворка, любых дополнительных зависимостей, которые вы добавили, и того, насколько хорошо ваш инструмент сборки может делать маленькие пакеты.
Замер #3: Строки кода
С помощью cloc мы считаем строки кода в каждой папке src. Пустые и закомментированные строки не учитываются. Почему это важно?
«Если отладка это процесс удаления багов в программах, тогда программирование должно быть процессом их внесения», – Эдсгер Дейкстра.
Чем меньше у вас строк кода, тем меньше возможность ошибок и тем меньшую базу кода нужно обслуживать.
Выводы
Производительность
Это сравнение RealWorld, а не сферический конь в вакууме. Тесты проводились в Европе (Швейцария). Все приложения размещались на Github. У вас значения могут не совпасть, это нормально. Тесты проводились пару раз для каждого приложения, затем усреднялись и округлялись. Результаты, полученные в течение дня были достаточно ровными. Показатели большинства библиотек/фреймворков ранжируются от «отлично» до «хорошо». Если речь идет о производительности, большой разницы вы не заметите.
Размер
Размер пакета для каждого приложения всегда одинаков. Мы сравниваем похожие реализации и смотрим, как отличаются размеры их пакетов. AppRun невероятен! Я посмотрел дважды, так как не мог поверить в это. Elm хорош, когда речь идет о размере пакета и особенно если вы посмотрите на строки кода.
Строки кода
Для вас как разработчика это важнее всего. Чем больше строк кода, тем больше надо вводить и больше обслуживать. Тут есть некая зависимость. Особенно, когда речь заходит о сравнении типизированных и динамических языков. Типы дают вам больше безопасности и очень затратны — нужно больше печатать.
Типизированные против динамических
Типизированные: Elm, Angular 4+ и AppRun.
Динамические: React | Redux, Angular 1.5, React | MobX, Crizmas MVC, CLJS Keechma и CLJS re-frame.
Так что же лучше? Лучших и худших нет, они просто разные. Это как TDD (Test Driven Development), кто-то любит, кто-то ненавидит. Вы можете разработать прекрасную программу хоть с TDD, хоть без – просто выберите, как вам нравится.
Где Vue, Preact, Ember, Svelte, Aurelia и остальные?
Выглядит, как будто они опоздали на вечеринку, но беспокоиться не стоит. Я сделаю еще один заход, когда они у нас будут. Уже есть поднятые темы – подумайте о возможности принять участие! Или начните со scratch и откройте свою тему.
Заключительные слова
Это сравнение в буквальном смысле. Сравнение различных реализаций или похожих настоящих веб-приложений в реальных условиях. Я знаю, оно не совершенно. Результаты зависят от загрузки сервера, трафика сети и многих других вещей, которые случаются в реальном мире.
***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]