Ночной бред

Хотел вам показать интересный пример, что иногда

JSON.parse(JSON.stringify(obj))

работает быстрее, чем

{...obj}

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

test(JSON.parse(JSON.stringify(objToCopy)))

значительно быстрее, чем

test2({...objToCopy})

Почему? кажется, что ответ на поверхности: запускаем Ноду с --allow-natives-syntax и проверяем

const a = {a: 1};
const b = {...a};
%HaveSameMap(a, b); // false

const c = JSON.parse(JSON.stringify(a));
%HaveSameMap(a, c); // true

Дело раскрыто, функция стала мегаморфной, JIT вырубился, можно писать пост.

Но! Попробуем добавить вариант с

test3(structuredClone(objToCopy))

test with JSON.parse: 268 ms.
test with structuredClone: 308 ms.
test with spread: 2802 ms.

Проверяем:

const d = structuredClone(a);
%HaveSameMap(a, d); // false

Таааак

Что же получается. И spread и structuredClone ведут к мегаморфности. Но при этом structuredClone не приводит к деоптимизациям.
Дальше докидываю

Object.assign({}, objToCopy)

и не смотря на мегаморфность

test with Object.assign: 238 ms.

Психую. Запускаю с --trace_deopt и вижу, что спред постоянно вышибает

(kind: deopt-eager, reason: wrong map)

Но почему Object.assign и structuredClone не приводят к деоптимизации? Я не знаю 🤡 и могу только предположить, что срабатывает какая-то дополнительная эвристика, и несмотря на то, что мапы разные, в деоптимизацию JIT здесь не уходит. (потому что надо спать!) А спред под такую эвристику не попадает (или, точнее, попадает через раз, так как чем больше попыток вызова, тем чаще случается деоптимизация).

Так, не пишите тесты глубокой ночью ) Одна загадка с утра раскрылась, но стало ещё веселей. Действительно, для structuredClone и Object.assign я в цикле не выходил из мономорфности, потому что стрелял клонами, они имеют между собой одинаковую мапу

const objToCopy1 = { a: 1, b: 2 };
const objToCopy2 = { a: 1, b: 2 };
const N = 100;

for (let i = 0; i < N; i++) {
    testFunction1(JSON.parse(JSON.stringify(objToCopy1)));
    testFunction1(JSON.parse(JSON.stringify(objToCopy2)));

    testFunction2({...objToCopy1})
    testFunction2({...objToCopy2})

    testFunction3(structuredClone(objToCopy1))
    testFunction3(structuredClone(objToCopy2))
}

Но вот что интересно, при увеличении N testFunction2 падает в деоптимизацию, %HaveSameMap({...objToCopy1}, {...objToCopy2}) вываливается в false.

Можете сами попробовать

const objToCopy1 = { a: 1, b: 2 };
const objToCopy2 = { a: 1, b: 2 };
const N = 13;

 for (let i = 0; i < N; i++) {
    console.log(%HaveSameMap({...objToCopy1}, {...objToCopy2}))
 }

В данном случае у меня на 13-й итерации (зависит от версии v8) мапы уже не равны.

gist чтобы погонять spread https://gist.github.com/melikhov-dev/51f92e84b7aa9456a4cdba0550130df7

Оказывается, Артём про это давно писал, не нужно было мне ночью не спать https://news.1rj.ru/str/artalog/178
C --nolazy-feedback-allocation упало бы сразу в деоптимизацию и было бы не так загадочно.

Встречал две стратегии работы с автотестами:

- повторный прогон, чтобы флапающие тесты прошли (дожатие)

- повторный прогон, чтобы поймать флапающие тесты и покрасить билд в красный

Первый вариант обычно идёт от бизнесовой, а второй от платформенной команды.

Так как я переехал на разработку на удалённой машине (ради чего пришлось отказаться от WebStorm), то оставалась одна боль — как визуально гонять E2E когда что-то ломается. Понятно, что с headless проблем нет, но иногда нужен headfull, чтобы пошагово подебажить.
Ради этого приходится локально держать копию проекта и гонять E2E из неё, но это просто неудобно.

Вчера попробовал сделать X11 форвардинг на MacOS и это вполне рабочая схема. Не супер-быстро, но, в целом, поковырять что-то вполне можно. Ставим XQuartz, прописываем ForwardX11 yes в .ssh/config — готово, ssh -X и мы можем запускать Playwright на удалённой машине и рисовать окошко у себя на макбуке. VSCode так всё это понимает бесшовно, красота.

В недавнем выпуске подкаста мы Алексеем обсуждали интервью Дагласа Крокфорда и историю JSON. На самом деле, там конечно много интересных моментов, которые не удалось затронуть. Попробою пересказать текстом, телега всё стерпит.

Во-первых про название «JavaScript». Вопреки расхожему мнению, что слово «Java» было тут добавлено Netscape, чтобы хайпануть на популярном в тот момент языке, Крокфорд утверждает, что это название было утверждено самой Sun и сделано ради амбиций Sun. В тот момент Netscape и Sun объединились против главного зла тех лет — Microsoft. Каждая компания предлагала своё решение для создания софта, не привязанного к операционной системе. Если Sun топила за виртуальную машину, на которой запускался универсальный бинарник, то Netscape за браузер, как универсальную среду. Не важно на какой вы OS, главное, чтобы на ней был браузер. Объединившись компании развивают чудовище — Java-апплеты. Мощное, но медленное и неприятное для пользователя решение.

В то же время у Netscape был язык Mocha (позже переименованный в LiveScript). И Sun это не нравилось. Зачем два языка в браузере? Зачем глупый LiveScript, когда есть прекрасная Java? Но Netscape видели потенциал скриптовых языков, потенциал программирования на событиях. Рядом уже расцветал HyperCard от Apple, новички, не стеснённые концепцией навязанной сложности неблокируемого асинхронного программирования творили на нём удивительные на тот момент вещи. Более того, великий Myst был написан на HyperCard! (этого факта я не знал, хоть и облизывался на Myst всю вторую половину 90-х). Да, Myst был собран фактически на коленке на домашнем скриптовом языке и вышел изначально только на Mac OS.

И тогда неожиданно нашёлся компромисс. Кто-то в Netscape (возможно Марк Андрессен) предложил переименовать LiveScript в JavaScript и солгать миру, что это такое подмножество Java. И Sun неожиданно согласились.

И вот сидит молодой Крокфорд, смотрит на это подмножество Java и думает, что это самая тупая вещь на свете, которую он видел. Но она работает в вебе, запускается мгновенно и ей не нужен JVM. И прекрасно решает стоявшую перед ним задачу создания интерактивных чат-комнат. Вот только вся команда Крокфорда, услышав про JavaScript посылает его куда подальше. И ему приходится разбираться самому, как писать на этой странной скриптовой Java, в которой не работают основные концепции Java.

Он страдает страдает, но в какой-то день до него доходит — это не Java 🤡. Это совершенно другой язык и, более того, в нём есть концепции, которых нет в других языках. Прежде всего, в нём есть функции как сущность первого класса и у функций есть лексическое замыкание (что было на тот момент только в Scheme). И функции могут быть анонимными, настоящие лямбды! Более того, язык ещё и мультипарадигменный.

Ну вот тут Крокфорд полюбил JavaScript, оседлал волну хайпа, стал везде выступать, консультировать и написал свою книгу и первый линтер для JS (JSLint).

В следующем посте расскажу про JSON.

Продолжаем.

Проникшись JavaScript Крокфорд чуствует, что будущее за Single Page Application (про которые пока ещё никто не знает). В своём стартапе State Software он с командой прорабатывает идею веб-приложений, написанных на JavaScript. Ну и быстро понимает, что XML очень жмёт. А надо сказать, что в тот момент XML был главным и важнейшим стандартом передачи данных. Умные именитые ребята ходили и убеждали всех, что будущее только за XML. Крупные компании вкладывались в XML. Где-то рядом уже запихивали XSLT в браузеры. All the hipsters were excited about XML 🤡.

Но вот сидит Крокфорд и грустит, что для того, чтобы запихнуть XML в JS ему нужен парсер. Но, тут вдруг его осеняет, что гораздо проще передать литерал объекта текстом, так, как мы уже привыкли создавать объекты в JS. И тогда парсер будет очень простым и объём кода, передаваемого по сети станет меньше. Даглас и Чип Морнингстар собирают концепт и идут искать инвесторов.

А на дворе самое начало нулевых, крах доткомов и инвесторы очень осторожны. Они не хотят вливать деньги в то, что не является стандартом. XML вот стандарт. Там есть инструменты. А ваша поделка завтра рассыпется и что делать? Тогда Даглас и Чип придумывают название нового стандарта — JSON (JavaScript Object Notation), Даглас покупает домен json.org и запиливает свой знаменитый сайт, который вы все возможно видели. У нас есть сайт и название, мы стандарт! :)

Дальше начинается битва с Дэйвом Винером который на тот момент был очень влиятельным разработчиком и создателем XML-RPC. Винеру очень не понравился JSON и он достаточно резко прошёлся по нему в своём блоге. «Я тут услышал о чем-то под названием JSON, что предлагает решить проблему, которая была аккуратно решена XML-RPC в 1998 году»

Кстати, Даглас назначает Винера ответственным и за популяризацию SOAP (тут Даглас язвит - Simple Object Annoying Protocol. I don’t remember what the A was, but it might have been atrocious or abominable, I don’t know) Но сам Винер признаёт, что SOAP so difficult to program если сравнивать его с оригинальным XML-RPC.

В общем, Винер смотрит на JSON и кричит «ВЫ ЧЕГО?!! ЭТО ЖЕ ДАЖЕ НЕ XML!», предлагает найти разработчиков этого чуда и привязать их к дереву. Кажется, Крокфорда это обидело на всю жизнь.

В любом случае, дело идёт так себе инвесторы не верят в идею и не дают денег, но тут появляется Gmail и совершает AJAX-революцию (X значит XML, хе-хе). Теперь все хотят SPA. Вера в будущее веба на XHTML и XSLT растворяется. Люди перестают думать про XML-инструменты. Новым людям, пришедшим сразу в веб был нужен стандарт, менее жирный, чем XML.

Тут Даглас говорит интересную штуку, что сложность формата XML породила логическую ловушку о том, что и все инструменты вокруг него должны быть сложными. И эта накопленная сложность воспринималась как должное и гуру XML говорили «ну да, мы делаем сложные штуки, а как вы хотели?». А тут появились ребята, которые топили за простоту, а не за сложность. И ментально было сложно принять, что все твои сложные знания уже больше не нужны, что инструменты стали простыми, что передача данных по сети — это очень просто. Что хорошо и красиво — это когда просто, а не когда сложно.

В итоге, JSON победил, а XML проиграл. JSON вошёл в стандарт и получил MIME type application/JSON. А Крокфорд хотел конечно text/JSON, потому что ну причём тут Application? Почему есть text/XML но нет text/JSON? Крокфорд не знает, шутит, что это месть ему от XML-фанатов.

Вот и всё. Даглас считает, что JSON это и была самая главная вещь, которую он сделал в своей жизни и второй великой вещи у него уже не выйдет.

А я однажды передал Дагласу соль, сидя с ним за столом. Возможно, это и был высшая цель моего существования :_)

TIL

Можно оверрайдить красиво через переменную $<имя пакета> (но лучше не оверрайдить, конечно).

{
  "dependencies": {
    "foo": "^1.0.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "foo": "^2.0.0"
    // GOOD, specs match so override is allowed
    // "foo": "^1.0.0"
    // BEST, the override is defined as a reference to the dependency
    "foo": "$foo",
    // the referenced package does not need to match the overridden one
    "bar": "$foo"
  }
}

Тут спрашивают, а зачем вообще оверрайдить зависимости? Причин может быть несколько:
- Причесать зоопарк в транзитивных (например, жёстко задать одну версию lodash или axios)
- Точечно починить транзитивные зависимости в тех либах, на которые автор уже забил
- При переезде на npm 8 и выше починить кривые peerDependencies
- Придумайте сами

Причём, овверайдить можно как глобально, так и точечно, подменяя один пакетик в глубине зависимостей.

Вот и я встретился в рабочем проекте со зловредным Синдре Сорхусом и его движением Pure ESM package.

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

Вот только переключить так сходу свой большой проект на сборку в Тайпскрипте в ES modules я, кажется, не готов. Но что делать, кажется придётся потихоньку.

Просто любопытно — есть ли у меня в подписчиках такие преисполнившиеся оптимизациями ребята и девчата, что отключили алгоритм Нейгла в node.js?

30 апреля — время отключить Node.js 14. Тимур Шемсединов выпустил отличный чеклист по миграции https://github.com/HowProgrammingWorks/Drop-Nodejs14 .
Добавлю про lockfileVersion: 2. На него имеет смысл переходить, если у вас CI крутится на node 14 и вы хотите переехать плавно. Если везде подняли npm до 8 и выше, то можно сразу на lockfileVersion: 3.

Что не так с iframe

Довольно часто у бизнеса возникает желание запихнуть продукт в iframe и вставить так в чужой ресурс. Всё нормально до тех пор, пока не возникает вопрос аутентификации пользователя. Обычно мы сохраняем идентификатор сессии в куку, и вот тут проблема, что куки в данном случае становятся third-party, т.е. принадлежат не тому сайту, где установлен iframe, а третьей стороне.

Chrome и FF ещё можно обойти, если переставить аттрибут SameSite в none (напомнию, что по дефолту там Lax, который так же не даст отправить куку в iframe). Конечно, вам придётся повоевать с безопасниками и защитить ваше решение понизить безопасность у сессионной куки. А вот в Safari уже несколько лет как включен Intelligent Tracking Prevention (ITP) который режет куки в любом случае. Кстати, режим инкогнито в Chrome так же режет все third-party куки.

ITP блокирует все third-party cookies по умолчанию. Обойти его можно двумя способами:

- Заставить пользователя в настройках снять галочку Prevent cross-site tracking, что повлияет на все сайты
- Воспользоваться Storage Access API, с помощью которого мы явно запросим у пользователя разрешения прочитать куки с третьей стороны

Storage Access API имеет достаточно жёсткие ограничения и задействует различную неоднозначную эвристику, пытаясь догадаться, действительно ли пользователь хотел разрешить доступ. А пользователь может и не захотеть. Но, самое важное, это API закрыто в Chrome за флагом. Почему же? Скорее всего, потому, что ломает рекламный бизнес Гугл :_)

Что же делать? Вы не должны встраивать ваши сервисы в iframe as is. Вам придётся провернуть какой нибудь трюк. Например, открыть встраиваемый сервис во втором, «честном» окне, пройти аутентификацию, получить временный токен и перекинуть этот токен через postMessage в окно со страницей со встраиваемым iframe. И вот там уже перезагрузить iframe передав ему токен как get-параметр. И никаких кук.

Это не значит, что вы должны отказывать продактам в их странных желаниях. Желания продиктованы бизнесом. Но продакт не должен просить iframe. Он должен просить возможности встраивания, а вот как оно будет сделано — зависит от того, что мы сможем сделать, как разработчики.

Не обновляйтесь на node.js 16

В этом нет большого смысла. Node.js 14 закончила свой срок жизни и лучшим выбором сейчас будет переехать сразу на v18. И v16 и v18 являются поддерживаемыми LTS-версиями, но жизнь v16 закончится гораздо раньше, чем могла бы быть в обычном релизном цикле — уже этой осенью, а именно 11 сентября. Связано это с тем, что 11 сентября прекратится поддержка OpenSSL 1.1.1, больше не будут выходить никакие патчи для него (да, там был вариант взять OpenSSL 1.1.1 из CentOS и протянуть ещё годик, но не сложилось).

Так получилось, что Node.js 16 не успела получить OpenSSL 3. Да да, тот самый из-за которого вам приходится писать --openssl-legacy-provider чтобы обойти ошибку ERR_OSSL_EVP_UNSUPPORTED на Node.js 17+. Возникает она от того, что в коде библиотек задействованы устаревшие криптографические алгоритмы и, как шутят авторы, ключ `legacy` открывает вам двери в дом престарелых алгоритмов.

К счастью, все важные библиотеки уже успели обновить свой код и если у вам нет престарелых зависимостей, то скорее всего ключ --openssl-legacy-provider вам будет не нужен. Так что смело обновляемся на v18, там уже v20 на подходе.

Ого, и я не знал, что в 18-й отключили по-умолчанию, пропустил.

Изучаю эту тему, и выяснил, что NodeJS с версии v16.15.0 помимо метода setNoDelay внедрила во многие сетевые конструкторы опцию noDelay (а также keepAlive and keepAliveInitialDelay). А так как почти все агенты прокидывают входящие опции ниже по течению, теперь есть возможность отключить delay из юзерленда даже в библиотеках, которые об этой опции не знают, и не нужен доступ к самому объекту сокета.

А начиная с NodeJS 18.0.0 метод http.createServer по умолчанию использует noDelay: true !!!
🪄💫 Пруф

Спасибо за наводку, очень интересно:)

С remote - SSH начинаю день с
ps -aux | grep "node --inspect" | grep -v grep | awk '{print $2}' | xargs kill -9

UPD

В комментах подсказали, что причина может быть в nodemon, и решается явным пробросом сигналов nodemon --signal SIGHUP

А я говорил (яжеговорил), что лямбды это дорого. Лямбды это способ гибко быстро масштабироваться при очень редких пиковых нагрузках, но держать на них большой проект — решение очень спорное.
А монолит.. Ну тут как с чиплетами, раз нужна скорость, значит придётся собирать всё вместе, поближе.

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

Продолжение от DHH https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580

В свежем выпуске подкаста напомнил соведущим, что error.stack это не стандарт. Тут же Лёша отыскал пропозал по Error.prototype.stack. TS вот согласен, поля stack в объекте Error может и не быть:

interface Error {
    name: string;
    message: string;
    stack?: string;
}

Как мы много узнали про ошибки и исключения в тот момент, когда TS 4.4 переключил catch(e) из any в unknown :) Пришлось разбираться и вспоминать, что в исключении может лететь не ошибка, а что угодно, например строка ( throw 'Oops' ). Набор полей там неизвестен, обработчики исключений необходимо писать, чтобы они сами не падали в исключения (а я встречал и такое).

На самом деле V8 даёт несколько довольно интересных механизмов по работе с трейсами. Например, можно увеличить глубину стектрейса через Error.stackTraceLimit или через флаг v8 --stack-trace-limit.

Ещё из интересного — так как остальные движки представляют стек просто как строку, то V8 решил не ломать это поведение, но даёт нам доступ к методу Error.prepareStackTrace(error, structuredStackTrace) который вызывается в момент обращения к свойству stack. И вот тут уже внутри метода можно работать с нормальным объектом structuredStackTrace и переписать весь вывод так, как нам нравится. Но опять же, напомню, что только в V8.

Подробнее в блоге V8