#spec
Что такое асинхронность/много-поточность с точки зрения официальной спецификации ECMAScript.

С точки зрения официальной спецификации - эти термины НИЧЕГО не обозначают.
И никогда не существовали.

Откуда растут ноги?
В далекие былинные времена (1997 год - 2015 год), спецификация языка ECMA была устроена таким образом, что взаимодействие JS кода, с JS кодом, например в другой вкладке, организовать было невозможно. По крайней мере, используя только возможности ECMA спецификации.

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

В силу этого опыта, появляется ряд докладов, о JS, где подобное поведение оправдывается его(JS) односторонностью.
С чем, в целом можно согласиться.

С 2017 года, когда официальная спецификация ECMA реформирует работу языка, декларируя термин Мульти - Агент, когда в спецификации появляется Atomics API - язык JS получает ту форму, которая позволяет HOST среде, так выстраивать исполнение JS кода, как ей (HOST) среде хочется. В том числе предоставляя API для всех возможных (паралельных )форм исполнения кода.

С 2015 года, когда официальная спецификация ECMA получила описание Promise, мы получили возможность от HOST среды в рамках списка задач - GenericJob и очереди задач PromiseJob - регламентировать процесс работы с JS кодом.



Что все это значит
До 2015 года, не существовало никаких механизмов в рамках спецификации ECMA, которые бы позволяли управлять потоком исполнения JS кода. Что, например, в том числе приводило к тому, что код одной влкдаки мог блокировать код другой вкладки.

Это поведение породило массу докладов, где авторы рассказывали о одно поточности JS языка, обосновывая это примерами из поведения выше. То есть маркирование JS как одно поточного языка.

С 2015 года, появляется официальный механизм управления выполнения кодом задач в ECMA, что автоматически приводит к тому, что тот же пример с вкладками перестает работать. стал ли JS много-поточным? (только потому, что соседние вклкдки перестали виснуть?)

С 2017 года, появляется API взаимодейтсвия (ATOMICS Api) для доступа к одной и той же области памяти.
С 2017 года появляется формализация процесса, который называется Claster Agent, который является абстракцией над процессом, кода любое католичество програмного кода, может взаимодействовать друг с другом, но при этом исполнеяется разным агентом.


Что из всего это следует
Язык JS, который регламентируется спецификацией ECMA, получил согласно спецификации, фозвомжность взаимодейтсвия разных блоков кода, между собой в условиях, когда они имеют доступ к одной и той же области памяти.

Язык JS - это язык, той формы абстракции, который не отвечает и не может отвечать на вопрос, КАК решается эта задача: многопоточно, асинхронно, мульти-процессами, вытесняющей многозадачностью и так далее.
Это язык, который предоставил с 2017 года, HOST среде, решать задачи в несколько Агентов, которые(агенты) могут взаимодействовать между собой на уровне абстрактного API, которое может быть реализовано как многопоточно, последовательно так и и любой другой форме которую придумают или реализуют на машинном уровне.

Это не задача JS - решать какая форма взаимодействия. Его задача была только в том, чтобы дать возможность HOST среде это сделать, что и появилось частично в 2015, и более полно с 2017 года.


Вместо ИГОГО
В былинные времена, язык JS был устроен таким образом, что он не позволял организовать вычисление разного кода, который бы мог между собой взаимодействовать.

С 2017 года, такая возможность появилась.

При этом сама спецификация - не диктует форму такой работы. Ее это не волнует. Она предоставляет только асбтракцию, которая позволяет взаимодействовать между собой таким блокам кода (Atomics Api)

То есть - утверждать в какой форме работает JS код (асинхронной, много-поточной или хуеточной) мы не можем, за исключением того, что HOST среда, может выбрать сама на основании тех возможностей которые предоставляет своременная спецификация, работать так, как ей удобно.

#spec
Какой ответ про асинхронность/много-поточность от Вас ждут на типичном собеседовании

Что JS однопоточен, на основании того что такая абстракция как Agent сама не может распаралелить вычисления в несколько потоков.

При этом, можно заметить, что язык JS регламентируемый спецификацией ECMA - это язык того уровня абстракции, где такие вопросы как много поточность, или что-либо подобное не могут регулироваться, подобно тому, как не регулируются вопросы работы с памятью.

И если возникает вопрос о потоках, то следует уточнить: какая у нас имплементація спецификации (v8, spider monkey, coreJS) и в каком окружении сама эта имплементация работает.

Потому как тот же V8 в случае windows OS реализует мультипроцесную модель взаимодействия, когда в случае Linux - мульти потоковую.


Вместо ИГОГО
Не в рамках возможностей языка JavaScript оценивать как он работает - однопоточно или как-то еще. Это регламентирует HOST среда в рамках возможностей которые предоставляет спецификация языка.

Современная спецификация, позволяет организовать работу JS кода, в любой из доступных форм, при этом сама спецификация - никаких стурктур для этого(форм ИСПОЛНЕНИЯ кода) не предоставляет. Но делает это возможным как для HOST среды, так и для предоставляемого API

Понедельник, 22-00 по Киеву
Посмотрим вместе: СОБЕСЕДОВАНИЕ НА MIDDLE FRONTEND РАЗРАБОТЧИКА. Уничтожение за 6 лет опыта

https://www.youtube.com/watch?v=e0DKj6JGDVQ

#spec
Замыкания с точки зрения официальной спецификации ECMA

Короткий ответ:
Формально, такой термин как замыкание - никак не описан спецификацией. Больше того, для пояснение работы любой из частей спецификации ECMA, термин замыкание - не требуется в принципе.

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

Проблемы начинаются там, где об этом начинают спрашивать на собеседованиях, ожидая "правильный" ответ, который в лучшем случае, правильный только частично.



Длинный ответ:
....
Я понял что сломаю пальцы записывая этот ответ и решил включить трансляцию про это самое.


22-00 по Киеву
Замыкания с точки зрения официальной спецификации.

https://www.youtube.com/watch?v=RvYq-wt_GEU

Суббота 21-00 по Киеву
Глазами реверс-инженера: Google Docs Internals

Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.

https://www.youtube.com/watch?v=2zKya01zYK4

🧩 Практичний майстер-клас Тимура Шемсединова
🗓 5 липня о 15:00
Тема: ⚡️Фічі швидше на ⅓ без перероблення і багфіксів!
Розберемо техніки й підходи які дозволять вам:
1. Пришвидшити розробку
2. Знизять кількість багів
3. Зменшать час на підтримку чинної кодової бази
👨‍💻 Для кого ефір? — мідли, сеньйори
https://wep.wf/st7j67?utm_source=telegram_channel&utm_medium=t_shemsedinov&utm_campaign=stream_05_07

Стрим про реверс Google Docs перенесен с сегодня 21-00
на сегодня, 11 утра.

Если Вам нечего делать в субботу утром, присоединяйтесь.
Там будет над чем подумать всем вместе.

https://www.youtube.com/watch?v=2zKya01zYK4

И снова все перенеслось на 21-00 вечера по Киеву.

По этому поводу вспоминается один анекдот:

Маугли и Каа сидят под пальмой.

Маугли:
- Каа, а видишь вон на высокой пальме банан?
- Да Маугли вижу...
- А Багира сможет его достать?
- Нет, Маугли, не сможет.
- А Балу сможет его достать?
- Нет, Маугли, не сможет.
- А ты, Каа, сможешь его достать?
- Нет, Маугли, не смогу.
- А я смогу его достать?
- Ты, Маугли, кого хочешь достанешь...


Ваш маугли.

Разыскивается художник, который сможет нарисовать глаза реверс - инженера.
А то у меня не получаются.

У рисовалок с претензией на интеллект - тоже.

Если Вам нечего смотреть вечером, посмотрите

wolf walkers

https://youtu.be/ord1YzvlDvs?si=mRY_lbBca0vW3CtW

Стрима сегодня не будет.
Я в коматозе.

Сегодня вскр 21-00 по Киеву
Глазами реверс-инженера: Google Docs Internals

Попробуем вместе найти все, что можно найти
и поковырять все что ковыряется.

https://www.youtube.com/watch?v=2zKya01zYK4

Что я пытался донести, рассказывая о Замыканиях в контексте ECMA specifiation.

Я придерживаюсь того мнения, что применение в обиходе какого-либо термина, должно нести что-то больше, чем просто название процесса.

Например термин Expression (выражение) в рамках спецификации ECMAScript дает понять, что какая-либо часть языка, которая названа Expression - возвращает результат, который может использовать другой Expression, без необходимости формирования отдельного Statement. ( То есть этот синтаксис, может быть частью другого синтаксиса)

a + b; // Expression; Значит он может быть частью другого Expression
theArr [ a + b ];

Замыканиями в языке JavaScript, пытаются пояснить процессы, которые действительно отвечают, как минимум части теории замыканий. При этом, в самом языке JS существует очень простая для понимания концепция Environments, которая в отличии от Замыканий, полно и со всех сторон описывает ВСЕ части JS языка. В тоже время когда Замыкания, касаются только одного частного случая.
Иными словами, это искусственный в рамках ECMA spec термин, который дублирует часть функциональности другого термина той же спецификации.

Потому, мне хочется настаивать на том, что на каких либо собеседованиях использовать вопросы о замыканиях - порочно. Так как они, провоцируют у соискателя, изучение только той части теории, которой достаточно для ответа. И не больше.
При этом - эта часть формирует ограниченное восприятие как самой теории, так и того что она описывает в части JS.

И если уж спрашивать о замыканиях в JS, то спрашивать ВСЮ теорию, по крайней мере в ее фундаментальной части.

И даже в этом случае я бы бухтел, потому, что это отвлекает от того, как описан язык современной спецификацией. Понимая которую, можно обьяснять ВСЕ типичные вопросы о "странностях" языка, таких как - потеря this как контекста, разницу в поведении для глобального окружения и функционального окружения, let/const vs var и т.д. и т.п.

И, тем более, почему алгоритмы, используемые V8 для оптимизации кода работы с "переменными", работают именно так, а не иначе.

22-00 по Киеву
Глазами реверс-инженера: Google Docs Internals [2]

Во второй части, попробуем написать код, который будет использовать найденные Google action.
Попробуем решить задачу, как нам интегрироваться в код Google Docs, при условии, что имена классов, функций, конструкторов и переменных все время меняются.


https://www.youtube.com/watch?v=xUvdte3tzYM

Сегодня вторник в 21-00 по Киеву.
Производительность Async Function

Как работают Async Function.
Разберемся в том почему Async Function не лучший выбор для эффективного кода.
Посмотрим на примерах, как можно решить некоторые из них.

https://www.youtube.com/watch?v=VfQiG2jATgQ

Кому нечем заняться.
Задача про суть трансляции async function

Естькод:

var theFetchList = [
  fetch("https://a.com"),
  fetch("https://b.com"),
  fetch("https://c.com")
];

Promise.all (theFetchList).then( console.log );

Заглянув в DevTols вкладку Network то мы увидим, что было отправлено паралельно три запроса, результат работы которых мы и увидели как реакцию на Promise.all после удачного их завершения.


Задача:
Сделайте тоже самое
1) не используя Promise.all или любых других методов Promise
2) с использованием async function
3) запросы должны идти паралельно, то есть так же как в случае Promise.all

Урезанная до 1 часа версия (без вопросов ответов)

https://www.youtube.com/live/A6zgTaxo3R4

Backend Developer (Node.js) — iGaming
📍 Формат: віддалено
📅 Зайнятість: фуллтайм / парттайм
💰 ЗП: обговорюється

Ми — продуктова iGaming-компанія, що розробляє ігри та backend-рішення для онлайн-казино. Шукаємо досвідченого Node.js-розробника з реальним досвідом в iGaming, щоб підсилити нашу команду.

Що потрібно робити:

⏺️ Розробка та підтримка backend-логіки (слоти, instant, crash)
⏺️ Робота з RGS, ігровими сесіями, ставками, API
⏺️ Масштабована архітектура та високе навантаження

Вимоги:

▶️ 4+ років досвіду з Node.js + TypeScript
‼️ Обов’язковий досвід в iGaming
▶️ Добре знання SQL/NoSQL, WebSockets, REST
▶️ Розуміння механік iGaming: сесії, ставки, раунди

Буде плюсом:

✅ Робота у гейм провайдері
✅ Досвід з NestJS, Redis, Kafka
✅ Робота з ігровими рушіями або RGS
✅ Участь у сертифікації ігор

📩 Надсилай відгук @growthac

Еще раз про Big O и почему он бесполезен в JavaScript

Есть целое направление в математике - оценка сложность алгоритма. Суть которой оценить какой алгоритм эффективнее другого.

Big O - это один из методов оценки временной сложности алгоритма. Таких методов больше десятка разных. В JS сообществе получило распространение именно Big O по причине того, что на JS собеседованиях и в разных видео стали упоминать именно его игнорируя прочие.


Почему Big O в JS это проблема.
Оценка сложности алгоритма оценивает только сам алгоритм который был поставлен на вход той методологии которую мы выбрали.

Он не оценивает стоимость имплементации этого алгоритма конкретным инструментом. Например языком программирования JS.

Проблемы с оценкой становятся столь большими, сколь высоким уровнем абстракции пользуется выбранный инструмент. Язык JavaScrtip - это язык программирования с наибольшим уровнем абстракции.

Иными словами, мы имеем дело со сферическим конем в вакууме. Когда оценка самого алогритма может радикальным образом расходиться со временем демонстрируемой самой реализацией.

Простой пример:
Реализация типа Array в V8 (реализации JS) устроена таким образом, что V8 самостоятельно выделает некоторый минимальный обьем оперативной памяти для обслуживания 4 елементов пустого Array.

В том случае, если происходит ситуация, когда все 4 слота использованы, то есть мы добавили в наш Array 5 элемент, это приводит к тому, что V8 выделяет новую память в два раза больше чем ранее, КОПИРУЕТ в нее все элементы массива.

Память использованная ранее, помечается на очистку GC.

Теперь представим ситуацию, когда наш алгоритм требует оперированием не 4 элементов, а например 4 000 000 000 эллементов. Представте ситуацию, когда все Слоты выделенные для этого Array уже заполнены. И тут алгоритм добавляет еще один элемент.

Это заставит V8 скопировать 4 миллиарада эллементов в область памяти, которая согласно его алгоритму будет умножена на два. То есть потребует 8 гб памяти. Если оперативной памяти будет не достаточно, и мы работаем в системе, которая использует swap (дисковые IO) для решения подобных вопросов, то это приведет к интенсвиным IO с диском.

Представим дальше, что наш алгоритм удаляет этот элемент из нашего 8млрд массива.
Это приведет к обнулоению этой области памяти создания другой в два раза меньше. Снова IO со свапом.

А теперь мы снова добавили элемент. И снова выделение памяти и снова IO.

И теперь представим алгоритм, реализующий иную сложность, но потребляющий меньше памяти на столько, чтобы не попадать в коллизию выделения/обнуления памяти.

Какой алгоритм будет работать быстрее?
Нам уже нужно учитывать не только итерации, не только память, но и то, как быстро работает наше дисковое IO, какие лагоритмы используются там - и так далее.


Как следствие, оценка временной сложности реализации алгоритма на языке JS, оказывается невозможной, без оценки возможностей самой реализации самого языка JS.

Как следствие, BIG O, без учета особенностей имплементации V8 это сферический конь в вакууме. Который может дать как правильный прогноз так и совершенно противоположный.


Другой пример из области теоретической механики
Кто учился на специальностях подобных инфизу, наверняка проходил курс Теоретической механики.
И должны помнить один из ее парадоксов:
Пусть у нас есть катушка с намотаной на нее ниткой.
Пусть отмотана часть нитки.
Что будет если потянуть за эту нитку?
Ответ - катушка будет наматывать нитку за которую мы тянем.
Это следствие упрощений теормеха.


Так вот Big O - это теоретическая механика, которая тем больше точна, чем ближе мы к тому набору упрощений которые используются для ее работы.

В случае Big O - наиболее точная оценка дается если алгоритм реализован на языке ассемблера. И тем меньше чем выше уровень абстракации. В случае языка JS эта оценка может давать совершенно противоречивые результаты, в силу того, что под каждой строкой кода, лежит СВОЙ алогоритм издержки на реализации которого могут оказаться очень дороги.

Вместо ИГОГО
Оценка сложности алгоритма BIG O, как и любая другая, в случае если за скобки выносится язык программирования, штука полезная но абстрактная. Которая становится столь больше бесползеной, сколько сложно работает язык программирования.

Можно ли использовать BIG o для адекватной оценки JS кода?
Можно, но при условии, когда на вход поадется не просто алгоритм, но алгоритм со всеми особенностями имплементации языка программирования JS. Без которых результат будет фальсифицирован.

Как следствие, того, что никто не может представить всю сложность имплементации современного JS, использование BIG-O бесполезно. И намного проще, а главное надежнее использовать простое профилирование своего кода.

Печать подпись.

Примеры возникающие с тем же Array на равном месте, на канале AsForJS.