Podlodka #416 – Node.js

Всем привет, друзья! С вами подкаст «Подлодка». Меня зовут Женя Котелло, и я сегодня в студии с Катей Петровой. Катя, привет! Всем привет! И я часто делаю такую подводку к некоторым выпускам, и сегодня не исключение, я снова ее сделаю. Я очень удивлен, почему на тему сегодняшнего выпуска мы пишем выпуск спустя сколько? Пять лет существования подкаста? Семь лет существования?

Алло, Женя, 8 лет уже. 8 лет, кошмар. Удивительно, что 8 лет мы обходили Node.js стороной. Да-да, вы все правильно поняли. Мы сегодня будем говорить про Node.js. Может, мы надеялись, что закопается? Извините, пожалуйста. Это типа не получилось.

Ну вот нет, не закопалось. Более того, кажется, все уже понимают, что Node.js это одна из мейнстримных технологий, все ее активно используют. Короче, что это такое? Что это за зверь? Вокруг него как раз-таки очень много, мне кажется, стереотипов, очень много каких-то предвзятостей непонятных.

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

система. Короче, разберемся. В выпуске я сам этих ответов еще не знаю. Я только чуть-чуть одним пальчиком трогал на JS. Тем сегодня и интереснее будет поговорить. И в гостях у нас Игорь Антонов, Игорь Тимлит в Т-Банке, автор канала про JavaScript и разработку. конференции подлодка React, TechLead и Java Crew, человек многих умений, лектор в HTML-академии университета ITMO и спикер. Ну и кроме того, Игорь еще пишет книгу по Node.js. И еще я просто докину, насколько я знаю, любопытный факт,

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

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

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

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

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

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

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

конференции, какие-то выступления. И я вокруг этого сфокусирован. То есть, либо помогаю организовывать, либо сам выступаю. Сначала это был журнал «Хакер», потом другие журналы про IT-шку, там «Стемный администратор». Даже успел поработать с ребятами из Битрикса, когда писал для них статьи про...

популярную систему управления контентом. Ну и впоследствии я перешел в HTML-академию, где как раз-таки я долгое время и преподавал, менторил и разрабатывал как раз-таки курсы для разработчиков. И основное направление было нода, JavaScript, TypeScript.

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

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

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

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

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

там типа на ноде где-то крутится. Кто-то вообще не знает, что речь идет о ноде, просто пишет npm install, а потом узнают, что это имеет какое-то отношение к ноде. Давай попробуем определиться, что такое Node.js вот сейчас в 2025 году, но я надеюсь, что... Жень, жалко, что ты про образ...

жизни не упомянул. Мне понравилось в плане. Мне кажется, это лучше всего описывать. Что такое Node.js? Это образ жизни. Нормально. Образ жизни — это когда ты начинаешь свой день с NPM install и, как говорится, поехали. На самом деле, все, что ты, Жень, сказала, оно плюс-минус равносильно.

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

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

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

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

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

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

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

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

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

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

всего крутого и интересного. Пустить снежок на сервере. Да, пустить снежок на сервере или положить сервер. Это как метафора, реально, пустить снежок на сервере. Я пытаюсь понять, что это могло бы означать. А у меня вопрос. Открываем серию ламерских вопросов.

Ну, не ламерских, а наивных, как мы любим говорить. Ну, прям как сильно журнала «Хакер» — ламерские вопросы. Вот я прям вспоминаю тот вайб того времени, ламерские вопросы. Как узнать ИП ламера в чате? Вот помните, такое было? Вопрос. На чем сама платформа написана?

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

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

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

И самое главное, выполнить его максимально быстро. Потому что приложение мы пишем, как говорится, уже серьезное на JavaScript. Его нужно выполнять быстро и максимально оптимизировано. Поэтому V8 это классный выбор. Он быстрый. Мне не хочется говорить самый быстрый, потому что сейчас...

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

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

Кстати, это на самом деле была не первая попытка, но мы можем, в принципе, тоже отдельно проговорить и разобрать, какие были другие решения. Но получилось, как говорится, что получилось. И второй большой компонент Node.js — это библиотека LibUV, как ее еще тоже говорят. Это как раз-таки...

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

более подробно. Как-то вот так. Написано оно, кстати, на C. Я предположил, что на C, когда услышал название LibUV, потому что, когда что-то на Lib начинается, это всегда обычно плюсовики либо сишники. Ну да, все так. Там много там Lib всяких разных. Понятно. Слушай, у меня, наверное, сейчас немножко произошло в голове коллизия. Что в итоге можно назвать рантаймом? Node.js можно назвать рантаймом для JavaScript? Или все-таки V8 это ближе, типа рантайм? Нет, именно с Node.js, потому что...

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

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

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

и долгое время единственным инструментом для создания и выполнения JS-кода на стороне сервера. Но это было не так. Впервые эксперименты в этом направлении начал еще делать Netscape. У них был LiveWire или LiveWare, который позволял как раз-таки выполнять JavaScript на сервере. И если мне не изменять память...

Это случилось еще то ли в 96-м, то ли в 97-м году. И, собственно говоря, они позволяли выполнять JS. JS-то только появился. По факту это JS появился в 95-м году, если мне память не изменяет. И по факту тут как раз начался такой цикл развития, где мы можем пользоваться этим языком и можем пользоваться ими только в Brawl.

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

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

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

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

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

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

Получилось стать платформой, которая, опять же, быстрая, опять же, переиспользует опыт браузера, где JS уже выполнялся быстро. Наверное, самое было благоприятное время для рождения Node.js. Хотя, когда Noda появилась, прошло какое-то время, Noda начала очень медленно развиваться.

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

Нода в начале пути очень медленно развивалась. Прям чертовски медленно. И была такая история, что даже браузер обгонял. То есть, когда выходили новые стандарты Экомаскрипта, нода не все сразу подхватывала. Почему не подхватывала? Ну, потому что не пытались быстро обновлять.

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

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

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

Тогда еще было принято называть его ECMAScript 6. Это промиссы, генераторы и прочие фичи, которые появились в этой спецификации, стали доступны. И, в принципе, разработчики получили классный опыт, который они могли переиспользовать как из браузера, так, соответственно, и в Node.js. это длилось не сильно.

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

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

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

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

Ага, сам автор ноды это Райан Даль. То есть он изначально позиционировал как отдельный проект, который позволит нам выполнять JS на стороне сервера. И изначальным саппортом, поддержкой ноды как раз-таки занималась компания JoyNet или Joy. что-то такое я точно название могу исковеркать но какая-то компания которая джой и что-то там м или в этом роде фронта да что-то похожее но потом как раз таки вот когда случилось это расслоение а ее джесс там уже как раз таки вступила

сообщество разработчиков, любителей open source и так далее. И уже стоял вопрос, а почему бы не принимать какие-то предложения уже от сообщества? Ведь сообществом же делать быстрее, тем более мы видим там проекты типа Linux и всего остального, они прекрасно развиваются, в том числе и какие фреймворки.

какие-то, и где задействовано максимальное сообщество. Ну, а потом, кстати, после этого объединения, тут, наверное, стоит дополнить, что в итоге появилась Node.js Foundation, под эгидой которой, в принципе, Node продолжает развиваться, и уже в нее присоединяются многие компании, крупные такие. как и Google, и Microsoft, и каждый вносит какую-то лепту, какие-то предложения.

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

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

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

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

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

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

шел на создание C-Sharp. Да, помню, у меня после годов использования Delphi, точнее, на Delphi я не очень много писал, но было дело. Ну, в общем, вся вот эта история с построением интерфейсов как раз в визуальных редакторах, там на Visual Studio много было на C-Sharp. Потом, когда первый раз пописал...

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

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

все, скорее всего, так или иначе в своей жизни видели, примерно представляют, что это за язык. Да и у нас был выпуск про JavaScript, так что, если кто-то хочет освежить именно базы по языкам, пожалуйста, Фил. Так, у нас есть выпуск про JavaScript? По-моему, есть. Есть, есть, есть. И про TypeScript тоже есть.

Чуть не провалился. Короче, выпуск есть, так что мы сегодня про JavaScript будем говорить в рамках того, насколько это нужно для ноды, но если хотите именно про JavaScript, идите туда. Ссылочку на выпуск приложим. Так вот, а концепции какие? Что нода такого поверх JavaScript делает?

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

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

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

какой-нибудь бэкэнд, либо на PHP, либо, например, на .NET, там какой-нибудь framework ASP, .NET MVC и так далее. И потом нужно было еще переключаться на front. Это, конечно, было дико неудобно, потому что, когда ты используешь несколько языков, особенно разных, это всегда вот сложно переключать.

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

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

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

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

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

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

Была всегда такая проблема. Если кто-то пользовался сервером Apache, его настраивал, то, в принципе, примерно понимает, в чем суть. Что потоки, они не бесплатны в системе. Каждый поток — это, во-первых, какое-то количество памяти, это инициализация потока, это какое-то время.

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

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

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

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

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

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

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

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

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

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

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

Как только операция будет завершена, информация о ней, о ее выполнении поместится в очередь, и, соответственно, event loop, часть Node.js, сможет выполнить этот код, какой-нибудь там callback, например, мы еще просто не будем закапываться уже в детали, сможет выполнить, и пользователь получит

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

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

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

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

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

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

концепцию node.js, про которую обязательно спросят на любом собеседовании про node.js, но на самом деле она работает очень быстро, и вот я когда читаю лекции про node.js, я всегда показываю исходник этого кусочка, написанный на C. Как это выглядит? По факту это обычный цикл, который вызывает там в определенном порядке определенные функции и это те самые фазы

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

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

Тут, кстати, еще стоит дополнить про саму библиотеку любви, про которую мы уже говорили. В чем еще ее, так сказать, изюминка? В том, что, во-первых, на основе даже она же кроссплатформенная, она работает и в Windows, она работает в Mac OS, работает и в Linux, но мы знаем, что какие-то...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

что без TS уже как будто бы жизни нет. На собеседованиях JavaScript разработчиков чаще спрашивают именно про JS, а не про TS, хотя потом все пишут на TS. Это, кстати, тоже такой странный факт. То есть ты на собеседовании спрашиваешь одно, а потом человек начинает писать на TS. Но в ноте сейчас начинает появляться

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Казалось, что если ты работаешь с TypeScript, ты сразу себе просто настраиваешь DevTooling так, чтобы запустить компиляцию было делом ничего тебе лично не стоящим. Зато у тебя все при проверке валидности типов и вообще того, что у тебя...

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

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

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

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

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

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

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

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

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

Я потом смотрю, у меня тогда еще Node был довольно грустный, и я смотрю, у меня память просто куда-то заканчивается, и я такой, ну что происходит? А у меня там Node Model просто распухло до каких-то непристойных размеров. Это тысячи файлов, тысячи файлов, которые просто лежат мертвым грузом, и самое интересное, что...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сделаны в Ярне, они тоже перетекли в NPM. Вот сейчас идет оптимизация загрузки, оптимизация установки зависимости. Она как раз-таки то, что предложено в PIN NPM, оно потихонечку как-то реализовывается в NPM. С одной стороны, можно использовать сразу готовый

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

которые ты применял раньше, которые уже устоялись там в других средах, там, если мы говорим там про спринт, там вполне себе там конкретная структура, есть абстракции в виде там контроллеров, сервисов, да, у нас есть какие-то там модельки и так далее. Если там брать мир PHP, там тоже, в принципе, самое еще Zen 4.

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

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

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

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

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

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

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

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

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

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

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

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

то вот Framework Nest — это один из таких мастодонтов в мире Node.js, который сегодня активно используется и часто является выбором по умолчанию. У него, конечно, есть свои ограничения, есть сложные вещи, которые не просто обходятся в определенных приложениях, но если вот...

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

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

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

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

Но сломать, конечно, и получить проблемы при отладке здесь, наверное, проще всего простого. Есть еще, кстати, один фреймворк. Он пока не так сильно популярен, но его активно прям пытаются продвигать. Это Adonis.js. Это еще один корпоративный фреймворк. Его очень часто пытаются...

сравнивать с воровал из мира печки потому что там очень мощный силой там генерация кода у них прям свой взгляд на то как это должно выглядеть и на выглядит это действительно хорошо то есть вот те кто привык работать с каким-то другим стекам будь то например с современными версиями PHP, если мы говорим про фреймворк Laravel, или, например, Symfony, или, например, тот же самый вот Spring, есть опыт, или ASP.NET Core. Вот это прям очень похоже.

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

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

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

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

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

Я просто помню, ты когда начала говорить про Kotlin, я сразу вспомнил то время, когда был еще Flow от компании Meta. И был этот TypeScript, и как раз-таки Kotlin в то время заходил, и начинали рассказывать, что вот мы можем идти на пи...

писать код, который потом скомпилируется в JS и сможете его использовать. И вот тогда было интересно, блин, а что же в итоге вы выстрелили? Кто победит? Какой инструмент станет первым? В итоге победил TypeScript. Я не буду рот здесь открывать и продолжать дискуссию, а то выпуск уйдет туда, поэтому я просто... Пипа.

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

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

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

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

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

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

По факту, если мы говорим про фреймворк экспресс, какой-то мини или Fastify, они все опираются на стандартную библиотеку. Только они предоставляют более простой API, который удобно пользоваться и который более понятен. В ноде мы все это можем сделать, как говорится, просто...

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

желательно, чтобы не сильно завязываться на этой legacy. То есть ждать, что Express, например, полностью перепишут, ну, скорее всего, такого не будет. Тут, наверное, еще можно сказать про фреймворки, да, то, что я назвал Express, Fastify, Nest, Adonis. На самом деле были еще промежуточные...

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

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

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

Сейчас принято в Node.js архитектурно подходить к сервисам. Это диктуется тем, какой фреймворк ты выбрал? Или есть какие-то общие принципы именно для всей Node.js? Ну, каких-то общих принципов нет. Тут, скорее всего, либо фреймворк, либо какие-то собственные предприятия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нода предлагает альтернативное решение, которое называется Child Processes. По факту это еще одно API, которое нам позволяет управлять дочерними процессами. То есть это не настоящие потоки, это дочерние процессы, но в которых мы можем прикладывать отдельные операции и, соответственно, эффективно задействовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

же самого TypeScript, им нода нужна для Visual Studio Code, который они сейчас активно продвигают. И опять же, если мы говорим про Azure, то там тоже можно запускать Node.js приложение, поэтому Microsoft здесь, как говорится, в прямой заинтересованности в развитии инструмента, который будет активно...

использоваться. Если брать другие компании, то тут точно я знаю, что есть и Red Hat, который одноименный Linux дистрибутив, и PayPal, насколько я знаю, тоже участвуют, ну и множество других компаний. Из таких необычных, кажется, только я слышал, что это SAP, который делает систему...

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

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

Короче, нашел какой-то блог-пост про то, что Node.js Foundation с кем-то там из Linux запартнерился. И там ссылка, вот, типа, вот, Node.js Foundation, подчеркнуто просто, я думаю, попаду на сайт Node.js Foundation. Кликнул, перешел, там оказался Open.js Foundation.

раз они и есть, потому что у них везде про ноды написаны. Я вот сейчас посмотрел. Платиновые мемберы — это IBM, Joint и Microsoft, а еще какие-то Sovereign Tech Fund. В золотых мемберах, например, GoDaddy и Google, и еще HeroDevs, не знаю, кто это такие. Silvermember тут просто, просто валом знаменитых, на самом деле, компаний. Тут и AWS, American Express внезапно, Bloomberg, GitHub тут же есть, Foursquare, Meta, Netflix, Red Hat, Uber, да. Вы откроете и вы 100%.

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

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

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

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

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

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

не было как раз сервер сайт gtm google так менеджер можно поднять instance у себя на сервере клиентская библиотечка отправить запрос только в него а он уже дальше разошлет всем кому нужно и вот короче для меня как раз был сюрпризом что google предоставляет тебе просто докер образ а в докер образе

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

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

когда подскочило, трафик может запроцессить до 50 машин. Смасштабировалось, все отработало, вернулось обратно. Максимальная автоматизация, да? Да-да-да. Ну, короче, правда, инструмент под задачу. Хорошо подходящий. Кстати, вот когда мы говорили про перформанс, еще одну вещь, там, ну, про...

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

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

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

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

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

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

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

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

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

Да, да, да, что-то похожее. Я прям вспоминаю, кстати, Delphi опять. Блин, сегодня у нас прям выпуск ностальгии. Я помню, там была та же команда Asm, Begin или что-то такое, где можно было вставки делать. А у меня вот еще вопрос такой. Просто мы опять про перформанс заговорили. И по поводу кейсов применим.

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

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

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

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

большой Enterprise, ну, вряд ли кто-то решит писать на Node.js, типа, зачем там страдать, там, делать какие-то сложные прям штуки, что-то монструозное, если мы это можем сделать уже проверенными способами, взять ту же самую Jaws Spring-On, там, да, или Kotlin, или взяв C-Sharp

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

Последний месяц работал на проекте, где мне пришлось поконтрибьютить в один сервис на Go, в другой сервис на Ruby, написать Cloud Function в гугловском облаке на TypeScript, и потом еще написать немножко кода под iOS-приложение на Swift и на React Native. В итоге я такой, блин, а можно... одном языке пописать, пожалуйста.

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

больше решается всякими AI-ми и LLM-ками. Я так и делаю, да. Потому что иногда, например, мне пришлось чинить сервис на Ruby или на Go. Я же с этими языками регулярно не работаю. В итоге я читаю Ruby, но...

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

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

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

Да, потому что раньше это вообще нерешаемая проблема до тех пор, пока у тебя нет человека, который сидит рядом с тобой и смотрит в ту же самую кодовую базу. Ладно, это мы ушли в сторону. На самом деле мы говорим сейчас про развитие. Ну типа, что ждет дальше? Я понял про внешние подключаемые модули и вот это вот все. А что еще вообще? Есть ли сейчас какой-то... Учите Rust уже сейчас. Каждый Node.js разработчик должен начинать учить Rust.

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

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

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

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

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

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

решение, которое это первое, наверное, Dino, еще как он называет Dino, это как раз-таки альтернатива, условно говоря, Node.js с авторством Райана Даля. И, как я уже сказал, это решение, попытка переосмыслить Node.js, то есть убрать изначально те вещи, которые были...

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

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

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

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

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

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

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

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

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

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

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

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

Мы получаем возможность даже создавать бинарники, кстати, из коробки. Это тоже одно время прям такая была вещь, что мы привыкли, что в Node.js приложение это что? Это, как правило, набор JS скриптов, который мы там выполняем с помощью ноды. А вот здесь у нас появилась сразу возможность получать полноценные...

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

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

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

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

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

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

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

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

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

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

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

как говорится сразу, они сделали модульную систему, которая называлась CommonJS. И если сейчас, например, зайти в документацию нуды, посмотреть пример API, там, как правило, есть два варианта всегда. ECMAScript модули и CommonJS модули, так называемые CGS. И вот его изначально сделали для... node.js то есть по факту ребята подумали нам нужна нормальная модульная система давайте сделаем command.js соответственно чтобы можно было переиспользовать то есть

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

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

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

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

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

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

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

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

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

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

поддерживать CommonJS модули, мы будем выпускать только новые версии для ECMAScript модули. Это стандарт, он будет развиваться, и мы, соответственно, будем его поддерживать. Что получается в итоге? Что те, кто использует CommonJS модули, а это львиная доля кода, это просто...

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

она требует дополнительных трудозатрат и дополнительного времени. Кто-то, наоборот, забивает и только делает CommonJet, потому что проще по наитью. Кто-то, наоборот, давайте делать сразу только ECMAScript-модуль и так далее. И вот здесь, с одной стороны, мы видим, что сообщество само не до конца еще определилось, потому что есть, как за...

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

присти к проблемам, что просто какой-то код перестанет работать резко с новой версией Node.js. Например, это не из последних изменений, которые они сделали пока в Current. Это функция require, которая импортирует Command.js модуль, она может импортировать и ECMAScript модуль. Но учитывая...

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

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

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

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

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

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

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

Но перед тем, как спрашивать, как вкатиться, я хочу задать другой вопрос. Как ты думаешь, сейчас, вот в 2025 году, надо ли вкатываться, кому точнее, надо вкатываться в Node.js? К чему вообще стоит быть готовым? Как сейчас там ситуация с рынком, с вакансиями? есть ли комьюнити, всякие конференции. Короче, надо ли вкатываться сейчас в ноду и чего от этого можно ждать? Можно еще, наверное, по ролям разложить, условно, если ты только входишь в IT и если ты, может быть...

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

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

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

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

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

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

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

ему точно не нужна. Зачем? Вопрос. То есть он может все эти вещи сделать на своем стеке. И если уже хочется JavaScript, то, скорее всего, в сторону фронтенда будет интереснее посмотреть, потому что по факту Back он так сделает на своем языке, который он постоянно использует. Если говорить опять же про новичков.

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

то лучше идти на фронт-энд сначала то есть мне кажется здесь будет проще работу найти вакансий гораздо больше там чем мы будем искать вакансию по ну джесс если хочется прям back я бы подумал если хочется чисто заниматься бак-эндом возможно тут выгоднее сразу же пойти в классический фактический бэк, там .NET, Java, PHP, в конце концов. Kotlin, да, Kotlin, конечно, Kotlin. Это лучше сразу же туда. Если хочется JS, не знаю, учил JS со школы, всегда любил JS, ну, можно попробовать.

Вакансий по ноде есть, конечно же, и достаточно много, то есть есть там открыт тот же самый HeadHunter, но я проверял по тому году, ради интереса был посмотреть. Вакансий тоже много, то есть это не какие-то там единицы, да, то есть это нормальное количество вакансий. Но на дотмете Java, Kotlin не найдешь...

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

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

нашей необъятной планеты. У всех по-разному. Где-то там, не знаю, только нужен дотнет, где-то, наоборот, делают ставку на Node.js. Окей, вот тогда совершенно точно финальный вопрос. Как лучше вкатиться? То есть там стандартная документация или есть какие-то другие ресурсы? Как вкатиться?

Здесь есть несколько вариантов, кто как привык. То есть самый первый вариант – купить какую-нибудь книжку по Node.js и почитать, вообще сделать какой-нибудь там Hello World, условно говоря, полноценный примерчик, который позволяет разобраться. Но, чтобы вкатиться в ноду, нужно вкатиться в JavaScript. Это первости.

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

постепенно прилазим на TypeScript, либо просто сразу изучаем JS и TypeScript по порядку, потом уже идем в Node.js. Литература, в принципе, документации ее предостаточно, то есть официальная документация, она более такая сухая, то есть сложно по ней будет, если нет книг.

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

про Node.js. Есть куча видосов на YouTube. Есть платная школа, например, как я работал в HTML Академии, которая предоставляет полноценные уже курсы от A до Z по использованию JS как на фронте, так и на бэкэнде. В общем, вариантов много на самом деле.

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

У меня травма. Я еще не прожил ее. Когда проживу, тогда... Что такое в go происходит? Это те самые функции, которые возвращают два значения? Это оказалось нормально. Мне пришлось просто проверить в одном месте, где парсился джейсончик, наличие какого-то вложенного...

полюшка, там, типа, на четвертом уровне вложенности в JSON или типа того, и это было if объект не равно nil, and if объект точка, там, первый уровень не равно nil, and if объект точка, первый уровень точка, второй уровень не равно nil, и я такой... Да, блин. Мне весь день, что ли, это писать надо. Да, да, типа того.

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

переписывает мне это все на ранние return, на, короче, на early return подход. То есть if объект равно nil, return nil, if объект точка первый уровень равно nil, return nil. И я такой думаю, ну да, точно стало лучше. Я же так много хотел, я же хотел побольше кода написать. Ну да ладно. А вот если бы ты писал Node.js, он прекрасно подходит для работы с JSON, потому что формат максимально родной и да. Да, нативный. Синоксический сахар, да, он бы здесь помог. Но это правда до первого...

Undefined is not a function, no. Не будем о том говорить сегодня. Да, это редко бывает. Да, подведем итоги под этим выпуском. Перед тем, как, собственно, перечислять все, о чем мы поговорили, я хочу заранее сделать дисклеймер. Нам уже давали обратную связь, что, ну, вы, короче, какие-то все очень мяшки-мяшки такие, Никон.

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

там делать вообще? Вот то ли дело наша любимая скала. Такое, ууу, все понятно. Но, в общем, сегодня, о чем мы поговорили? Сегодня, друзья, мы наконец-то разобрались, что такое Node.js. Это фреймворк, это библиотека, это среда исполнения, это экосистема. На самом деле все и сразу, и образ жизни, и мы...

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

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

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

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

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

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

даже несмотря на то, что там не всем, наверное, нода интересна, он должен встать на полочку золотого стандарта вообще подлодки, когда мы берем популярные технологии и просто разбираем их от УДО, потому что ты прям очень круто пояснил за ноду. Да. Спасибо, что пригласили. Жень, у меня тем временем для тебя вопросик, как всегда. Да-да. Готовься.

Что тебе нравится больше, чем... Нет, здесь не будут шутки про JavaScript, не про многопоточность, ничего такого банального. Я хочу спросить, что тебе нравится больше, чем откапывать в нашем огромном восьмилетнем веклоге бриллиант и записывать... на эту бриллиантовую тему, бриллиантовый выпуск с бриллиантовым гостем. Ой, больше этого мне нравится NPM install и смотреть, как медленно растет NodeModules папочка. А на самом деле, больше этого, дорогие друзья, мне нравится, когда вы приходите

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

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

подписывайтесь на канал, ставьте лайки, еще раз пишите комментарии. Да и, наверное, все. Больше это мне нравится только, когда вы на самом деле слушаете подкаст «Подлодка» и рассказываете о нас своим коллегам, друзьям и вообще всем, до кого можете дотянуться. С вами был подкаст «Подлодка». Сегодня мы говорили про Node.js. Всем спасибо и всем пока-пока. Пока-пока. Пока-пока.