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

Но что касается скорости, то падение конечно весьма существенное.
я попробую донести мысль.
Сразу дико извиняюсь не писал на ассембле со времён доса ))

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

возьмём пример на js
a=a+b;

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

mov eax,a ;//Перемещаем в eax, значение из a
mov edx,b ;//Перемещаем в edx значение из b
add eax,edx ;//складываем значения

А если нетипизированы то что делать ?
процессор то только с регистрами умеет операции выполнять, а про нетепизированные переменные он слыхом неслыхивал :D

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

//в al- значение символизирующее тип обоих переменных (пусть для простоты примера он общий для обоих переменных)
// если тип =1 тогда перейдём к метке sumvar
cmp al, 1
jz sum_var

// если тип =2 тогда перейдём к метке sumstring
cmp al, 2
jz sum_var

//подпрограмма сложения целых чисел
sumvar:

jmp next_step

//подпрограмма сложения строк
sumstring:

jmp next_step

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

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

monolithed,
Увы, незна ни CoffeeScript, ни LiveScript. JSа хватаем по самые уши :) Но TypeScript интересно. Когда буду писать для win8, тогда наверно и попробую.

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

А что не так-то? Разве так удобнее

x = {
  'a':1,
  'b':2
}

чем

x = {
  a:1,
  b:2
}

?
Да и методы зачем переписали? Имена классов? Что с ними не так?

Несколько примеров отсюда:
http://synonym.dartlang.org/

console.log('Level completed.'); → print('Level completed.');

Зачем? Ну то ладно.

Якобы ничего → final name = 'Bob';

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

new Array(); → new List();
a.push('donut'); → a.add('donut');

Зачем?

a.pop() → a.removeLast()

Да, это выглядит несколько логичнее, но, опять же, зачем?

numbers.sort(function(a, b) {
  return a - b;
});

→

numbers.sort((a, b) => a - b);

Молодцы, конечно, но это есть в ES (не помню, какой версии). Запилите, вместо того, чтоб херней страдать.

new Object(); → new Map();

Тот же вопрос.

var periodic = {
  gold: 'AU',
  silver: 'AG'
};
var periodic = {
  'gold': 'AU',
  'silver': 'AG'
};

→

var periodic = {
  'gold' : 'AU',
  'silver' : 'AG'
};

Идиотизм.

periodic.gold // == 'AU'
periodic['gold'] // == 'AU'

→

periodic['gold']

Не меньший идиотизм. Вообще нифига не удобно.

Якобы ничего → var fruits = new Set();

Set есть в ES, его поддерживает FF, он же легко реализуется ручками.

var queue = []; → var queue = new Queue();

И че это? Оптимизированные списки типа как в Прологе?

...
Тут еще масса негодования.

Дарт масдай. ES должен развиваться и реализовываться в Хроме, там и остальные потянутся (мелкософт, если мне не изменяет память, обосрала Дарт и не будет его поддерживать).

В TC39 состоит не только Mozilla, но и Microsoft, Apple, Opera и Google. Они развивают его. V8, один из первых кто поддерживает большинство эксперементальных фишек, не считая конечно SpiderMonkey.

Дарт конечно тоже не очень люблю, но глупо говорить, что ES никто не поддерживает и он не развивается в Хроме.

Он настолько медленно реализовывается, что я прям хочу спать.

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

FINoM, ответ на часть твоих вопросов я уже приводил:
Например, касательно add/removeLast для массивов. На остальные - производительность.

Нет, ты здесь не угадал, речь не о приведении в порядок.

P.S. Мысли теряются на фоне эмоций. Чего ты так разнервничался?

а зачем им вообще заниматься?