Точно, я и забыл, это же школа в Одессе

Как сказано из тайтла книги, эта книга будет сфокусирована на JS, как языке в вакууме, что меня лишь натолкнуло на правильный ход мыслей, но не дало понимания проблемы. А проблема крылась в том, что Node.js состоит из условно 3 крупных макроблоков:

1) V8
a) Ignition interpreter (Parsing, AST formation ... bla-bla, scheduling for optimization.
b) TurboFan (for optimized code).

2) libuv library( абстракция для ОС и её примитивных операций + сам концепт Event Loop ).

3) Собственные библиотеки Node.js для всего


В сухом остатке:

1) node.js по дефолту использует асинхронные операции, где это возможно, но это возможно только для части из них, в остальных случая реализация блокирующая, увы

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

3) нужно всегда помнить, где исполняется JS, а где мы пересекаем эту границу и в ход идёт c++ и всякие жуткие вещи, как epoll-ы на уровне ОС (they're *unix-specific)


Могу скинуть пачку ссылок на ютьюбе и статейиз блогов, где об этом подробнее гораздо, если тов. Архитектор не будет против.

Там еще из сюрпризов есть внутренняя типизация для arrays. Если кратко, то перед отправкой на оптимтзацию часто используемых блоков нашего JS кода, Ignition проставляет для arrays типы данных и работает это однонаправленно. Соответственно, имеем такую схему :
Если мы создаём пустые(holey) аллоцированные участки памяти для еще не пришедших данных:
const a = new Array(10);
То мы теряем оптимизацию навсегда для конкретных типов.
Это не приговор и если вы не часто вписываете или переписываете эти данные, то это нормальная практика.
Но если вы планируете много изменений вносить, то никогда так не делайте и лучше пишите код так, будто вы пишете в жестко-типизированном языке.

Надеюсь вы это прочитаете, Андрей 🤣

читаю ) интересно

Раз такая тема, то вот еще подвох для изучения: setImmediate() и process.nextTick() работают мягко говоря не так, как это следует из их названий :)
Это libuv легаси, нам с этим жить.

ну тоже самое и про setTimeout можно сказать ) я ж когда-то думал что если туда передали 5000 скажем, то ровно через 5(+- eps) сек выполнится нужное действие

Ну, разумеется, это относится к таймерам в целом

Серия книг отличная, кстати. Рекомендую все-таки прочитать.
Но этого(я выше писал) он там не объяснял, если мне память не изменяет, поэтому все просто магически нужно принимать, как есть.

подскажите, есть front SPA, back node, auth0
мне на фронте надо получить sessionID
и я что-то ума не приложу где его брать с учетом авторизации через auth0

В document.cookie, если не установлен httpOnly

ты уверен что тебе нужен sessionID, а не JWT?

в аналитику надо отправлять sessionID, вот я и думаю что его роль выполняет

"Если мы создаём пустые(holey) аллоцированные участки памяти для еще не пришедших данных:
const a = new Array(10);
То мы теряем оптимизацию навсегда для конкретных типов."

что-то совсем не понял)
а если у меня масив изначально заполнен строками и цыфрами, то он что лучше будет работать? о0

Я не считаю, что я - тот человек, который компетентен отвечать на ваши вопросы, но попробую.

Краткий ответ: да.

Полный ответ:
Там существует иерархия типов, в которой сущестуют 3 типа данных :
1) smi_elements
2) double_elements
3) elements
Каждый из которых имеет по две реализации, в зависимости от того, как именно этот участок памяти был создан и заполнен:
1) packed_... (наиболее оптимизированные)
и
2) holey_... (это те, которые были сначала созданы пустыми)

Ключевой момент здесь в том, что переход из одного класса в другой может быть только по стрелочкам( без потери оптимизации TurboFan для конкретного типа данных):
Packed_smi_elements -->
Packed_double_elements -->
Packed_elements.

Однако, в случае, если вы создали пустой участок памяти, то он навсегда теряет возможность быть высокооптимизированным и идет по линии holey:
Holey_smi_elements -->
Holey_double_elements -->
Holey_elements.

Также, есть способы потерять оптимизиацию 'вертикально", то есть из Packed_smi_element > Holey_smi_element
Вот так.

Назад нельзя двигатся ни "вверх" ни по стрелочкам.

И еще момент, к этой иерархии справедливо: чем ближе к packed_smi_elements, тем быстрее (и наоброт самый медленный это holey_elements), а также packed > holey(всегда быстрее holey)

Еще один подлый момент с +0 и -0 :

// packed_smi_elements
const a = [1, 2 ,3 , +0];

// packed_double_elements
const a = [1, 2, 3 , -0 ];