Организованное программирование

Kirill Mac (00:00.266)
нода... такая интересная вещь, которая, с одной стороны, всегда где -то рядом, а с другой стороны, никогда не выходит на уровень, как, знаешь, там, ГО или ещё что -то, что вот нода пошла, все её там захватывают, и поэтому она вроде есть, на ней вроде

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

Andrei Melikhov (01:08.36)
Попробуем,

Kirill Mac (01:09.994)
Давай сейчас, ну как бы для телезрителей напомним, вообще контекст вспомним, расскажи, пожалуйста, сейчас где работаешь, что делаешь.

Andrei Melikhov (01:18.266)
Я работаю в Яндекс .Обл делаю инструмент, который называется DataLens, это BI -ка, Business Intelligence. Это инструменты, когда надо исследовать данные. У тебя есть база данных, и тебе по ней надо какие -то графики построить. И вот, смотря на эти графики, понять, что с этими данными дальше делать. В чем -то похоже на графану, например, для тех, кто ближе к программированию или девопсу, а к бизнес -аналитике.

Kirill Mac (01:48.138)
Кстати, хочу тебе сказать, не могу про это не сказать. У меня есть два проекта, Хексли сам находится, Google Data Studio мы используем, а College мой мы используем там как раз линзу. И у нас сейчас есть тенденция в смещение туда, так что я теперь знаю к кому обращаться, если что, потому что у нас есть большой план переезда с гуглого облака, у нас просто там часть осталась связанная именно с аналитикой к вам в даталинзу. А то, что ты делаешь, ты делаешь back, front.

Все вместе, как вас там разделяется.

Andrei Melikhov (02:19.816)
Вообще в Яндексе есть такое разделение, что нода это всегда остается фронтендом. Но это старый такой вопрос, что является ли это бэкендом или фронтендом. Да, мы делаем в какой -то степени то, что называется BFF, бэкенд для фронтенды. Когда бэкенд он считает, подключается к базам данных, потом сапишек забираем, что -то с данными еще делаем и уже на клиента даем красивые данные, которые легко отрендерить.

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

Kirill Mac (03:17.61)
Ну понятно, что Frontend в том смысле, что есть некий большой индексовый там некий такой черный ящик, в который вы за ручки дергаете и как -то ним взаимодействуете или нет, или вы прям

Andrei Melikhov (03:27.176)
Не -не -не -не, смотри. Мы в облаке работаем с облаком. То есть у нас все там установлено. Те же самые базы данных, наши бэкенды. Там нет никакого черного ящика. полностью все, что нам нужно, мы это и обслуживаем. Наши бэкенды сидят рядом. Они пишут там на Python. Рядом стоят наши базы данных. Мы во все это можем залезть. Все это вместе компонуем и отдаем пользователям. И у нас есть Open Source версия.

Kirill Mac (03:43.466)
Понятно, ну то есть всё -таки бэкэнд нормально.

Andrei Melikhov (03:55.976)
То есть мы это выложили уже на GitHub, можно это скачать и у себя поднять там просто Docker Compose. Вот.

Kirill Mac (04:02.858)
Да ты что? То есть, типа, если я свой источник данных подрубаю, то я могу линзу у себя локально развернуть

Andrei Melikhov (04:09.704)
Можешь, но с некоторыми ограничениями. Там пока есть не все источники данных, там есть вопросы к тому, где ты будешь хранить своих пользователей, но мы это все постепенно решаем, чтобы это превратилось в полноценное решение, которое можно поставить в Enterprise. Но фактически, да, весь код доступен. То есть внутри мы используем уже с дополнительными наворотами, тогда оно бежит внутри. Но там нет никакого магического черного ящика, к которому мы ходим через запишки. Весь код – это код нашей

Kirill Mac (04:24.938)
Мммм... Не понял.

Kirill Mac (04:40.362)
Окей. Так, хорошо. Для того, чтобы лучше опять же контекст понимать, скажи, объем. То есть сколько кода, сколько может быть приложений, то есть что из себя

Andrei Melikhov (04:51.048)
Ну, я тебе в строчках не скажу. Это, наверное, два приложения на Node .js и два приложения на Python. Ну и плюс клиентская часть, которая написана на

Kirill Mac (05:05.578)
Какая вас команда? Все это обслуживает.

Andrei Melikhov (05:09.896)
тебе количество людей.

Kirill Mac (05:11.658)
Ну, прям да. Ну, я пытаюсь, знаешь, общий объем понять, чтобы люди примерно представляли, сколько там всего.

Andrei Melikhov (05:19.016)
Ну, человек 25.

Kirill Mac (05:20.874)
Но 25 — это достаточно большая команда на 4 приложения. А по технологиям, если мы пробежимся, не знаю, там ОРМК, Framework, из таких значимых вещей что -то входит.

Andrei Melikhov (05:35.432)
25 это не значит что это разработчики, и проекты, дизайнер. есть это в целом сколько у нас количество иногда плавает, нас то меньше, то больше. По технологиям, по этому у нас используется по моему без каких -либо фреймворков. Но я тебе точно не скажу, я в принципе туда не лазил. Для Node .js мы используем Express.

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

Kirill Mac (06:32.73)
сейчас, ам секунду, подожди, кашлянуть хотел экспресс, ну понятно, да, экспресс это скорее просто вы давно стартанули, да, и просто так с этого не следишь

Andrei Melikhov (06:45.224)
Ну знаешь, а варианты -то какие? А, ну если так, то да. Да, конечно. Ну, смотря, в Яндексе Express много лет используется, и для него есть готовые мидлвары. Поэтому ты очень быстро собираешь на экспрессе, да, все это можно подключить к Fastify, но если ты Fastify соединяешь с мидлварами, то тоже немножко уже не то становится. Надо бы тогда все с нуля переписать. Тогда. Да, наверное, если

Kirill Mac (06:47.978)
Простивай.

Kirill Mac (07:12.202)
Ну да, понятно, что

Andrei Melikhov (07:14.92)
У меня был такой Green Field, я бы взял Fastify.

Kirill Mac (07:18.57)
И вот в начале вопрос, который я тебе задал, меня очень сильно волнует, и мне прямо это интересно. Есть небольшая предыстория, что мы тоже используем, понятно, ноду в разных местах, и каждый раз, хочется сделать на нём какое -то большое полноценное приложение, оно такое чисто бизнесовое, чтобы не самому сидеть там фреймворке писать, собирать всё это, а иметь что -то олл инклюзив, когда у тебя ИОРМ и решение всех вопросов, ну, заниматься такой бизнесовой частью.

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

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

Andrei Melikhov (08:41.768)
довольно сложный то есть если брать мой пузырь то в нем ноды довольно много все себе делают bff вот в этом качестве ноды много опять же есть да тот же самый next который всем нужен чтобы быстро на реакции у тебя там кэш был и все у тебя там ссг или сср если тебе надо то есть это же тоже нода

Такого много, но если брать что -то где мы уже ноду используем нагруженно и как настоящий бэкенд, такого очень мало и очень мало специалистов. Может быть есть какие -то страны где не так, но в целом ощущение что комьюнити оно довольно маленькое. вот ездил по -моему в 18 году в Ирландию на NoteConf, ну сколько нас там было? Человек наверное 250.

И это были и core -разработчики Nod и много известных людей. И вот оно, вот всё довольно компактное комьюнити. То есть это не Java. Ты не можешь сделать большую конференцию по Nod с кучей разных потоков, где будет всё представлено. Нет, инструмент довольно узкий.

Kirill Mac (09:59.114)
про потоки у тебя очень в тему получилось, что ты не сможешь делать конференцию с кучей разных потоков на ноде. уже да, да, да, сейчас уже да, это правда. Знаешь, просто интересно, если посмотреть комментарии, я регулярно натыкаюсь, то есть как будто это в миф уже какой -то превратилось, что типа вот ребят, нода, нода, нода, и я каждый раз думаю, да вроде как бы не очень много, а почему вы выбрали ноду?

Andrei Melikhov (10:07.112)
Тут поспорить можно, если мы про ноды говорим, да.

Andrei Melikhov (10:26.184)
Но как и многие, ноды выбирают из -за того, что у тебя есть фронтендер, им нужно немножко на бэкэнде себе сделать. И тогда тебе надо или искать людей, которые знают несколько языков и одинаково в них сильны. Или сказать, окей, у нас есть хороший JavaScript разработчики, вот с такой задачей они справятся, поэтому пусть они себе на ноги сделают то, что им нужно.

И опять же у тебя же есть библиотети такие как React, которые надо запускать и на сервере, и на клиенте. И как ты будешь это делать, если у тебя не Node .js?

Kirill Mac (11:05.45)
Понятно. есть в основном по этой причине. наверное, быть, могу усилить вот эту штуку. Знаешь, какую я вещь вижу в современном мире, особенно когда TypeScript проника на Backend тоже, мы про это тоже сейчас поговорим, что вообще -то это дает офигенные преимущества для определенных проектов. Это сквозные типы. То есть тебе не нужно никакие трансформеры использовать для того, чтобы типа гонять туда -сюда.

Andrei Melikhov (11:30.312)
Спорное

Kirill Mac (11:33.13)
Ну я могу просто кейс, конкретный кейс. Вот меня было недавно два приложения, за последние полгода я разрабатывал. Например, мы наш редактор Хекс это переводили на TypeScript. И там бэкэнт очень маленький, как ты понимаешь. Это в основном проксирование, чтобы сохранить все на файлы. И для меня, например, это оказалось невероятно круто, потому что, ну, например, там socket .io, да, и он растипизированный, тебя front и back соответственно вместе работают. Это механизм для взаимодействия iframe и внешнего API, который ты даешь. То есть я очень сильно там ощутил

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

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

Andrei Melikhov (12:57.032)
Но у меня подход другой. Я предпочитаю, чтобы модельки не гуляли по системе, что есть модельки, а есть DTO. И DTO прекрасно вложатся в Open API. И более того, предпочитаю, чтобы контракты были описаны отдельно. И если они меня описаны отдельно, я могу их сгенерировать в тот язык, который мне надо. Да, они там как универсально описаны на Open API, а дальше я собираю и у меня типа улетают и на Back и на Front.

Поэтому мне не очень нужно, чтобы они гуляли через какую -то папочку shared. Так можно. Мы тоже так делаем. У нас приложение выглядит как клиент, сервер рядом, shared и мы типа переиспользуем. Но это очень опасная область, потому что дальше начинают думать, а может нам и релизы также гонять. Типы поменяли и зарелизили одновременно и back и front. Но так же не бывает. Они же у тебя поедут раздельно.

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

Kirill Mac (13:57.61)
Ну я понял, вопрос как раз так бывает, что у меня -то такой, этот, если ты знаешь, это современный подход, ну во -первых, ED -шка у нас просто это приложение на 5000 трок -кода, там нет отдельного фронта, отдельного бека, у тебя просто это совместный релиз, поэтому там просто, ну типа, это даже не приложение, которое я full -time пилю, вот. А бэк -энд, в смысле, там нету отдельного бэк -энда, отдельного фронт -энда, там есть релиз просто приложения и все, 5000 трок -кода.

Andrei Melikhov (14:16.776)
Но не бывает совместного релиза же.

Andrei Melikhov (14:24.456)
Ну что -то же бежит на сервере, а что -то бежит на клиенте. Так? Да подожди, подожди, а сколько у тебя машинок, на которые ты релизишь?

Kirill Mac (14:28.266)
Ну оно одновременно релизится,

Kirill Mac (14:35.626)
А там не так это работает. Это же редактор. стартует. Например, одновременных практик может быть запущено, зависит, сколько тебя параллельно людей. Прямо запустило практику. И тебя редактор стартует не в момент, что, типа, как на сайте. такой зашел и в пять. А у тебя, как бы, во время старта практики где -то там внутри прописано, что текущая версия редактора вот такая. И он разворачивает этот редактор, естественно, конкретный... под конкретного человека. Понимаешь, да? То есть это не сайт, запущенный все время.

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

Andrei Melikhov (15:25.704)
Ну ладно, принимается.

Kirill Mac (15:32.586)
Но, говорю, что вот для меня это сработало просто круто. Я даже недавно на конференции выступал с докладом по поводу того, как я на OTS переписал эту штуку. Но она маленькая. Она там, говорю, 5000 строк кода, что -то типа такого.

Andrei Melikhov (15:46.152)
Ну это же да, да, есть такая старая мечта, и чтобы стейт у нас тоже прорастал от клиента до бека был же нас Cerebro, например, когда -то, как стейт менеджер, они вот такую же идею продвигали, что мы прямо от бека до фронта везем один тот же стейт, одни и те же типы и становится проще.

Kirill Mac (16:03.978)
Я с тобой согласен, что когда у тебя все -таки большое приложение, раскатывающееся на большое количество людей, совместимость по типам сложная. Действительно, вот Open API, эта штука выносится. Но оно, видишь, кстати, еще знаешь, чем, мне кажется, связано с тем, что когда ты говоришь про генерацию для вашего бэкэнда, вы же генерите все равно типы для бэкэнда, которые на ноде

Andrei Melikhov (16:29.768)
Ну в данном случае да.

Kirill Mac (16:31.658)
Просто если, например, вас там джанго, вы там не сгенерите типов, потому что там типов нет. Поэтому этот подход немножко не работает, когда вы используете фреймворки, такие rich -фреймворки на бэкэнде, типа Laravel, Rails, Django. Где тебя своя экосистема с моделями со всем остальным, вот я что имею в виду. Поэтому там, к сожалению, приходится вот такое делать, типа трансляцию из бэкэндовских моделей во фронтэндовские типы.

Andrei Melikhov (16:59.464)
Ну можно JSON схему хотя

Kirill Mac (17:02.986)
Ну, это не сильно что меняет, я имею ввиду у тебя все равно есть некий код, который написан конкретно на Ruby, например, и тебе конкретно надо его превращать, да, то есть он не описывается отдельно в OpenAPI, то есть те же яйца только сбоку по сути.

Andrei Melikhov (17:14.536)
Ну, в этой схеме самое главное, где у нас источник правда. То есть летят ли у тебя типа из бэка на фронт или они описываются отдельно и

Kirill Mac (17:25.386)
Ну а вы, кстати, вы на TypeScript, я сейчас всё пишу.

Andrei Melikhov (17:26.952)
Ну это другой спор.

Kirill Mac (17:33.514)
И вот эта история про проигновение TypeScript Anabek произошла примерно в одно время с Front, или все -таки чуть позже она пришла в ноду.

Andrei Melikhov (17:45.544)
где -то примерно одновременно по

Kirill Mac (17:49.29)
Ну

Мне просто было ощущение долгое время, что сначала все -таки TypeScript как -то на фронте был очень активен, да, и только потом он постепенно -постепенно в ноду начал уходить или... Все -таки нет, все -таки он пришел туда достаточно

Andrei Melikhov (18:04.328)
Ну, смотри, опять же, если мы говорим про фреймворки, то их пишут на JavaScript. Тот же самый Fastify он написан на JavaScript. То есть, типа там это DTS. И это понятно, с чем связано, потому что мы должны писать производительные вещи, и для них пока TypeScript мешает. Иногда, ну да, да, ну ты можешь найти у Тимура Шимсиддинова тоже, про это много рассуждений, где ему жало.

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

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

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

Kirill Mac (19:53.07)
Я тебя понял. А смотри, а чё ты думаешь про такие вещи, как... Очень важно не путать, да. Есть Next .js, есть Nest .js. Вот чё ты думаешь про такую штуку, как Nest .js? То есть вот вроде... Я просто сколько вижу ребят, которые у нас в чатах общаются, они каждый раз, про это говоришь, они там слезливые смайлики ставят, что они недовольны. Типа им приходится писать, но они недовольны. Это один из не многих, кстати, фреймворков, которые я вообще не пробовал, и пока не очень представляю, что он есть.

Andrei Melikhov (20:00.872)
Угу.

Kirill Mac (20:22.154)
Что ты скажешь про

Andrei Melikhov (20:22.952)
Но штука красивая. Именно nest это знаешь, это такой ангуляр на бэкэнде. Ты когда его берешь, для тебя это как будто ты, не знаю, снова вернулся на PHP, взял там, как там фреймварх -то назывался, симфонии, вот. тебя вот ощущение того же симфонии.

Kirill Mac (20:45.866)
Визуально он похож на Spring Boot, есть такое ощущение, что он джавовую модель там использует.

Andrei Melikhov (20:50.44)
все они примерно одинаковые. есть ты чувствуешь классический ОП -фреймворк со всякими красивыми идеями. Но, к сожалению, все это построено на декораторах. Декораторы там используются не современные, legacy. Если в ангулярии у тебя тоже есть декораторы, но тебя сам движок ангуляра их разворачивает, то nest он построен поверх декораторов из TypeScript.

Kirill Mac (20:55.498)
Угу.

Andrei Melikhov (21:18.216)
legacy декораторов, ты их должен включить в TypeScript, чтобы они работали, потом они у тебя заводятся. Что с ним дальше будет здесь непонятно. И всё это очень тяжело дебажить. То есть когда его вот эта огромная Диайка, построенная на декораторах, у тебя в продакшене падает, ты открываешь то, во что она скомпилировалась и сидеешь. Потому что это очень много

Kirill Mac (21:40.266)
А, вот оно чё. Слушай, это кстати, я же хотел не просто к тебе спросить про эту штуку, ты сам на декораторы пошёл, я хотел ещё спросить про TypeORM, про MicroORM, все эти штуки. То есть я правильно понимаю, что это всё одного поля ягоды с этими декораторами и все имеют абсолютно те же самые проблемы.

Andrei Melikhov (21:58.504)
Да, это всё примерно одно и то же. То есть ты должен это принять, что ты согласен, что может быть завтра это всё развалится и не будет работать. Ты согласен с тем, что тебе будет это больно дебажить, а дальше ты получаешь удовольствие. Красивый синтаксис, всё быстро описывается, очень удобно, но бывают проблемы. Я участвовал, когда мы переводили проект Большой на Нест, выкатили его в прод и...

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

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

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

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

Kirill Mac (23:46.378)
Я бы даже, знаешь, немножко расширил эту штуку, потому что на микрофреймворках я писал на большом количестве разных языков, и проблема, честно говоря, похожа. То есть я бы сказал, что эта проблема не чистая экспрессовская, она вот именно микрофреймворка, которых у тебя мидлвары, основной способ навешивания вот этой логики на реквесты, они все в это сваливаются, если они мутабельные.

Andrei Melikhov (24:07.976)
Вот. И мы переписали. И в целом стало хорошо. То есть мы решили, сойдет. Сойдет, там до сих пор пишут на насте. И кажется довольны. Но я, наверное, второй раз в это бы не пошел. Плюс мне архитектурно многие вещи там не понравились. Там чувствуется, например, что это все заточено на то, чтобы отдавать данные. Туда очень сложно добавить рендер. Да, можно, но сложно.

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

Но там иначе нельзя. И такие вот мелочи мне не очень

Kirill Mac (25:12.106)
Это очень забавно. сейчас буквально одним... Ты знаешь, я такой для себя решал, насколько я хочу в это погружаться, но ты отбил у меня желание. я сразу понимаю, о чем идет речь, потому что я очень много тоже с этим сталкивался. Это реально очень такое решение. Не очень. И ты хочешь сказать, там такого много, да?

Andrei Melikhov (25:30.216)
Ну вот, смотря насколько ты отклоняешься от того курса, который есть вот базово. Если тебе нужно просто достать из базы данных какие -то данные и отдать их там рестом, например, на клиента, то ни во что такое ты не воткнешься. Если ты на нем начнешь строить что -то свое с роутингом, с СССР, ну, побольше, побольше, чем он дает из коробки, то ты везде уже начнешь искать, как это все дело обойти. Но в целом, я бы рекомендовал просто пройти их базовый курс.

Kirill Mac (25:35.978)
М -м

Andrei Melikhov (26:00.84)
чтобы посмотреть на это и решить, подходит оно или нет. Вот, например, тоже для чего оно хорошо подходит. Когда у тебя есть разработчики, пришедшие из .NET, и ты их просишь написать тебе бэкэнд. Даешь им nest, они смотрят, говорят. Все понятно? Нам все нравится и начинают работать. Если ты им дашь Express, то что это будет? Люди у тебя, наверное, просто уйдут писать на чем -нибудь им привычном и любимым, а не вот

Kirill Mac (26:02.634)
Угу.

Kirill Mac (26:30.186)
Если подвести итог, меня как раз смущает эта история, что только Нест, тебя получается, что абсолютно все ORM -ки на TypeScript построены на

Andrei Melikhov (26:47.88)
Нет.

Kirill Mac (26:49.674)
Ну, имею ввиду, мы... Ну, смотри, Type -URM построена на декораторах, это самое основное. Дальше Micro -URM, которая тоже сейчас довольно популярна, тоже на декораторах. Sequelizer, но он вообще я бы не назвал его Type -скриптовой уремкой.

Andrei Melikhov (27:03.368)
Ты к нему можешь написать типы, но ты втыкаешься в то, что в принципе очень сложно типизировать УРМ. Потому что ты сделал join и дальше ты начинаешь его уговаривать, что это не тот базовый тип, что него еще появились какие -то поля. И все это делается так вот. В принципе к SQLize можно уже это прикрутить.

Kirill Mac (27:32.81)
Ну, имею ввиду, что он всегда находится в таком режиме, когда ты думаешь, блин, ещё чуть -чуть и он вроде станет нормальной УРМ, но он никогда до этого не доходит. И них, по -моему, седьмая альфа там висит уже сколько год. И видно, что чувак, по -моему, был же момент, когда он сказал, я вообще один, и я вообще не могу больше работать над этим проектом. И вот это, кстати, глобально, вот эта проблема, она очень странная. То есть, ты думаешь, вроде джез, вроде столько разработчиков, даже столько инструментов, но почти все инструменты делается полтора...

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

Andrei Melikhov (28:05.448)
зависит от инструментов. Может быть тут и причина, что потребность небольшая. В моей парадигме ноды не нужны в RMP, ей не нужно ходить в базу чаще всего. Кажется, для этого можно взять что -то другое. Что нода, хороша там, где у нас есть frontend и мы хотим для него подготовить данные, но эти данные не лежат в базе. Мы стучимся в backend, через опишку забираем данные, доклеиваем и идем на

Вот там нода идеально встаёт в эту парадигму. Но одна из причин, что мы немножко затрадивали, это однопоточность, когда мы говорим именно про сам JavaScript. Здесь очень сложно. Если ты отказываешься от этого, надо городить уже какие -то сложные системы. Можно вспомнить, ребята, как же он назывался, компания, забыл уже, у них был фреймворк на акторах. Они его называли Comedy, по -моему. Да, Comedy Framework.

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

Kirill Mac (29:29.837)
Я просто скажу тебе, не то, что согласен, не согласен, просто да, он так используется, как ты описал, но я бы, например, с удовольствием бы перешел, знаешь, на ноду для именно таких классических бизнесовых задач, когда у тебя такой rich backend, но я не могу физически просто, не потому что нода не позволяет, с нодой как раз все хорошо, а потому что просто инструментария нет, а типа...

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

Andrei Melikhov (30:15.496)
есть современные декораторы, ты их уже можешь включить и использовать, потому что они из JavaScript. Но правда я не видел, чтобы на них что -то писали.

Kirill Mac (30:25.354)
Вот -вот, я тоже не видел, чтобы на них писали, типа это больше такая

Andrei Melikhov (30:29.384)
но они и такие немножко убогие пока. Там очень многого не хватает. Ты не можешь взять вот эти современные декораторы и заменить те декораторы, которые у тебя были legacy. Ну потому что, например, нельзя декорировать параметры входящие в функцию. Ты можешь только сверху на функцию накинуть декоратор, а этого мало. И кажется, это одна из причин, почему эти декораторы новые пока не заходят. Все сидят на старых.

Kirill Mac (30:40.266)
Понятно.

Kirill Mac (30:56.33)
Короче, мне значит напоминает, это опять будет история, у нас были калбеки, потом появились генераторы, там резко все рванули, либо на генераторах писать, потом появился осинк, резко все рванули переписывать на осинк. Видимо, все сидят в ожидании появления полной поддержки, чтобы потом вся экосистема опять -таки, знаешь, типа, забываем все, что было, двигаемся в новый мир. Дивный, да?

Andrei Melikhov (31:20.616)
Возможно, возможно.

Kirill Mac (31:23.274)
Это, если даже, знаешь, питоновские драйвера брать. Ой, питоновские, говорю, пасгрессовские, да? Ну, как правило, у тебя в каждом языке есть один коннектор нормальный для работы с базой. Ну, редко бывает несколько. Я буквально недавно тут глянул, потому что нам для курса надо было выбрать как... Ну, знаешь, удобно, там в PHP или в Java. У тебя есть GDBC, у тебя есть PDO, вот это, И ты понимаешь, что выбрать базу — просто выбрать... Ну, типа ты просто указываешь другой URL, по сути. А с точки зрения работы это всё одно и то же.

В ноде у тебя такого стандарта нет, и мало того, что нет такого стандарта, у тебя еще и нет... Ну, как это... DBXS Slayer это называется, Так у тебя еще и Deposgres, минимум два или три популярных библиотечки, причем одна из них работает, я, кстати, в реальной жизни это первый раз увидел использование, или второй раз, по -моему. Это не template literal, а как они называются? Template... Экспрессион, что ли? Я забыл, короче, название, когда ты, в общем, как литерал пишешь, но по факту это expression, который исполняется.

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

Andrei Melikhov (32:31.816)
А ну тогда.

Да, так на нём же построены и некоторые CSS и JS решения. Забыл правильное название. Ну да, ты функцию подкладываешь.

Kirill Mac (32:45.098)
Да -да -да, он такой редкий. И тоже там оказывается, что вроде и нормально, а при этом он, оказывается, там кучу вещей не поддерживает, и тоже такое, какое -то половинчатое решение. В итоге, ну, пришлось выбирать какой -то вариант, но всё равно меня каждый раз, когда я это ныряю, меня вот в ноде это немножко удивляет. Я думаю, блин, ну как -то немножко не хватает такого, знаешь, направленного вектора, чтобы не каждый городил свой огород,

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

Andrei Melikhov (33:27.656)
У меня немного похожий подход. Нам это не очень нужно, потому что это не задача Node .js Хотите делать бэкенд? Возьмите языки для бэкенда и подключите к ним ноду.

Kirill Mac (33:39.178)
Слушай, ну вот, видишь, мы выяснили причину, почему -то в ноде этого никогда не появится. Ну, нода это же просто инструмент, то есть, я не знаю, него... Эта же задача у не прописана в миссии тех, кто создает

Andrei Melikhov (33:52.584)
Ну он же изначально -то, как его придумали? То есть был бэкэнд, который был синхронный, с которым было тяжело работать, чтобы ты в браузере нажал кнопку и начинаешь ждать. Хотелось как -то сделать это все красиво, чтобы ты нажал кнопку, у тебя появилась надпись, окей, запрос ушел, я тебе нарисую, когда придет ответ. Не просто висеть синхронно, да, получить ответ, и когда он придет, уже в конце результат нарисовать. И вот тут вот Райан дал...

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

Kirill Mac (34:41.45)
А у меня есть... Да, а у меня есть что на это сказать. Я тебе две примеры могу привести. Кстати, даже прикольно, что мы сейчас обсуждаем, потому что когда это, знаешь, выйдет в эфир, это будет история, что такие типа вот... Есть два разных взляда и как раз определить... Ну, можно понять по этому отношению к ноде, ко всему. У меня есть два момента. Первое. Я всегда могу в таком случае приводить PHP, который вообще задумывался не так, чем он впоследствии стал. И это все прекрасно знают, что это был шаблонизатор, это не было даже язык программирования.

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

учитывая, что она сама по себе мощная, то есть ты можешь принципе много чего классного сделать, то есть нет такого ограничения, что типа вот только так делай и всё. Нет, в отличие от того же Go или какого -нибудь Husky, ты можешь писать нормальные УРМки, и вообще много чего нормального писать, тебе язык не ограничивает возможности. Так вот, понимаешь, в чём прикол? Прикол в том, что я вижу потенциал такой в ноде, и что если бы оно попёрло, это было бы классно. Знаешь, что проблема? Остальные все страдают, потому что, например, давай возьмём Jungle, Ravel,

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

а я имею в с точки зрения синхронности, поэтому, на Python появился кто? Fast API. Я с ним не работал, но я знаю просто, что он как раз ответ типа Flask синхронный, Fast API асинхронный. И мне кажется, что вот нодовская вот эта вся история, немножко пропустила момент, потому что она могла как бы возглавить это движение и всех пересадить на себя, как сейчас, например, делает Go. Да, можно, конечно, говорить, типа нам это не надо,

Kirill Mac (36:58.986)
Мне было бы приятно, если бы Noda заняла эту область, потому что я бы с удовольствием писал на ней, но не могу, потому что она мне не

Andrei Melikhov (37:07.848)
но это во многом связано и с языком, на котором нода построена, потому что это JavaScript, он развивается в большей все -таки в степени необходимости браузеров, нельзя сказать, а давайте его полностью переделаем для того, было удобно писать многопоточенные приложения на бэкэнде. Никто этим не будет заниматься.

Kirill Mac (37:27.754)
Они же не многопоточные. У тебя Python, GreenTreads, Jill. Возможности у нода ровно столько же, сколько у остальных. Это Java, мы можем говорить, что кардинально по -другому. А всякие Ruby, Python, стандартные интерпретаторы, все не многопоточные. Concurrency есть, многопоточности нигде нет. Это хорошая тема. Ребят, кто нас слушает, очень интересно, что вы на эту тему думаете.

Потому что меня волнует на самом деле будущее нода и возможность писать такие штуки. Я знаешь, такой в режиме, может быть зря, но я в режиме нахожусь, что ну кто -то когда -нибудь что -то напишет. Кстати, чтобы Андрей, правильно понимал, я среди тех людей, которые все -таки пытались что -то с этим делать. У меня есть несколько, во -первых, библиотека, во -вторых, писал, попытка была написать фреймворки, отвечающие на вот эти вот запросы, и даже они есть на GitHub, и там есть интересные решения. Я знаю, что ребята их использовали в своих проектах. Но я до продакшн это, к сожалению, не довел.

И может быть мои потомки смогут это довести.

Andrei Melikhov (38:33.48)
Но вот была еще одна область, где тоже показалось, что нода резко взлетает. Это лямбда. Потому что действительно нода достаточно быстро стартует, по сравнению с джавой, например. И ты можешь выполнить какую -то функцию и умереть, но нода не спроектирована для того, чтобы умирать. Это не PHP. По -хорошему, она так работать не должна. И уже сейчас мы видим, что в этой области нода немножко отходит в сторону.

что берут вместо этого, например, Amazon QuickJS. Это просто легкий движок для JavaScript, который запаковывает вас, ставит там, запускают и все. Потому что он стартует быстро. И для лямбда он подходит лучше. Ну, меньше тебе надо ресурсов, быстрее стартует. Для лямбда самая важная скорость старта. То, что она будет, например, долго молотеть, им наоборот выгодно. Потому что они с тебя деньги возьмут за это. Но чтобы она ответила мгновенно, им важно.

В этом нода вытесняется.

Kirill Mac (39:53.386)
О, вот про это я вообще ничего не знал. Чуть поподробнее. Просто смотри, я не совсем понял. Ты сказал, что нода стартует быстро. Это да. Но самое главное, что она медленно умирает. А потом, когда ты сказал про... Ну, в смысле, у неё проблема типа с умиранием. Она не для этого нужна. А потом ты привёл пример других штук, но говоришь только про старт. И я не до конца понял. Всё -таки, если нода быстро стартует, проблем это с стартом нет. Есть остановка или я тебя неправильно понял?

Andrei Melikhov (40:18.44)
Нет, смотри, эти штуки стартуют еще быстрее, а ресурсов им надо меньше.

Kirill Mac (40:24.97)
Ещё быстрее, понял теперь, да.

Andrei Melikhov (40:26.408)
Оно просто не спроектировано. Мы не пишем так наше приложение. Мы пишем, чтобы приложение стартануло и живет часами, днями, каши какие -то там загружаются. Оно для этого. И там тоже свои проблемы начинаются с той же самой модульной системы, что тебе надо бандлить, чтобы влезть в лямбду. Вот развесистый node -modules ты туда не будешь затаутивать, он тебя часто и не влезет.

Kirill Mac (40:38.378)
Угу. Угу.

Andrei Melikhov (40:53.768)
Поэтому там достали смотреть на что -то полегче. Просто полегче.

Kirill Mac (40:58.09)
Расскажи в двух словах про эти движки. Как ты назвал? Quick Jazz? Ага, может в двух словах.

Andrei Melikhov (41:02.408)
QuickJS. Это написанный на C, интерпретатор JavaScript, в нем нет JTA. То есть на тяжелых вычислениях он будет медленнее. Но сделать что -то простенькое, для чего нам нужны лямды, особенно edge лямды. Вот в edge лямде тебе наиболее важна скорость. Ну здесь скорость старта и скорость выполнения, но у тебя там никогда не бывает большого объема. Ты не будешь там 50 мегабайт лопатить. Ты просто возьмешь, например, там заголовка поправишь и дальше побежишь.

Вот поэтому такой движок прекрасно подходит. есть просто носи написанный движок JavaScript. Он лежал несколько лет мало кому нужный. Первым его заметила Figma, потому что они занимались тем, что делали плодины в браузере. И сначала они пытались это сделать на шиме для Shadow Realms. У нас есть пропозл для того, чтобы исполнять безопасно пользовательский код в браузере.

Вот у нас есть пропозал Shadow Realm. Они взяли для него полифильчик, и он протекал. Конечно же. Тут они такие, что делать, что делать. О! У нас же есть написанный на C очень легкий движок JavaScript. Мы его запакуем в Asm и будем в него затидывать результат, вставлять назад, и нас все будет чистенько, и никуда он не вылезет. Они его использовали. А не так давно, несколько месяцев назад, по -моему, Amazon сказали, что вот они уже у

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

Kirill Mac (42:35.594)
Слушай, я сейчас попробую сформулировать такую мысль. То получается, что с одной стороны, V8 невероятно оптимизирован, там всякие крутые штуки, но учитывая, что лямбда работает быстро и так далее, все эти оптимизации работают хуже, потому что они занимают время, занимают ресурсы, и выкинув все это, сделав тупой как дрова вообще имплементацию, они получили мега выигрыш вот для

Andrei Melikhov (42:36.136)
Это QuickJS.

Kirill Mac (43:04.874)
очень компактных

Andrei Melikhov (43:06.152)
Да, ну у Gita же какая система. Он должен сначала прогреться, потом твои функции станут быстрее. Но иногда тебе выгодно не греть, а сразу вычислить и отдать результат. И здесь он выигрывает. Да, но не все на это идут. Кому нужен V8, но который не хочет тащить всю обертку ноды, но ему надо исполнять просто немножко JavaScript на сервере, и они сейчас смотрят на то, что у V8 у тебя есть V8

Это просто возможность поднять еще один экземпляр V8, кинуть ему на вход JavaScript и получить ответ. Да, тебя там будет все синхронное, потому что тебя не будет там event loop, но опять же для таких пользовательских скриптов этого хватает. И Cloudflare на этом строит свою систему.

Kirill Mac (43:53.45)
Сейчас извини, если я правильно понял, ты мне что просто они в баке это как сервис поднимают и JavaScript туда кидают, то есть они не стартуют ноду, а просто переиспользуют

Andrei Melikhov (44:02.024)
Да, да, именно так. То есть там не нода, там просто запущенный V8 с какими -то их обёртками. Ты же можешь запустить чистый V8, тебе не нужна нода для того, чтобы тебя JavaScript бежала на сервере. Просто запускаешь V8. Не обязательно V8, сейчас есть решение, которое построено и поверх SpiderMonkey, например, как же он называется, Winter .js. Там движок. А SpiderMonkey, как я понял, они решили это, что...

Kirill Mac (44:15.562)
Угу.

Andrei Melikhov (44:32.008)
у них это лучше упаковывается в Asm, потому что это нам на вазмере поднимается дальше. Поэтому они взяли SpiderMonkey, и на нем тоже решают задачи. Но это решение задачи, как нам выполнить JavaScript на сервере. Это не означает, что для этого нужно взять Nodo, потому что Nodo — это больше гораздо. Это V8, плюс большая обвязка на libUV. Там чтение файлов, работа с сетью и так далее. Все это можно заменить. Ну и мы видим, что разные решения есть. Тот же самый банн, вот который хайповый.

Там же тоже не V8. Там JavaScript Core используется.

Kirill Mac (45:06.57)
Прям секундочку подожди, я сейчас зарядку поставлю. Хорошо, что ты про Бам вспомнил, я тебя сейчас про него поспрашиваю.

Andrei Melikhov (45:09.576)
Угу.

Kirill Mac (46:14.25)
Ты меня слышишь сейчас?

Да, у меня... А,

Kirill Mac (47:44.586)
Так, ты слышишь меня сейчас? меня представляешь, пока мы с тобой разговариваем, меня взяла и камера. Это как раз может быть та самая проблема. Первый раз я шел зарядку ставить и смотрю в камеру, и там такое, прикинь, сообщение типа, произошла какая -то ошибка, надо рестартануть. такой, ну елки.

Andrei Melikhov (47:46.728)
Да.

Kirill Mac (48:02.922)
соответственно может быть получится что у нас как бы только вот основная эта камера и заработает ну ладно чего страшного так ты да мы с тобой постепенно перешли к разным вариантам да и вот ты про бан сказал и действительно я забыл совершенно про него спросить раз уж мы пошли в эту сторону слушай я вот честно когда вообще в ноде особенно до появляется чуть новое я стараюсь ну не тратить сильно это время ты сам знаешь почему front -end но да

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

Это технология, которая в итоге умирает, исчезает и исчезнет? Или это какая -то штука, которая займёт своё место в

Andrei Melikhov (49:07.528)
Ну вообще, давай да, про альтернативы на сервере. То есть, как я уже сказал, немножко нас выжимает уже из лямбд. Если вернуться к тому классическому использованию, что ноду мы ставим на сервер и используем как бэкенд, ну или как бэкенд для фронтэнда, как прослойку. У нас, во -первых, появился сначала Dino от Райна Дала. Это разработчик Node .js в какой -то момент сказал, что все было сделано неправильно.

делаем иначе и сделать DIN. Там TypeScript, V8 и другая обвязка. Там много было разных идей придумано, потом от чего -то он отказался, там говорил нам node -модули не нужны вообще, сейчас можно туда прикрутить уже package .json. Понимание есть, что нужно двигаться в сторону все -таки чего -то привычного, но тогда уже это сильно подстегнуло ноду.

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

А следующий вызов для нода был бан. Бан — это нас еще одна реализация JavaScript на сервере, где они взяли JavaScript Core, этот движок из Safari. есть они везде пытаются выиграть чуть -чуть по скорости. Это такой вот факт, может быть, спорный, но про который часто говорят, что JavaScript Core все -таки быстрее, V8. Вот, у них используется JavaScript Core и своя обвязка, где они вот в каждом

пытаются сделать быстрее. И они пришли и сказали, вот смотрите, вот вам не DIN, а drop -in replacement для ноды. То есть концепции не меняются, вы можете убрать node .js, поставить туда бан и у вас все заработает. Да, там есть методы, которые называются бан .что -то, это методы более быстрые, у них более лучшие API, но вы их можете не использовать. Тогда, если что, можно будет прыгнуть назад на ноду.

Andrei Melikhov (51:32.2)
Но если вам не хватает скорости, вот вам решение, где можно стать быстрее. Именно на этом он и выстрелил. Все пошли делать бенчмарки и доказывать, вот здесь бан работает нечестно, здесь он ставит файлы типа умолчания из кэша, и там Even You пришел и сказал, да, это можно все то же самое сделать, и у нас будет точно так же там каком -нибудь там pmp -е -ме работать. Но везде они пока выиграют. То есть нашли много моментов.

где разработчики других решений говорят, да, вот здесь мы тоже можем вот это вот решение скопировать. Здесь они хитро вот так пошли, и вот здесь мы видим, что для Windows так сделали, чуть -чуть выиграли, здесь для MacOS чуть -чуть выиграли, здесь на Linux тоже побыстрее работают. Ну, все на это смотрят. И команда NotJazz, что сказала, да, у нас не было фокуса на скорость. Потому что, кстати, очень интересное высказывание, я помню, от них, что, мол...

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

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

То есть мы как думали, да, они нам сейчас что -то показали, но там еще непонятно, под виндой не работает. Вот они выложили, пожалуйста, берите, работает под Windows. У них там появились интересные фреймворки, та же самая Elysia, которая работает только на банн. У нее много идей, взятых с Fastify. Красивый фреймворк, но не работает на Node .js. И в то же время, же самый Fastify у тебя на банн не заведется. Там еще много несовместимости.

Andrei Melikhov (53:54.44)
Мне кажется, сейчас существует в таком режиме, чтобы подскёдивать ноду. Мне неважно, я его никогда не буду использовать в обозримом будущем. Я, конечно, не могу сказать, что через 5 лет не окажется, что нода заброшена, бан стал стандартом, поэтому переходим. На горизонте год -два точно такого не будет. Скорее, останется, знаешь, как для реакта был Inferno, Когда они говорили, смотрите, мы

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

Kirill Mac (54:35.35)
Это, кстати, вот эта часть в ноде, пожалуй, самая забавная из всего, что я наблюдаю, потому что я не в какой другой экосистеме. Нет, ладно, такое в Java последнее время было, вот последние годы. Но знаешь, вот эта история, когда разработчики нода нет, модули одновременно грузить старые и новые нельзя, автоматически детектировать нельзя. Нет, вот тут мы не можем. Появляется

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

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

Andrei Melikhov (55:36.488)
В целом да, да, стараемся так и жить, что особо не дёргаемся, нам это доедет, можно пойти поконтрибьютить. У ноды очень открытое к этому сообщество, поэтому я живу на NPM -е, на ноде. Не заменяй ни на что. Зачем мне NPM менять? Что мне даст Yarn? Я уже видел, что Yarn умер очень давно. Потом появился Yarn 2, который Barry. Но это же не тот

Если мы возьмем по популярности, то популярен тот заброшенный Ярн, потому что он шел вместе с Crate React Up. А так -то многие даже не знают, что есть Берри, а есть Ярн. разные

Andrei Melikhov (56:21.224)
Поэтому от задач опять же отталкиваюсь. То есть я видел, когда тот же pnpm лучше подходил, потому что он лучше живет с монорепозиториями. Многих вещей не хватает пока в npm. Может быть,

Kirill Mac (56:35.274)
Я уверен, теперь и завезут, потому что у меня даже ощущение, что у ребят есть какая -то ревность, что ли. То есть если какой -то инструмент начинает слишком сильно внедряться, они тут резко просто такие выпускают новую версию, которой типа «а мы всё перенесли к нам». Это очень забавно наблюдать.

Andrei Melikhov (56:52.68)
Ну не всегда так бывает, бывало даже хуже, как раз с Ярном и его плагонплеем и в NPM -е команда анонсировала чуть ли не за день, что у них будет похоже и ничего не сделала. А команда Ярна потом говорила, что то ли они в баре рассказали, что они такое запустят, то ли еще что -то. И появился анонс. В NPM -е будет такая штука, но в NPM -е ее так и нет. А анонс был.

Kirill Mac (57:21.226)
Угу.

Andrei Melikhov (57:22.056)
да, действительно, местами бывает, чувствуется ну или как вот эта вся история с corepack, в которой не заезжает npm и команда node говорит, что нет, npm не часть corepacka npm это вот просто часть node .js неотъемлемая мы не можем вам дать возможность выбирать у вас всегда будет npm и к нему дополнительно вы можете поставить или yarn или pmpm или что угодно но не замена

Kirill Mac (57:49.93)
Угу.

Andrei Melikhov (57:51.592)
NPM всегда в

Kirill Mac (57:54.858)
Ну, справедливости ради, эта ситуация, которая есть в ноде с пакетными менеджерами, честно говоря, какая -то специфическая для ноды. Ну, то есть нет нигде такого... Нет, хотя я вру. В Python периодически что -то происходит, но там как -то народ не сопротивляется. Там есть PIP, в Ruby есть гемы, тут есть у Composer. Ну, то есть там почему -то именно в ноде стараются все время, знаешь, типа не улучшением текущего, а давайте напилим новый инструмент и заменим все старые. Вот

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

Andrei Melikhov (58:29.928)
Может быть это связано с достаточно жесткой позицией Core Team, позиция стоит в том, чтобы не ломать старые. У ноды отличная обратная совместимость. Во многом с этим и связано то, что некоторые вещи заезжают очень долго, потому что нужно не сломать то, что есть. Зачастую мы видим, что можно на 10 мажоров ноды обновиться и ничего тебя сильно не сломается.

Kirill Mac (58:55.562)
А ты не находишь забавный факт, что за это же любят Java, да, и говорят, вот почему Java в Enterprise, да, вот у нее такая штука, что ты берешь там код, написанный там, черный, это когда, запускаешь на новый JVM, и тебя все хорошо. И получается, что года идут, вот ты говоришь, что у них вот такая штука, там они так придерживаются, но отношение к ноде, по -моему, не поменялось от слова вообще. То есть ощущение, что это типа…

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

Andrei Melikhov (59:31.24)
Но это не правда. Как раз нод это очень стабильно.

Kirill Mac (59:32.906)
Вот. В этом ты и прикол, да, что, видишь, получается, это не правда, а ощущение никуда не делось.

Andrei Melikhov (59:40.264)
не знаю почему. Там на самом деле была история, что нода почти не развивалась. нас там была версия 0 .12. Потом команда отдельно форкнула. Федор Индутный форкнул тогда и вместе с ним несколько человек ушли и стали обновлять ноду. Они сделали... а я уже забыл за давностью лет как назывался этот форк. А да, точно, айо. А потом

Kirill Mac (01:00:04.074)
Айон назывался.

Andrei Melikhov (01:00:08.488)
влились назад и дальше уже пошел четкий ритм с LTS версиями все так уже достаточно интерпрайзно мы знаем, что раз в год весной нас появляется версия, которая осенью станет LTS и проживет со всей поддержкой там пару лет ну не всегда иногда бывает вот как с 16 версии, которая пораньше умерла из -за OpenSSL, а так нормально все очень очень очень ровненько

Kirill Mac (01:00:35.038)
Ну и раз уж мы как бы пошли в эту тему, да, мы поговорили, что есть банн, что есть специфические вещи для лямбда. Это очень интересно, я потому что это пропустил немножко. Да и вообще, честно говоря, лямбда нам не очень нужны. А вот в целом, если говорить про развитие ноды, будущее, -то знаешь, таких фундаментальных вещей, ты что -то об этом знаешь? У тебя есть какая -то картинка или там как положит руку на сердце, фиг знает, что они там будут делать?

Andrei Melikhov (01:01:02.696)
Ну, мы видим. Все, что я сказал про Dina и про BAN, это то, куда двигаются ноды. То есть мы видим, что максимально хотят стандартизировать все с браузером. Есть же WinterCG. Это комьюнити -группа, которая занимается тем, что выравнивает опишки. Там можно зайти и прямо посмотреть в разных движках, какие опишки поддерживаются. И чтобы в ноде меньше было того, что было написано когда -то чисто для ноды.

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

Kirill Mac (01:01:51.914)
У

Andrei Melikhov (01:02:02.92)
то что решили все -таки что эти самые старые наши command .js должны умирать должны заехать ECMAScript модули которые у нас есть в

Наверное, в ближайшие годы будет ожидаться еще более лучшая поддержка, потому что там еще очень много боли. Там же даже этот вышел. Проект Harmony. Помнишь, было когда -то с JavaScript? Вся эта история, когда у нас был ES4, который не взлетел, который нас внутри Flash Action Screed был, там даже типы были, там были объекты, и все это отстрелили, сказали, мы сейчас делаем ES5 попроще.

А чтобы достичь гармонии, мы открываем проект Harmony и это будет наш ES6, когда мы сделаем всё, что мы хотим. Промесы заедут, сингвейты, объекты, что -то ещё туда заезжало, много чего. А, LED -конст тогда. Кто на ES6 заезжал, те помнят. И вот сейчас то же самое говорят. Да, всё -таки мы признаём, что нормально у нас в ноду никак Экмоскрипт -модули не заезжают. Поэтому...

Kirill Mac (01:03:04.778)
Угу.

Andrei Melikhov (01:03:15.784)
собрали пачку пропозалов, которые нам нужны, чтобы всё -таки это всё дело заработало. Обозвали это тоже Harmony. Это вот большой проект, который, я думаю, будут года два тянуть на то, чтобы всё -таки у нас появилась возможность полноценно заменить CommonJS модули. В какой -то момент, может быть, даже примут вот это сложное решение, что CommonJS вообще не работает. Хотя я не очень в это верю. Я думаю, будут гасить

Опять же, ну так вот в ноде мы живем, что мы не должны совсем уж всё ломать. Ну кажется так. То есть я не ожидаю, что будет что -то большое. Я не вижу, чтобы сейчас обсуждалось, давайте там, не знаю, те же самые гринтреды сделаем, там, как гартины. Вот чтобы вообще легко было. Такого движения нет, людей -то мало. Там не стоит никакая крупная корпорация за нод .js, чтобы что -то такое вносить. Я думаю, вот так вот ровненько, ровненько.

будут продолжать решать свои

Kirill Mac (01:04:16.938)
Интересная вообще, конечно, судьба у инструмента и такое ощущение, что вот действительно, если бы джесс и фронтенд его не было, нода бы, наверное, и ушла с небосклона.

Andrei Melikhov (01:04:26.536)
Ну, наверное, да. То сила нода — том, что это тот же самый JavaScript, который нас есть в браузере. Но это вот тоже не совсем правда. Ты не можешь взять разработчика из браузера и посадить его пилить бэкэнд. Потому что другая специфика, парадигмы, должен им обучиться. Даже само понимание того, что вот там у тебя это окружение отдельного пользователя, а здесь у тебя все пользователи живут вместе.

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

Kirill Mac (01:05:10.666)
Я обычно это рассматриваю как парадигмы, типа событийная архитектура именно с точки зрения браузера и клиент -серверная, то есть понимание, что есть клиент -сервер и вот это взаимодействие множество коннектов, потому что тебя все фреймворки по сути являются следствием этой архитектуры и поэтому, например, все бкн -фреймворки вообще выглядят абсолютно идентично, тебя там разница абсолютно в микроскопических деталях и по -другому там особо не сделаешь,

Кстати, знаешь, хотел тебя спросить, знаком ли ты с такой концепцией. Я недавно ней стакнулся, я недавно разрабатывал приложение, и мне очень понравилось, это называется «Инерция». JS, не видел? В двух словах просто скажу. Разбирать может не будем, но может интересно будет. У меня, значит... Давай так, сейчас попробую, чтобы глубоко в это не копать. В общем, концепция такая.

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

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

Но нужен клиент. И оказывается, я очень был удивлен, мы сделали это приложение, используя Laravel, используя такую штуку, как Inertia. Это на самом деле подход Next .js, но адаптированный под другие фреймворки. То есть когда у тебя фактически используется классический роутинг и вообще бэкенд твой фреймворк, но вместо того, чтобы отдавать вьюху с бэкэнда, шаблонизатор классический, какой -нибудь, у тебя фактически рендерится вьюха на реакте.

Kirill Mac (01:07:30.442)
устроено всё таким образом, что для тебя это абсолютно прозрачно. То есть у тебя нет API, ты просто в контроллере в экшене кладёшь данные, как обычно, ну типа передать во вьюху, а в реакте они тебя просто прилетают как props, неким магическим образом. И получается, что тебя routing бэкэндовый, ну опять же, как в Next получается, у тебя по сути нету… ну всё происходит прозрачно абсолютно, и у тебя нету менеджмента на клиенте. Ну если у тебя несложный какой -то очень прям

У тебя, как правило, же вопрос отрендерить или заполнить форму. И эта штука называется «Инерция». Её создали изначально для Laravel, а сейчас она принципе расходится широко и начинает использоваться для других тоже штук. Ты с ней не знаком, но я думаю, ты, может быть, будешь видеть, потому что она всё шире и шире расходится. И знаешь, я оценил. Мы последние три месяца командой разрабатывали эту приложуху. И да, там ещё не всё готово с точки зрения экосистемы, но скорость разработки типа приложений…

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

Andrei Melikhov (01:08:39.592)
Из таких же сейчас, тот же HTMX очень популярен.

Kirill Mac (01:08:44.362)
Это немножко другое. HTMX это ближе к решениям типа Hotwire. А это прикол в том, что здесь у тебя не создается какая -то новая штука. По сути, Inertia — просто клей. У тебя на фронт -энде обычный реакт. Но смысл в том, что тебя, грубо говоря, как тимплейт с бэкэнда приходит и рендерится под конкретную

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

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

Andrei Melikhov (01:10:01.0)
Ну, я не видел.

Kirill Mac (01:10:08.906)
В общем, и, кстати, злые марсиане тоже меня очень удивило, после того, как я написал пост, злые марсиане затвитили, потому что они, оказывается, в это время тоже начали с ней экспериментировать и, типа, тоже пытаются продвигать немножко. Я у Ситника хочу поспрашивать в следующий раз на эту тему, что они с этим делают. Но это все -таки больше решение фронтендовых проблем. Окей, по ноде более -менее понятно. Слушай, а скажи, в России вообще есть какое -то, не знаю, движение, комьюнити, хоть что -то связанное

ноды.

Andrei Melikhov (01:10:40.072)
особо

Kirill Mac (01:10:42.026)
То есть просто сидят люди в разных компаниях, что -то там пилят и все,

Andrei Melikhov (01:10:45.224)
Ощущение такое, да. У нас было небольшое комьюнити в Петербурге, но его больше нет, и оно было прям очень маленьким. Ну, человек там 12 -20 собирались

Kirill Mac (01:10:58.57)
А че ребята делали, где?

Andrei Melikhov (01:11:00.936)
Да просто мы собирались докладить и читали.

Kirill Mac (01:11:03.85)
Не, я имею в в смысле, какие компании, то есть они рассказывали, где они работают, какие задачи.

Kirill Mac (01:11:29.77)
Но обычно, кстати, я каждый раз, когда встречаю компании, которые пытаются делать прям полноценный бэкэнд, ну используют такие тяжелые фреймворки, УРМки, все жалуются, что очень сильно по -разному код написано, очень -очень много

Сначала такое,

Andrei Melikhov (01:11:45.672)
Ну, чаще всего это экспресс, на который навернули просто немерено, и ты в этой лапше

Kirill Mac (01:11:54.506)
с «Экспрессом»… В моей практике «Экспресс» умер давно, и, знаешь, меня тоже… Мы местами где -то не дергаемся, а местами где -то дергаемся. Я помню, что «Коа», помнишь, какое -то время два именно почему -то, не «Коа», а просто «Коа 2» было очень популярен. И мы такие «О, классно переходим», мы на него перешли, и он умер. И причем умер довольно быстро, и мы такие «Да что ж такое -то? Ну что делать ?» И вот когда вышел «Фастифай», я его застал прям, когда он только, знаешь, появился, и я такой долго смотрел, смотрел, у него смотрел, а потом он как попер.

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

Andrei Melikhov (01:12:37.416)
Но смотри, COLA почему стала популярной? Потому что она дала возможность красиво писать асинхронный код. Да, когда у нас заехала SYNC -AV, и оказалось, что ты можешь в экспрессе объявить асинком функцию, и вот у тебя более -менее нормальный, ну, с отдельными вопросиками, но более -менее нормальный асинхронный код на экспрессе, то COLA уже и тебе не нужна, потому что точно так же написать просто на экспрессе. А Fastify...

Kirill Mac (01:12:42.474)
Ассихронный,

Andrei Melikhov (01:13:06.984)
Он жив скорее за счет того, что его активно двигает автор. Мать твоя Калина. Это один из корк -интрибьюторов ноды. И он на каждом... На любой нодовой конференции он везде рассказывает про Fastify. Он про него пишет. У него там есть и блогжик, и рассылка. И ежегодная вот эта конференция Node .Conc, он там один из организаторов. Он продолжает тащить, тащить везде Fastify. Показывает его, активно

в тот же самый банк появился, он пришел к ним, показал, него есть issue, что это дело не работает. И за счет этого Fastify живет. Несмотря на то, что Express по установкам популярнее, попробуй ты в него законтребьютить. Там месяцами просто ждешь. Там очень маленькая группа людей продолжает его тащить. Этот несчастный Express 5, он все еще в бете. Да, там они опять вроде бы собрались и

Kirill Mac (01:14:00.33)
Ха

Andrei Melikhov (01:14:04.2)
Да, мы вот собрали уже список задач, которые надо доделать, и тогда пятый экспресс выйдет. Но очень маленькая группа, достаточно медленно двигается. А там один человек, который супер активен, и он на нем уже строит бизнес. Он сейчас же продвигает еще это решение поверх Fastify, которое позволяет сделать опишку, ростовую опишку в базе данных. Вот, он ее... Я забыл ее

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

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

Kirill Mac (01:15:18.666)
Единственное, поправ в справедливости, ради 80 % сайтов написано на PHP, 30 % на WordPress. Я просто эту статистику смотрел, но да, 30 % всех сайтов на WordPress. И, кстати, удивительно, насколько сложно вот эти перемещения происходят, просто капец, чтобы сдвинуться с одного на другое. Но мне кажется, FastEY всё -таки дорос до момента, когда, если у него активность упадёт, там всё -таки комьюнити гигантское, и там такое количество решений уже вокруг него, причём стандартизированных довольно.

Блин, приятно на нем

Andrei Melikhov (01:15:49.96)
Приятно, но я не ощущаю того, что все такие. Все. Никакого экспресса. У нас появился Fastify, мы все на нем пишем. Да, что ты нам принес? Удали немедленно экспресс. Нет такого.

Kirill Mac (01:15:55.178)
А, переключение ты не ощущаешь,

Kirill Mac (01:16:03.178)
Слушай, не могу не спросить такую вещь. У нода откусывают постепенно. А не откусывают ли у него бэк энд го?

Andrei Melikhov (01:16:13.64)
Я думаю нет, потому что опять же, ну опять же, это мой пузырь, что в моем пузыре нода все -таки это BFF. И какой гол, когда тебе надо рендерить React на сервере? Те же самые типы, да, надо шарить. Вот. И надо взять людей, которые пилят браузер и дать им, ну браузерный код, дать им возможность под себя что -то поправить на сервере.

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

Kirill Mac (01:16:52.397)
Хорошо, тогда я по -другому сформулирую. Получается, что твой тезис основной сводится к тому, что BFF, если только мы это наблюдаем. Но даже на самом деле люди пытались и использовали, особенно когда Go не было, но надо какие -то быстрые бэкэндовые воркеры организовать, но да вполне себе под это добро подходит. вот там...

Речь не про frontend, речь про какие -то штуки, которые быстро в бэки работают. Я так понимаю, что нода становится там... Если ее использовали, то перестают, потому что Go окончательно всех побеждает. Кто -то Java использует, но в основном это горячая история. И нода остается... Если у вас есть front, значит будет нода, если есть бэк для нее. Либо... Либо зачем тебе нода?

Так, наверное, ты формируешь это,

Andrei Melikhov (01:17:46.12)
Ну, на самом деле надо же плясать от того, какие у тебя специалисты есть. Что ты делаешь, даже в какой стране ты живешь, потому что в одной части мира одни фрэмворты популярнее, какие -то инструменты, в другой другие. И тебе надо решить задачу, да? Ты что -то сейчас пилишь. Что это? Это будет MVP? Или это ты все -таки думаешь, что это годами будет литься? Сколько специалистов ты можешь нанять, если тебе их не хватает? Может быть, у тебя тут полный рынок джавистов?

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

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

Kirill Mac (01:18:53.002)
А насколько... Я правильно понимаю, что основной приток людей туда, это типа вы взяли фронтендер и говорите, давай чуть -чуть расширишься на ноду, Насколько слож... Насколько, во -первых, им нравится, такие, такие, когда пробуют бэк -энд, такие, о, прикольно. И насколько легко их туда затащить.

Andrei Melikhov (01:19:09.928)
Знаешь, что это абсолютно разные люди. То есть я вот люблю писать бэкэнд. Мне нравится, что я делаю запрос в опишку и получаю ответ. И мне все понятно. И я знаю людей, которые также говорят. Поэтому я люблю писать для бэка, потому что все очень просто. Я могу там тестов написать, юнит тестов и все это проверить. Все так красиво, удобно. Запаковал там на сервер, поставил. Все побежало. А на этом браузере ко мне будут приходить у тебя

не работает в Safari такой -то версии, мне его еще поднимайте, изучайте, почему вебпак неправильно там CSS -ки склеил, какая скука. А есть абсолютно другие люди. Они говорят, что я вообще не хочу лезть на сервер, я не хочу в девопсе этом разбираться, мне очень нравится визуальная составляющая. И вот их прям не затащить. Они скажут, да, я чуть -чуть себе там поправлю в контроллере, но, пожалуйста, таких задач на меня не кидайте.

дайте мне лучшую возможность классную динамическую формочку на реакте сделать, от этого удовольствие получу. И такие -такие люди есть. Главное под палкой не заставлять, чтобы делать. Ну, я вот редко касаюсь клиентов, мне это не очень интересно. Я могу. Я могу там на реакте что -то собрать, там... Я даже на фликсах уже очень плохо верстаю, я есть тех времен, когда там float left, клея above, вот. Да.

Ну просто мне это не очень интересно, а там мне интересно. Там автоматизировать что -то, там ямли типа писать. Ну люди разные. Поэтому просто так не получится. Да, взять человека с улицы, а, умеешь на реакте писать, ты Node .js разработчик, тоже. JavaScript, JavaScript. Нет, надо в специализацию

Kirill Mac (01:20:58.282)
Честно, мне кажется, что гораздо проще взять любого бэкэнд -разработчика и на ноду пересадить, что синтакс есть другой. Ну да, синхронность, самая непривычная деталь будет в остальном, язык и

Andrei Melikhov (01:21:11.304)
Ну зависит. Ты можешь найти такого человека, что он будет делать, но каждый день будет тебе жаловаться, что вот и его любимые там Гошечки, всё гораздо лучше. Зачем же я тут страдаю? Не так много. Вот нам же нужен человек, который будет это дело любить, что он придёт и не будет ненавидеть, что там какой -то дурацкий JavaScript, а он наоборот такой, интересно, как там в других языках, а вот здесь так, а мне вот это нравится, а здесь у меня мультипарадигменность. Я

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

Kirill Mac (01:21:49.194)
Знаешь, я хотел тебя спросить, сейчас подумал, есть в ноде одна вещь, которая меня всегда смущает и она кардинально отличается в других языках. Она связана с инкриментальным апдейтом изменений. Если вдруг кто не знает, я просто объясню, что, например, если мы берем PHP, у PHP

Каждый запрос странички — по сути, старт приложения с нуля. Поэтому там вообще проблем не существует. Поправил, что угодно, моментально получил результат, все хорошо. Самое смешное, что все так… Ну, как бы, когда -то так только и работало, когда CGI был. Потом все от этого ушли, PHP единственный остался — это его legacy. В других языках, вот берем, например, рельсу, джангу, не знаю, спринбут и так далее. То есть ты стартуешь приложение, это может занимать какое -то время.

Например, в Spring Boot -е хорошее приложение может быть часик стартовать, но в целом оно потом нормально легко отдаёт. Но во время разработки, когда ты стартанул, люди, которые с этим никогда не сталкивались, они могут увидеть интересную деталь. В тех фреймворках, где это не встроено. Ты исходник поменял в браузере F5 жмякаешь, у тебя ничего не поменялось. И понятно дело, что почему это происходит, потому что при старте он в память загрузился и висит там. Так вот, если опять же мы берём с тобой... Давай на рельсе, потому что мне это ближе всего, я с ней...

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

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

Kirill Mac (01:24:05.29)
тяжелому рестарту. Я отстал от жизни или это проблема? Или я неправильно делаю что -то?

Andrei Melikhov (01:24:14.376)
Ну да, рестарт тяжелый. Мы спасались во времена Common .js модулей тем, что Require позволяет сбросить кэш. И ты можешь перереквари без кэша и тебя все побежит уже с новым кодом файла. Так делали даже, чтобы на живую подменять. С ESM так нельзя.

Kirill Mac (01:24:36.234)
Кстати, тебе хочу на что сказать. Вот я делал свой фреймворк на джессе. Это было года 3 -4 назад. Нодос он называется. Так вот, ты не поверишь, это одна из главных фич в нутри него была как раз сброс кэша реквайера для того, перезагрузка работала. И у меня получилось. Я такой вау, оно реально работает.

Andrei Melikhov (01:24:52.488)
Да, это работает. Так делают даже на живых проектах, чтобы не рестартовать все. Вот только этот кусочек. Ну а в остальном, да, также и живем, что более того, если у тебя TypeScript, тебе же еще нужно дождаться, пока он транспилируется и перезапустится. Ты перезапускаешь приложение постоянно. Написал, перезапустил. Да, все

Kirill Mac (01:25:13.258)
Елки -палки. Слушай, а меня всегда удивляло, ну как бы, я когда начинал, особенно крупных приложений, такой думаешь, ребят, ну а что вы не... Почему никто ничего с этим не делает? Ну типа видно же, что это проблема. Я так понимаю, что просто всем лениво, привыкли и, не знаю, подстроились как -то, да?

Andrei Melikhov (01:25:30.792)
скорость не такая уж медленная, есть перезапускается достаточно мгновенно во -первых, во -вторых, мне кажется на фоне того сколько мы ждем пока у нас виппак перебилдит все привыкли что здесь еще быстрее это не так больно перезапустить на джайс приложение ну это что такое, это секунды

Kirill Mac (01:25:52.202)
секунды много, когда у тебя такой быстрый цикл разработки. Но я тебя понял. Это одна из причин, почему, например, приложение, такое бэкендовое классическое, с моделями, ОРМами и всем таким, будет сделать сложновато из -за необходимости постоянного рестарта. Там тоже прогрузка может быть большая. Пока конфиги, пока ди, пока тосио 5 -я, 10 -я. Это займет время. Окей, я тебя понял. Ладно, серебряной пули нет, все понятно.

Andrei Melikhov (01:26:22.152)
Ну опять же, да, как мы это решаем, мы переходим на то, что у нас появляются юнит -тесты, и ты пилишь все на моках очень быстро, маленькие файлики, а потом оно все вместе уже запускается и тестируется, тогда у тебя все работает, ну тебя цикл становится

Kirill Mac (01:26:31.05)
Угу, да.

Kirill Mac (01:26:40.01)
Хорошо, тогда не могу тебя еще не спросить. Это, конечно, ближе к фронт -энду, но все -таки и бэк -эн тоже затрагивает. Появление... То есть веб... Вот ты уже несколько раз сказал веб -пак, веб -пак, веб -пак, да? Тут же тоже происходят изменения. Там много кто пытался веб -пак подвинуть, все они поумирали доблестно, кроме Вита. Я все время White хочу назвать, но мне заставляют называть его VIT. И VIT -еста, который появился, наверное, чуть позже, да, но я уже сейчас честно тебе скажу...

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

Andrei Melikhov (01:27:25.128)
Не -не -не -не, ну там всё Ролапы есть,

Kirill Mac (01:27:28.906)
Ну да, да, Ну я имею ввиду, что... Смысл в том, что там понятно почему это быстрее, да, это не просто магия. А вот недавно, я долго думал время, что ну джез -то уже вряд ли кто -то подвинет. Но черт побери, каждый раз, там с фронтендом что -то надо делать, когда тестинг там лайбрери какой -нибудь и всякие вэпаковские штуки, и плюс модулей, плюс TypeScript.

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

Andrei Melikhov (01:28:04.808)
есть такое движение. Опять же, джез не совместен пока с ESM модулями и в это упирается уже. Есть такие движения. А если встроенная сейчас в ноду уже нас заехала даже простенькая система для тестирования, то есть ты можешь написать простенькие тесты прямо на чистой ноде.

Kirill Mac (01:28:12.874)
И болит каждый раз из -за этого.

Kirill Mac (01:28:30.858)
Слушай, да, но мне кажется, я не очень понимаю, честно говоря, смысла прямого. То мне кажется, может там есть какой -то непрямой смысл. И я объясню почему, потому что в Python есть тысячу лет встроенные тесты. Но кто их использует? У тебя там PyTest и так далее. Но слишком мало они дают возможностей. Может они как базу, типа основу для своих фреймворков туда это завезли?

Andrei Melikhov (01:28:51.24)
Уменьшение зависимости. Это нас очень популярный тренд. Если у тебя какая -то микро, либо тебе нужно 2 +, 2 проверить, зачем тебе еще тащить рядом Jest?

Можешь сделать это всё

Kirill Mac (01:29:04.682)
Ну да, это правда. Да -да -да, согласен, согласен. То с этой точки зрения вообще вопросов нет. Но это тогда просто кейсы, когда у тебя действительно просто микроскопическая штука, и тебе там не надо развить структуру файлов с хорошим выводом и все такое. Но в любом случае, да, то есть ты видишь эту миграцию, и что ты думаешь, все -таки мы на Витест все сдриснем или джест починят или что -нибудь еще

Andrei Melikhov (01:29:29.928)
Но я пока вижу, что активно она видят смотрят. Сейчас, секунду.

Andrei Melikhov (01:29:38.472)
не могу сказать здесь у меня нет мнения так же как и с веб паком знаешь тоже вот мы его не сильно любим но он остается стандартом и кажется многие проекты с него не слезут очень многие продолжают ожидать что он станет таким же

И также есть Jest и Vitesse. да, как вариант, да, я вижу, что многие на него уже смотрят. У меня здесь нет мнения.

Kirill Mac (01:30:13.706)
Но в любом случае, кроме Vita, альтернатив нет. Все остальное, какие -то поделки, переделки, которые не имеют такой сил и

Andrei Melikhov (01:30:23.08)
Ну да, появляется, умирает. Там Ром был. Теперь вместо Рома, Биом они пилят. Ещё что -то. Но тоже ещё раз надо понимать, что Вид это не сборщик, что у него под капотом есть билд и роллап. И них есть идея того, что они там сделают ещё свой сборщик какой -то более быстрый. Но сейчас у вас в дев режиме есть билд.

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

Ну неплохо, неплохо растет, многим нравится,

Kirill Mac (01:31:18.25)
Да, да, да, он просто из коробки решает проблемы, но вот я опять вот ощущаю тот вайп того, что вся экосистема сдвигается, знаешь, типа все вместе дружно перебегая в новое место. Причем вот какую бы мы с тобой тему не затронули, вот реально в каждой теме так происходит, в каждой. Но да, конечно, в этом плане не остановимо, я не знаю, доживу ли я до того момента, когда я увижу какую -то, знаешь, более -менее стабильную систему и не придется каждые несколько лет.

Видишь, Nodo, вроде ты говоришь, она там поддерживает совместимость, а вот с инструментами, мягко говоря, там не

Andrei Melikhov (01:31:54.024)
Но мы видим, что все эти инструменты говорят про скорость. Нам не хватает скорости, и наше приложение становится больше и тяжелее. Ну и что делать? Или ты 20 минут ждешь, пока оно соберется, или меняешь себе

Kirill Mac (01:32:09.738)
не могу не сказать, что я буквально на днях записывал там парнем Тимур из мира, где они у них приложение, них реп, он сказал два миллиона строк кода, и он говорит, что у них есть отдельная команда, которая занимается именно оптимизацией, вот знаешь, типа, я бы назвал это, они говорят это front ops,

или developer experience, то есть они занимаются именно оптимизациями, инструментария того, что все работало быстро, меняют. У них тоже там есть типа история, что они на webpack очень сильно засели, потому что много своих плагинов и так далее. Но он мне же сказал такую интересную штуку, что них сборка занимала, я не помню сколько, но что -то очень много она занимала, ну два миллиона строк на TypeScript, сам понимаешь, там пока это соберешь. Так вот он говорит, что их ребята там умудрились ускорить это до 20 секунд, что, честно говоря, очень неплохо.

И они там какую -то Rastovскую имплементацию использовали. Я что -то не помню. Оно как -то типа Webpack, только Rastpack, что -то RSpack. RSpack, по -моему. Не использовал никогда.

Andrei Melikhov (01:33:08.808)
СВС может

Andrei Melikhov (01:33:14.472)
А, а, RSPAC, да. Ну просто, ну да, у нас же есть еще для ускорения TypeScriptа свс, которые отстреливают вообще твои типы и просто максимально быстро пересобирают это в JavaScript, не проверяя по

Kirill Mac (01:33:30.25)
Ты имеешь ного? А, или это Растовский? Я просто их путаю.

Andrei Melikhov (01:33:32.136)
а вот я не помню, помню ногу, ногу, наверное, ага, там другая проблема, что у тебя у TypeScript нет, в принципе у TypeScript нет никакой спецификации и не факт, что оно завтра будет работать так же, как ты задумал сегодня

Kirill Mac (01:33:35.562)
Да, один ногой написан, второй на оресте написан.

Kirill Mac (01:33:53.674)
замечаешь, какая -то грустная нота получается. Я думал, сейчас мы немножко такой bright future для ноды нарисуем.

Andrei Melikhov (01:34:00.168)
А, нет, ну как? Ну, я не знаю, смотри, мы же должны быть инженерами. Мы не должны, я выбрал себе, что вот, это значит там, в Японии, там, с RRMN какой -нибудь там, пришел в компанию и до старости в ней работает. Вот я выбрал, что я node .js программист, выпустился с универа, стал работать с ноды и хочу до пенсии сидеть на ноде. Нет, мы должны смотреть на весь

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

Kirill Mac (01:34:53.866)
Ну да, и у нас такой типа претендент на это бан, по крайней мере он пытается таким стать. Мы -то вряд ли его будем использовать, но я -то точно не буду. Но он хочет.

Andrei Melikhov (01:34:54.312)
ничего не

Andrei Melikhov (01:35:04.936)
Ну не факт, да, у него есть свои вопросы, ну как минимум там другой движок. Это уже делает его не очень тропым реплейсмент, потому что что -то тебя в V8 работает, а что -то у тебя работает только JavaScript Core. И может быть ты где -то во что -то упрешешься. Там надо осторожненько.

Kirill Mac (01:35:22.922)
Да, да и плюс, слушай, люб... Ну, все -таки опытные разработчики прекрасно знают, что окей, это классно с нуля делать проект, когда у тебя никакого легоси нет, но давайте посмотрим, когда у вас появится проект, и вам придется поддерживать какую -нибудь хрень, где вы приняли неправильное решение, теперь вам надо менять, и появляются новые ребята, которые делают что -то бодрее и веселей. Все абсолютно попадают в это, и вот вопрос том, как это произойдет. мы знаем миллиарды примеров, типа вот CoffeeScrute появился, и где он?

Все это просто забрали в ЖС, и все с ним стало нормально. Это далеко не единственный пример, когда такое происходит.

Andrei Melikhov (01:35:57.864)
Да, и я не расстроюсь, если у меня и TypeScript отберут и скажут вот тебе решение на чистом JavaScript. Ты можешь здесь написать типы, у тебя здесь нет енамов, и хорошо. Я буду писать просто на типизированном JavaScript и отличное. То есть если так случится, так даже лучше. меня исчезнет эта непонятная прослойка.

Kirill Mac (01:36:17.994)
В этом плане, я так просто для тех людей, которые пишут на JavaScript, я хочу сказать, что они все знают. Я недавно тут убедился, что в JSC TSCervey предоставляет такую штуку, которая называется TestCheck. То есть ты комментарии в начале файла пишешь, и тебя, в общем -то, бесплатно появляются в JSC типы TypeScript 'а. Если кто так не делает, обязательно сделайте, вы просто на халяву получите дополнительные проверки типов. И, кстати, даже местами можно там JSDoc

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

Andrei Melikhov (01:36:59.944)
Да, я с нодой так живу. Я не хочу, когда я делаю что -то маленькое на ноде, не хочу рядом разворачивать TypeScript. Я не хочу это компилить. Я пишу это на чистом джессе, но TypeScript всё равно подхватит типы у меня в escode, они появятся. Этого мне

Kirill Mac (01:37:08.33)
Угу.

Kirill Mac (01:37:15.338)
Да, да, да, да, это

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

Andrei Melikhov (01:37:33.416)
Вообще я давно хочу посмотреть на Go, наверное я бы пошел туда.

Kirill Mac (01:37:40.298)
наверное довольно логично и привычные в этом смысле. Я тебя понял.

Andrei Melikhov (01:37:46.504)
Мне очень импонирует, что там есть паника, которую ты не используешь. Ты вместо этого выводишь такой тупл из ошибки и результата. Очень хочу такое.

Kirill Mac (01:37:59.562)
Я тебя понял, в тебе живет такой этот сишник, такой, чтобы знаешь, по модному, но без эксепшенов. А есть ребята,

Andrei Melikhov (01:38:08.328)
Ну без exception

Потому что это же... Ну это же GotoStyle.

Kirill Mac (01:38:17.578)
Да, я тобой согласен, но знаешь, я когда... Как тебе сказать? Мне, наверное, больше импонирует подход с монадами, левт -райт, но я не думаю, что их можно так втащить. Кстати, может быть вполне можно сделать, знаешь, не хаскель -тащить, а вот типа такого же языка. Затащили.

Andrei Melikhov (01:38:38.408)
Мы в NES затащили ResultContainer Но я увидел, что народ его использует как промисс У которого есть какой -то результат, а они не склеивают дальше. Ftrite можно хитро это направить, но это не использовали. Но в целом, когда мы делали приложение, мы решили, что максимально постараемся избавиться от Exception и сделали ResultContainer типизированной.

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

Kirill Mac (01:39:14.442)
То есть есть ребята, типа, давайте попробуем все -таки, ну, без проверок, да, чтобы тебя внешний механизм проверять от резалта, и соответственно тебе не надо наличие ошибки проверять, Ну, кстати, если ребята, кто из вас никогда это не пробовал, в этом плане я могу сказать, что очень сильно прокачивает функциональные языки, потому что там все это по полной используется, и после этого ты возвращаешься в свое, в свое болотце, так сказать, просветленном, и можешь использовать всякие интересные штуки.

Andrei Melikhov (01:39:22.696)
Да.

Kirill Mac (01:39:41.226)
Главное слишком сильно не перестараться, сам знаешь в продакшене можно там потом у тебя никто работать на проекте не сможет, если

Andrei Melikhov (01:39:49.512)
Да, если кто -то не понимает, о чем мы говорим, есть классный доклад от Артема Кобзаря и Дима Махнева про монады с резалтом. Надо на него ссылочку дать. Там они хорошо объясняют, как это в разных языках, в чем проблематика и как это можно решить.

Kirill Mac (01:40:03.946)
Обязательно тогда скинь ссылку, да.

Kirill Mac (01:40:09.194)
Я говорил, что последний вопрос. Нет, я понял. Я еще один хочу тебе вопрос задать. Смотри, есть определенный набор пропозолов, которые в ноде стоят. Я ждал некоторые из них по разным причинам. Например, я очень обожаю этот оператор. Господи, представляешь, я даже забыл, как он называется, который они взяли из F -sharp или Xero, когда у тебя вот эта передача данных от функции к функции. Pipe, да, Pipe, точно. Господи, что же мной случилось, что я забыл?

Andrei Melikhov (01:40:33.064)
А, ну пайп такой,

Kirill Mac (01:40:37.994)
И я помню,

Andrei Melikhov (01:40:49.224)
Но это же не к ноге вопрос, это к JavaScript вопрос.

Kirill Mac (01:40:53.098)
Согласен. Но я в целом имею в виду, что это я просто как пример привел. А есть ли какие -то вот сейчас пропозалы, которые реально интересные, крутые, классные, которые примуты и изменят нашу жизнь или все там такое просто

Andrei Melikhov (01:41:07.4)
Но вот как я говорил, есть набор пропозалов, которые нам в ноде очень нужен для того, чтобы перейти на ECMAScript модули. Вот этот вот Harmony проект, это важно. Так я больше не помню ничего, зачем бы я прям сидел, следил. Была интересная вся эта история с декораторами, когда же их довезут. Ну как бы они у нас уже заехали. Вон на стейч 3 они сейчас находятся и появятся в браузерах. Вроде всё.

Ааааа

Kirill Mac (01:42:04.65)
Это, кстати, интересно, это как будто бы даже немножко семантику нарушает, то есть у тебя язык вроде работает одним способом, но у тебя часть языковых возможностей резко перестает работать не потому что, в спецификации написано было изначально, Ну, то есть типа у тебя по прототипу вроде как формально идти можно, но если там наложат эту штуку, то ты должен как бы проверять как будто бы, где ты

Andrei Melikhov (01:42:28.712)
Но это скорее создание хорошего изолированного контекста. есть для кода, который там исполняется, него Global будет ограничен вот этим закрытым контекстом. Он не сможет вылезти. И ты сможешь в нем запускать модули. Вот ты с npm скачал, ты же не знаешь, что на самом деле там. Может быть там в свежем патче что -то долетело. И ты не хочешь, чтобы он тебя в файловую систему лазил. что -то тебе. Все это надо изолировать. Это мы уже двигаемся, кстати. Тоже в ноде появилась весь DIN.

Kirill Mac (01:42:32.202)
Да, да.

Andrei Melikhov (01:42:57.512)
возможность сказать, что нельзя ходить в файлы, нельзя ходить в сеть. Ну и в принципе классно было бы, если бы мы могли код который исполняется сказать нельзя лазить в наш глобал. Исполняясь там, отдай мне только результат.

Kirill Mac (01:43:12.138)
Ну да, особенно учитывая, какие периодически стреляют истории, мне хочется прямо даже с гитхаба собрать и статейку написать, потому что это очень прикольно, да, как кто -нибудь куда -нибудь внедряется и потом всем попадает, и после этого начинают подписи делать, для комитов, пакетов, всего чего угодно. Это же довольно забавная история. Понятно. Андрей, тебе... Чего, большое тебе спасибо, что ты пришел, рассказал про ноду. Ребят, кто нас слушает?

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

Kirill Mac (01:44:11.914)
А что, в принципе... Да? Скажи что -нибудь. Слушай, никакой специфики нет. Ты можешь просто сказать что -нибудь, что хочешь, и в принципе всё.

Andrei Melikhov (01:44:13.256)
Прощаемся или как?

Я не знаю, как у тебя видео -то заканчивается.

Ааааа

Andrei Melikhov (01:44:26.28)
Я еще раз напомню, что самое важное выбирать инструмент под задачу. Не нужно пытаться заколачивать гвозди микроскопом, засовывать ноду туда, где она не предназначена. И наоборот, если вам кажется, что здесь она хорошо работает, вы тесты прогнали, производительность хорошая, значит сделали на ней полноценный бэкенд. Тоже ничего в этом нет страшного. Просто понимайте ограничение инструмента. Это самое важное.

Andrei Melikhov (01:44:55.528)
Спасибо. Пока.

Kirill Mac (01:44:58.41)
Так, я не знаю, Наташа придет или нет, смотри, значит, как у нас тут все с тобой работает. На камере, значит, я не знаю, тебя... А, у тебя сколько камер, кстати, включено? У одна камера, да? А, ну все. Так, здесь... Я каждый раз немножко боюсь, потому что здесь, мне кажется, можно что -нибудь нажать, и что -нибудь неправильное получится. Но по большому счету, если я не ошибаюсь, все, надо сделать, это сделать лифт. И просто не вырубать, да.

Andrei Melikhov (01:45:09.511)
Одна.

Andrei Melikhov (01:45:25.128)
Там вот аплодинг. Видно, что идет.

Kirill Mac (01:45:29.738)
да вот но в любом случае когда ты либо жмякаешь аплоудинг нормально до закачивает вот так что давай давай нажмем да и просто дождемся когда закачается и все андрейте еще раз спасибо

Andrei Melikhov (01:45:41.544)
на самом деле у меня товарищ пилит эту штуку, можешь его позвать к себе и хорошо попытать в Израиле но там больше девопсит и немножко фронтендит так что

Kirill Mac (01:45:49.77)
А, да? Прикольно. Ну, я думаю, что

Я понял. У нас есть к вопросики, честно тебе скажу. Ну, надеюсь. А, кстати, знаешь, что хотел сказать? Я же с Антоном Назаровым тут встречался пару недель назад. Меркантильность. Короче, мы... Да -да. Я туда тоже вступил, сейчас там всё изучаю очень подробно. Короче, я... Пока мы с тобой разговаривали, вышло видео с ним. Моё. Это как раз первый раз, когда я с нормальным микрофоном был.

Andrei Melikhov (01:46:06.696)
А, это который учит, что надо на двух работах работать. Волчары.

Andrei Melikhov (01:46:23.432)
Ясно, ясно.

Kirill Mac (01:46:24.938)
Пойду смотреть. Всё, большое тебе спасибо. Давай, пока. До новых встреч через пять лет. Я думаю, снова увидимся. Давай, пока.

Andrei Melikhov (01:46:26.76)
Пока. Ну неплохо было. Пока.