Потому что [] - это не массив, а хеш-таблица на самом деле - это главная причина всех бед. Ну и плюс всякие издержки от необходимости держать лишние ссылки в памяти и т.д. Также имеет место быть несовершенство самого JIT VM, т.к. например в ИЕ11 нативные методы работают значительно шустрее ФФ или Хрома.

kobezzza,
Хеш-таблица
объясни что ты имеешь ввиду говоря

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

К тому же базовые массивы JS поддерживают "дырки", что ещё сильнее усложняет логику работы JIT компилятора и кстати это один из главных аргументов гугл против JS :)

Но тем ни менее в JS есть и настоящие массивы: https://developer.mozilla.org/en-US/...t/Typed_arrays

***

Если посмотреть стандарт про новые arrow function в JS, то можно увидеть, что внутри них не поддерживается ссылка arguments, который является виновником многих тормозов, т.к. не позволяет JIT делать многие оптимизации. К слову в моём Collection оптимизация arguments идёт всегда, т.е. в callback передаются только те параметры, которые явно декларированы в описание функции, т.е.:

$C([]).forEach(function () {
    console.log(arguments); // []
});

$C([]).forEach(function (el) {
    console.log(arguments); // [el]
});

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

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

:)