[kobezzza]

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

Потому что VM это не знает изначально, а утверждать на 100% она не может, а если она начнёт изучать код на возможность AOT, то это замедлит "старт" приложения, ибо в реальном мире мы имеем не простой цикл, а хренову тучу говно кода

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

В ES6 появились новые синтаксические конструкции, которые могут позволить делать дополнительные оптимизации (такие как arrow function или const), но пока JIT-ы только учатся их понимать, думаю через пару лет ситуация улучшиться.

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

Если бы всё так было просто, то всё было бы сделано давно Я как то смотрел видео одного из разработчиков V8 и он как раз рассказывал, что многие исторические вещи в JS сильно усложняют жизнь при анализе и оптимизации кода, например "дырявые массивы":

var a = [];
a[99] = 1; // Такой массив будет реализован поверх хеш-таблицы

var b = [1, 2, 3]; // Такой массив может быть представлен как нормальный массив

WebAssembly или тот же ASM.js работают в рамках той же VM, просто за счёт того, что язык очень строгий и низкоуровневый, то можно вы первых сразу генерить супер быстрый машинный код, а во вторых делать многие оптимизации, которые нельзя делать в простом JS.

просто болит душа за него, потому что на других форумах я постоянно читаю много упреков в сторону JS и node.js, особенно от c++ программистов, которые считают что на нем пишут те, кто не умеет программмировать, а причина именно в скорости выполнения.

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

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

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