Главная » Статьи » Сравнение Front-End фреймворков с помощью тестов производительности от Real-World (обновление 2018 года)

Сравнение Front-End фреймворков с помощью тестов производительности от Real-World (обновление 2018 года)

Сравнение Front-End фреймворков с помощью тестов производительности от Real-World (обновление 2018 года)

От автора: эта статья является обновлением «Сравнения Front-End фреймворков помощью тестов производительности от Real-World» от декабря 2017 года. В этом сравнении мы покажем, чем отличаются друг от друга разные реализации практически идентичных приложений RealWorld, и как делается с их помощью тест производительности.

Пример приложения RealWorld характеризуется следующим:

Приложение Real World — нечто большее, чем «задача». Обычно «задачи» не предоставляют достаточно данных для фактического создания реальных приложений.

Стандартизация — проект, который соответствует определенным правилам. Предоставляет базовый API, статическая разметка, стили и спецификации.

Написано или просмотрено экспертом — последовательный, реальный проект, который, в идеале, был написан или просмотрен экспертом в этой технологии.

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

Angular не был представлен рабочей версией. Демо-приложение, указанное в репозитории RealWorld, использовало версию для разработки, но благодаря Джонатану Фэрклету сейчас Angular представлен рабочей версией!

Vue не был указан в репозитории RealWorld, и, таким образом, не был включен. Как вы можете себе представить, среди front-end разработчиков это вызвало бурную реакцию. Почему вы не добавили Vue? Что, черт возьми, с вами не так? На этот раз Vue.js в игре! Спасибо Эммануэлю Вилсболу.

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

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

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

Производительность. Сколько времени уходит у приложения на вывод контента и его использование?

Размер: Насколько велико приложение? Мы сравниваем только размер скомпилированных файлов JavaScript. CSS является общим для всех вариантов и загружается из CDN (Content Delivery Network). HTML также является общим для всех вариантов. Все технологии компилируются или переводятся на JavaScript, поэтому мы ограничиваем размер этого файла(ов).

Строки кода: Сколько строк кода необходимо автору, чтобы создать приложение RealWorld на основе спецификации? Ради справедливости, некоторые приложения содержат немного больше специфических элементов, но это не должно иметь существенного влияния. Единственная папка, которую мы оцениваем в каждом приложении — src/.

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

Ознакомьтесь с тестом Первого значимого отображения, выполненным с помощью Lighthouse Audit, который поставляется с Chrome.

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

Первое значимое отображение (мс) — чем ниже, тем лучше

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

Показатель №2: Размер

Размер передаваемых файлов мы определяем на вкладке Chrome Сеть. Заголовки ответа GZIP плюс тело ответа, поставляемое сервером.

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

Размер данных (КБ) — чем меньше, тем лучше

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

Показатель № 3: Строки кода

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

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

Количество строк кода — чем меньше, тем лучше

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

Автор: Jacek Schae

Источник: https://medium.freecodecamp.org/

Редакция: Команда webformyself.