[Перевод] Проект RealWorld: сравнение фронтенд-фреймворков

Материал, перевод которого мы предлагаем сегодня вашему вниманию, представляет собой обновлённую, с учётом положения дел в 2018 году, версию статьи об исследовании фреймворков, которая была опубликована в декабре 2017.

image

В ходе исследования применяется приложение, варианты которого созданы в рамках проекта RealWorld с использованием различных фреймворков. Тут нельзя говорить о полной идентичности разных вариантов приложения, всё же, созданы они на разных платформах, но такой подход позволяет реалистично проанализировать и сравнить характеристики различных фреймворков. Если говорить об этом приложении, то можно отметить следующие его особенности:

  • Реальные задачи. RealWorld — это приложение, функционал которого выходит за рамки стандартного «списка дел». Подобные приложения обычно очень просты, они не отражают всё то, что необходимо в настоящих программах.
  • Стандартизация. Каждый вариант приложения соответствует определённым требованиям. В частности, эти требования описывают серверное API, статическую разметку и характеристики приложения.
  • Поддержка экспертов. Приложения либо написаны специалистами высокого класса, либо проверены ими.


При подготовке этого исследования были учтены замечания к его предыдущей версии. В частности, раньше не изучался фреймворк Vue, теперь же он имеется в списке. Стоит отметить, что здесь задействована версия Angular, применяемая для разработки, но использование в приложении продакшн-версии этого фреймворка — лишь вопрос времени.

Фреймворки


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

1048b0dd2c384987404dba9d3bd2bb88.png


Фреймворки, включённые в исследование

Анализируемые характеристики


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

  • Производительность приложения. Сколько времени нужно для того, чтобы приложение загрузилось, вывелось на экран и оказалось бы готовым для работы с ним?
  • Размер готового приложения. Каков размер приложения? Тут сравнивались лишь размеры скомпилированных JS-файлов. Во всех вариантах использовались одни и те же CSS-правила, соответствующие материалы загружались с CDN. Везде применялась одна и та же HTML-разметка. Программный код, подготовленный средствами всех фреймворков, компилировался или транспилировался в JavaScript, в итоге сравнивались лишь размеры итогового JS-файла или файлов.
  • Количество строк кода приложения. Сколько строк кода надо написать для того, чтобы создать приложение RealWorld, соответствующее предлагаемым требованиям? Тут стоит отметить, что в некоторые варианты приложения включены второстепенные дополнительные функции, но это не слишком сильно влияет на итоговый результат. В ходе анализа исследовалась только папка src/ каждого из приложений.


Производительность


Здесь мы пользовались таким показателем, как первое значимое отображение страницы (First Meaningful Paint), полученным с помощью инструмента Lighthouse, который поставляется вместе с Chrome.

Чем быстрее будет выведена страница приложения — тем лучше оно будет воспринято пользователями. Средство Lighthouse также позволяет измерять показатель первой интерактивности (First Interactive), но он пока находится на стадии бета-тестирования и практически идентичен для всех вариантов приложений, поэтом тут мы ограничились именно показателем первого значимого отображения страницы.

4bea3b489507247036f1c00449e0a432.png


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

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

Размер приложения


Здесь мы анализировали объём переданных данных, полученный средствами вкладки Network инструментов разработчика Chrome. Учитывалось всё то, что передаётся с сервера, включая заголовки и тело ответа. Чем меньше файл готового приложения — тем быстрее он загружается, и тем меньше времени нужно на его разбор в браузере.

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

8f33de878878fd85c26fdf8b00c03806.png


Размер передаваемых данных в килобайтах. Чем он меньше — тем лучше.

Можно заметить, что лидерами по данному показателю являются Svelte, Dojo 2, AppRun и Crizmas MVC. Об ELM пока сложно сказать что-то определённое, особенно учитывая данные по размеру кода программ, которые мы рассмотрим ниже. Кроме того, интересно было бы взглянуть на то, как в подобном сравнении покажет себя Hyperapp. Возможно, нам удастся исследовать этот фреймворк в следующий раз.

Количество строк кода


Подсчёт количества строк кода приложения выполнялся с помощью cloc. Обработаны были только файлы, находящиеся в папке src. Пустые строки и комментарии не учитывались. Почему число строк кода, необходимое для создания приложения — это важный показатель? Вот что по этому поводу говорил Эдсгер Дейкстра: «Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения».

9e17cb0fb7d88173861a56d68a9abad6.png


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

Чем меньше строк кода нужно для того, чтобы создать приложение — тем меньше вероятность сделать что-то неправильно. Кроме того, проекты, представленные меньшим объёмом кода, легче поддерживать.

Итоги


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

Уважаемые читатели! Какими соображениями вы руководствуетесь, выбирая фреймворки для фронтенд-разработки?

1ba550d25e8846ce8805de564da6aa63.png

© Habrahabr.ru