Чтобы показать размер акулы, через которую современный Software development перепрыгнул, вот реальная история.

Пять лет назад надо было организовать JWT аутентификацию на сайте с PHP бэкендом. Взял firebase/php-jwt - продукт разработчиков Google, ноль зависимостей, один файл среднего размера который делал всю криптографию. Логика там простая - сгенерировать JWT токен при логине и проверить подпись токена при запросе с фронтенда. Реализация на бэке заняла строк 50 кода, на фронте - столько же.

Через некоторое время делал JWT аутентификацию на другом проекте, заметил, что firebase/php-jwt переписался в ОО стиле - появились классы JWT, Key, ExpiredException и т.д. Логика та же, размер общий чуть увеличился.

Продолжение следует...

#laravel #dx #optimization #jwt

О сложности в SD (продолжение)

Недавно надо было поставить JWT аутентификацию на Ларавель. Посмотрел в интернете - делается через пакет tymon/jwt-auth. Поставил, настроил.
Залез внутрь пакета - там 65 php файлов. Глянул в зависимости в composer.json:

"require": {
  "php": "^5.5.9|^7.0",
  "illuminate/auth": "^5.2|^6|^7|^8",
  "illuminate/contracts": "^5.2|^6|^7|^8",
  "illuminate/http": "^5.2|^6|^7|^8",
  "illuminate/support": "^5.2|^6|^7|^8",
  "lcobucci/jwt": "<3.4",
  "namshi/jose": "^7.0",
  "nesbot/carbon": "^1.0|^2.0"
}

Ой-вей, так этот пакет даже JWT криптографией не занимается, это просто прослойка между Ларавелем и другими пакетами, которые уже делают что-то полезное. То есть, это аналог того кода в 50 строк, который я писал пять лет назад.

Вот этот пакет со всеми зависимостями делает, по сути, то же самое, что и firebase/php-jwt. То же самое с точки зрения бизнес-требований, технической стороны, безопасности.

Складывается впечатление, что как минимум 90% кода пишется не для того, чтобы решить конкретную бизнес задачу, а по другой причине. Чтобы получить доход, но не прямо и конкретно, а в целом, "для отрасли". Для этого усложняются фреймворки и методики. То, что можно сделать просто, делается сложно. Это как таксист, который везет кругами неместного пассажира, чтобы накрутило на счетчик. Причем таксист сам не знает куда ехать - он ведёт по навигатору, он только это умеет. А навигатор ведет так, как в него заложил его хозяин.

Сфера software development усложняется и задурманивается, чтобы там нельзя было найти прямых путей. А те, кто помнит, как их находить, побыстрее вымерли.

#laravel #dx #optimization

Порядок свойств в js объекте важен для оптимизации js движком, и лучше его сохранять

Такая функция:

function add(a, b) {
  return {
    x: a.x + b.x,
    y: a.y + b.y,
  }
}

на таких объектах:

const o1 = { a: 1, b: 2};
const o2 = { a: 3, b: 4};

будет выполняться в 7-10 раз быстрее, чем на таких:

const o1 = { a: 1, b: 2};
const o2 = { b: 4, a: 3};

#js #optimization

Использование функций на массивах, типа filter, map и других, очень удобно и даёт красивый код, но может создавать проблемы в производительности из-за:

1. Выделения и потом уничтожения промежуточных массивов
2. Cоздавания циклов в циклах ( сложность O(N^2) ), хотя весь код можно разместить в одном цикле ( O(N) )

Например, код 1. ниже выполняется в 2-3 раза дольше, чем код 2.

// setup:
const numbers = Array.from({ length: 10000 }).map(() => Math.random())

// 1. functional
const result =
  numbers
    .map(n => Math.round(n * 10))
    .filter(n => n % 2 === 0)
    .reduce((a, n) => a + n, 0)

// 2. imperative
let result = 0
for (let i = 0; i < numbers.length; i++) {
  let n = Math.round(numbers[i] * 10)
  if (n % 2 !== 0) continue
  result = result + n
}

#js #optimization

Во всех браузерах кроме Firefox реализован Fetch Priority API

Это атрибут fetchpriority на тэгах img, script, link, который указывает, насколько приоритетен данный ресурс для загрузки.

Это важно в первую очередь для метрик Core Web Vitals, а именно - LCP. Если элемент LCP - картинка, имеет смысл указать ей fetchpriority="high".

Учитывая, что ресурсов на странице может быть много, а браузеры выделяют на сетевые соединения около 5 потоков на один домен, то может образоваться очередь, и ваша LCP картинка появится не сразу.

Также можно указать fetchpriority="low" для картинок вне области видимости, - в том числе, в слайдере.

#tip #optimization #webvitals

Если у вас есть большая строка в JavaScript, и вы с помощью slice() вытаскиваете из нее подстроку, то эта подстрока не даст Garbage Collector-у уничтожить большую строку, даже если вы на нее больше не ссылаетесь. Это верно в V8, где подстрока оформляется как С++ указатель на нужное место в большой строке. В результате при обработке большого числа строковых данных могут происходить утечки памяти. Чтобы избежать этого можно делать копирование подстроки.

Также утверждение, что конкатенация строк - дорогая операция, уже не соответствует действительности. Например, на массиве строк

.join(' ')

будет медленней конкатенации через reduce:

.reduce((acc, c) => acc + ' ' + c, '')

Опять же из-за особенностей V8. Более того, конкатенация будет даже быстрее шаблонов строк (`Hello ${name}`), хотя обычно учат обратному.

В целях оптимизации работы со строками следует избегать мутирующих операций.

#tip #js #optimization

Подбирайте для своих данных подходящую структуру, в зависимости от операций над ними.
Это сильно влияет на производительность

В примере ниже Array.includes() примерно в три раза медленней, чем Set.has()

// setup:
const userIds = Array.from({ length: 1000 }).map((_, i) => i)
const adminIdsArray = userIds.slice(0, 10)
const adminIdsSet = new Set(adminIdsArray)

// 1. Array

let num = 0
for (let i = 0; i < userIds.length; i++) {
  if (adminIdsArray.includes(userIds[i])) { num += 1 }
}

// 2. Set

let num = 0
for (let i = 0; i < userIds.length; i++) {
  if (adminIdsSet.has(userIds[i])) { num += 1 }
}

#js #optimization

В подтверждение нашему недавнему совету по оптимизации js кода, твит Эвана:

Самое приятное в этом то, что вы можете писать хороший функциональный код, который выполняет итерации над коллекциями (аналогично map, filter и т.д.) с оптимизированной вручную производительностью.

Каждый раз, когда я использую map/filter в JS вместо обычных циклов for, мне кажется, что я добровольно отказываюсь от производительности.

#tip #optimization #evanyou

Самое время узнать, за счет чего главная лендинговая статичная страница GitLab смогла набрать 13Мб в скриптах

На скриншоте бандлофобии разрезолвились не все пакеты

Первая тройка тяжеловесов:

1. @nuxtjs/i18n - 2.5Mb
2. slippers-ui (GitLab's Marketing Design System) - 1.8Mb
3. vue-mermaid-string (построение диаграмм) - 1.1Mb

#gitlab #optimization #nuxt #i18n

Немного OSINT-a в ленту.

Давайте еще поизучаем результаты исследования бандла лендинга GitLab, потому что это интересно и познавательно.

Первая тройка тяжеловесов:

1. @nuxtjs/i18n - 2.5Mb
2. slippers-ui (GitLab's Marketing Design System) - 1.8Mb
3. vue-mermaid-string (построение диаграмм) - 1.1Mb

На третьем месте хорошая библиотека для генерации налету диаграмм по тексту mairmaid . Я тоже хотел поставить её на Vue-FAQ, поставил, посмотрел насколько она просадила размер бандла и производительность в браузере, убрал и заменил генерацию налету на статичные заранее сгенеренные ею картинки ради UX.

На втором - slippers-ui, это гитлабовский относительно небольшой (20 компонент) UI kit. Без какого- либо тришейкинга и оптимизации, естественно. Очень много, с учетом того, что любая современная UI библиотека весит в несколько раз меньше.

Ну и победитель - то, за что так любят Nuxt. Это когда он берет что-то хорошее и делает его еще лучше. В этот раз он взял vue-i18n, естественно, для интернационализации.

Используя pkg-size.dev смотрим сперва на vue-i18n, отключив учет peer dependencies:

Install size: 2.8MB / 6 packages
Bundle size: 73KB minified (23KB gzip) / 9 modules

Очень неплохо для i18n библиотеки

То же с @nuxtjs/i18n:

Install size: 61MB / 239 packages
Bundle size: Не собрался (ошибки)

Error: Process exited with code 1
✘ [ERROR] No matching export in "node_modules/unicorn-magic/default.js" for import "toPath"

Bundlephobia тоже дала ошибки при сборке

Самая простая реализация i18n пишется в один composable. Но на Nuxt-e всё намного серьезней.

#nuxt #optimization #i18n #gitlab