судя по всему трансляция переносится на завтра.
снова сидим без света без перспектив на включение.

12:00 По Киеву

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

Напоминалка
22:00 По Киеву

Таймкоды:
00:00:00 Музыка
00:11:00 Приветствие
00:18:00 Начало по сути
01:15:00 Ответы на вопросы
01:15:45 Ловим Кота!!!
01:17:20 Откуда вероятность в 25% срабатывания requestAnimationFrame раньше setTimeout
01:38:40 О логике поведения EventLoop
02:00:00 Выяснение деталей относительного того есть 4мс задержка по умолчанию у setTimeout или нет
02:28:30 Еще одна попытка с другой стороны рассказать о TaskQueue и MicroTaskQueue
02:45:25 Про Event Loop лучше забыть и не вспоминать
02:53:00 setTimeout в Node

https://www.youtube.com/watch?v=-FmCm-Wjdok

Рекорд лаконичности: 23 минут из которых 3 музыки и еще 2 в конце повтор выводов.

Таймкоды:
00:00:00 Музыка
00:02:08 Начало по сути
00:03:21 Таймеры и стандарт HTML5
00:11:24 Таймеры и NodeJS
00:13:32 Сравнение таймеров HTML5 и NodeJS
00:17:37 Таймеры и d8
00:18:20 Откуда взялся миф про ограничение 4мс на таймер

Ссылка на презентацию: тыц


https://www.youtube.com/watch?v=MxL04wXIyBQ&list=PL3ziSA8uO7KmJo-QbCvhj57cVW5JF5Nyx

посмотрите "могила светлячков"
может быть єто даст вам возможность понять.

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

6:30 по Киеву

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

16:30 по Киеву

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

11:30 по Киеву
JavaScript Live Coding: Morse. Часть 2.
https://www.youtube.com/watch?v=ZU0St05ifyQ


22:00 по Киеву
JavaScript: От мифов к спецификации. Часть 2 раздел 3 - Выражения
https://www.youtube.com/watch?v=lq5vi6DmEpA

11:30 по Киеву
JavaScript Live Coding: Morse. Часть 2.

Таймкоды:
00:00:00 Музыка
00:05:50 Ай нє нє. Настраиваемся. Жуки ползают.
00:09:15 Кратко что было в первой части
00:17:40 Решение задачи в лоб
00:35:01 Почему решение в лоб, не очень
00:37:01 Готовим другое решение и знакомимся с copy в DevTools
00:44:11 О связи Морзе с двоичным представлением чисел
01:00:10 Адаптируем код приведения двоичной формы к декодированю Морзе.
01:10:41 Мурыч открыл для себя возможность использования в обьекте специального property "toJSON", которое позволяет управлять приведением обьекта к JSON
01:17:17 Пишем код преобразования Морзе к числу подобно двоичной форме
01:43:50 Сопли про бумажную книжку
01:56:47 Проверяем текущий вариант на codeWars
02:01:15 Разбор по шагам как сейчас работает конечный автомат
02:15:10 Вопросы: Про innerText, санитайзеры, chatGpt и т.д.
02:41:30 Итоги по текущему решению Морзе и что будет в следующий раз.

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

17:00 по Киеву
⎡razbor:10⎦ Разбираем видео: "Утечки памяти в SSR. Владимир Захаров"
https://www.youtube.com/watch?v=dLSPBz3wK_Y

21:00 по Киеву
⎡coding: 06⎦ JavaScript Live Coding: Morse. Часть 3.
В третьей части, мы сосредоточимся на решении кода Морзе с использованием языка JavaScript и строго в рамках концепции конечных автоматов.
(Это то, что я забыл сделать в части 2, сразу перейдя к двоичному представлению индекса)

https://www.youtube.com/watch?v=hX0w6efA-oo

Вот и прелетело мне на YT за разборы видео.
Я все ждал ждал у кого у первого руки зачешутся.

Людей волнует не факт качества подаваемой информации, но возможность ее монетизации так долго как это возможно.

Это восхитительно. Особенно в плоскости того, что факт дискуса вокруг видео, собрал бы им гораздо больше чем текущее состояние того самого видео.

Это восхитительно.

3:30 по Киеву
⎡razbor:11⎦ Разбираем видео: "Языки программирования ПОД КАПОТОМ [...] Kotlin - Дмитрий Жемеров."

https://www.youtube.com/watch?v=8f-YLCobZog

Так как сейчас, обьем комментариев стал таким, что я не в состоянии прочесть все,
я очень Вас прошу, если Вам нужно услышать именно мое мнение - ставте ссылку @demimurych
я точно прочту и точно отвечу.

Не гарантирую что моментально. Но гарантирую что обязательно.

Спасибо что даете мне возможность думать, что я кому то могу быть полезен.

Первые замечания про Bun

Сначала важное - люди которые занимаются маркетингом для Bun могут отбратиться ко мне, у меня есть для них абонементы в биореактор.

Я так радикален потому, что эти люди, совершенно беспардонно манипулируют цифрами для выпячивания себя на фоне выбранных для них удобных метрик.

То есть сейчас, первое и самое важное замечание относительно Bun заключается в том, что его ХАЙПОВОСТЬ продиктована работой людей который впаривают это путем манипуляцией цифрами. Но не путем честных бенчмарков.


Чтобы было понятно о чем я - можете ссылаться на этот пост где я утверждаю:
Bun унылое Г-но, проигрывающее без шансов d8.

Скорость загрузки и выполнения скрипта d8 почти в 90 раз выше чем у Bun. Это абсолютная правда.


Как и правда в том, что d8 ни делает ничего более полезного, что поясняет издержки которые есть у Bun но нет в d8.

Как и правда в том, что агрессивный маркетинг Bun делает ровно тоже самое что я сделал сравнивая его с d8, абсолютно справедливо утверждая, что Bun в щи проигрывает d8 по всем показателям. Без каких бы то ни было шансов по всем метрикам.

Зачем нужен Bun когда есть d8, который в 10 - 100 раз быстрее чем Bun?
Ну если d8 чего-то не умеет то возьмем Node. Так ведь?

Главное же это цифры где d8 сто процентов в 10 - 100 раз быстрее!!!


То есть первый важный вывод:
Bun метртв потому, что его раскручивают люди, которые не понимают что они делают. Своими постами, сравнениями - они вредят, а не способствуют. Я пока даже не вникал в то, что внтури Bun, но уже могу состярпать пост подобный главной странице Bun где Bun в салат проиграет d8. Ровно с той же аргументацией.

Когда продвижением технического решения, занимаются люди с подобным роадмеп, у этого решения не будет никогда будущего.

Вторые замечания про Bun
Я оказывается видел этот проект много месяцев назад.
И писал тогда о нем. Так что во первых я был тогда прав, во вторых все только стало хуже.
А в третьих судите сами:

Первое о чем "все" забывают, кроме конечно тех, кто прочитал/прослушал второй раздел книжки от мифов к спецификации - это тот факт, что JS это RunTime (Agent) и Host который его содержит.
Bun - это хост.
Какой RunTime внутри Bun?
JavaScriptCore.

А теперь важные вопросы, которые бы себе задал человек, который - прочитал прослушал весь второй раздел книжки от мифов к специифакции, а именно:

СТОП - если Bun это Host. И в него вмонтирован JSC - ТО О КАКИХ ЦИФРАХ ВОПИТ МАРКЕТИНГ?

СТОП2 - если в Bun вмонтирован JSC, то есть это не V8, то какова его производительность при выполнении современного JS кода в сравнении с V8.

СТОП3 - почему именно этих цифр ну вообще нихуа нет ни в одном - абсолютно честном и неподкупном обзоре?


Ответ на этот вопрос на поверхности. JSC ничем не может конкурировать с V8. Вообще. Самые радикальные оценки гворят о том, что JSC вообще ничего не может в сравнении с современным V8.


Да, JSC это работающий Agent (RunTime) который используется в том числе в Safari. Но это - 3% рынка. Причем преимущественно для одной архитектуры. В отличи от V8 с почти 90% для 15 разных архитекутр. Даже если бы инженеры V8 были полными кретинами ( а это не так) то степень оттестированости V8, запросами аудитории на решений задач плюс задач - при втсраивании - несоизмеримо больше чем у JSC.


А где много людей - там много денег. Где много денег - много инженеров. Где много инженеров - много времени исправлять проблемы и набивать себе портфолио оптимизациями. И все это - еще раз подчеркну ПОД 15 архитектур.

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


То есть первый и очевидный вывод:
Bun, выполняя именно JS код - в лучшем случае такой же по производительности что и NodeJs.
Реально - проигрывает ему везде в этих задачах.


Из этого вопрос номер два
а почему авторы Bun не встроят V8?
И это вопрос который как раз задавался много месяцев назад когда была какая то бета или альфа. И на этот вопрос, разработчик - очень талантливый человек - скажем так отмалчивался.

Как видно сейчас ( это не факт это мои догадки) он связан контрактом теми для кого CJS имеет значение. А если вспомнить странную идеотию с раскруткой этого продукта, то я почти уверен что там гениальные маркетологи из Apple. Которые и связали контрактом автора Bun.


Из этого вопрос номер три
О чем все вопли если, внутри Bun, скажем так явно не фаворит по выполнению JS кода?

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

Получилось ли у него? Как минимум отчасти. Точнее можно сказать только после внятных тестов под нагрузкой именно на API - НЕ НА JS. И вероятно, все будет уже не таким радужным.



А если подумать - что наоборот? что сильно радужным?
И тут мы подходим к самому важному - тому с чего начали

Всего этого сейчас ВООБЩЕ недостаточно, чтобы начать конкурировать.

Давайте на секунду представим, что в bun реально API по обслуживанию запроса к серверу быстрее на целых надцать миллисекунд.
Это круто? безусловно. А для кого круто?
Для тех, кому нужно их выиграть. А это совсем иные нагрузки чем у типичного проекта.

То есть Bun это пшик?
Пшик - это Deno.
Bun может стать крутым если в него встроят V8.
Bun может стать крутым если в реальных условиях под нагрузкой, работа его API дейтвительно останется выигрышной.
Bun может стать крутым если его автору не будут выламывать руки.

Сейчас разработчикам Node - посрать. Даже с радужным Bun API. Потому что текущее состояние Node устраивает большинство рынка.
А Bun может конкурировать только тем - что и так всех устраивает. Пока устраивает.

За то в том, что реально жрет ресурсы как не в себя - в JS коде, Bun очевидный аутсайдер.