Сравнение фреймворков от Real-World

Автор статьи — Jacek Schae.
Оригинальная статья — https://medium.freecodecamp.org/a-real-world-comparison-of-front-end…
Переведено — Front&Blog: @mtsymlov


Эта статья является обновленной версией сравнения интерфейсов, реализованных на фреймворках, от Real-World  (декабрь 2017 года).

В этот раз, мы покажем различия между практически идентичными шаблонами Real-World.

Шаблоны Real World дают нам:

  1. Real World App — нечто большее, чем “todo”. Обычно примеры “todo” не содержат достаточных знаний о том, как на самом деле строить реальные приложения на той или иной технологии.
  2. Стандартизация — все проекты соответствуют определенным правилам. Предоставляется внутренний API, статическая разметка, стили и спецификации.
  3. Написано и переписано экспертами — шаблоны Real-World почти идеальны, они написаны экспертами в своих областях.

Критика последней версии (Декабрь 2017)

  • Angular был не в prod-версии. Демо-приложение из репозитория Real World использовало develop-версию, но благодаря Jonathan Faircloth сейчас всё работает корректно!
  • Vue не был в Real World, и, таким образом, он не был включен в рейтинг. Как вы можете себе представить нашу фронтенд вселенную без Вью? Почему мы не добавили Вью? Что, черт возьми, с нами такое? На этот раз Vue есть в нашем списке! Спасибо Emmanuel Vilsbol.

Какие библиотеки / фреймворки мы сравниваем?

Как и в статье за декабрь 2017 г., мы включили все реализации, перечисленные в репозитории RealWorld. Не имеет значения, сколько последователей у библиотеки/фреймворка. Единственное требование заключается в том, чтобы наши претенденты были в репозитории RealWorld.

На какие показатели мы смотрим?

  1. Производительность: сколько нужно времени приложению, чтобы показать контент и стать полезным?
  2. Размер: сколько весит наше приложение? Мы будем сравнивать только размер скомпилированных файлов JavaScript. CSS является общим для всех вариантов и загружается с CDN. HTML также является общим для всех вариантов. Все технологии компилируются или переносятся на JavaScript, таким образом, мы сравниваем только размер финального бандла.
  3. Количество кода: сколько строк кода потребуется, чтобы создать реальное приложение? Чтобы быть справедливым, некоторые приложения имеют немного больше наворотов, но это не должно иметь значительное влияние. Мы оцениваем только папку src/.

Метрика #1: Производительность

Взгляните на тест First meaningful paint с помощью Lighthouse , который доступен в Chrome.

Чем быстрее произойдет отрисовка этой части, тем выше будет UX у человека, который использует ваше приложение. Lighthouse также имеет First interactive, но он был практически идентичен для большинства приложений + это бета-версия.

First meaningful paint (ms) — чем ниже, тем лучше

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

Метрика #2: Размер

О размере бандла вы можете узнать с помощью вкладки ‘Network’ в Chrome. Чем меньше файл, тем быстрее загрузка.

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

размер (KB) — чем ниже, тем лучше

Вы можете видеть, что Svelte, Dojo 2, AppRun и Crizmas MVC работают достаточно хорошо. Я бы хотел посмотреть, как аналогичные тесты делает Hyperapp. Может, в следующий раз, Jorge Bucaran?

Метрика #3: Количество кода

Используя cloc, мы подсчитываем количество строк кода в каждой папке src. Пустые строки и комментарии не являются частью этого расчета. Кому они вообще нужны?

 

Если отладка — это процесс удаления программных ошибок, то программирование должно быть процессом их ввода — Edsger Dijkstra

количество строк — чем ниже, тем лучше

Чем меньше строк кода у вас есть, тем меньше вероятность обнаружения ошибки.

В заключение

Я хочу сказать большое спасибо Eric Simons за создание RealWorld Example Apps, и всем тем, кто ему помогал.