Как писать JS-код, который не будет тормозить? Советы от Demi Murych | Максим Бобров #39

Он говорил эту фразу, не выдавая индульгенцию людям, пишите код как попало, а потом будете его оптимизировать, когда упрётесь в производительность.

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

Оно же может работать гораздо эффективнее.

Тебя эта проблема волнует?

Или она тебя не волнует?

Это меня бесит, это меня с ума сводит.

Ну, друзья, пожалуйста.

Ты можешь прикинуться гуглом, зайти, получить любую инфу?

Нет, ну что ты, ты не можешь прикинуться гуглом.

Привет, друзья!

С вами Кирилл Макевнин, ведущий подкаста «Организованное программирование», и сегодня у меня в гостях Деми Мурыч.

Я думаю, его можно особо не представлять, все знают, видели и есть какое-то понимание о том, что это за человек, но Деми Мурыч у нас реверс-инженер.

Много чего интересного знает.

Пожил, повидел.

Посмотрел, точнее.

И сегодня мы поговорим много на какие темы.

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

Я, кстати, раньше не пересекался.

Так получилось, что свою карьеру где-то параллельно мы находились.

Ты в одном месте, я в другом.

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

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

Куда, даже в какую сторону пойдет, не знаю.

Попробуем, по крайней мере, сделать так, чтобы это не было повторением предыдущих подкастов.

То есть мы будем стараться зацеплять какие-то другие темы, смотреть как-то по-другому.

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

Есть у меня что по этому поводу вам сказать.

Есть у тебя, да, истории, да.

Так что, короче, попытаемся сегодня в целом расслабленно с байками, с историями все это сопроводить.

Еще раз привет, рад, что ты на моем канале.

Здоров, здоров.

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

Да привет, давайте поговорим, пока я еще жив.

Все-таки.

Ты, кстати, напугал текстом.

Это шутка была или по-настоящему?

Нет, что-то, конечно, по-настоящему.

Там у меня, в общем-то, на канале все люди знают достаточно уже давно, что я с этим сражаюсь.

Я сейчас буквально сейчас, можно сказать, из этой комнаты отдыха почти что в больнице вещаю.

Там все стараются помогать со всех сторон и так далее и тому подобное.

Да нет, сейчас перспективы уже хорошие.

Да?

Ну, отлично.

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

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

Я по-другому немножко думаю.

Я думаю, что самое главное для жизни человека – это чтобы он был счастлив в тот момент, когда он живет.

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

А там черти уже знают.

Да, это такие сейчас философские деды.

Я, можно сказать, тоже немножко в деды перехожу.

Мне как раз 40 недавно исполнилось, и я такой, так, все.

Народ уже начал посмеиваться на эту тему.

Согласно новым стандартам ВУЗ... До 45, да?

Да, да.

Молодой человек считается до 45 лет.

Так что у тебя еще... Вся жизнь впереди.

Да, да, да.

Да.

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

Ты сказал, что что-то очень серьезное по производительности произошло в Джесси.

Да.

И ты прям хотел очень поделиться этим.

Давай.

А я адвоката дьявола поиграю немножко.

Да, я хотел просто обозначить одну очень важную вещь, что в то время, когда я запускал свой канал, который назывался S4JS, такая вот игра слов, S4JS, одно из первых видео, или чуть ли не самое первое, которое я записывал, было связано с тем, с очень такой провокационной темой, где я заявлял о том, что в JavaScript есть три возможности декларировать идентификаторы var, let и const.

ВАР это та, которая существовала с испокон веков.

ЛЭТ и Конст появились не так давно, лет 6 или 7 назад.

Я заявил о том, что это большая проблема с производительностью.

У вас может возникать, если вы используете ЛЭТ и Конст.

В то же время, когда...

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

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

О том, что нет, лет и конст хорошо, а вар плохо.

И где-то год назад приблизительно появился пост, заявляя issue для компилятора TypeScript.

где товарищи, которые пишут этот компилятор ТСЦ, написали, что у них просадка в производительности приблизительно 10-15%, в то время, когда они используют LAT и CONST против VAR.

И где-то через полгода, в 2024 году, где-то в июле, в июне месяце,

автор V8, а V8 это один из самых популярнейших агентов, исполняющих JavaScript код от Google, который в браузере присутствует, в ноде присутствует.

Они выпустили отчет, в котором говорили, что они очень сильно поборолись за то, чтобы избавиться от этих 10-15%.

И вот канал мой этот существовал уже лет 5, наверное.

Все это время постоянно там возникали видео один за одним относительно того, что вот VAR это...

высокая производительность лет и конст это низкая производительность были разные замеры перфоманса совершенно с разных сторон споры на эту тему и вдруг вот ставится жирная точка когда выпускается новая версия V8 где в отчете V8 написано что они очень сильно постарались и сократили издержки с этих 10-15 процентов там до 5 процентов

Это была большая жирная точка.

Я считаю, что не зря прожил свою жизнь, рассказывая об этом людям.

Прикольно.

Есть только, знаешь, наверное, с практической точки зрения у меня такая мысль по этому поводу.

Ведь 100%, когда они про это говорят, речь идёт про бенчмарки, в которых у тебя происходит это что-то в очень массивных циклах, когда у тебя, например, миллионы оборотов, оборотов, говорю, итераций.

Далеко не так всё просто.

Сейчас я сразу тебя прерву.

Это то, что очень многие не учитывают.

Дело все в том, что с появлением ES15 в языке JavaScript появилось очень много таких вещей, которые связаны с правилами, которые называются правилами static semantics.

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

Если до момента появления let и const любой агент, который выполнял JavaScript-код, взяв наш, например, бандл на несколько мегабайт агрегированного JavaScript-кода, мог выбирать из него только маленькие кусочки, которые только сейчас будут выполняться, и их можно было анализировать, и с ними как-то можно было поступать, то в случае с let и const появились правила, которые потребовали в обязательном порядке полного анализа всего бандла.

для всех Let и Const.

И это одна из основных частей, связанных с просадкой с производительностью.

Не только то, что происходит в рантайме, в момент выполнения кода, но и то, что происходит в момент подготовки этого кода.

И одно дело взять 100 килобайт из 2-3 мегабайтного бандла,

и с ним что-то сделать.

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

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

Но даже придумав этот обходной путь, у них все равно остались те самые 15%.

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

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

И вот это в конечном итоге привело к тому, что V8 очень сильно над этим поработали.

Вот что я пытался сказать.

То есть не только рантайм.

Рантайм-то, конечно, это тоже да.

И там есть еще очень много условий, где

особых условий, при которых действительно существует эта разница между Варлетт и Константином, не так все просто.

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

Все, я понял, да.

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

Ну, кстати, тут еще такой момент, что это и нормально, то, что многие не знали, по одной простой причине.

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

И более того, это вообще-то не должно приводить к проблемам.

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

В зависимости от того, как организовывают люди свою работу.

Но в большинстве случаев, да, в продакшене, конечно же, сейчас из TypeScript и так далее...

В любом случае используют транспайлеры.

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

Я считаю, что TypeScript – это мое личное мнение.

А, я помню, ты говорил, что TypeScript ты не хочешь, чтобы внедряли в JS.

Я это помню.

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

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

Это привязка к TypeScript и отсутствие решения основных проблем языка JavaScript.

Это не в этом дело.

Что же такое TypeScript?

TypeScript – это штука, которая накладывает дополнительные ограничения на программистов, и эти ограничения могут быть очень полезны в том случае, когда у нас большое количество программистов и их квалификация недостаточно высока.

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

А если мы их совершаем, то сигнализировать об этом.

Но TypeScript – это костыль, который появился как необходимость, как ответ на запрос.

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

И реформация этого языка не в сторону того, чтобы повторить TypeScript, а в сторону того, чтобы вводить статические, нормальные статические типы в язык JavaScript.

Об этой революции говорят очень много.

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

Сейчас мы об этом поговорим, да.

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

Частичное решение – это в транспайлерах просто настройку поставить, типа, компилируй в старый JS с варами, и это спасет хотя бы, и как бы по идее даже сломаться не должно, по идее.

Если там, конечно, снаружи что-то не полезет туда.

А в самом рантайме, как будто бы, как я себе это вижу, если у тебя там... Ну, там нет в момент работы такого объема обычно все-таки переменных, чтобы это было настолько существенно, если ты там не обрабатываешь в циклах огромный объем информации.

Как знать, если взять Google Docs, один из очень больших проектов, написанных на языке JavaScript, который выполняет гигантский объем работы и действительно является полезным для...

большого количества людей, решающих их проблемы.

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

Полтора миллиона.

Он, кстати, не на ГВТ ли написан?

Это такой ГВТ.

ГВТ – это еще, сейчас скажу тебе, когда я работал в 2010 году.

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

Не могу тебе сказать точно ничего на этот счет.

Знаю точно, что он собирается при помощи Google к лажур-компайлерах.

Вот, ГВТ его использовал, это вообще, по-моему, из него вытащили.

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

Ну, это JavaFX, если ты помнишь, сначала была, потом он ГВТ был.

Потом, конечно, все это поумирало, но оно осталось, потому что много проектов с тех пор создали.

Оно-то уж точно в VAR превращалось.

Но ты прав.

Получается, что такие интенсивные, скажем, редакторы 100% под это попадают, синтексивные работы.

Очень большой проект.

Если там полтора миллиона идентификаторов, то представим себе на секунду, что эти идентификаторы из VAR превращаются в Letty Constance.

Каждый запуск, каждый анализ этого Let&Const добавляет... Это как я говорил, JavaScript-производительность, это как в той поговорке, курочка по зернышку, вечером весь двор в мусоре.

Так и в языке JavaScript постоянно происходит.

Вроде бы как VAR и Let&Const отличаются в производительности, но вроде бы как не очень сильно, и можно этим пользоваться.

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

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

Да, опять же, я хочу подчеркнуть, все эти рассуждения не имеют никакого смысла теперь, потому что смотрим в разработчиков TypeScript компилятора TSC, где они подняли вот такую тему по этому поводу и собирались переходить, уничтожая все леты const и navar, или в Angular точно такая же тема.

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

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

Окей, да.

Конечно, у меня возникают вопросы, о чем идет речь, потому что на 10% при загрузке кода и до начала исполнения или во время?

Потому что это очень большая разница у тебя, когда есть… Да, совершенно верно.

Разница очень большая.

Действительно, если погружаться в детали, нужно смотреть именно эти детали и вникать в то, что происходит.

Опять же, еще раз подчеркну, с теми же самыми VAR, LED и CONST есть очень большая проблема.

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

Если вы используете LED, CONST и VAR в одной и той же области, там же, где они были определены, то никакой разницы там не будет в производительности от слова «совсем».

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

Это уже как минимум.

Да, когда замыкание начинается.

Кстати, в PHP... Да-да, совершенно верно.

Знаешь, как решили эту проблему с производительностью?

Потому что они об этом подумали.

Когда PHP... Он же, в принципе, развивался последние много лет очень активно.

Да-да, я слышал, что там они очень сильно переработали...

Так вот, это единственный язык.

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

Вот PHP один из них.

И там еще давно они сделали следующую вещь.

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

И они сделали по-другому.

То есть, если ты хочешь что-то замкнуть, у тебя после определения функции прям есть такое понятие, как use.

Именно в лямбдах.

Да, ты пишешь use и должен, обязан просто их перечислить.

Да-да-да, интерпретатор, что конкретно тебе нужно использовать.

Ну, с одной стороны, да, с другой стороны, что-то тебя знает.

Но это можно автоматически как будто бы определять.

Оптимизатор, да, современный оптимизатор того же самого V8 отлично с этим справляется.

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

Хотя знаешь, что самое смешное?

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

Это же просто константа.

Это не константа, в том-то все и дело.

Если без референса.

В языке JavaScript конст – это всего лишь навсего объявление имутабельного идентификатора в рамках той области видимости, где он был объявлен.

Только появляется следующая область видимости, следующее окружение.

Все, этот конст и интерпретатор понять не может.

Это имутабельный конст, неимутабельный, заново он появился, не заново.

Динамическая природа языка JavaScript –

Это не позволяет интерпретатору знать в момент вызова функции, тот идентификатор, который используется внутри функции, это тот идентификатор, который был объявлен когда-то как конст или нет.

Это то, что избивает с толку, это я называю отвратительным дизайном.

Люди смотрят на конст и думают, что это константа, а это нифига не констант.

Ну да, но я же как раз проискал, что есть ли он не референсный.

Они все референсные.

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

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

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

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

Он должен каждый раз себя перепроверять.

И этот каждый раз перепроверять, это и есть та дополнительная издержка в 10-15%, которая и возникает.

Является ли это тот идентификатор, который был когда-то объявлен как конст, или не тот идентификатор, а какой-то другой идентификатор, который просто совпадает именем, но выходит за пределы текущего окружения.

В этом-то вся и разница.

Да, ему по окружениям надо прыгать еще.

Это в любом случае.

Бежать по окружениям и в конечном итоге приходить куда-то.

В случае ВАРа этого нет, потому что там просто нет таких ограничений.

Поэтому не надо выполнять дополнительных проверок.

В этом смысле, кстати, VAR – это такой типа из серии… А в C это было неплохо, когда у тебя все определяешь, у тебя просто в глобальном пространстве есть бесконечный набор переменных.

По поводу того, что ты говоришь, существует такой любопытный хак в V8, каким образом объявляются…

на самом деле константы, которые V8 при работе с вашим кодом и берет как константу.

Объявляется стрелочная функция, возвращающая одно единственное значение и больше ничего не делающая.

Например, мы хотим иметь константу P, то мы объявляем стрелочную функцию или любую другую функцию, которая все, что делает, это делает return 3 и 14 и больше ничего.

И тогда V8 в процессе, когда мы работаем где-либо и вызываем функцию V8,

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

И получается реальная константа, но только что слегка через одно место.

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

Если даже не на уровне V8, то можно на уровне TypeScript и так далее.

Да, совершенно верно.

Ну, TypeScript вообще пошел не тем путем, они вообще этим не занимаются, что очень зря они сделали.

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

Процесс Ignition, Sparkplug, Maglev, TurboFan.

Четыре разных процесса, которые проходят наш код от JavaScript до машинного кода.

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

Предполагать и делать эти онлайны.

Чем дальше, тем больше.

Хорошо, нормально копнули.

Ребят, напишите, что вы об этом думаете, насколько вы подобные вещи упирались и в ваших проектах что такое случается.

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

Но давай тогда просто сейчас еще обобщено о производительности.

То есть это тема некая, которая такая, скажем, у тебя просто изначально была.

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

Сейчас вот веб-воркеры все активнее и активнее начинают использовать.

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

Как будто бы не становится такого, что у тебя софт становится быстрее.

Я, например, чисто как пользователь, могу сказать так.

Меня бесят эти спашные все приложения.

Они тормозят и тупят как не в себя.

Правильно.

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

И виноваты в этом, в первую очередь, как раз не сам язык, а разработчики, например, V8, которые в самое…

с десяток лет назад сделали тезис.

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

И как показала практика, нет, ребята, не справляетесь.

У людей настолько гибкий и изощренный ум, что они пишут код таким образом, что приходится создавать целые конференции, объясняя людям, как надо писать код на языке JavaScript, чтобы его интерпретирующий компилятор или оптимизирующий компилятор мог приводить к высокопроизводительной форме.

Об этом, кстати, еще говорил Кнут, по-моему.

Помнишь эту фразу?

Предварительная оптимизация – корень всех зол.

Так вот он эту фразу говорил, не выдавая индульгенцию людям «пишите код как попало, а потом будете его оптимизировать, когда упрётесь в производительность».

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

Он имел в виду, не пытайтесь сами вручную приводить этот код к максимально машинно эффективной форме.

Знайте свой компилятор, и зная свой компилятор, пишите код в форме, который бы компилятор понял и оптимизировал этот код так, как надо.

Потому что придут новые технологии,

А компилятор у вас изменится.

И ваш код будет заново компилирован.

В случае интерпретированных языков это вообще становится все гораздо проще.

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

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

То, что сейчас пишут люди, это на уши не натянешь.

Громаднейшее количество вещей, которые люди в принципе не понимают.

Вот, например...

Знаешь библиотеку React, например, такую очень популярную сейчас в разработке, в фронт-энде?

Мне кажется, я один из первых разработчиков React в России.

В 2013 году уже продакшен у меня на React был.

Не так давно, года два назад, даже на уровне React в блоге V8 писалось вот такое здоровенное полотно текста, где они объясняли разработчикам React и рассказывали всю историю относительно того, каким образом нужно было переписать определенную часть вещей

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

Не деградация, как это правильно слово называется.

Ну, правильно ты говоришь.

V8 они писали, они сами начали разбираться и показали программистам React, как они написали целый кусок кода, который приводил к тому, что V8, оптимизирующий компилятор V8, не мог справиться с этим кодом.

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

Из-за чего он начинал работать.

А напомнишь, кстати, интересно, что за кейс такой был?

В8 это на... Нет, я имею в виду, что в React конкретно написали.

Там все сводилось, как обычно, в первую очередь к очень простой вещи.

Потому что когда вы передаете какой-либо параметр функции... Массив объекта?

Когда вы передаете какой-либо параметр в функцию, то эта функция выполняется достаточно часто, что с точки зрения терминологии V8 называется «функция стала горячей».

Очень часто повторяется.

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

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

И это еще не самое страшное, потому что тогда V8 становится еще чуть умнее.

Он создает два варианта функции под строку и под число.

Это хорошо, когда просто строка или число.

А когда вдруг это связано с объектами, то передаваемые объекты внутри функции.

количество форм этих объектов настолько может быть большим, что V8 через определенное количество времени, это у них называется мономорфное представление функции, полиморфное представление функции, и потом он просто отказывается.

Если формы объектов, которые передаются в эту функцию, становятся настолько разными, что он уже перестает создавать эти варианты оптимизированных функций, я очень общее, абстрактно говорю, чтобы не углубляться в детали, то он просто сбрасывает это все в сторону

обычного интерпретируемого кода.

И теперь мы себе представляем функцию, которая тысячи-тысячи раз вызывается внутри самой библиотеки React, и AV8 отказался ее оптимизировать, то есть привести к машинному, хотя бы к машинному представлению, и каждый раз просто как интерпретатор ее проходит.

Насколько сильно это сказывается в случае производительности.

Кому интересны детали, блок V8 разработчиков называется V8Dev,

Вы просто пишите в гугле сайт www.v8.dev и пробел react и вы тут же попадете на эту их статью, где они рассказывают все подробности о том, что у них произошло.

Ну, мономорфизация – это история, которая при перегрузке функции, при параметрическом полиморфизме часто происходит.

Это касается не только JS.

И действительно, JIT с ума сходит, если у тебя такие изменения происходят.

В этом плане, кстати, вот смотри, безотносительно того, как конкретно TypeScript реализован, все-таки, когда у тебя появляется четкая структура, он автоматически очень сильно повлиял на производительность тем, что у тебя структурировано все заранее.

Это то, что меня поражает больше всего.

Когда появился TypeScript, например, я предполагал, что они приведут... Это карт-бланш с точки зрения производительности.

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

Но компилятор TSC этим не пользуется, и он генерирует какую-то кашу из кода, которая иногда совпадает, иногда не совпадает.

Они вообще не обращали на это внимания.

Громаднейшее количество времени.

Сейчас компилятор с TypeScript никаким образом не приводит код TypeScript к JavaScript представлению максимально производительному.

Он как будто бы вообще на это внимание не обращает.

Они сосредоточились на функциональности, которые может предоставить сам по себе TypeScript.

И почему-то совершенно отказались от...

того что могло бы сделать их понятно там тоже не бесконечные ресурсы для разработки я просто понимаю что сейчас приоритетно я наверно согласен с ними приоритет на переписывание для того чтобы он ускорился а там же ускорение просто дичайшая и они в течение года хотят его выпустить ну блин это очень круто то есть когда сколько там 10x компиляция будет или там даже больше там какие-то цифры безумно не показывали а дальше я думаю не займутся

Нас что волнует?

Компиляция?

Или нас волнует, чтобы мы могли запускать браузер не с тремя вкладками, а не ставят наш современный процессор с 64 гигабайтами оперативной памяти раком?

Или все-таки приводит это в какое-то состояние, при котором это работает?

Оно же может работать гораздо эффективнее.

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

Это меня бесит, это меня с ума сводит.

Друзья, пожалуйста, у вас современные компьютеры.

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

Кто вас там просит профилировать код до этих миллисекунд?

Хотя бы штуки, которые... О чем мы говорим?

Вы посмотрите на современный YouTube.

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

Ну, приложения стали большими, что тут говорить.

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

То есть когда все-таки сама система тебя заставляет делать нормально.

Ну, вот TypeScript один из примеров.

Он, грубо говоря, он в принципе заставляет писать нормально, если ты Any там не используешь.

И дальше это вопрос уже разработчиков TypeScript.

Поэтому это круто, когда головную боль убирают с разработчиков, и они могут об этом не думать.

Но у тебя, как ни крути, при этом есть огромная экосистема проектов, React, например, все, что вокруг него, и вообще его концепции, и, например, стейт-менеджеры, которые могут быть просто дико неэффективны.

Потому что когда ты берешь... Помнишь вот эту историю?

Я просто вот эту историю прошел по полной программе.

Когда мы начали писать в 2013 году на React, например, редактор Hexlet в продакшене в 2013 году уже мы выпустили на React.

Я думаю, что мы одни из первых в России, кто вообще в принципе продакшен на React сделали.

Просто тогда мне Angular не нравился, я очень быстро свищнулся, потому что мне буквально через месяц после релиза React была версия 0.0.12, что ли, 11, что-то такое.

Так вот, ты помнишь, тогда же ни флакса, ничего такого не было, и типа, а как управлять стейтом?

И, соответственно, появился очень быстро редакс, ну, через какое-то время.

И вся же концепция пошла в чем?

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

И я такой смотрю и думаю, о, круто.

И мы начали во все поля использовать редаксовский подход.

Ну, ты помнишь, сколько потом было статей на эту тему, насколько, когда ты начинаешь объекты, ресты, эти спред-операции использовать, к чему это стало приводить.

И когда пошла вот эта массовая история, остановитесь, ребята, давайте снова приходить к нормальной мутабельности.

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

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

Возьми тот же виртуальный дом.

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

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

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

Чтобы он получал цифры относительно того, как его программа, которую он в будущем начнет писать, он получал цифры, чего стоит выполнение его программы.

По крайней мере, для интерпретируемых языков программирования, таких как JavaScript, Python и прочее.

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

Тут ни в коем случае тебя не убеждаю, просто понимаю, что мы, скажем, по-разному немножко на это смотрим.

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

То есть я не считаю, что вот эти вот ребята сейчас, которые занимаются прикладной разработкой, это разработчики в чистом виде, как это было когда-то.

То есть это нормально, что они...

Ну, скажем, знаешь, вот есть такое понятие «ноу-код».

Например, у меня в компании работают специалисты, которые только этим занимаются.

То есть они такие как бы не до конца разработчики.

То есть они пишут код интеграции, опишки, микроскрипты внутри систем, но они не пишут полноценные приложения.

И реально там уровень программирования как бы сильно не сопоставим с девелопероспособным сайдвисом.

Когда ты на коленке для себя это пишешь, то вроде это «бога».

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

Поэтому сейчас есть разделение в этом плане труда.

Вот я, наверное, про что.

У тебя действительно такие спецы должны быть, это важно, но их количество не должно быть таким большим, потому что…

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

Это, конечно, не маркетплейс, но дзен, вот этот новостник со всякими штуками.

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

Вот какая-то такая там история.

Просто потому что функциональности огромное количество.

Но в целом.

Это не то чтобы какой-то космос, а есть какие-то люди.

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

Ну типа вот просто сайт.

Уже не просто сайт.

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

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

Ну, это так, это уже.

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

Мы плавненько подобрались.

Расскажи свою идею.

Я пока ассоциативно не понял, что ты имеешь в виду, когда ты говоришь про статические типы, но не TypeScript.

Раскрой, пожалуйста.

статические типы, которые существуют на уровне самой спецификации языка.

Не на уровне транскомпиляции, а на уровне спецификации.

Когда мы объявляем идентификатор и говорим, например, что он будет у нас всегда связан с числовым типом, то оптимизирующий компилятор, как работает современный оптимизирующий компилятор, по крайней мере в Python и в языке JavaScript.

Это называется спекулятивная оптимизация.

Они понятия не имеют, какие данные могут быть связаны с этим идентификатором.

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

На основании этой статистики они потом генерируют машинный код, который опирается на эту статистику.

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

Захотелось человеку вдруг его теперь связать со строкой или с каким-либо другим объектом.

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

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

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

Это решение гигантского количества издержек.

Пример.

Существует такая версия V8, называется V8 Lite.

V8 Lite – это сборка V8, из которого был выкинут полностью оптимизирующий компилятор.

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

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

Почему?

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

Статическая оптимизация снимает все эти проблемы.

Она заранее говорит оптимизирующему компилятору о том, что с этим делать, и это никак не изменится.

Вот почему это снимет большие проблемы.

Что такое TypeScript?

TypeScript на процессе транскомпиляции имеет...

информацию о типах.

Когда он собрал JavaScript-код, он просто привел этот код к определенному виду.

А оптимизирующий компилятор на языке, который внутри V8 находится, он все так же пытается собирать статистику и принимает решение.

Если мы внесем это в спецификацию, если у нас появится не useStrict, а useSuperStrictMode, где у нас появятся те самые статические типы, где мы будем гарантировать, что у нас вот такой-то объект такой-то формы, и он никогда меняться не будет.

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

Да, это классно, что ты это объяснил.

Но мой вопрос как раз-таки был дальше.

Просто ты сказал такую вещь, что я не хочу, чтобы там TypeScript был.

Поэтому я и пытался понять, когда ты про это говоришь, а чем тебя не устраивает концепция именно того, что TypeScript это делает?

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

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

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

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

Слушай, я уточню.

Очередная попытка Microsoft оставить за собой доминирование на рынке.

Понял.

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

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

Ну, он не совсем JS-док, но очень похоже, они его хотят внести в спецификацию как одну из возможностей описания типов.

И прибить это гвоздями к спецификации.

То есть они не меняют сам язык за раскрытым.

Я понял.

Слушай, я почему-то всё это время, вот просто мы говорим, и почему меня это удивление вызывало, потому что у меня в голове было понимание, что они именно внедряют сам синтаксис в язык.

— Возможно, у тебя просто смешалось, потому что было 2 разных пропоузла.

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

А в случае Microsoft они работают именно на уровне описания того, что идет в комментариях.

— Все, я тебя понял.

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

И это плохо.

И слава богу, что в комитете ТСЦ год от года этот проползл банится, и они его заново пытаются, и опять он банится, и заново, и посмотрим, к чему это все приведет.

Слушай, я почему все-таки думаю, что что-то как будто там еще есть, потому что я буквально недавно смотрел, там же есть какой-то флаг, типа skip или three types, то есть что-то в ноду уже добавили по удалению уже экспериментально, или я точно такой флаг видел?

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

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

Может, где-то там насчет чего-то экспериментируют, ну и слава богу.

Сейчас, сейчас, сейчас, я хочу посмотреть, потому что вот, об этом написали.

Ага, смотри, да, это апдейт от практически 1 февраля.

Начиная, вот.

Короче, начиная с версии 23.6, нода поддерживает TypeScript без флагов.

Там нет работы никакой.

А, и даже смотри, прикинь, экстеншен называется MTS.

Вот нормально, да, MTS теперь у нас?

Эта штука.

И они просто, знаешь, что делают?

Они, судя по тому, что я сейчас вижу, они просто вырезают, просто тупо отрезают типы, все.

Может быть.

Ну, это путь в никуда.

Но это уже внедрили, прикинь.

Ну, они, по всей видимости, на уровне... Это я предполагаю.

Опять же, шапочку из фольги надели и слушай.

На фоне того, как развивался Дэна или... Как?

Бан?

Или как правильно?

Бан, он кому читается.

Голова называется, да.

Где берется точно так же TypeScript и они...

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

Возможно, они решили на волне этого хайпа и туда добавить.

Это мои только предположения, не знаю.

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

Я-то говорю о фундаментальных вещах, которые связаны с развитием языка, самого языка.

Знаешь, мне что кажется?

Я просто вот смотрю на это, оно же бывает и в обратную сторону.

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

Другой вопрос, опять же, транспайлить, там V8-то все равно это не поймет.

Я напомню, что когда-то Noda добавила свою собственную систему импортов модулей, да,

Которая не была в спецификации.

А потом после этого еще года полтора не могла туда же прикрутить нормальную систему импортов, которая уже была в спецификации.

Потому что она входила в конфликт между первой и второй.

Как бы здесь они опять не вляпались в ту же самую историю.

Но это только мои рассуждения.

Не принимайте их всерьез как какую-то экспертную оценку.

Это так брюзжание.

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

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

Там есть вот такая вот хитрая многоэтапная штука.

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

Хотя, конечно, это не имеет отношения к тому, о чем мы говорили с точки зрения...

семантики и того, как это влияет уже на JIT.

Что не делается, все к лучшему.

Язык JavaScript — это химера, у которой руки, ноги торчат из разных сторон, по шесть рук, по семь ног, и поэтому он никогда не умрет.

Из-за особенностей того, как он развивается.

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

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

По крайней мере быть чрезвычайно гибким.

Это большой плюс и большущий же и минус.

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

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

И очень сложно писать код профессионалу.

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

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

Как ты думаешь, чего тебе стоит в случае использования AssignNetArrayPattern, то есть когда ты пишешь, например, let, квадратные скобочки, перечисляешь идентификаторы через запятую, равно и ссылаешься на массив.

Чего тебе это стоит?

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

Это чрезвычайно нагруженная операция.

В то же время, когда ты используешь object assignment part, когда ты пишешь фигурные скобочки, а не квадратные, и там пишешь имя поля, двоеточие, с чем его связать, или просто имена полей.

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

И люди не знают, что array assignment pattern – это вообще в принципе команда, предусмотренная для совершенно иных задач, а все, поскольку очень красиво и легко это можно написать в одну строчку лаконичную, которая становится вроде бы как понятной, его используют, не понимая, что это стоит с точки зрения нагрузки на агент, который этот JavaScript-код выполняет.

Это вот один из примеров того, что сейчас происходит.

Hook.use стоит в React и напрягся.

Да, да.

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

Не переписать, а заменить.

Там же можно использовать тот же самый Object Assigned Pattern, только лишь нужно руками прописать ключи.

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

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

Зато производительность не страдает.

Да.

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

Это, кстати, вообще забавная вещь, могу тебе сказать.

Вот мы с кем-то обсуждали буквально тут недавно на одном из подкастов, насколько же эта штука зашла.

То есть, казалось бы, это же вообще не совсем разумно даже так делать, но...

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

И другие языки бросились это адаптировать во все поля.

То есть это очень интересно.

Программирование – это не про эффективность написания кода, а программирование – это про то, как программисту удобно этот код писать.

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

Ну, я за то, чтобы машина всё страдала и делала.

Да, так и должно быть.

Но ей, конечно, типами помогать надо.

Я с тобой полностью согласен.

Компилятор должен страдать, или системный программист должен страдать.

Но штука же заключается в том, что если синтаксис языка таков, что он допускает...

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

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

Другое дело язык JavaScript, где ты можешь...

Не знаю, наворотить чего угодно.

В этом плане я тебе так скажу, в любом случае, поскольку у меня одна из специализаций – это Ruby Rails, ты, наверное, знаешь, насколько сильно метапрограммирование и динамическая передача сообщений и так далее, что, конечно, когда…

То есть для меня любой код на JavaScript с позиции Ruby, он в тысячу раз более правильный, понятный и направленный.

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

Это, конечно, безумная история, которая...

TypeScript, я хочу каминг-аут небольшой сделать такой для тех, кто меня слушает, потому что они знают, насколько я люблю Rails, например, как фреймворк, как концепцию, что он позволяет.

Но скажу так, вот в последнее время я очень много работаю с TypeScript.

То есть, например, я по ИИшке очень много ассистентов всяких пишу.

То есть, знаешь, такие небольшие штуки.

И дэшка у нас написана, редактор наш на TypeScript.

Ну, много, короче, разных элементов и проекты какие-то.

Я в люб... Ну, просто все, TypeScript меня захватил.

Учитывая, что там и в бэкэнд неплохо развили, там, Drizzle.RM, если кто знает, Fastify вот с его экосистемой.

Черт побери, не могу ничего с собой сделать.

Мне вот сейчас хочется писать на Тейсе.

Генерики, это же какая классная вещь.

На TypeScript можно написать полностью свой собственный язык.

В принципе, мы можем написать и на JavaScript, использовать свою систему типов и всего остального.

Проблема заключается в том, что правила непрозрачные для всех, в отличие от TypeScript.

Мне не нравится, как реализован сам по себе TypeScript.

Это набор костылей.

Если посмотреть внутрь, как он работает...

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

Это посмотрите, как выведет TypeScript для вас тип, когда вы объедините больше трех объектов, используя API Object Assigned.

Возьмите больше трех объектов и посмотрите, что с этим сделает TypeScript.

Это пример того, что TypeScript – это набор костылей.

Потом посмотрите, как эти типы выписаны в самом TypeScript.

Типы, почему Object Assigned работает таким образом.

С одной стороны.

А с другой стороны, другого же нет.

Но все равно это мощно.

Все остальные не зашли.

Первая версия TypeScript, кто не в курсе, когда его привезли на выставку, показать просто как концепт, он же был написан на Google Кложуры, которая сейчас существует.

И там есть свои типы, но не зашла Google Кложура, она сложная.

А TypeScript оказался интуитивно для людей понятен.

Я тебе так скажу, вот поскольку я, например, много писал тоже на всяких обертках, например, у меня был в продакшене Clojure Script, мы очень Rescript, который аналог OCaml, да, мы смотрели, использовать пытались, и Elm, еще Push Script, который это аналог Haskell, то есть мы очень активно все это смотрели и Clojure Script использовали.

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

очень сильное расширение системы типов, и у тебя нет возможности, например, как в Kotlin или как в TypeScript одновременно использовать файлы на JS, на TS, Java и Kotlin в одном месте, все эти языки гарантированно умерли.

Вот прям готов поспорить.

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

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

Возможно, это и правильно происходит.

Не, ну, интерпробилити – это важная вещь.

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

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

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

И это круто работает на примере этих языков.

Когда он сделает для любого другого программиста окружение, при котором он будет делать меньше, а не больше.

Окружение капец как важно.

Слушай, вот по поводу TypeScript.

Я еще, кстати, хотел добавить.

Ты говоришь, когда первая версия была.

Честно говоря, тогда же... Прикинь, я забыл название.

Как эта штука называлась, которую выпустил Фейсбук?

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

Кто-то выбрал фейсбуковское решение, кто-то выбрал TypeScript.

Они же еще параллельно существовали какое-то время, и даже по выставкам ездили люди, которые рассказывали про те и про те варианты решения.

Так вот, в тот момент я выбрал то решение.

Выбрал его, знаешь, почему?

Потому что это был не новый язык, это была именно система надстройка типов А поскольку, в принципе, я, ну, например, в Орланге там есть диалайзер, у тебя система типов Он сам язык динамический, но у тебя есть возможность типы прописать, это прям задумано Это один из немногих языков с by design встроенной опциональной системой типов Да

Но там к нему претензий было много.

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

Ну, типа как с Any в TypeScript.

Что если нет жесткого контроля, оно все поедет по одному месту.

Что делает TypeScript?

Он простые вещи делает сложными, а сложные вещи делает Any.

Ну, типа того.

Если не бить по рукам, то люди будут делать Any.

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

Почему-то у тебя все объектом может быть, и ты можешь все что угодно делать.

Так что в этом смысле джава очень… Можно классно показывать код, который работает, все прекрасно, но он абсолютно будет динамический по своему работу, принципам, виду и всему остальному.

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

В TypeScript немножко этого не хватает, это правда.

Потому что я когда пишу на Java, ты просто понимаешь, что у тебя тупо не скомпилится.

В TS, если в TS ты сам не заставил инструментарий тебя остановить, то ты все-таки запустишь этот код.

И дальше может что-то пойти совсем не так.

Поэтому и костыль.

Я бы, знаешь, сейчас перешел куда, можно дальше пойти.

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

Например, одно время сложность TypeScript была связана с тем, что программирование на типах дает много возможностей, но и дает такое, что без пол-литра не разобраться.

Да, да.

Казалось бы, типы должны были бы облегчать тебе работу, но на самом деле перегружают мозг очень сильно.

Ну, если такие возможности.

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

Это, извините, космос.

Такого нет нигде, кроме ТС, за счёт его системы типов.

Но если мы открываем исходник,

то мы тут же как бы его закрываем, потому что понять это могут, я не знаю, полтора человека в этом мире.

Но это очень сложно.

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

Но, блин, Иишка неплохо типа сама пишет и исправляет.

То есть это же, в принципе, гораздо более детерминированная область, чем написание просто кода.

И она справляется неплохо.

И как будто есть такая тенденция, вообще есть такое мнение, что мы типа вообще перестанем писать.

Как ты считаешь, произойдёт такое или нет?

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

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

Более того, я записывал несколько видео, когда показывал, как проводится собеседование с чатом GPT.

Чат GPT как будто бы у нас конкурсант, соискатель на должность.

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

И вроде бы код как бы и работает, и выполняется, но существует целый спектр пограничных условий, при которых он будет работать неверно.

Или он объясняется чатом GPT неверно.

То есть чем выше уровень абстракции языка, тем хуже сейчас справляется с этим чат GPT.

И вероятно это связано не столько с ущербностью модели современного слабого искусственного интеллекта, сколько с тем, на каком коде он учится.

На языке JavaScript такое количество говнокода было нагенерировано, на базе которого чат GPT или другие обучаются, что не мудрено, что и тот код, когда ты ему ставишь определенного рода задачи, которые он генерирует, не отвечают тому уровню качества, который бы я предъявлял к этому коду.

А так-то, конечно, да.

Господи боже, 10 или 15 лет назад...

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

А сейчас люди заходят, в общих словах генерируют задачу, он выдает код, который работает.

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

Да, да.

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

Незаменимый ассистент.

Помнишь, мечта какая была?

Но он незаменимый.

Как?

Да.

Помнишь, какая мечта всегда была?

То есть всегда, как рассказывали, вот типа старые системы.

У тебя есть архитектор, и у тебя есть такие исполнители.

Всегда сравнивали это со стройкой, что у тебя есть прораб, у тебя тра-та-та.

Раньше же даже были две разных должности.

Один человек, который писал программу, другой человек, который набирал эту программу.

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

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

И самое смешное, что на этом уровне итерации это сработало.

По крайней мере, очень многие вещи действительно писать не надо.

А вот конкретно типы, ну так он пишет вообще по красоте.

Потому что типы все-таки подчиняются очень строгим правилам.

И там вот так вот не забалуешь.

Поэтому мне, например, очень нравится.

И, кстати, даже, знаешь, что я заметил?

Именно если ты берешь чисто TypeScript либо и просишь по ним код писать.

Ярчайший пример.

Query-билдеры, когда тебе надо в бэкэнде составлять SQL-запросики, но на языке конкретной ORM-ки.

У тебя, например, вот есть такая Drizzle ORM, очень прикольная, украинскими ребятами сделана.

Вообще, самое лучшее, что, наверное, с нодой за последнее время случалось.

Она генерирует такой на своем языке, но понятным для JS-а, как бы схему базы данных.

Ты отдал в нее, он знает, что это Drizzle ORM.

И вот у меня еще не было ни разу такого момента, чтобы я, когда попросил с Генери мне такой-то запрос, она мне не давала рабочий код.

Причем не в смысле там, знаешь, трэш.

Это же просто компактный как бы запрос на их языке.

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

Вот.

Такой вот у меня есть опыт по этой штуке.

Да, и здесь есть еще другой интересный аспект всего этого происходящего.

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

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

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

А что будет делать следующее поколение, если оно будет постоянно этим пользоваться?

Кто будет контролировать этот код?

Знаешь, можно смотреть по-разному, можно переживать, действительно, многие такие, вот, что там произойдет с индустрией и так далее.

Я всегда очень спокойно к этому отношусь.

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

А во-вторых, так нам же лучше будет.

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

Вот и все.

Вот поэтому...

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

У меня вот недавно был пример, вот не поверишь, что я вчера делал.

Есть проект, на котором мне нужно завести тренажер онлайн для 1С языка.

Я с ними, конечно, никогда в жизни не работал.

И если ты пойдешь, чтобы докер-файл готовый найти, ну, проблема.

Я, соответственно, говорю, дай-ка мне готовое.

Он мне выплевывает огромную там установку, и понятно, что мне копаться в этом неинтересно вообще.

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

Он в конце концов мне выдал рабочее решение после часа колупаний.

Я такой думаю, а сколько бы, интересно, времени я бы это сам делал?

Там же капец просто.

Да.

Но вот то время, если бы ты делал сам, это же время, которое не просто потрачено заново зря.

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

А так-то, безусловно, я с тобой полностью в этом согласен.

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

Я тоже, когда посмотрел как-то на язык в 1С, на русском языке свой собственный, какой-то выстроенный, меня тоже это слегка коробит.

Слушай, знаешь, что самое поразительное?

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

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

В 2007-м у меня коммерческие проекты пошли, а учиться я в школе начал еще.

Так вот, меня знаешь, что поразило?

Я открыл код на этом языке.

Оскрипт – это имплементация 1С вне их системы.

И это первый раз в жизни, когда у меня мозг не смог распарсить исходник.

То есть это выглядит просто как текст.

Я вообще не понял.

Да, конечно, стоят скобки.

Что, где, для чего.

Но он тебя не считывает это как параметр, он не считывает это как функцию.

Это вот то, о чем я и говорю.

Что со мной происходит.

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

А почему это произошло?

Мозг воспитал у себя в голове такие определённые части этой нейросистемы в своей башке.

А тут я тоже, когда смотрю на эти русские буквы, меня это вступило.

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

Ты понимаешь, о, это конструкция языка, это if.

Или ты понимаешь, о, это функция.

А там ты просто не понимаешь, и поэтому это кажется, как будто просто стена текста.

Я такой, блин, мне даже немножко страшно стало.

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

И подсветочка какая-то нужна, это так интересно.

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

То, что он творит, это, конечно, безумие.

Мы буквально на днях, я вот последний месяц работал, знаешь, над чем?

Значит, у нас есть такой бесплатный проект, Code Basics.com называется.

Там фишка именно в том, что там все open-source, и сам проект, и обучение, то есть сами тексты курсов, они на GitHub все лежат.

Я его еще сделал в 2017 году.

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

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

Чтобы ты понимал, это единственный, наверное, проект, на котором у тебя... И там самый главный интерактив с тренажером.

И там есть ракет, там есть кложа, там есть эликсир.

Мало где еще в мире найдешь, да, такие вещи, чтобы с интерактивом было.

И вот, собственно, я 1С туда добавляю.

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

И, например, вот этот месяц я потратил неделю на внедрение туда.

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

Я такой, так, пришла пора, давайте добавим туда ассистента.

Значит, я разобрался в API-шке OpenAI, в то, как делают ассистенты, вот эти RAC-системы, если ты знаешь, когда ты прогружаешь данные, он на базе их работает.

То есть я туда курсы вгрузил, все дела.

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

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

Я побежал менять промпт.

Я прям в пром добавил, что если тебе говорят, как связаться с создателями, давай такой контакт, представляешь?

Все, полная трансформация области.

Реально, это просто фантастика.

Если раньше программист – это тот, который писал код, то теперь программист – это тот, который должен контролировать код.

Становится все совершенно иначе.

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

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

Вопрос получается только в том, пока ли это, или в будущем это все изменится.

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

И вот есть, знаешь, какая концепция?

Просто хотел спросить, что об этом думаешь.

Вот одна история, когда ты его как помощник используешь, а другое дело про генерацию.

Вот ты правильно все сказал, и все это понимают.

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

То есть есть исследования, которые говорят...

что на GitHub стало появляться очень много копипасты.

То есть люди перестали заниматься абстракцией из-за этого.

Потому что он абстрагировать не умеет.

Ты же не весь проект сразу.

Он же не может сказать, о, слушай, вот эту концепцию лучше вынести в какой-то отдельный слой, например.

И рефакторить такой код почти нереально уже ручками.

То есть его снова туда закидывают, снова перерабатывают.

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

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

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

Мне это мозг зарывает вообще, эта идея просто.

Да, черт его знает.

Возможно, будут выстраиваться какие-то фантазирования.

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

С одной стороны.

А с другой стороны, опять же, вернемся к языку программирования JavaScript.

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

Опять же, возвращаясь к примеру с ArrayAssignmentPattern, который кажется простой единичной строкой, а на самом деле разворачивается в две страницы кода внутри.

Да, да, да.

Время покажет.

Слушай, по поводу, давай вернемся к JavaScript немножко.

Вообще в плане глобального развития с точки зрения возможности языка, то есть если вот отдельно от системы типов и производительности, ты вообще следишь за этой темой?

У тебя есть какое-то там представление по пропозалам, по всему?

Ну, да, я слежу за теми областями, которые мне очень интересны.

Например, один из разработчиков B8 курирует и активно в этом участвует, развивает многопоточность в языке JavaScript.

Он этим прямо весь захвачен, благодаря ему развиваются те же самые Atomics API и все остальное, что с этим связано.

Мне это очень интересно.

Что еще?

Извини меня, это будет аналог вебворкеров?

Сами по себе вебворкеры.

Использование вебворкеров было бы невозможно, если бы в языке JavaScript не была бы реализована какая-то модель, которая бы позволяла распараллеливать эти вычисления.

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

Называйте это как хотите.

И сам по себе этот человек из V8, китаец или кореец, он это называет именно многопоточным программированием.

Как называют, так и называют.

Это мне затея очень нравится.

Из-за того, куда он развивается язык.

Мне нравилось очень сильно...

А вот что сейчас проходит уже одни из финальных частей Proposal, это так называемая Shadow Realm спецификация.

Это когда мы на уровне языка JavaScript сможем создавать свои собственные песочницы языка JavaScript.

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

Только мы можем со стороны теперь это контролировать.

Такая вот своего рода система виртуализации, Shadow Realm называется.

Извини, я правильно понимаю, что скорее визуально это такой эвал на стероидах?

Не вполне.

Эвал-то у тебя существует внутри того окружения, в котором у тебя весь твой JavaScript-код существует.

Ну, я имею в виду концептуально.

То есть, скорее всего, это будет объект, который ты конфигурируешь, что-то в таком духе, и передаешь код на исполнение.

Ты создаешь, по сути дела, среду, это и сейчас так есть, контекст.

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

А тут делается API, который тебе позволяет…

Внутри своего JavaScript-кода создавать вот такое окружение, внутри которого будет выполняться JavaScript-код, который не будет иметь доступа к внешнему коду, который все это контролирует.

Насколько я понимаю, в JVM это очень классно реализовано, когда ты вплоть до ограничений, что, например, ты можешь читать, работать с файлами и так далее.

Да, да, да.

То есть, например, это классно для людей, которые пишут онлайн-инструменты а-ля код пены и так далее.

Да, системные вещи какие-то изолированные с большими претензиями к безопасности и всему остальному.

Да, да.

И нам, кстати, в этом смысле когда-то докер помог, потому что у нас была как раз проблема, когда мы стартовали инструменты.

Типа, как нам исполнять код так, чтобы он не вылез за определенные рамки.

И докер нас спас.

Но это на бэке, а на фронте его нет.

Слушай, я правильно понимаю, что это еще позволит переиспользовать виртуальную машину для того, чтобы ее инстансов не создавать многое?

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

Тебе не надо будет для этого создавать новый агент.

Не нужно использовать никаких дополнительных ресурсов.

Для этого.

В этом смысле, да.

Кстати, это интересно.

Я сейчас вот думаю, интересно, сколько это может сохранить ресурсов.

Надо будет подумать.

У меня даже кейсы есть, где я мог бы это заиспользовать.

Для каких-то специфических задач очень сильно может.

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

Сейчас же, если взять любой код, сторонний код, которому ты не доверяешь,

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

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

А здесь у тебя есть гарантия и контроль за всем этим.

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

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

Это же используется там content security policy, подпись каждого скрипта ключом, и уже не так все сложно или не так все просто.

Ну, как бы то ни было, да.

Да, есть много всяких этих механизмов.

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

То есть ты вроде там что-то делаешь, делаешь, делаешь, а есть вот провалы.

Вот у меня одна из этих тем, не знаю почему, но вот эти все системы безопасности браузерной, я почему-то их всё время избегаю, стараюсь не погружаться.

Они меня бесят все, вот честно скажу.

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

А та же самая система типов, ну, людям тяжело и не заходит.

Content Security Policy сложно.

Я ее наизусть никак не помню.

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

Это нужно себя именно заставлять.

Это как внутренняя самодисциплина.

А это очень неприятно и неудобно.

Проще про это как бы не думать.

Может быть, потом, когда-нибудь, поэтому и не используют.

Хотя такие инструменты есть.

Ну, это вообще большая тема, да.

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

Разумеется.

В 90-х годах, когда я начинал развиваться как программист, мы присутствовали в иллюзии о том, что если программиста хорошо воспитать, дать ему опыт, то он будет писать хороший, замечательный код.

Ничего подобного.

Он обязательно когда-нибудь ошибется.

Мы сейчас пришли эволюционно к тому, откуда появились песочницы, Shadow Realm, докеры, системы изолирования, которые...

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

Обязательно допустит какую-то ошибку.

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

Внешнее окружение снизит издержки на проблемы, которые возникнут с той самой ошибкой.

В идеальном случае до нуля.

Вот и Content Security Policy, оно как раз про это.

Сколько боролись, сколько пытались учить людей бороться с такими вещами или не писать такие вещи, которые приводят к XSS, Cross-Site Scripting.

В результате плюнули и придумали Content Security Policy.

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

Вот так.

Только другое дело, что сложно у них это получилось.

Да, и я подозреваю, что если ты не используешь какую-то автоматику, которая сама это делает, то там 100% этого нет, просто никто не воткнет.

Да, это то же самое в Линуксе.

Есть идеальнейшая система безопасности, SE Linux.

Но для того, чтобы ее отконфигурировать, нужно быть отдельным специалистом в конфигурировании SE-Linux.

Поэтому по умолчанию даже современные все дистрибутивы в большинстве случаев идут с отключенным SE-Linux.

Я тоже про это всегда слышал, когда сталкивался.

Максимум у тебя firewall какой-нибудь работает, базовый.

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

потому что на него наложены соответствующие ограничения при помощи SE Linux.

Но чтобы его отконфигурировать, нужно себе мозг взорвать, нужно быть гением, чтобы это все помнить.

Я подозреваю, что если это хостинг какой-нибудь, они не то, что могут себе позволить, для них это вообще must-have.

Они сейчас по-другому все делают.

Это на уровне того же самого докера.

Проще виртуализировать и потерять 10-15% производительности текущей своей машины, чем конфигурировать и съесть Linux.

Там взломали эту виртуальную машину, прибили ее и поставили на ее место новую, и все хорошо.

Стильно, модно, молодежно, быстро, элементарно, и думать ни о чем не надо.

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

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

Меня спроси человека, который с 98 года только сидит в Linux, смогу ли я сейчас отконфигурировать SE Linux на сервере, даже со своим опытом системного администрирования.

Я сейчас скажу, что дайте мне сначала несколько дней, я должен перечитать документацию.

Почитаем, да.

Знаешь, такая вот интересная еще вещь есть, которая меня всегда веселит.

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

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

И плюс ИИ тут еще прибавился к нам.

И ты понимаешь, что

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

Сейчас можно у любого человека угнать все, что угодно.

Перегрузить его мозг звонками, чем угодно, ночью его разбудить так или иначе.

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

И так далее и тому подобное.

Поэтому все системы развиваются теперь в сторону...

Не иллюзии относительно надёжности человека, сколько в сторону создания.

TypeScript – это как раз про это же то же самое.

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

А ты помнишь эти истории про внедрение эксплойтов?

Из-за того, что в NPM пакеты, по-моему, не подписывались.

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

А в Node тоже через этот опыт прошли.

Все постепенно, мы все повторяем одни и те же детские болезни.

Ты недавно слышал вот последнюю супер такую эпичную историю с Next.js с уязвимостью, которая по CVE, девятка, по-моему, из десяти.

Да ты что?

Существует знакомое, что там было?

Обходы авторизации и так далее.

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

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

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

Это те же самые детские болезни, которые в свое время пережили все PHP-шные фреймворки, которые там когда-то развивались.

Это прекрасно.

Надо как-то по-другому учить людей программировать.

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

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

Ну или хотя бы вылезли с большой сложностью.

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

Я единственное помню, вот кто-то на днях показывал, сканеры, например, да, смотрят.

Ты знаешь, сейчас есть такая даже штука, называется, придумали LLM или TXT, что-то такое.

Короче, прям файлик, который ты кладешь и ты делаешь описание под сайты.

в смысле описание для LLM-ок, потому что они сейчас же что делают?

У тебя парсят интернет все эти штуки без остановки, смотрят, что там происходит.

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

Есть robots.txt, который мы даем поисковикам, а давайте для них сделаем, типа, отдельный.

И ты текстом туда выгружаешь свой сайт.

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

Причем там формат очень простой, там Markdown, потому что это типа LLM, она распарсит.

И, соответственно, ты все это забирает.

Не видел такой проект?

Нет, еще не видел, но это очень сильно напоминает то, что было когда-то реализовано много лет назад в Google, когда они тестировали долгое время API, связанное с новостными порталами.

Это не AMP и не похожая технология, у них была своя собственная API для этого.

Они создавали такие вещи.

Это самому ходить надо было туда.

В Google сейчас разрешено, кстати, в отличие от того, как это было много лет назад, когда ты для индексирующего робота отдаешь какую-то другую HTML-ку и не ту, которую показываешь пользователю.

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

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

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

индексирующим роботом значительно упрощалась.

По всей видимости, это какой-то дополнительный новый инструмент.

Знаешь, такое было общее движение, когда про это говорили.

Помнишь, это Web 2.0, семантический веб.

Была идея в том, что сейчас все добавят микроразметку.

Ну, а, например, для нас все очень важно.

Мы, естественно, всегда были в тренде, всегда за этим следили.

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

Есть вот этот чувак известный, который я, кстати, приглашал тоже на подкаст, но пока еще не дошел.

он просто очень много пишет про парсеры.

Может быть, ты его видел.

Что-то как бы IT-бизнес, как-то так у него называют.

Очень популярный канал.

И вот он очень много пишет про парсеры, про запросы.

То есть это целая большая вообще индустрия, где народ хочет парсить постоянно сайты.

И вот, соответственно, они сейчас переходят все на эти технологии.

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

Ты, кстати, знаешь про это, что...

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

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

То есть у них огромное количество заходов, это фермы, которые специально, в общем-то, через все эти инструменты, знаешь, да?

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

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

Ты про клоакинг сейчас рассказывал, про подмену.

Например, когда раньше создавали такие полотенца,

С Дорвеями, со всеми остальными вещами.

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

Это то, что ты показываешь пользователю.

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

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

Но на самом деле у тебя внутри этой HTML будет, например, содержаться 200 товаров, а не 10 товаров.

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

Если раньше за это банилось, когда-то очень давно, 5 или 6 лет назад, или 7, то теперь это считается нормой.

Такие вот вещи используются.

Но поведенческий фактор не используется.

Это точно, это очень легко доказывается.

Я просто знаю, что в Яндексе используется, просто потому что мы… В Яндексе это отдельная тема разговора, как работает Яндекс.

Послушайте, что такое поведенческий фактор?

Это же информация, которую нужно снять.

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

Google Chrome – это тот браузер, на который накладывается громаднейшее количество ограничений с законодательством в Европейском Союзе или в Соединенных Штатах.

Он мониторится 24 на 7 специалистами, снимается весь трафик с этого.

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

Этого сейчас просто не существует.

На уровне хрома, да.

Я имел в виду, конечно, Google аналитика.

Понятное дело, что она с тебя все клики собирает, и как ты вводишь...

В случае с Google Analytics это тоже отдельный разговор.

Там, во-первых, эта информация вся обезличена, во-вторых… Но там личность-то не нужна.

Я целую статью по этому поводу когда-то писал.

Это надо вспомнить.

Интересно.

Кстати, я про Clocking-то сказал, не могу не рассказать одну интересную вещь.

Кстати, я не знаю, насколько, ребята, вам интересна тема SEO и всего вокруг этого.

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

Вот про клакинг есть прикольная штука.

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

И справедливо.

Есть просто куча сейчас правил.

Сейчас в Гугле это разрешено.

Ну, скажем так, если все-таки сделать какую-то совсем жестко, то забанят так, что мало не покажется.

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

Но есть еще один нюанс, который интересный, с которым мы столкнулись.

Знаешь, есть такая история, связанная... В Гугле есть такое понятие flexible sampling.

Возможно, ты про него слышал.

В чем он заключается?

Существует огромное... В какой-то момент появилось огромное количество проектов, работающих по подписке, которые дают контент по подписке.

Это особенно касается новостников.

Но новостник обязан индексироваться, потому что иначе как бы как?

Ну, то есть они так работают.

И Google это прекрасно понимает.

Но просто иначе он индустрию уничтожит, если он не будет этого делать.

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

Ты действительно можешь поступать двумя способами.

Первый способ.

Ты отдаешь Гуглу как бы все...

А человеку отдаешь только часть статьи.

Может быть, ты видел, когда у тебя там буквально первые строчки, а потом появляется вот эта штука «Купи».

И он это не считает за обман, потому что… Но ты должен разметить определенным образом HTML.

Он должен прямо прочитать, что это конкретно оно.

Paywall такой класс называется, надо поставить.

Либо второй вариант, когда ты знаешь, как делаешь.

Например, ты в месяц показываешь полных три статьи,

А четвертую, типа, за бабки.

Знаешь, кто так делает?

Так Medium делает.

Ты замечал, что ты на него ходишь, ходишь, ходишь, а потом в какой-то момент он тебе показывает.

И вот эта штука называется Flexible Sampling.

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

Но давали индексировать Google все.

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

Нет, ну что ты, ты не можешь прикинуться Google.

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

Серьезно?

Конечно.

Они прямо рекомендуют и прямо пишут о том, что вы должны делать реверс-запрос по IP-адресу.

У тебя пришел запрос, который, допустим, агентам представляется Google.

Ты делаешь реверс-днс-запрос к тому адресу,

К DNS-серверу, что это за IP-адрес и что он этот.

И все боты Google сейчас в обязательном порядке возвращаются из DNS-строка, которая непосредственно связана с Google.

Гарантированно стопроцентное доказательство.

Единственный недостаток, конечно, что это медленно.

Потому что каждый реверс-запрос к DNS, это все-таки не какие-то миллисекунды, это может до полусекунды доходить.

Ну, закэшировать есть только.

Да, но кэшировать, можно и IP-адреса кэшировать и так далее.

Слушай, а прикольно, я, кстати, не знал эту тему.

Окей.

Слушай, а, кстати, мы не поговорили, вот действительно у тебя же, когда JS, вот эта вся история, у тебя еще появляется общая проблема с SEO, потому что все это должно на баке исполняться.

Ну, она решается очень просто.

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

Сейчас у тебя автоматика все это решает.

То есть в большинстве экосистем все само.

Если Google Chrome уже, дай бог, что тех 5 лет распространяет свою Headless-версию, где она работает без интерфейса, то составить хотя бы для анонимных пользователей HTML-ку на уровне...

нашего недоразвитого JavaScript-кода, который должен был бы у пользователя генерировать ту же самую HTML-ку, а здесь у тебя на сервере лежит этот Headless Chromium браузер, ты сам к себе делаешь запрос и сохраняешь готовую HTML-ку, которую потом отдаешь как кэш, как самый простой способ реализации сайтрендеринга.

Но вообще, по большому счету, я считаю, что это...

порочная практика.

Вообще сама по себе порочная практика подобным образом.

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

Конечно, должен быть отдельно.

JavaScript в случае того, когда мы его используем в браузере...

Потому что фронт это все-таки не обязательно браузер.

Но допустим мы его используем в браузере.

Это должна быть вещь, которая идет поверх HTML.

А не является сама источником того самого HTML.

Это противоречит тому, что является первичным и вторичным.

По крайней мере это должно касаться тех проектов, которые...

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

Если у вас какой-то просто сложный интерактивный интерфейс, то бог с вами.

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

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

Джаваскрипт должен просто поверх вешаться на все это происходящее.

Это если мы говорим про веб.

Вопрос тогда.

Давай так.

В принципе, так всю жизнь работал когда-то jQuery и все остальное.

Но у меня тут к тебе вопрос.

Хорошо, а если у меня это каталог?

Вот там выводится список чего-либо.

Ну, как я HTML заранее?

То есть ты предлагаешь в смысле... Так ты же его так или иначе.

У тебя же JavaScript-код есть, который сгенерирует эту HTML-ку у клиента.

А, все, понял.

Я просто думал, ты предлагаешь не генерить.

Значит, это же логика сама по себе уже существует.

Но это, опять же, подчеркну, это разговор, который касается истории, связанной с HTML.

HTML – это, как он правильно называется, Hyper Transfer… Я не помню.

Markup Language, по-моему, это.

Да, Markup Language.

Это язык разметки документов.

То есть того контента, который должен бы легко индексироваться каким-либо внешним алгоритмом.

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

Все-таки они больше же думали про гипертекст.

В самом начале это, безусловно, да.

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

Я, кстати, на протяжении всего подкаста хотел про это вспомнить.

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

Я просто хотел тогда еще напомнить про HTML, потому что когда делали HTML, там примерно такая же была концепция.

Был момент, когда еще до пятого параллельно с ним

XHTML появился.

И я был из тех людей, которые его пытался применять.

Потому что такой, о, смотрите, строго все дела.

Но почему он не попер?

Потому что он накладывал слишком много ограничений на людей, которые вообще-то далеко не всегда программисты.

Я сейчас детали не помню, но, по-моему, он же... Но он требовал строгости, помнишь?

Нет, я не про сам XHTML, я про то, почему он не попал в стандарт как таковой.

Я помню, что там был...

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

Когда на них начали давить сторонние игроки рынка, крупные типа Google, типа Microsoft, что нам нужно срочно, срочно, срочно.

Я сейчас не вспомню.

Но понятно.

Но проблема там однозначно была, потому что они говорят, окей, ладно, вот, допустим, мы его применим, и что, у нас сейчас перестанут работать вообще все сайты, и мы будем ждать, пока их там переделают, ну, типа, это нереально, потому что он был слишком строгий, он фактически как XML, ты не имел права там ни в одной запятой как бы ошибиться, и поэтому это вот оно примерно в эту же сторону, когда ты говоришь, почему JS вот такой, и там можно писать все подряд, а страдать приходится на нижнем более уровне,

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

А где ты найдешь это решение в случае того же самого браузера?

Нигде.

Пока что.

А вот давай про это поговорим.

Почему до сих пор не происходит... То есть это же логично.

Вот у тебя есть WASM.

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

Просто раньше это транслировалось в JavaScript, сейчас это может транслироваться в WASM.

Я расскажу одну прохладную историю по этому поводу.

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

Назывался он Dart.

Была полностью готова виртуальная машина.

Синтаксис этого языка был полностью обратно совместим с языком JavaScript.

были готовы компиляторы и транскомпиляторы из JS в Dart, из Dart в JS.

Разрабатывалось это все группой, которую в том числе курировал Google.

Все было готово для того, чтобы запустить.

Даже в сборке Google Chrome были бета-версии готовы, в которых работал и JavaScript, и Dart.

Почему Google не дал ходу этому языку?

Почему вдруг дальше это развитие никакого не приобрело?

Я не знаю.

Шапочку из фольги и начинаем рассуждать на эту тему.

Интересно.

На тему теории заговора.

Блин, а ты мне прям напомнил это.

Я забыл, что они реально внедряли его, что это не просто был язык, что была концепция, мы перейдем все на Dart.

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

Да, да.

Есть один из моих любимых специалистов в V8, который когда-то раньше занимался, который потом перешел в эту команду разработки Dart.

Вячеслав Егоров.

У него на YouTube есть несколько рассказов по этому поводу.

о том, как у них было все готово к запуску.

Но Google сказал «стоп, остается JavaScript».

С WASM та же самая любопытная история.

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

И люди, подобные мне, например, думали, что WASM – это будет дополнительный альтернативный язык JavaScript на более низком уровне.

Если ты умеешь программировать, пользуйся и делай.

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

Это как жрать кактус.

WASM сейчас это технология для транскомпиляции из других языков программирования в язык JavaScript.

Опять же спрашивается, почему, если с самого начала для этого в самом WASM только нужна была бы добрая воля.

С чего вдруг педалируется сам по себе JavaScript?

— У них, видимо, есть свои какие-то цели.

— Но я всё-таки вот в это верю, потому что вот это правильная штука, потому что у тебя, по сути, тебе не нужен язык, тебе нужна виртуальная машина.

И, собственно, вот один из примеров — Kotlin.

Ты знаешь, да, что они очень сильно на это давят, они...

Ты пишешь на Kotlin, у тебя туда все уходит.

Причем там еще сложная экосистема с тем, что у тебя под все платформы оно готовится и работает.

Единственное, я так понимаю, что у вас там есть мега-ограничение о невозможности работать с домом.

Я могу это обманывать, но это долгое время было.

И поэтому, получается, ты на него можешь приложение сделать?

Но там есть сейчас другая вещь.

Из WASM можно писать на Canvas.

То есть вы можете рисовать интерфейс непосредственно на самом Canvas, этого бывает часто достаточно.

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

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

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

Да, так по-моему Figma сейчас и переписывается, и транскомпилируется, по-моему, кажется.

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

Но надо пересмотреть, чтобы я ничего не перепутал.

А так да.

Возможно, он в эту сторону и двигается.

Но я считаю, кстати, это очень плохим, потому что я считаю, что это мы возвращаемся во времена флэша.

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

Была попытка еще Silverlight.

Да-да-да.

И даже спецы успели появиться.

Да.

Но при этом я должен отдать должное специалистам, которые писали Flash плагин.

Несмотря на все проблемы с безопасностью, производительность этого плагина была дичайшая.

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

Это им надо отдать должное.

Но Adobe же, по-моему, владел Flash.

Не захотели его делать открытым.

И Google сказал, найдите его к черту.

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

CRM-маркетинг, вот это все.

То есть там ими пользуются крупнейшие вообще компании мира, и это интересно.

То есть они давным-давно уже ни фотошопы, ни вот это все, никакого отношения к этому не имеют.

И поэтому они в таком корпоративном мире, и для нормальных людей они как бы умерли.

Хотя мы до сих пор продолжаем говорить слово «фотошоп».

Пока еще живы те люди, которые это говорят.

Через какое-то время это уйдет.

Но вообще это интересно.

Слушай, а кстати, по этому поводу, я, честно говоря, в WebAssembly вообще плохо в эту тему погружался, поэтому могу сейчас глупость сморозить, но...

Я правильно понимаю, что по сути он где вообще находится?

То есть у тебя v8 – это ProJS, или он и Wasm еще обрабатывает?

Внутри v8 у тебя сейчас есть две отдельные экосистемы.

Одна выполняет JavaScript-код, другая выполняет WebAssembly-код.

То есть по сути это две разные, то есть они не шарят?

Внутри v8…

реализованы две разные машины, которые... Причем я тебе более сейчас скажу, для самого ВАСМ сейчас еще появляется две разных машины.

ВАСМ изначально это была штука, у которой такой вещи, как гарбэш-коллектор, отсутствовала как таковая, ты должен был памятью управлять самостоятельно в ВАСМе.

А сейчас появляется новая спецификация, которая так и называется ВАСМ-ЖС, ВАСМ с гарбэш-коллектором, в которой появляется уже третья машина внутри

в 8, которая занимается выполнением этого кода.

Но очень многие от этого рады, потому как там языки с garbage-коллекторами, такие подобные с C-sharp и так далее, если раньше они компилировались какой-то код в Wasm, они должны были за собой тянуть еще и какой-то код на Wasm, эмулирующий работу garbage-коллектора.

Теперь этого делать им не надо.

Это очень сильно упрощает

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

С одной стороны.

А с другой стороны, это уничтожает очень важную часть того, что было раньше в WASM.

WASM был предсказуем.

Что плохо с точки зрения производительности в языке JavaScript?

Это далеко не всегда возможность предсказать факт того, когда у тебя вдруг может появиться какой-нибудь лаг из-за срабатывания того же самого garbage collector.

В WASM этого не было, потому что памятью ты управлял самостоятельно.

Но, с другой стороны, это упрощает транскомпиляцию из других языков, когда в самом WASM реализовали свой garbage collector.

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

У тебя же, по сути, рантайм должен свой какой-то туда еще идти, дополнительный контроль.

Да, но это вообще насколько технически реализуемо?

С чего мы начали?

С того, что...

А будет ли альтернатива языку JavaScript?

Вот я не знаю.

Может быть и не будет.

Непонятно, почему Google так зубами держится за это.

Ну, точно он... Я не верю, что это история про то, что давайте жить в параллельных мирах.

То есть они, видимо, на долгосрок, типа лет на 20 вперед смотрят, что в какой-то момент произойдет свитч.

Я ничего не могу по этому поводу сказать.

Просто знаешь, что точно?

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

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

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

Этого не произойдет, потому что на языке JavaScript ты сел, тяп-ляп, тяп-ляп, и у тебя быстро что-то заработало.

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

Наверное, JavaScript никогда не умрет.

Я понял.

Кстати, ну да.

Но это вообще интересно.

Потому что про WebAssembly что-то так долго говорили, и все кричали.

А, слушай, я знаешь, что понял?

Вот я что заметил, как он используется.

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

Как только появляется какая-то платформенная сборка для каких-то нодовских штук,

то я заметил, что появляются альтернативы.

Типа, ребята, ставьте WASM, работает везде.

И в первую очередь речь идет про ноду.

То есть когда... Не очень ясно понимаю, о чем ты.

Смотри, есть либы, у которых есть C-шные модули.

И когда ты работаешь в Docker, в Mac и еще где-то, у тебя, например, ты начинаешь запускать что-то на Mac, вот у меня часто бывает, а его работали до этого, например, на другой платформе.

И он мне прям падает с ошибкой и говорит, я не буду у тебя запускаться, типа, либо перекомпилируй, либо ставь другое, либо ставь WASM.

Это что-то с roll-up было связано в первую очередь.

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

Не могу ничего по этому поводу сказать.

Не уверен.

Вот если кто-то с таким встречался, напишите.

Но, в общем, я в этот момент посмотрел и понял.

Речь же идет не только про запуск в браузере.

Речь идет еще и про то, чтобы писать твои модули на бэке универсальными по платформе.

Потому что WASM везде работает.

У тебя машина сама не меняется.

То есть, по сути, мы получаем Java.

Так-то уж.

WASM в этом смысле очень простой.

Там-то как раз статическая типизация в WASM, только там нет объектов.

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

До Java WASM очень далеко.

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

Ну, я скорее про концепцию write once, use everywhere.

Вот это вот, да?

Потому что у тебя там есть learn once, use everywhere.

Знаешь, что я хотел спросить?

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

Тебя эта проблема волнует?

Нет.

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

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

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

Только это нужно правильно подготовить этот код с самого начала.

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

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

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

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

Слава богу, что система импортов в современном JavaScript достаточно приемлемая и хорошая.

Это абсолютно правильный подход, на мой взгляд.

По крайней мере, сейчас.

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

Можно и так, а можно и без этого обходиться.

Но и так в том числе, конечно.

Мне не нравится, знаешь, что?

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

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

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

Ну, это вопрос времени.

Они в любом случае к этому придут.

Сейчас же тенденция именно в эту сторону наблюдается.

Откуда взялась вообще эта вся тенденция собирать в один большой бандл?

Это тенденция...

Родовая травма протокола HTTP 1.1.

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

Когда мы сейчас уже давно перешли на HTTP 2, HTTP 3, уже он появляется всюду,

Проблем с этим уже никакой в этом необходимости нет.

Зачем собирать это все в один единственный бандл, задается вопрос.

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

Знаешь, на что я постоянно натыкаюсь?

Там так много проблем с динамической загрузкой модулей.

У него же есть рантайм, да, который их подгружает.

Там же дело не просто, что файл ему указал, он их пошел грузить.

Там же важно тоже в правильном порядке все это пособирать.

Сейчас, конечно, все в более упрощенном виде стало, чем раньше, когда все это было совсем ручную.

Трясется.

Но постоянно все равно.

То есть я вижу... Да, более того, если ты прям смотришь, у тебя в Вите есть такой, типа, для билда же есть отдельная прям статья для продакшена.

И там написано, что, смотрите, когда мы не смогли загрузить какой-то модуль, соответственно... Кстати, это может еще от предыдущего сохраниться, потому что предыдущий там удалили.

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

Все равно вот этого добра тоже довольно много бывает.

То есть грузится, грузится, чуть не загрузилось.

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

Хотя, я думаю, просто эволюционно мы к этому придем.

Код перепишется и начнет писаться по-другому.

Окей.

Слушай, не могу тебя не спросить, наверное, такое последнее.

Вот ты говоришь про… Я просто когда тебя слышал, ты много говоришь про концепции, которым надо учить, в каком порядке и так далее.

Как бы ты вообще сейчас учил программистов?

Что ты считаешь самым важным?

Я не знаю, честно тебе скажу.

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

Спроси меня несколько лет назад, я бы начал рассказывать что-нибудь про какие-нибудь фундаментальные вещи, связанные с тем, как устроены современные машины компьютерные, как устроен процессор, как устроена память, как устроена система исчисления.

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

Совсем не обязательно этого все знать.

Достаточно ориентироваться в эффективности этих абстракций.

Можно очень здорово программировать.

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

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

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

Мне кажется, что очень важен опыт.

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

Вот интересный пример по этому поводу.

У меня дочь.

училась в школе не обыкновенной школе, а в школе развивающего обучения.

В чем основное отличие была этой школы от типичной среднестатистической школы?

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

Может быть, в случае с программистами в современных реалиях нужно поступать именно так же.

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

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

Но обязательно, чтобы они прошли через это время,

своими собственными руками и своими собственными мозгами.

Может быть так, но не уверен.

Чем старше я становлюсь, тем менее категоричен я в своих исканиях.

В этом плане, да.

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

где-то граница в другом месте проходит.

Не всегда понятно, в каком, но где-то в другом она проходит точно.

Потому что, знаешь, иногда я просто офигею.

Мы с ребятами как-то для себя выяснили, что, может быть, у тебя другое ощущение, но у нас почему-то возник такой ощущение, что именно циклы повторения, когда мы возвращаемся на те же самые концепции, но немножко в другом формате, такой по спирали, здесь такая спиральная теория, где-то 8 лет проходит в индустрии, когда мы возвращаемся к тем же самым штукам, но немножко по другим углом.

И вот, как прикол, помнишь, было 90-е, 2000-е, когда все говорили про паттерны в ООП?

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

Исчезло нафиг, я до сих пор поверить в это не могу.

Все вдруг резко посчитали, что это неважно.

Да, немножко с другой стороны подойдем.

На собеседованиях сейчас, кроме твоих технических

Важно теперь что?

Софт-скиллы, начинают спрашивать.

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

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

Черт его знает.

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

Когда начинают говорить, вот сейчас, знаешь, вот сейчас важны soft skills.

Я такой, блин, да вам всегда это было важно, просто не придумали отдельную просто секцию под это, как правило.

Но извините, системы, которые создавались во времена Брукса, там, блин, над одной системой полторы тысячи человек работало.

И это было немного микросервисов, это была одна большая цельная система.

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

Потому что у тебя много независимых команд, вы там сами варитесь.

При этом это было еще то время, когда объем рынка программистов был совсем не такой, как сейчас.

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

И тем не менее они каким-то образом коммуницировали и решали эти задачи.

У нас с тобой, знаешь, такой под конец получилось, деды бурчат.

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

Эй, конечно.

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

Ага, это вам спасибо.

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

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

Всем спасибо, пока.