компиляция JavaScript
 

Добрый день, господа.
Меня мучает не конкретный, а скорее абстрактный вопрос по которому я хотел бы услышать ваше мнение.

Вопрос такой - почему на ваш взгляд браузеры не могут ввести функцию компиляции javascript-кода?

Опишу ситуацию, чтобы было понятнее: у меня на сайте есть анимация и другие подобные эффекты, реализованные с помощью JS. Но когда я открываю сайт на старых компьютерах, или на мобильных устройствах, эффекты начинают дико тормозить, ХОТЯ, если написать любое компилируемое приложение, например на C++ под винду, оперирующее теми же ресурсами (картинками и текстом) и выполняющее на вид точно такие же действия, то естественно, запустив это приложение на слабом компе, тормозов там не будет. При этом компилируется приложение достаточно быстро (неск.секунд).

Так почему браузер не может после загрузки страницы, скомпилировать JS в машинный код и запустить его в своем окне?

Да, у скомпилированного кода есть плюсы и минусы в сравнении со скриптовым. Основной плюс - значительное быстродействие, минусы: 1) программу можно будет запустить только после того, как она полностью скачается и скомпилируется. 2) скриптовый код может в реальном времени модифицироваться.
Но в некоторых случаях последние два пункта не важны для сайта (веб-приложения), а важна лишь скорость выполнения кода. Можно было бы например в заголовках страницы указывать, использовать ли браузеру компиляцию, или выполнять как скрипт.

Мне кажется это было бы крайне удобно. Так что же останавливает производителей браузеров?

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

Может потому что то небольшое количество неплатежеспособного населения, что сидит на слабых компах.
так, вот может потому что то небольшое количество бедняков за несколько лет разработки станет еще меньше?
И потому, что эти затраты не окупятся

JavaScript в анимации не тормозит. Тормозит рендеринг, которым занимается сам браузер, который и так откомпилирован. Так что компиляция вам не поможет.

Я не говорю, что он не нужный, я говорю что иногда он нужный, а иногда им можно пожертвовать в пользу быстродействия. Главное, чтобы у программиста была возможность выбора.

Ресурсы у проиводителей браузеров есть. Уж какой только ерунды они в браузер не пихают.

Тут вы ошибаетесь. С каждым днем количество "слабых" компов в сети стремительно увеличивается, если отнести к слабым компам планшетники, нетбуки и коммуникаторы. А ведь на них как раз таки и тормозят большинство сайтов, напичканных различной JS-анимацией.

Боюсь, что и вы ошибаетесь, Kolyaj.
Объясните тогда мне, как так получается, что моя прога на С++, которая перемещает jpeg-картинку по окну не тормозит на процессоре Atom, а ТАЖЕ САМАЯ jpeg картинка которую я перемещаю по окну с помощью JS в браузере тормозит.
Или вы хотите сказать, что я использую более продвинутые методы рендеринга, чем производители браузеров?

Боюсь, что дело все-таки в компиляции..

аха.
и теперь на каждую "ерунду"(которая объективно отношения к JS никакого не имеет) они должны тратить в два или более раз времени больше, чтобы написать еще и компилируемую версию.
Плюс не забываем, что уже существующий функционал также надо сделать в компилируемой версии. А это значит несколько лет, в течении которых программисты будут трудится не давая какого-то результата(всмысле релиза), и даже дав его, он принесет денег ну крайне мало, что даже им на зарплату не хватит.
ну, если вы их считаете слабыми, то лажно...
А я считаю, что под их железо вполне можно писать адекватные сайты, если стоит такая цель.
Другой вопрос, что 90 % заказчиков не требуется написание сайта, "чтобы не тормозил на афоне", и при этом они не готовы платить даже средн ие деньги за данную работу. Поэтому и делается безграмотное говно школьниками за минимальную оплату.

99% нужд веб-а, грамотный специалист(при условии что ему адекватно заплатят) сможет реализовать, что они не будут тормозить на 600 и даже меньше МГц Хотя и остается 1% весьма специфичных задач.
Это не так уж трудно, и вполне реально, ИМХО.
Другой вопрос, когда сайт заказывается за 50-150 баксов школьнику. Тут о качестве совсем другой разговор.
Поэтому и делают дилетанты ширптортеб.
а с чего бы ширпотребу быть качественным? он таким не должен быть

потому что js выше, чем С++.

сравните вычисления C++ и asm. {trollface}

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

А если подумать, и немного включить мозг?
Когда ты на с++ двигаешь картинку, то ты двигаешь только ее.
когда ты делаешь это в браузере, то ее движение затрагивает также всех потомков,и соседей ее, и каждлого из потомков. как минимум.
Не считаюа перерисовик объектов поверх, и перед объектом. А это еще огромное количество потомков и соседей.

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

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

Кто сказал что не компилируют.

1)V8 компилирует код. Точнее там механизм компиляции кода на лету.

2) firefox также компилирует код при помощи tracemonkie уже c 2009 года, это версия 3.5.
с версии 4, также появилась компиляция на лету (проект JaegerMonkey).

JavaScript- вполне сносно справляется даже с 3D графикой, полно 3d движков. Дури много, а тормозит именно рендеринг DOM . Другое дело что javascript не совсем подходит для компиляции. Аналогичный код на c++ всё равно производительнее. Эту проблему можно решить только заменив javaScript другим более строгим языком, что гугл уже во второй раз пытается сделать.

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

У меня на atom-е простенькие 3D игры не тормозят, а между прочим одна 3D модель содержит тысячи полигонов и десятки текстур и при изменении положния модели надо тоже их всех пересчитать. И я вас уверяю, это гораздо сложнее, чем перебрать DOM.

Насчет говнокода не надо. Этим вы показываете свою некомпетентность в вопросах производительности браузеров.
Вот вам пример - http://www.bkosborne.com/jquery-feature-carousel
Демо данной галереи тормозит на atom-e. Может быть конечно эту галерею тоже писали дилетанты из кусков кода. Если вы профессионал, напишите такую штуку, чтобы она не тормозила на процессоре 600Mhz, я вам денег дам. У меня как раз такой заказ и заказчик как раз хочет, чтобы сайт работал именно на планшетах. Вот вам и статистика. Это сейчас 90% заказчиков не знаю что такое планшет с процессором 600Mhz, а через пол года у каждого второго в ТЗ будет это прописано.

Проверьте код, изучите проблему изнутри.

Почитайте на досуге --
http://chikuyonok.ru/2010/11/optimization-story/

Ну, допустим тормозит рендеринг DOM.
Но в галереи по ссылке из сообщения выше элементов в DOM-e не больше сотни, а я видел приложения под винду в которых тысячи и больше элементов (если вспомнить, то для винды каждая кнопка является отдельным окном или элементом) и ничего нигде не тормозит.

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

http://ru.wikipedia.org/wiki/JIT

Вот небольшое демо,
в первом эксперименте цикл на 10 миллионов итераций цикла
в цикле идёт работа только с переменной.

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

z=0;
    for (var i=0;i<10000000;i++){
	z=z+i;
    };

alert("конец "+z);

    z=0;
    for (var i=0;i<100000;i++){
	document.write("1");
	z=z+i;
    };

alert("конец второго эксперемента "+z);

Помоему очевидно, что работа с dom, самое слабое место в браузере, в плане скорости.

У меня ff вообще его тормознул))

+1 Эпик фейл, работа с DOM самое медленное место в браузере. Когда-то у меня было учебное задание - написать XML конструктор, я тогда реализовал его при помощи стандартных DOM функций, а другой парень сделал чисто на строках и у него работало в разы быстрее.

Хах) Долой responseXML, даешь responseText!

Чувак, поздравляю, ты сделал открытие! Сначала данные нужно аккумулировать, а потом записывать. Во всем виноват браузер и ДОМ-2, конечно.

П. с.: Аббревиатуры, кстати, пишутся с заглавных букв.

Вы тоже открытие сейчас сделали) Это называется "пример") Пример того, как долго выполняются операции с DOM.

P. S. К незнакомым людям на "вы" обращаются обычно.

Вот тут и демка и код открытый. http://www.bkosborne.com/jquery-feature-carousel
И прямо демка с этого сайта и тормозит.

А еще есть такой вариант: сделать анимацию на Java и запустить как java-аплет. У меня есть пример, но надоело слушать как меня ругают за саморекламу, так что ссылок не даю. Но вот JRE как раз компилирует байт код в код машины и работает быстро. И тоже в интернете.

компиляй@ускоряй

А приводить jq для теста скорости - глупость.