Состоялся релиз Node.js 24.0.0, платформы для выполнения сетевых приложений на языке JavaScript. Node.js 24.0 отнесён к веткам с длительным сроком поддержки, но данный статус будет присвоен только в октябре, после проведения стабилизации. Поддержка Node.js 24.x будет осуществляться до 30 апреля 2028 года. Сопровождение прошлой LTS-ветки Node.js 22.x продлится до апреля 2027 года, а позапрошлой LTS-ветки 20.x до апреля 2026 года. Сопровождение LTS-ветки 18.x прекращено 30 апреля 2025 года, промежуточной ветки Node.js 23.x будет прекращено 1 июня 2025 года...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63194
Кто там делал форк чисто на ts без js с компиляцией — получилось, что по скоростям?
Deno? Он вроде ещё существует. Написан кстати на расте*.*достаю попкорн
Дено же внутри всё равно в жс трансирует для того же v8?
Ох г-спди, дено — та же нода, только в профиль, внутрях там то же в8, на ржавчине только обвязка. А тайпскрипта там внутри нет и не может быть, просто встроенный транслятор жс в тс, продакшон реди житов/интерпретеров тс просто не существует в природе. Бун — та же ерунда, только внутри жскор вместо в8
Сабж так тоже умеет, просто игнорит типы. Но там не все работает вроде.
В ванильном js тоже можно проверять типы перед каждой операцией. Только никто этого не делает, а потом у них язык плохой.
Я про то, что node умеет запускать ts без необходимости компиляции в js.
> проверять типы перед каждой операциейэто(связка) всё равно(нареч.) что(союз) после(предл.) каждого(опр. мест., ср.р., род.п., ед.ч.) слова(сущ., ср.р., род.п., ед.ч.) описывать(гл., нес.в., н.ф.) его(притяж. мест., ср.р., ед.ч.) словоформу(сущ., жен.р., вин.п., ед.ч).
> никто этого не делает
В смысле "никто"? Этого не делает только компилятор, и всё. Больше никто этого делать ПЕРЕД КАЖДОЙ ОПЕРАЦИЕЙ и не должен. А компилятор этого не делает, потому что - ВНИМАНИЕ! - в языке не предусмотрено средств, которые позволяли бы ему это делать. Так что плохой здесь именно язык.
Bun? Deno? Это не форки
Ага, причем вроде Deno пилит сам автор сабжа, вроде хочет убрать все костыли из сабжа.
Да, это не форки. Это чистейшая nih ерунда с нескучными обоями
> (дополнительно Microsoft развивает вариант Node.js с движком Chakra-Core)Уже давно забили
https://github.com/nodejs/node-chakracore
Еще была версия ноды на мозиловском движке, тоже забили.
> шаблонизаторы, CSS-движки, реализации криптоалгоритмовЛОЛ. Щас бы использовать реализацию криптоалгоритма на жс))) А вообще тенденция пошла переписывать с жс все тулзы на более быстрые языки: typescript-go, например, или сборщики там go или расте.
Ну а что, я использовал эту реализацию криптоалгоритмов. Зашифровать/расшифровать AES, подписать ключом или проверить подпись. Работает. Есть мануал, причем он получше, чем в некоторых криптографических библиотеках.
> Работает. Есть мануал, причем он получше, чем в некоторых криптографических библиотекахКриптографию так не проверяют)))
А я разве рассказал как проверял? Расскажите как вы проверяете криптографию и что не так в нодовской криптографии и мы предметно пообщаемся, поделимся опытом.А для солидности добавлю смайлов)))))
> что не так в нодовской криптографииВ ноде криптография - биндинги к openssl, никто на жс её не реализовывал.
До появления биндингов в браузерах портировали библиотеки по типу TweetNaCl, и оно работало шустро
> А я разве рассказал как проверял?Да, выше же написал. "сделал, вроде работает".
> А для солидности добавлю смайлов)))))Это не спасет он неумения читать сообщения.
какой нафиг typescript? это же убогий транспилер для JS полностью зависимый от фич JS
typescript-go — это не быстрый язык, это быстрый транспилятор. Исполняться будет всё тот же js.
> typescript-go — это не быстрый язык, это быстрый транспилятор. Исполняться будет
> всё тот же js.Это понятно, я про то, что раньше он был на жс, а теперь переписывают на более быстрое, как и сборщики.
> XML-парсеры.Покажие нормальный парсер XML, который поддерживате пространства имен, xpath и прочее, но не является биндингом или wasm.
> но не является биндингомА почему бы и не биндинг? И если уж на то пошло, покажи нормальный парсер XML на любом языке. Чтоб поддерживал последний стандарт xpath, и чтобы он не был проприетарным (на этом критерии отвалятся примерно все решения).
Я не против. Просто написано в статье как-будто на жс такое написано. Ну или я неверно прочитал.
из статьи следует, что на жс этим можно пользоваться, а не что это целиком на нём написано
Easysax
Это не обязанности парсера, это процессор.
У меня на втором пне 32 битная сборка не запускается (NetBSD).
попробуй core2duo + linux
Интересно, кто нить в продакшене как бекенд ее использует? На хайлоаде? Интересно, просто у меня лично еще на первых релизах были сомнительные ощущения, жс для сервера... Зачем и кому это надо?
Используют и достаточно активно, правда в основном для всяких корпоративных внутренних вещей.
Конечно! Ведь нода - самый быстрый язычок из скриптовых для вебни. Быстрее пихона и пыха.
Для сколь-нибудь загруженного лучше использовать что-то другое: например go или java.
А хайлоад вообще лучше писать на C или C++.
Хайлоад писался и будет писаться на java/go и т.д. по экономическим причинам. К примеру, никто не будет ставить супер-пупер технологичные движки от Формулы 1 на грузовики, скорее купят много грузовиков на предмет если планируется большой поток грузов. Так и с использованием C/C++ для хайлоада, скорее поставят лишнюю стойку с компами (или закажут больше инстансов в облаке) для софта на java, чем будут долго и дорого делать хайлоад на плюсах.Айти - это инженерное дело, а не чистая наука, и в этих самых инженерных делах в первую очередь думают о ресурсах: человекочасах, сколько ожидается времени на разработку и можно ли распараллелить (а может и не нужно), ожидаемый средний срок жизни готового продукта, сложность поддержи/тиражирования, далее про возврат на инвестиции и т.д., и только потом начинают технарствовать.
> Так и с использованием C/C++ для хайлоада, скорее поставят лишнюю стойку с компамиУгу. или лишний дэйтацентр :)
> (или закажут больше инстансов в облаке)Угу. Или увидят что заплатить за это дороже чем заменить команду программеров. :)
Короче - зависит отЪ(С)
Зачем гадать? Можно просто посмотреть на реализации в дикой природе и увидеть, что хайлоад пишется примерно на всём, от Явы до Питона, и, так же, что язык реализации снова мало на что влияет. Напоминаю, что FB написан на PHP, и стал хайлоадом задолго до начала всех оптимизаций.
HipHop for PHP (HPHPc, букв. HipHop для языка PHP) — транспайлер исходного кода, созданный компанией Meta Platforms и использовавшийся ранее в проектах компании. HipHop программно превращает исходный код, написанный на языке PHP, в оптимизированный код на C++, а затем использует компилятор g++ для его компиляции. HipHop включает в себя транслятор кода, альтернативную реализацию среды выполнения PHP, а также множество наиболее распространённых расширений PHP (англ. PHP Extensions), переписанных на C с целью повышения производительности.https://ru.wikipedia.org/wiki/HipHop_(%D1%82%...)
Шах и мат.
А ты не подумал, что это вышло в 2010, а Фейсбук в 2004?
> А ты не подумал, что это вышло в 2010, а Фейсбук в
> 2004?И что?
Программисты не инженеры.
Это самый быстрый и самый лучший язык с революционной асинхронностью которой нигде нет и новаторским подходом к ООП.Умные C++ перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже работают над тем, чтобы джаваскрипт работал быстрее С++, потому что он комплируется сразу в результат, минуя стадию вычисления! Вы наверняка заметили это по тому,
что gmail.com открывается за 5 секунд, а не 20 как это было в до-интернетную эпоху, может хотя бы самые древние.То есть, если вы напишете свой сайт на nodejs, он автоматически будет бытсрым и будет масштабироватсья (обрабатывать столько клиентов, сколько пришло, это настоящая проблема в пхп была и некто не знал как с ней быть).
Но самое главное, что над нодой сейчас работает туча народу просто, они переписывают все что было до них написано на ноду и у них получается лучше потому что они сразу заточились на производительность и чтобы было лучше а так же просто использовать. Например нужно сходить в базу данных создал проект на гитхабе сразу набежали форкнули завтра только пуллреквесты принять и можно заливать в продакшн на свой ноутбук. Сообщество очень дружелюбное, если кому-то удается сделать что-то работающее на ноде его обязательно хвалят и подбадревают потому что это правда успех.
Ктому же nodejs так оптимизирован что никогда не займет больше одного ядра а это значит что базу данных например можно поставить на тот же ноут на другое ядро для экономии ресурсов и надежности.
Но в серверы как раз много ядер и ставят и как видите nodejs прекрасно справляется с этой задачей. Правда что бы писать на ноде нужно купить макбук потому что все примеры в интернете написаны на мак буке но я думаю если выделаете высокопроизводительный веб-сервис, вам всеравно прийдется пройти раунд финансирования у родителей чтобы потом его запускать.
>>Это самый быстрыйТочно не самый быстрый
>>Ктому же nodejs так оптимизирован что никогда не займет больше одного ядра
Странно недостатки записывать в плюсы.
P.S.
node плохо подходит для бэка, где интенсивно используется CPU.
Это не недостаток. Это значит что базу данных например можно поставить на тот же ноут на другое ядро для экономии ресурсов и надежности (иметь что-то на той же машине всегда надежнее, много ли что, все у кого есть дома интернет вы это итак знаете) и все будет быстро бегать и даже можно во что-нибудь пошпилить или дальше форум по nodejs почитать но тогда надо побольше ядер купить.
Речь про наргуженные сервисы и прод. Какие ноуты, СУБД на соседнем ядре и "пошпилить"?
Вы о чем?
Нода - чистая асинхронщина, а значит она вообще не подходит для баз данных, где ответ нужен сразу. В остальном же для api, не для микросервисов, нода - отличный вариант. Для микросервисов лучше всего кваркус.
Когда там уже решат проблему с dependency hell? Мало того что развели зоопарк с языками JavaScript и TypeScript, так еще и импорты commonjs и esnext. Когда будет решение? Это пожалуй самый важный момент с которым часами иногда возиться приходиться решая проблемы зависимостей. А зоопарк бандлеров и прочего интересного? Почему не сделать как в Rust упаковщик в один обычный cargo, а вот уже различную функциональность запихнуть в плагины. Короче просто уничтожают язык вполне пригодный для серверного программирвоания. А если бы еще и в браузеры затащить TypeScript без транспиляции... Эх...
Не используй зависимости, если они тебя смущают. Странная какая-то претензия.
> А если бы еще и в браузеры затащить TypeScript без транспиляции... Эх...в браузеры и так что угодно можно тащить вплоть до сей и плюсов с преобразованием к васм, разумеется
Зачем браузеру сверх того что и так там есть нативная поддержка какого-то ультрапереусложнённого кривого мусора вроде тайпскрипта, предложенного "гениями и мастерами веба" в лице микрософта, который даже собственную версию ноды забросил на помойку ?
Смысл нативного тайпскрипта как минимум в повышении производительности благодаря типизации.
Про плюшки языка, которые будут уменьшать размер кода (что для браузера ультраактуально, посмотрите какие мегаметровые портянки на жс в современных проектах) и делать его более предсказуемым вовсе можно не упоминать.Просто тайпскрипт сейчас в таком состоянии, что из-за вынужденной завязки на жс получается только базовая проверка времени преобразования на деплое, не более. Гугель же не хочет тайпскрипт нативно, потому что конкурент дарту и го, да и модернизировать v8 — дорого. Типовые жс-разработчики тоже против, потому что всё, что противоречит тяп-ляп-питон-стратегии для них только усложняет жизнь.
> Смысл нативного тайпскрипта как минимум в повышении производительности благодаря типизации.А как это получится, если система типов unsound? Язык придется менять или систему типов.
В этом и весь смысл — если сам движок будет изначально под строгие типы заточен, без всякого жс и с минимумом any.
> В этом и весь смысл — если сам движок будет изначально под
> строгие типы заточен, без всякого жс и с минимумом any.Как-то давно читал про оптимизации в васм, там разработчики упоминали, что ключевое там никакие не типы, а ожидаемое/предсказываемое потребление ОЗУ. Отчасти потому в тот же жс ввели изменяемые переменные и константы что уже прогресс на фоне просто переменной которая в любой момент может измениться как угодно
Вдобавок, сама по себе типизация едва ли даст внятный выигрыш в производительности
Да и разбор громоздкого текстового мусора под названием тайпскрипт едва ли будет жрать меньше ЦП и ОЗУ нежели жс
Там( в браузере ) ещё специфика в том, что изначально предполагается что будет исполняться минимум кода и функций ибо разбор всего и оптимизация жрёт гору ресурсов и времени. Поэтому даже их разбор и оптимизации включаются далеко не сразу, а по мере роста количества вызовов функции от момента последнего её изменения.
Например, первые несколько раз вызываемая функция вообще будет исполняться интерпретатором даже без минификации - тупо как оно написано. Потом, перед очередным исполнением, её таки "уменьшат", затратив на это ЦП и ОЗУ. Ещё через много( очень ) вызовов - ещё больше оптимизируют вплоть до подобия компиляции.
А в итоге - осн. потеря времени при многократном исполнении функции может прийтись на исполнение через интерпретатор + исполнение минифицированного кода через интерпретатор и несколько уровней "оптимизации"Как видишь, дело едва ли в типах
А что ты будешь делать когда завтра TypeScript станет немодным? Лучше бы Google таки протолкнул свой Dart.
ms так развивают node-chakracore, что даже проект на github заархивировали
А смысла нет. Гугл через whatwg рулит вебом, любой браузерный движок в итоге обречён превратиться в v8 или сдохнуть. Как в формуле-1 — вроде и разные производители, а по факту из-за жёстких ограничений все машины практически одинаковые. Фейлфокс, который держат на плаву как псевдоальтернативу это только подтверждает.