Comments 4
Сейчас мне конечно же насуют, но по моему вы изобрели php, причём только условно fpm, и без op cache
Не думаю, что будут минуса. На самом деле тут действительно прослеживается идея, которая идёт ещё от CGI, всё циклично, в других моих статьях я это как раз и описывал. V8 jit можно вполне сравнить с opcache. Но справедливости ради, тогда уже нужно вспомнить Phalcon Framework. Тут прямая аналогия, когда роутинг, работа с базой, кеш и прочие писались на системных языках, а логика на PHP.
В сравнении с worker_threads стоит поправить важный момент: у каждого Node Worker собственные V8 isolate и event loop. Проверил на Node 24: пока один воркер занят синхронным циклом, второй отвечает на сообщения. Оба работают в одном процессе.
Сравнивали ваш вариант с заранее созданным пулом Node workers на той же задаче? Snapshot может дать выигрыш на инициализации, но параллельное выполнение в отдельных JS-кучах доступно и без перехода к deno_core. Сейчас в статье это выглядит как преимущество, которого у Node нет.
Согласен, что формулировка в статье не совсем корректная, текст поправил. Паралелить код, конечно можно и на Node.js. Но смысл статьи был в другом: deno_core не замена Node, а всего лишь либа с удобным API для встраивания V8 напрямую в Rust-процесс. Когда JS выполняется внутри, а не в отдельном Node worker, мы получаем:
Прямые вызовы Rust-функций из JS через ops.
Более легковесные изоляты: поднять изолят из snapshot-а за 2-3 мс проще, чем менеджить пул тяжелых Worker Threads с их MessagePort.
С пулом node workers не сравнивал, так как изначально было понятно, что snapshot даст выигрыш именно на скорости создания контекста и отсутствии оверхедов.
V8 startup snapshot: как правильно запустить JS-код на сервере