Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 183
Если вкратце: язык интерпретируемый (приходится разбирать текст программы на лету, а компиляция кода обычно занимает времени больше, чем однократное выполнение того же кода), большое количество объектов (правильное DOM-дерево страницы, содержащее все узлы атрибутов, вообще-то немаленькое), библиотеки (типа prototype или jquery) тоже непростые, каждая легкая снаружи операция (например выборка по CSS-классу) реализуется довольно сложным механизмом внутри.
К тому же о клиентской оптимизации JavaScript задумываются далеко не все программисты, а сделать тормозно легче легкого при таких условиях.
К тому же о клиентской оптимизации JavaScript задумываются далеко не все программисты, а сделать тормозно легче легкого при таких условиях.
Спасибо за ответ, все равно как то все это странно… Я не программист, но мне кажется трудности о которых вы говорите в разы проще чем нагрузки возникающие в результате работы других приложений. Вот к примеру когда я открываю всем известный сервис aqua.livejournal.ru загрузка моего процессора (Celeron 2,6 ) составляет около 100% причём на других более мощных компьютерах в офисе результат примерно такой-же :(
у меня в FF 3.1 (Core2 Duo 2.2GHz) загрузка — 45%.
И всё-таки, да, не смешивайте скомпилированную программу и интерпретацию (причём, интерпретацию без кеширования кода)
И всё-таки, да, не смешивайте скомпилированную программу и интерпретацию (причём, интерпретацию без кеширования кода)
в современных js-движках всетаки в байткод компилится
реал-тайм компилинг… это тоже не простая задача.
тоже самое что интрепретация, только вместо выполнения идет преобразование в машинный-код/байткод. Зато при многократном выполнении (а современные WEB2.0 сайты так и работают) этого кода будет большой выигрыш.
Да же при исполнении любого цикла, если при первом проходе тела цикла его преобразовать в байткод, то при остальных проходах он будет выполнятся уже быстрее
Да же при исполнении любого цикла, если при первом проходе тела цикла его преобразовать в байткод, то при остальных проходах он будет выполнятся уже быстрее
При чем здесь PHP?
JS и PHP по своей сути разные, зачем их сравнивать?
JS и PHP по своей сути разные, зачем их сравнивать?
Да, сайты на HTML уже не модно — модно на PHP, да-да, как я вас понимаю.
*искренне покачивая головой из стороны в сторону*
*искренне покачивая головой из стороны в сторону*
Прежде всего, Java != JavaScript :)
Сам по себе JavaScript весьма неплох. Никакой излишней кривости или запутанности в языке нет, он очень простой.
Тормозит обычно не интерпретация языка, а работа с DOM и прочими браузерными API. Манипуляции с DOM приводят к необходимости пересчитывать положение объектов и заново выполнять рендеринг частей страницы. Хуже того, до наступления полного AJAXа мало кто задумывался об оптимизации. Я уж не говорю о браузерных войнах и несовместимых корявых API, из-за которых приходится использовать всякие тормозные прокладки (Prototype etc.).
В случае PHP все намного проще: прослойка между функциями PHP и системными вызовами ОС минимальна. Интерпретатору не приходится в runtime решать, например, как открывать файл в данной ОС. Скорость интерпретации PHP не очень-то отличается от JavaScript (примеры тестов можно посмотреть на shootout.alioth.debian.org/ )
Сам по себе JavaScript весьма неплох. Никакой излишней кривости или запутанности в языке нет, он очень простой.
Тормозит обычно не интерпретация языка, а работа с DOM и прочими браузерными API. Манипуляции с DOM приводят к необходимости пересчитывать положение объектов и заново выполнять рендеринг частей страницы. Хуже того, до наступления полного AJAXа мало кто задумывался об оптимизации. Я уж не говорю о браузерных войнах и несовместимых корявых API, из-за которых приходится использовать всякие тормозные прокладки (Prototype etc.).
В случае PHP все намного проще: прослойка между функциями PHP и системными вызовами ОС минимальна. Интерпретатору не приходится в runtime решать, например, как открывать файл в данной ОС. Скорость интерпретации PHP не очень-то отличается от JavaScript (примеры тестов можно посмотреть на shootout.alioth.debian.org/ )
Читайте внимательно: «причём, интерпретацию без кеширования кода»
и что? современные js движки умеют компилять в байткод, аля «кэширование кода» если хотите.
Потому что используется только 1 ядро :)
Широко известный сервис в узких кругах? :-) я, например, его не знаю, и судя по вашей фразе, знать не хочу.
Криво написать можно что угодно и загрузить пустыми вычислениями любые мощности. Если страничка грузит современный компьютер на 100%, то надо руки оторвать тому программисту который писал ее. Производительности яваскрипта хватает на многое, когда это сделано прямыми руками. Конечно 3d моделирование будет тормозить, но это же не тот случай?
Криво написать можно что угодно и загрузить пустыми вычислениями любые мощности. Если страничка грузит современный компьютер на 100%, то надо руки оторвать тому программисту который писал ее. Производительности яваскрипта хватает на многое, когда это сделано прямыми руками. Конечно 3d моделирование будет тормозить, но это же не тот случай?
По поводу jQuery, сайты с его применением не намного сильнее тормозят, нежели с т. с. классическим яваскриптом, разница собственно, ощущается на более-менее нагруженых сайтах.
а как зависит скорость выполнения клиентского скрипта от загруженности сервера?
Никак (только ajax запросы из клиентского скрипта работают с сервером). В остальных случаях задача сервера отдать js код. А скомпилировать его и выполнить — задача клиентской машины. И как бы криво кто-то не написал js код, если он не делает запросов к серверу, то трудности с его выполнением будут только у клиентов и ресурсы он загрузит клиентские.
Навероне имелась ввиду нагруженность интерфейса страницы.
Потому что язык динамический слаботипизированный с кучей возможностей типа анонимных функций, прототипов, variadic functions и многого другого. Естественно, что написание эффективного интерпретатора или компилятора в JIT требует больших усилий.
Но ведь это все равно не «рендер в реальном времени». А если взять во внимание то, что существует он бог знает сколько лет и вполне себе работал на 486-х то уж по моему мнению на современных процессорах должен просто летать…
Так то, что делали для 486-х на современных компьютерах действительно будет летать. Кстати, если веб-разработчиков принудительно сажать за слабые компьютеры, то проблема должна решиться ;)
У нас в офисе уже минут двадцать идёт спор, но консенсуса мы пока не нашли :). Даже, если допустить что сложность современных задач решаемых с помощью javascript многократно увеличилась, мегагерцы ведь тоже на месте не стояли… я даже не беру в расчёт многоядерные системы.
С увеличением производительности появляются новые возможности. Их начинают использовать, и производительность куда-то рассасывается :)
Кроме того, у разработчика появляется ощущение вроде «памяти много — что её экономить?». Так получаются тормоза и загрузка процессора.
Кроме того, у разработчика появляется ощущение вроде «памяти много — что её экономить?». Так получаются тормоза и загрузка процессора.
Вы зря тратите время на этот спор. Не важно почему вам кажется не стправедливым положение вещей. Те, кто имеет на это влияние делают то, что могут. А вам, раз вы не можете предложить реальных решений, заботиться (и тем более выдавать возмущение за непонимание) об этом не следует.
Ну я не то чтобы возмущён, мне кажется к такому положению вещей настолько все привыкли, что просто не могут допустить что такой проблемы не должно быть в принципе (теоретически конечно).
Не будьте наивным. К таким вещам никто не привыкает. Разработчики браузеров делают оптимизации нешуточных масштабов.
Ваши теоретизирования не имеют смысла. Вы просто не представляете себе насколько реально сложным является движок браузера и какой объём вычислений ему приходится проделывать.
Ваши теоретизирования не имеют смысла. Вы просто не представляете себе насколько реально сложным является движок браузера и какой объём вычислений ему приходится проделывать.
Ну флэш как-то умудряться работать быстро(приемлемо). А JS — вещь, действительно, довольно не оптимизированная даже потому, что разработчики(Mozilla, Webkit) разом вдруг повышают производительность на ~50% и больше процентов. Если бы JS до этого была хорошо оптимизирована, то вряд ли могли бы произойти подобные скачки. Никто не спорит разработчики стараются… и задачи перед ними стоят действительно не легкие. Но то, что JS может и должен работать быстрее — факт.
Вы путаете системные вещи. Флеш не взаимодействует со всем содержимым страницы. (и кстати страницы сделанные целиком на флеше тормозят зачастую сильнее, чем аналогичные на html+javascript)
Повышение производительности нынешних движков связано уже не с неоптимальностью старых, а с тем, что новые движки начинают использовать очень серьезные и ещё более сложные методы выжать из процессора больше возможностей. Думаю будет понятна аналогия с автомобильной турбиной — это приспособление в разы повышает мощность (при том же объеме камер сгорания), но и плата за такие возможности высока.
Повышение производительности нынешних движков связано уже не с неоптимальностью старых, а с тем, что новые движки начинают использовать очень серьезные и ещё более сложные методы выжать из процессора больше возможностей. Думаю будет понятна аналогия с автомобильной турбиной — это приспособление в разы повышает мощность (при том же объеме камер сгорания), но и плата за такие возможности высока.
Где это вы видели рендер в реальном времени под 486? Если у вас есть конкретные примеры, то они или узкоспециализированные или изрядно урезанные. Я никогда не забуду как просчитывались ланшафты на 486-м в программе Bryce (так называлась?) — десятки минут.
Рендером может называться не только визуализация 3d сцен, спрайтовая анимация — тоже рендер в реальном времени :)
Все верно. В вашем примере «десятки минут» по крайней мере оправданы, в нашем случае (aqua.livejournal.ru) это три десятка слов пролетающие по двум координатам с реакцией на мышь. Мне кажется две эти задачи совсем не сопоставимые по сложности.
Вы путаете скомпилированный, оптимизированный под задачу код и программу на интерпретируемом языке, у которого нет (пока) JIT и кеширования кода. Причём, в этом языке достаточно мало средств (хотя они есть) оптимизации.
Да ладно, интерпретируемом. По-моему, вполне себе интерпретируемый бейсик всеми когда-толюбимого (околодвухмегагерцового восьмибитового) синклера-спектрума и то обгонял жабий скрипт на современных несколькогигагерцовых 64-битных числомолотилках.
Не надо плодить легенд. Я на «Спектруме», благо, три года плотненько сидел. Знал его внутренности, ассемблер, язык калькулятора.
Этот бейсик ощутимо тормозил даже на прокрутке одной фразы, не говоря уже о том, что сдвигать её попиксельно он вообще не смог бы.
Этот бейсик ощутимо тормозил даже на прокрутке одной фразы, не говоря уже о том, что сдвигать её попиксельно он вообще не смог бы.
Не знаю что за язык калькулятора :), я этих спектрумов пару спаял когда-то и мучил всяко-разно тоже изрядно. Конечно тормозной по нынешним временам. Вот примерно как жабий скрипт :).
Ну, что вы так буквально :), возможно, таки спектрум чуть и медленнее. Я же про ощущения говорю. У меня в компьютре сейчас с десяток интерпретируемых языков встроено. И ни один из них не тормозит так сильно как жабаскрипт.
Ну, что вы так буквально :), возможно, таки спектрум чуть и медленнее. Я же про ощущения говорю. У меня в компьютре сейчас с десяток интерпретируемых языков встроено. И ни один из них не тормозит так сильно как жабаскрипт.
У него был встроенные математический язык. Язык калькулятора. Не слишком известная штука.
Спектрум — куда более медленный, а не чуть-чуть медленный. Вы ещё разрешение и глубину цвета сравните на Спектруме и у себя.
А о каком «десятке языков», которые «не тормозят так сильно» идёт речь?
Спектрум — куда более медленный, а не чуть-чуть медленный. Вы ещё разрешение и глубину цвета сравните на Спектруме и у себя.
А о каком «десятке языков», которые «не тормозят так сильно» идёт речь?
>> А о каком «десятке языков», которые «не тормозят так сильно» идёт речь?
Ключевое слово — «встроено»
Ключевое слово — «встроено»
>Но ведь это все равно не «рендер в реальном времени».
Отключи трёхмерный ускоритель видеокарты и будешь сильно удивлён скоростью рендера.
>Ведь по идее этих гигагерцев должно с лихвой хватать для не сложной анимации и простых эффектов.
Не знаю как там в мире яваскриптов, но «как это ни странно» без того же 3д ускорителя видеокарты никакие эффекты не могут быть выполнены быстро. Даже на простые задания с полной перерисовкой экрана уйдёт как минимум одно ядро, собственно многие компьютеры только его и имеют, и его ещё будет нехватать.
Таким образом для вывода графики браузеры должны использовать 3д ускоритель, а для интерпретации кода что-то навроде виртуальной машины, только в этом случае можно расчитывать на скоростной вывод.
Отключи трёхмерный ускоритель видеокарты и будешь сильно удивлён скоростью рендера.
>Ведь по идее этих гигагерцев должно с лихвой хватать для не сложной анимации и простых эффектов.
Не знаю как там в мире яваскриптов, но «как это ни странно» без того же 3д ускорителя видеокарты никакие эффекты не могут быть выполнены быстро. Даже на простые задания с полной перерисовкой экрана уйдёт как минимум одно ядро, собственно многие компьютеры только его и имеют, и его ещё будет нехватать.
Таким образом для вывода графики браузеры должны использовать 3д ускоритель, а для интерпретации кода что-то навроде виртуальной машины, только в этом случае можно расчитывать на скоростной вывод.
кстати, тут ты отчасти прав.
в случае с Firefox, например, тот же код в старой доисторической Mozilla на старом компе с 98й виндой выполняется быстрее :)
в случае с Firefox, например, тот же код в старой доисторической Mozilla на старом компе с 98й виндой выполняется быстрее :)
может просто коряво написано? ))
JS-скрипты усложняются. Уже сейчас, кстати, есть несколько скриптов, работающих с подтормаживанием. А в дальнейшем их (т. е. сложных) будет только больше.
Я думаю, что разработчики браузеров далеко не дураки. И я уверен, что они как могут оптимизируют JS-движки.
прирост скорости js-движков буде скомпенсирован усложнением задач.
(Следствие из закона Ломоносова-Лавуазье)
(Следствие из закона Ломоносова-Лавуазье)
По статистике с LiveInternet более 30 процентов пользователей в рунете использует ie6 который по данным википедии вышел 27 августа 2001. А его брат ie7 имеет 27 процентов (вышел 18 октября 2006).
Итого, в сумме получается 57 процентов. Не так много конечно как раньше. Но все равно — с таким количеством пользователей нельзя не считаться.
И о какой оптимизации движков можно говорить?! Если рассчитывать все равно придется на худший вариант!
Единственно возможно что-то оценивать, это при разработке внутрикорпоративной системы, где вы сможете навязать свои требования пользователям.
PS Мне кстати кажется, что у большинства пользователей IE ко всему прочему старенькие и слабые машины купленные давным, давно.
Итого, в сумме получается 57 процентов. Не так много конечно как раньше. Но все равно — с таким количеством пользователей нельзя не считаться.
И о какой оптимизации движков можно говорить?! Если рассчитывать все равно придется на худший вариант!
Единственно возможно что-то оценивать, это при разработке внутрикорпоративной системы, где вы сможете навязать свои требования пользователям.
PS Мне кстати кажется, что у большинства пользователей IE ко всему прочему старенькие и слабые машины купленные давным, давно.
жаваскрипт довольно быстр. основная проблема производительности — перерисовка страницы из-за манипуляций с DOM деревом. напишите плагин к safari / firefox с использованием другого скриптового языка — разницы будет совсем немного.
Лично мое субъективное мнение — узкое место не в самом интерпритаторе JavaScript, а в движке рендеринга страниц.
+1
Рендерится все до сих пор без применения возможностей 3D-акселераторов, да еще и через кучу промежуточных API, каждый, соответственно, отжирает свои пять копеек ресурсов.
Для анимации перемещения картинки надо взять объект «картинка», установить новые координаты, выдать событие, по которому движок рендеринга пробежится по дереву объектов, и все перерисует. Механизм аналогичен применяющемуся во всех играх SceneGraph, и, соответственно, жрет не меньше ресурсов. Только в играх для отрисовки картинки надо эту картинку скормить процессору видеокарточки, и забыть о ней, а в браузере надо еще и отрисовать ее, и прозрачность для каждого пиксела посчитать, и заново опять по дереву пробежаться в случае reflow, и еще много чего… В случае текста все еще сложнее, чем с картинками, т. к. надо заново отрисовать надпись (а это сколько-то кривых и куча вычислений на каждую букву). В играх все шрифты обычно битмапные используют (ну или надпись один раз рендерят, и потом картинкой пользуются).
Можно аналогичный эффект посмотреть, если выключить в настройках видеокарты ускорение 3D графики, и запустить какую-нибудь простенькую аркаду =)
А вообще, профайлинг рулит, надо посмотреть, сколько времени на что тратится, и тогда уже решать, что делать.
Рендерится все до сих пор без применения возможностей 3D-акселераторов, да еще и через кучу промежуточных API, каждый, соответственно, отжирает свои пять копеек ресурсов.
Для анимации перемещения картинки надо взять объект «картинка», установить новые координаты, выдать событие, по которому движок рендеринга пробежится по дереву объектов, и все перерисует. Механизм аналогичен применяющемуся во всех играх SceneGraph, и, соответственно, жрет не меньше ресурсов. Только в играх для отрисовки картинки надо эту картинку скормить процессору видеокарточки, и забыть о ней, а в браузере надо еще и отрисовать ее, и прозрачность для каждого пиксела посчитать, и заново опять по дереву пробежаться в случае reflow, и еще много чего… В случае текста все еще сложнее, чем с картинками, т. к. надо заново отрисовать надпись (а это сколько-то кривых и куча вычислений на каждую букву). В играх все шрифты обычно битмапные используют (ну или надпись один раз рендерят, и потом картинкой пользуются).
Можно аналогичный эффект посмотреть, если выключить в настройках видеокарты ускорение 3D графики, и запустить какую-нибудь простенькую аркаду =)
А вообще, профайлинг рулит, надо посмотреть, сколько времени на что тратится, и тогда уже решать, что делать.
тоже самое хотел сказать, DOM структура плохо предназнеачекна для быстрого передвижнения по экрану «ветвей» дерева, особеено если если элементов много. Да и сам элемент имеет кучу взаимосвязанных свойств.
Про шрифты — нек знаю, по идее шрифт должен кешироватться в растровом виде.
Автор — для анимации используйте флеш. А лучше — вообще забейте на нее, в большинстве случаев она нафик не нужна.
Яваскрипт — не для анимации, а для простейших задач вроде скрытия дивов и валидации полей на клиентской стороне. (Ну максимум — рисование графиков через SVG).
И вообще хочу сказать всем дизайнерам и прочим: достали уже ваши пляшищие и прыгающие надписи! Давайте работать над удобством пользования сайтом, а не над тем чтобы выпендриться перед заказчиком/коллегами. Например, ребята из antiflash (ссылка где то в комментах): конечно, у вас очень красиво и оригинально все сделано, но вот перетаскивание картинки (в просмотре работ) работает у меня в хроме не так быстро как хотелось бы, и вообще это неудобно. Так почему ж вы не оставили возможность пользоваться линейкой прокрутки, быстрее бы ведь получилось, разве нет?
* морально готов вернуться к опере с отключенным яваскриптом и флешем (включается вручную только там где этожизненно нужно, например в гуглеридере)
Про шрифты — нек знаю, по идее шрифт должен кешироватться в растровом виде.
Автор — для анимации используйте флеш. А лучше — вообще забейте на нее, в большинстве случаев она нафик не нужна.
Яваскрипт — не для анимации, а для простейших задач вроде скрытия дивов и валидации полей на клиентской стороне. (Ну максимум — рисование графиков через SVG).
И вообще хочу сказать всем дизайнерам и прочим: достали уже ваши пляшищие и прыгающие надписи! Давайте работать над удобством пользования сайтом, а не над тем чтобы выпендриться перед заказчиком/коллегами. Например, ребята из antiflash (ссылка где то в комментах): конечно, у вас очень красиво и оригинально все сделано, но вот перетаскивание картинки (в просмотре работ) работает у меня в хроме не так быстро как хотелось бы, и вообще это неудобно. Так почему ж вы не оставили возможность пользоваться линейкой прокрутки, быстрее бы ведь получилось, разве нет?
* морально готов вернуться к опере с отключенным яваскриптом и флешем (включается вручную только там где этожизненно нужно, например в гуглеридере)
О! прокрутка колесиком вдруг заработала! но это только вверх-вниз(
Давно (т. е. изначально) так делаю.
Раньше сидел с отключенными скриптами. Когда перешёл на FF, поставил плагин noscript, в нём явно задаю, что везде скрипты и флеш запрещены и только [список] разрешены. Разрешения для каждого конкретного сайта можно переключить на лету через значок на панели статуса.
Отсекается куча рекламы, всякие неудобные и раздражающие анимации и, безусловно, повышается безопасность. Есть очень малый процент сайтов, на который ходить необходимо, и в котором гораздо лучше включить скрипты\флеш. И ещё меньше сайтов, которые с выключенным js не работают, но на которые ходить надо.
Раньше сидел с отключенными скриптами. Когда перешёл на FF, поставил плагин noscript, в нём явно задаю, что везде скрипты и флеш запрещены и только [список] разрешены. Разрешения для каждого конкретного сайта можно переключить на лету через значок на панели статуса.
Отсекается куча рекламы, всякие неудобные и раздражающие анимации и, безусловно, повышается безопасность. Есть очень малый процент сайтов, на который ходить необходимо, и в котором гораздо лучше включить скрипты\флеш. И ещё меньше сайтов, которые с выключенным js не работают, но на которые ходить надо.
Если все сильно утрировать, получается что результат многолетних усилий тысяч инженеров в Intel а так же известных всем софтверных гигантов — слегка подтормаживающий яваскрипт. Грустно как то становится, не находите?
Давайте уж дальше пойдём. Например, религию затронем. Результат сотворения мира всемогущим божеством — слегка подтормаживающий яваскрипт.
Забавно: сначала вы признаёте, что сильно утрируете, а потом вам «грустно».
Забавно: сначала вы признаёте, что сильно утрируете, а потом вам «грустно».
вообще можно сравнить прибыль от оптимизации 3d-игрушки и от оптимизации браузера. Количество денег, вложенных в разработку, тоже имеет ощутимое значение.
вообще можно сравнить прибыль от оптимизации 3d-игрушки и от оптимизации браузера. Количество денег, вложенных в разработку, тоже имеет ощутимое значение.
Почему, речь не только о нем — хотя вы правильно подметили, именно он навел меня на эту мысль :). Данный проект конечно-же не показательный, посмотрите к примеру aqua.livejournal.ru — там дела обстоят не лучше хотя это продукт более опытной команды.
Вы что, серьезно не видете там ничего кроме движущегося текста? А справка? А сообщения при наведении? Самое главное— асинхронная загрузка «свежачка» без дубликатов и подстройка скорости под частоту сообщений.
Ну а вывод окна на экран — 20 строк на WinAPI. Тока чето никто крупные проекты на нем не пишет, все больше на MFC да на .NET
MFC это обычный набор классов и методов.
MFC это обертка над WinAPI.
MFC это обертка над WinAPI.
Потому что разхработчик ставит свою лень выше удобства пользователя, только и всего. Использовать монстроватый jQuery (да, он клевый и удобный для программиста, я знаю, но монстроватый, кто не верит — загляните в код) ради того, чтобы скрыть/показать форму логина — показатель непрофессионализма кодера, имхо.
Если просто взять и вынести джаваскрипт который двигает тэги отдельно
все равно будет тормозить. Тем более что в итоге двигает тэги не наш скрипт, а джквери. А он то уж написан профессионалами. ))
все равно будет тормозить. Тем более что в итоге двигает тэги не наш скрипт, а джквери. А он то уж написан профессионалами. ))
Правда, но тогда это будет уже не тот сайт, а какой-то другой. )
А как же скорость разработки? А как же ограниченность в финансах? А время где взять на это все? А мы 100 раз уже переделали все это в соответствии с постоянно меняющимися желаниями закачика, причем все на живом уже работающем проекте.
Не все так просто.
Есть еще проблемы за гранью программерских вопросов и кода, которые приходится решать.
Поэтому и получилось то, что получилось.
Так что не судите строго. )) Косяки есть, согласен. Конечно все сделали лучше бы если бы знали с самого начала. И да… сделаем лучше, в следующий раз.
Не все так просто.
Есть еще проблемы за гранью программерских вопросов и кода, которые приходится решать.
Поэтому и получилось то, что получилось.
Так что не судите строго. )) Косяки есть, согласен. Конечно все сделали лучше бы если бы знали с самого начала. И да… сделаем лучше, в следующий раз.
Зачем качества сотрудников? Симпатичную вещь сделали.
Очешуительная реализация идеи: выбор цвета автомобиля (png полупрозрачное и подкладка цветная).
kylish, Ваши ребята молодцы.
Очешуительная реализация идеи: выбор цвета автомобиля (png полупрозрачное и подкладка цветная).
kylish, Ваши ребята молодцы.
Сугубо мое мнение по поводу js, сводиться к тому что он хорош, но в небольших количествах, ибо черезмерное его использование ведет в огромную яму неоправданных вложений!
Т. к. вы не программист, попробую объяснить на примере.
1. Представьте, что JavaScript — механический манипулятор «руки», работающий в изолированном помещении (браузере).
К нему есть стандарты, предписывающие как он должен отзываться на команды пользователя, большой набор команд, которые он должен выполнять. С помощью этих команд он теоретически должен «уметь всё»: от приготовления еды до выполнения нейрохирургических операций.
2. Теперь представьте 3D рендеринг как промышленный токарный станок с ЧПУ.
3. Сделайте выводы о производительности (скорости).
На этой аналогии я попытался предствить только один аспект, а их в действительности несколько.
1. Представьте, что JavaScript — механический манипулятор «руки», работающий в изолированном помещении (браузере).
К нему есть стандарты, предписывающие как он должен отзываться на команды пользователя, большой набор команд, которые он должен выполнять. С помощью этих команд он теоретически должен «уметь всё»: от приготовления еды до выполнения нейрохирургических операций.
2. Теперь представьте 3D рендеринг как промышленный токарный станок с ЧПУ.
3. Сделайте выводы о производительности (скорости).
На этой аналогии я попытался предствить только один аспект, а их в действительности несколько.
Еще добавлю. Описанный выше манипулятор (JavaScript) может использовать некоторый набор инструментов и множество материалов, а также отслеживать «где что лежит».
Так вот, при таком раскладе некоторые программисты учат манипулятор «вытачивать» детали подручным резцом. А другие — этим же манипулятором создают новый «токарный станок». Результат, как ни странно, почти одинаков.
Так вот, при таком раскладе некоторые программисты учат манипулятор «вытачивать» детали подручным резцом. А другие — этим же манипулятором создают новый «токарный станок». Результат, как ни странно, почти одинаков.
Вообще-то для рендеринга 3D сцен (или для тех же игр) вовсю используется графическая карта (и ее процессор(ы)). Поэтому всё так хорошо с графическими приложениями. А компиляцией JavaScript'а и его исполнением может заниматься только центральный процессор. Это во-первых.
А во-вторых вспомните как работают приложения с очень навороченным интерфейсом, кучей тулбаров, меню (взять ту же Visual Studio). Они тоже нехило съедают процессорное время. А современные веб-сайты мало чем оличаются в этом плане от таких приложений (я говорю именно о сложности UI). Вот вам и объяснение.
А во-вторых вспомните как работают приложения с очень навороченным интерфейсом, кучей тулбаров, меню (взять ту же Visual Studio). Они тоже нехило съедают процессорное время. А современные веб-сайты мало чем оличаются в этом плане от таких приложений (я говорю именно о сложности UI). Вот вам и объяснение.
Боюсь, что они «тормозят» лишь потому, что написанны на .NET ;)
А это тоже какбы-интерпретируеммый язык, хотя и оптимизированный под x86.
А это тоже какбы-интерпретируеммый язык, хотя и оптимизированный под x86.
Почитал про видеокарты и подумал, что скоро появятся JS/DOM- акселераторы :) и вы забудите об этих проблеммах ;)
а вы попробуйте на windows калькуляторе расчитать факториал числа 123456789 и посмотрите сколько это займет времени:) А ведь казалось бы всего то несколько чисел перемножить, это ведь не рендеринг в реальном времени, а поди ж ты:) яваскрипт тормозит не от того что задачи у него слишком сложные, а оттого что объем расчетов в текущей реализации языка может становиться слишком большим, даже для выполнения тривиальных задач, и мегагерцы они не волшебные, они какой то объем расчетов поднять могут но не более.
C моей точки зрения при создании JavaScript были допущены стратегические ошибки. Возможно, дело в том, что тогда представлялось, что он будет только чуть-чуть дополнять статические страницы, о какой-то сложной работе речь не шла.
Интересная проблема — очень странная работа с DOM. Вроде бы должна быть простая быстрая функция getElementById — а в действительности это чуть ли не самая тормозная функция. Мне кажется, что простое индексирование DOM сняло бы все вопросы с производительностью. В FF следы индексирования, кстати, есть, но именно следы, в IE даже следов нет.
Объектная модель настолько дурная, что использовать её на практике в чистом виде невозможно — приходится ставить кучу подпорок, которые, естественно, отжирают ресурсы.
В общем, мне кажется, проще ещё один язык добавить в браузер, чем исправлять JS. И что-то мне подсказывает, что не я один так думаю.
Интересная проблема — очень странная работа с DOM. Вроде бы должна быть простая быстрая функция getElementById — а в действительности это чуть ли не самая тормозная функция. Мне кажется, что простое индексирование DOM сняло бы все вопросы с производительностью. В FF следы индексирования, кстати, есть, но именно следы, в IE даже следов нет.
Объектная модель настолько дурная, что использовать её на практике в чистом виде невозможно — приходится ставить кучу подпорок, которые, естественно, отжирают ресурсы.
В общем, мне кажется, проще ещё один язык добавить в браузер, чем исправлять JS. И что-то мне подсказывает, что не я один так думаю.
Рендеринг шрифтов, текстов, html объектов, DOM дерева со всеми параметрами каждого узла даже без JS зачастую занимает не мало процессорного времени, особенно когда страница не оптимизирована. А при исполнении JS приходиться перебирать все эти объекты, менять их свойства, перерисовывать.
Попробуйте сравнить скорость работы «голого» JS, т. е. без взаимодействия с DOM и тот же самый код, но с изменением параметров объектов на странице.
А вот про оптимизацию — видел одну страничку, так там для того, чтобы показать или скрыть всего лишь один объект грузился целый фреймфорк на несколько десятков килобайт, хотя реально это можно сделать 1 строчкой кода.
Попробуйте сравнить скорость работы «голого» JS, т. е. без взаимодействия с DOM и тот же самый код, но с изменением параметров объектов на странице.
А вот про оптимизацию — видел одну страничку, так там для того, чтобы показать или скрыть всего лишь один объект грузился целый фреймфорк на несколько десятков килобайт, хотя реально это можно сделать 1 строчкой кода.
Интересно, а зачем и кому может понадобиться голый JS? Факториалы считать?
Кроме скорости работы в моём списке ещё один недостаток, не менее серьёзный — отсутствие ООП в общепринятом виде.
Кроме скорости работы в моём списке ещё один недостаток, не менее серьёзный — отсутствие ООП в общепринятом виде.
таблицы в google docs просчитываются на сервере?
а чего из ООП вам не хватает в JS?
а чего из ООП вам не хватает в JS?
Из ООП не хватает ООП :) как ни странно. Нету его там.
Посмотрите на все практические примеры использования объектно-ориентированных подходов к программированию на JS — везде в каком-то виде дополнение исходной модели, и нигде — использование её в чистом виде. ООП в JS — это хак, что следует и из практики его использования, и из описания в ECMA 262. Язые не может описываться алгоритмом его реализации — посмотрите на C++, Java, любой другой язык.
Посмотрите на все практические примеры использования объектно-ориентированных подходов к программированию на JS — везде в каком-то виде дополнение исходной модели, и нигде — использование её в чистом виде. ООП в JS — это хак, что следует и из практики его использования, и из описания в ECMA 262. Язые не может описываться алгоритмом его реализации — посмотрите на C++, Java, любой другой язык.
А это что? :)
это потому, что представления о ООП у вас основаны исключительно на С++ (и производных), и вы пытаетесь имитировать на js несвойственную ему технику программирования
Я, кажется, обосновывал свою точку зрения. Вы можете аргументы опровергнуть?
Мой комментарий, скорее, к предыдущему вашему сообщению.
Что касается того, как используются объекты в js — это же «скриптовый язык» — он разрабатывался для расширения функциональности других «базовых» систем. Поэтому все практические примеры использования ООП — дополнение исходной модели. И опять мы приходим к тому, что «Если я не привык к этому в C++, значит это хак» — других аргументов я не вижу.
Что касается того, как используются объекты в js — это же «скриптовый язык» — он разрабатывался для расширения функциональности других «базовых» систем. Поэтому все практические примеры использования ООП — дополнение исходной модели. И опять мы приходим к тому, что «Если я не привык к этому в C++, значит это хак» — других аргументов я не вижу.
А чем хороша модель ООП в JS по сравнению с C++ и Perl, к примеру? Есть что-то положительное? C моей точки зрения — нет. Есть что-то отрицательное? Да, и много. Зачем считать хорошим вариант реализации ООП, который не имеет внятного описания, кроме данного в стандарте через алгоритм конструирования объектов? То что он другой — ещё не повод считать его хорошим и правильным.
Если в ваших словах поменять JS и C++. Утверждение останется таким же верным, всё сводится к тому же «он не такой, как я привык в C++»
Нет. Я вообще не очень понимаю, почему Вы именно С++ взяли как пример, но я привёл две реализации, одна из них не похожа на JS, а другая, наоборот, очень похожа. Вот как раз сравнение ООП в JS и Perl показывает, где главная ошибка при выборе модели JS.
Насчёт С++ — есть описание, JS — описания нет, есть алгоритмы реализации разной степени детальности.
Насчёт С++ — есть описание, JS — описания нет, есть алгоритмы реализации разной степени детальности.
Была у меня один раз задача проанализировать данные о 120 000 файлах и оценить, какой из подходов структурирования этой кучи будет оптимальней, для этого был написан js файл, в котором как раз и все делалось. Первая реализация повергла в шок: скрипт выполнялся более 40 минут и занял аж 2Гб памяти и до конца так и не дошел. После того как я его немного поменял он выполнился за 5 минут с использованием «всего» 100Мб памяти. Отличие в реализации было минимальное:
Первый вариант
Второй вариант
На странице при выполнении анимации будет работать дополнительный уровень связи между скриптом и DOM элементами, а это дополнительные расходы ресурсов. Плюс к этому практически все браузеры бросаются перерисовывать окно (и пересчитывать размеры элементов) при изменении в DOM. Сильно снизило бы нагрузку очень простая вещь: перед массированным изменением DOMа вызывается метод, который блокировал бы перерисовку на время изменения, а потом вызывался бы другой метод, разрешающий перерисовку. Опять же пример из жизни: HTA копирует 7000 небольших файлов, если ничего не выводить в HTML, то процесс проходит за (примерно) 2 минуты, если просто выводить число скопированных файлов и аналог ProgressBar, то это уже 7 минут. Промежуточный вариант: данные о процессе обновляются каждые 5 секунд, и время работы получается 3 минуты.
Вывод: даже если язык и выглядит просто и незатейливо, но писать на нем все равно нужно с умом.
Первый вариант
function File(...)
{
this.method = function(...)
{
... // использовались обращения только к this, никаких замыканий
}
}
Второй вариант
function File(...)
{
this.method = File_method;
}
function File_method(...)
{
...
}
На странице при выполнении анимации будет работать дополнительный уровень связи между скриптом и DOM элементами, а это дополнительные расходы ресурсов. Плюс к этому практически все браузеры бросаются перерисовывать окно (и пересчитывать размеры элементов) при изменении в DOM. Сильно снизило бы нагрузку очень простая вещь: перед массированным изменением DOMа вызывается метод, который блокировал бы перерисовку на время изменения, а потом вызывался бы другой метод, разрешающий перерисовку. Опять же пример из жизни: HTA копирует 7000 небольших файлов, если ничего не выводить в HTML, то процесс проходит за (примерно) 2 минуты, если просто выводить число скопированных файлов и аналог ProgressBar, то это уже 7 минут. Промежуточный вариант: данные о процессе обновляются каждые 5 секунд, и время работы получается 3 минуты.
Вывод: даже если язык и выглядит просто и незатейливо, но писать на нем все равно нужно с умом.
На самом деле браузер никогда не рисует и не персчитывает после каждой строки. Все свойства сохраняются и после конца обработки, либо по таймеру (как, например в опере) происходи обнавление страницы. Но всеже пересчет размеров можно вызвать, обратившись к некоторым свойствам, для которых он необходим. Такое обращение в цикле в скопе с измененим DOM дает потрясающие тормоза.
Все очень просто. В данном случае у Вас создается отдельная ф-ция для каждого экземпляра объекта.
Чтобы этого избежать можно вынести определение метода из конструктора и присвоить его прототипу.
function File(...) {
}
File.prototype.method = function(...) {
}
Тогда у вас сохранится объектная модель первого варианта, но по использованию памяти он будет соизмерим со вторым вариантом.
Чтобы этого избежать можно вынести определение метода из конструктора и присвоить его прототипу.
function File(...) {
}
File.prototype.method = function(...) {
}
Тогда у вас сохранится объектная модель первого варианта, но по использованию памяти он будет соизмерим со вторым вариантом.
Да, это собственно еще один способ, который применяю в том случае, когда мне нужно чтобы все объекты имели такой метод. Описанный мной способ подходит когда для конкретного объекта нужно сделать метод по каким-то соображениям логики. Но стоит задуматься о том, насколько хорошо использовать запись типа
в часто вызываемом куске кода.
$.each(..., function(...){...});
в часто вызываемом куске кода.
Различия между FF2 и Opera+FF3: последние как раз бросаются перерисовывать DOM при каждом изменении, FF2 — не всегда. Хорошо это заметно при добавлении абсолютно позиционированных картинок. Но я не могу сказать сходу какой вариант лучше — иногда приятно видеть изменения, иногда нет. Было бы здорово иметь функцию блокирования изменений, но как её реализовать, без перехода к транзакционной модели? И что такое тогда вообще будет DOM?
специально не замерял, но у меня сложилось впечатление, что IE отрисовывает все изменения в DOM после отработки скрипта, а FF2 рисует сразу, и если изменять свойства DOM в глубоко вложенном цикле вперемешку с вычислениями, то это становится видно (объекты изменяются не все сразу, а последовательно, с заметными промежутками времени), и мне приходилось сперва вычислять и запоминать изменения, а потом уже применять их к DOM.
как-то так, но в работе JS в IE и Fx и без того много отличий
как-то так, но в работе JS в IE и Fx и без того много отличий
Моё приложение выводит примерно 600 картинок на карту, и разница в IE6, FF2, FF3, Opera9,Safari бросается в глаза — первые два сначала отрабатывают скрипт, потом выводят. Safari выводит сразу и выглядит это красиво, Operа чуть хуже, FF3 отвратно.
Отличий у IE и FF действительно достаточно, но я перестал обращать на это внимание — главное чтобы в IE хоть как-то работало.
Отличий у IE и FF действительно достаточно, но я перестал обращать на это внимание — главное чтобы в IE хоть как-то работало.
А можно ответить несколько глобально?
Основная проблема здесь не в JavaScript, а в HTTP. Задачи, для решения которых протокол разрабатывался в 91-м году, и те, которые решаются с помощью него сейчас — разные по классу.
На мой взгляд, давно пора бы делать следующую версию протокола. Концептуально правильнее стандартизировать основные задачи и реализовать их на Си/Си++ (касается и бразуера и вебсервера), чем писать на JavaScript. И работать будет быстрее, и безопасность будет выше. Да и надёжность, я так думаю.
А нынче получается, что статику обвешали динамическими заплатками, низкоуровневыми по своей природе.
Основная проблема здесь не в JavaScript, а в HTTP. Задачи, для решения которых протокол разрабатывался в 91-м году, и те, которые решаются с помощью него сейчас — разные по классу.
На мой взгляд, давно пора бы делать следующую версию протокола. Концептуально правильнее стандартизировать основные задачи и реализовать их на Си/Си++ (касается и бразуера и вебсервера), чем писать на JavaScript. И работать будет быстрее, и безопасность будет выше. Да и надёжность, я так думаю.
А нынче получается, что статику обвешали динамическими заплатками, низкоуровневыми по своей природе.
Так браузеры и веб-сервера уже на Си написаны. Или вы RIA & серверные приложения на Си предлагаете писать?
Я предлагаю (ну, как предлагаю, скорее мечтаю), чтобы появился протокол, уровень которого соответствует уровню существующих задач.
Чтобы сессии поддерживались не через низкоуровневые куки. Чтобы события от сервера клиенту и наоборот передавались стандартным высокоуровневым способом. Чтобы элементы управления соответствовали современным стандартам.
Иначе получается так, как получается: любая задача требует, ну, пусть не затрат на написание (в условиях, когда столько фреймворков появилось), но всё-равно выполнения многих строк js-кода.
Чтобы сессии поддерживались не через низкоуровневые куки. Чтобы события от сервера клиенту и наоборот передавались стандартным высокоуровневым способом. Чтобы элементы управления соответствовали современным стандартам.
Иначе получается так, как получается: любая задача требует, ну, пусть не затрат на написание (в условиях, когда столько фреймворков появилось), но всё-равно выполнения многих строк js-кода.
даже банальная следующая версия html — xhtml — не прошла. А вы предлагаете менять вообще всё.
А что делать? Сейчас ситуация выглядит так: на каждое требование индустрии изобретается новая заплатка. Сначала CGI, затем куки, затем JS и DOM, затем XHTTPRequest.
И всё это механизмы низкоуровневые.
Впрочем, о предложениях с моей стороны говорить не стоит. Я лишь замечаю определённый тупик в развитии, но не готов предсказать, когда и как ситуация изменится.
Java была хорошим решением, позволяла писать высокоуровневые производительные программы. К сожалению, Sun несколько напортачила с библиотеками, затем Microsoft насолила. И это очень печально.
И всё это механизмы низкоуровневые.
Впрочем, о предложениях с моей стороны говорить не стоит. Я лишь замечаю определённый тупик в развитии, но не готов предсказать, когда и как ситуация изменится.
Java была хорошим решением, позволяла писать высокоуровневые производительные программы. К сожалению, Sun несколько напортачила с библиотеками, затем Microsoft насолила. И это очень печально.
человека тоже было бы неплохо спроектировать с нуля с учётом современных требований. Собственно, спроектировать и можно. Только вот воплотить это в реальность не получится. Так и с технологиями: мы видим далеко исключительно потому, что стоим на плечах гигантов. Отказ от этих плеч — непосильная задача.
Мне аналогия кажется несколько нелогичной. Человек это человек, а технологии это технологии.
Только на моей памяти было несколько технологических прорывов. Я ещё помню время, когда мы пользовались дискетками на 5 дюймов и 360Кб ОЗУ. Я помню время, когда писали под ДОС.
А сейчас у нас гигабайтные флешки и event-oriented windows-based программирование.
Ну и в данном конкретном случае, я нисколько не умаляю тех самых гигантов. Тем не менее, Ньютон Нюьтоном, а Эйнштейн Эйнштейном.
Только на моей памяти было несколько технологических прорывов. Я ещё помню время, когда мы пользовались дискетками на 5 дюймов и 360Кб ОЗУ. Я помню время, когда писали под ДОС.
А сейчас у нас гигабайтные флешки и event-oriented windows-based программирование.
Ну и в данном конкретном случае, я нисколько не умаляю тех самых гигантов. Тем не менее, Ньютон Нюьтоном, а Эйнштейн Эйнштейном.
а вы знаете, сколько усилий microsoft тратит для поддержания совместимости со старыми программами? Или может быть, у нас часто меняется i386-совместимость процессоров? Приведенные вами примеры — примеры количественного, а не качественного изменения. Такое изменение и в интернете есть.
Что-то у нас по кругу дискуссия получается. «У меня шарики красные» — «А у меня зелёные» — «Да, но у меня то красные» — «А я говорю, у меня зелёные». Давайте попробуем с другого конца зайти.
Вы утверждаете, что протокол развивать не надо, достаточно заплаток? Или сам термин «заплатки» кажется Вам притянутым за уши, и с протоколом вообще всё нормально? Или Вы считаете, что протокол менять надо, но не прямо сейчас? Или Вы не за резкую смену, а постепенную, чтобы не терять наработки?
Что именно в моём тезисе кажется Вам неправильным?
Вы утверждаете, что протокол развивать не надо, достаточно заплаток? Или сам термин «заплатки» кажется Вам притянутым за уши, и с протоколом вообще всё нормально? Или Вы считаете, что протокол менять надо, но не прямо сейчас? Или Вы не за резкую смену, а постепенную, чтобы не терять наработки?
Что именно в моём тезисе кажется Вам неправильным?
не думаю, что по кругу. Сейчас у меня есть ощущение, что своим предыдущим комментарием я опроверг вашу попытку привести пример революционного развития компьютерных технологий. Других примеров революционного их развития я не вижу, поэтому считаю его невозможным. Желание революций я отношу к распространённому (по слухам) среди русских программистов желанию весь старый мир разрушить, и на его обломках что-нибудь построить
но можно и по пунктам
> Вы утверждаете, что протокол развивать не надо, достаточно заплаток?
да, я считаю, что протокол достаточно хорош
> Или сам термин «заплатки» кажется Вам притянутым за уши, и с протоколом вообще всё нормально?
да, я бы вместо «заплатки» говорил «расширения», благо протокол расширяемый. Как xml. И с ним всё нормально, да.
> Или Вы считаете, что протокол менять надо, но не прямо сейчас?
нет, не надо, со своими задачами он отлично справляется
> Или Вы не за резкую смену, а постепенную, чтобы не терять наработки?
я считаю, что смена не нужна. И ещё, что резкая смена невозможна из-за инерции, а постепенная — потому что без критического давления никто этим заниматься не будет. Как ipv6 продвигается исключительно из-за угрозы заполнения адресного пространства. Хреново продвигается, кстати.
но можно и по пунктам
> Вы утверждаете, что протокол развивать не надо, достаточно заплаток?
да, я считаю, что протокол достаточно хорош
> Или сам термин «заплатки» кажется Вам притянутым за уши, и с протоколом вообще всё нормально?
да, я бы вместо «заплатки» говорил «расширения», благо протокол расширяемый. Как xml. И с ним всё нормально, да.
> Или Вы считаете, что протокол менять надо, но не прямо сейчас?
нет, не надо, со своими задачами он отлично справляется
> Или Вы не за резкую смену, а постепенную, чтобы не терять наработки?
я считаю, что смена не нужна. И ещё, что резкая смена невозможна из-за инерции, а постепенная — потому что без критического давления никто этим заниматься не будет. Как ipv6 продвигается исключительно из-за угрозы заполнения адресного пространства. Хреново продвигается, кстати.
Ну, скажем так, я нигде не писал о революционном развитии. Поскольку версия протокола передаётся в заголовке запроса, сервер может параллельно работать и с 1.1, и с любой другой новой версией. Причём, код для 1.1 уже есть, его даже трогать не надо будет.
По вопросу же возможного развития, вероятно, наши мнения не совпадают. Тут, думаю, время рассудит.
По вопросу же возможного развития, вероятно, наши мнения не совпадают. Тут, думаю, время рассудит.
возможно, это и имеет смысл, и интернет неплохо было бы спроектировать заново, а не дорабатывать старинные разработки, но просто попробуйте представить, в какие временные и денежные затраты выльется разработать новые системы, подготовить специалистов, заменить весь существующий софт.
в таких масштабах это даже Джобс не потянет :)
в таких масштабах это даже Джобс не потянет :)
нет, как раз протокол трогать не надо — он очень хорошо работает. Собственно, а какие к нему претензии? Надёжный, быстрый.
Я бы, например, предложил поддержку передачи event'ов от клиента серверу и наоборот в рамках самого протокола. Ну и поддержку сессий тоже.
Поддержка сессий уже есть. Что за event'ы?
Если Вы под сессиями понимаете куки, то я не назову это поддержкой. Чтобы обосновать, напомню историю 5-тилетней давности. В PHP, если куки включены, сессия делается посредством них, если же нет, посредством query-переменной, которая по умолчанию называется PHPSESSID. Думаю, это всё Вам известно, но пишу, чтобы исключить возможное недопонимание.
Механизм прекрасно работает в браузерах. Но как только речь заходит о поисковых роботах, возникает проблема. Они, ествественно, куки не поддерживают, поэтому каждый раз, заходя на страницу, получают новое значение PHPSESSID. URL разные, следовательно, и страницы тоже считаются разными. И на этом захлёбываются инструменты анализа логов.
Насколько я знаю, как-то эту проблему разрешили, то ли на уровне поисковых роботов, то ли на уровне инструментария. А может быть, и нет. Тем не менее, я помню все эти бодания.
И, если посмотреть на проблему пристально, выяснится, что она вытекает из особенностей HTTP. Вот если ввести понятие «сессия», то проблемы бы не было.
А event'ы — это событие. Мы хотим, чтобы при нажатии на кнопку BUTTON в SELECT подгрузился бы какой-нибудь список. Как это делается сейчас? AJAX, XHttpRequest, ну, наверное, какой-нибудь фреймворк, который скрывает 10-20-30 строчек кода. На более высоком уровне можно было бы написать: у BUTTON есть серверный обработчик события onserverclick. Тогда при нажатии на кнопку браузер сам шлёт запрос серверу, тот стандартным способом собирает данные и отправляет их.
Ну а у нас в обработчике можно написать (синтаксис очень условный):
document.all['my_select'].items = server.response;
Вместо js используется быстрый код на Си++ (соответствующая поддержка нового стандарта в браузере и сервере). И тогда уже не нужно думать, как ускорить js-код, всё работает. Да и сам код проще, и миллионы вебмастеров вздыхают с облегчением.
Ещё раз повторю, это некая идеальная картинка. Лично мне кажется, что дальнейшее развитие веба возможно и по такому варианту. Но как оно будет, не знаю. И не настаиваю.
Механизм прекрасно работает в браузерах. Но как только речь заходит о поисковых роботах, возникает проблема. Они, ествественно, куки не поддерживают, поэтому каждый раз, заходя на страницу, получают новое значение PHPSESSID. URL разные, следовательно, и страницы тоже считаются разными. И на этом захлёбываются инструменты анализа логов.
Насколько я знаю, как-то эту проблему разрешили, то ли на уровне поисковых роботов, то ли на уровне инструментария. А может быть, и нет. Тем не менее, я помню все эти бодания.
И, если посмотреть на проблему пристально, выяснится, что она вытекает из особенностей HTTP. Вот если ввести понятие «сессия», то проблемы бы не было.
А event'ы — это событие. Мы хотим, чтобы при нажатии на кнопку BUTTON в SELECT подгрузился бы какой-нибудь список. Как это делается сейчас? AJAX, XHttpRequest, ну, наверное, какой-нибудь фреймворк, который скрывает 10-20-30 строчек кода. На более высоком уровне можно было бы написать: у BUTTON есть серверный обработчик события onserverclick. Тогда при нажатии на кнопку браузер сам шлёт запрос серверу, тот стандартным способом собирает данные и отправляет их.
Ну а у нас в обработчике можно написать (синтаксис очень условный):
document.all['my_select'].items = server.response;
Вместо js используется быстрый код на Си++ (соответствующая поддержка нового стандарта в браузере и сервере). И тогда уже не нужно думать, как ускорить js-код, всё работает. Да и сам код проще, и миллионы вебмастеров вздыхают с облегчением.
Ещё раз повторю, это некая идеальная картинка. Лично мне кажется, что дальнейшее развитие веба возможно и по такому варианту. Но как оно будет, не знаю. И не настаиваю.
Насчёт сессий: проблем нет. Всё давно решено и куки достаточно покрывают практические потребности. С поисковиками же вообще проблемы совсем другие — что вообще считать документами для них, если документ сейчас всё чаще формируется как ответ на действия пользователей. Да и использовать куки им никто не запрещает. Например, для wget есть возможность их отслеживать, во только ни разу мне эта возможность пока не потребовалась.
Логи сейчас отслеживают по разному — часто URL вообще не существует, например при POST запросе что считать URL, если по нему нельзя получить страницу? Так что не в протоколе дело, а в авторах сайтов. Хотят учитывать интересы поисковиков — будут учитывать, средства есть.
Теперь разберём события. Напоминать о том, что и тут нет проблем, наверно, не стоит — jQuery и подобные библиотеки с практическими проблемами вопрос закрыли. Писать так, как написали Вы — «document.all['my_select'].items = server.response;» — нельзя по причинам асинхронности выполнения и по причинам ненадёжности сети — на каком этапе выполнять обработку ошибок? Что если ответ никогда не придёт?
Логи сейчас отслеживают по разному — часто URL вообще не существует, например при POST запросе что считать URL, если по нему нельзя получить страницу? Так что не в протоколе дело, а в авторах сайтов. Хотят учитывать интересы поисковиков — будут учитывать, средства есть.
Теперь разберём события. Напоминать о том, что и тут нет проблем, наверно, не стоит — jQuery и подобные библиотеки с практическими проблемами вопрос закрыли. Писать так, как написали Вы — «document.all['my_select'].items = server.response;» — нельзя по причинам асинхронности выполнения и по причинам ненадёжности сети — на каком этапе выполнять обработку ошибок? Что если ответ никогда не придёт?
Вот в первой половине своего поста Вы как раз описываете проблемы HTTP. Он создан для статического контента, а веб уже лет 10 как динамический. Ну ладно, 8.
Что считать контентом? Вот вопрос.
По поводу jQuery — они закрыли вопрос использования, но не вопрос быстродействия. Всё равно «внутри» исполняется 10-20-30 медленных JavaScript-инструкций. О чём, собственно, и наша тема.
Писать так, как я написал, не надо. У меня указано специально — «синтаксис очень условный». Если Вам интересно, как это может быть, давайте обсуждать, это интересно. Если Вы считаете, что действительно, менять ничего не стоит, или стоит, но не в протоколе/DOM/ещё чём-то, давайте покрутим Ваши идеи.
Что считать контентом? Вот вопрос.
По поводу jQuery — они закрыли вопрос использования, но не вопрос быстродействия. Всё равно «внутри» исполняется 10-20-30 медленных JavaScript-инструкций. О чём, собственно, и наша тема.
Писать так, как я написал, не надо. У меня указано специально — «синтаксис очень условный». Если Вам интересно, как это может быть, давайте обсуждать, это интересно. Если Вы считаете, что действительно, менять ничего не стоит, или стоит, но не в протоколе/DOM/ещё чём-то, давайте покрутим Ваши идеи.
Да нет же. Скорость выполнения JS гораздо выше, чем вызов по сети.
HTTP вообще не имеет дело с контентом статическим или динамическим. Это протокол, который реализует простейший RPC запрос к web серверу. Уже web сервер разбирается что это за запрос — статический ли файл, CGI запрос, или ещё что-то. А протокол просто передаёт запрос-ответ. Причём делает это достаточно надёжно. Что 10 лет назад, что сейчас — tcp-ip работает недостаточно надёжно чтобы надеяться что соединение будет долго открыто, и нет оснований считать, что web сервер сможет долго поддерживать соединение (keepalive на нагруженных серверах уже работает плохо).
Синтаксис Ваш показывает, что Вы хотите получить результат, как будто пишете синхронную (последовательно выполняющуюся) программу, но этого же нет и не будет в обозримом будущем. Если Вы напишете два подобных оператора, в каком порядке они выполнятся?
HTTP вообще не имеет дело с контентом статическим или динамическим. Это протокол, который реализует простейший RPC запрос к web серверу. Уже web сервер разбирается что это за запрос — статический ли файл, CGI запрос, или ещё что-то. А протокол просто передаёт запрос-ответ. Причём делает это достаточно надёжно. Что 10 лет назад, что сейчас — tcp-ip работает недостаточно надёжно чтобы надеяться что соединение будет долго открыто, и нет оснований считать, что web сервер сможет долго поддерживать соединение (keepalive на нагруженных серверах уже работает плохо).
Синтаксис Ваш показывает, что Вы хотите получить результат, как будто пишете синхронную (последовательно выполняющуюся) программу, но этого же нет и не будет в обозримом будущем. Если Вы напишете два подобных оператора, в каком порядке они выполнятся?
> Что 10 лет назад, что сейчас — tcp-ip работает недостаточно надёжно чтобы надеяться
> что соединение будет долго открыто, и нет оснований считать, что web сервер сможет
> долго поддерживать соединение (keepalive на нагруженных серверах уже работает
> плохо).
Я бы сказал, что надёжность соединения выросла на порядок. Хотя сразу вспоминается «не единого разрыва», но тем не менее, 10 лет назад большинство подключений были по модему, сейчас по АДСЛ и оптике.
Ну и речь не о keep-alive в смысле физическом, а скорее, в логическом. Если соединение утеряно, оно должно быть автоматически восстановлено, условно говоря, с того же самого места.
> Синтаксис Ваш показывает, что Вы хотите получить результат, как будто пишете
> синхронную (последовательно выполняющуюся) программу, но этого же нет и не будет в
> обозримом будущем. Если Вы напишете два подобных оператора, в каком порядке они
> выполнятся?
Синтаксис мой показывает желание продемонстрировать идею, больше ничего.
> что соединение будет долго открыто, и нет оснований считать, что web сервер сможет
> долго поддерживать соединение (keepalive на нагруженных серверах уже работает
> плохо).
Я бы сказал, что надёжность соединения выросла на порядок. Хотя сразу вспоминается «не единого разрыва», но тем не менее, 10 лет назад большинство подключений были по модему, сейчас по АДСЛ и оптике.
Ну и речь не о keep-alive в смысле физическом, а скорее, в логическом. Если соединение утеряно, оно должно быть автоматически восстановлено, условно говоря, с того же самого места.
> Синтаксис Ваш показывает, что Вы хотите получить результат, как будто пишете
> синхронную (последовательно выполняющуюся) программу, но этого же нет и не будет в
> обозримом будущем. Если Вы напишете два подобных оператора, в каком порядке они
> выполнятся?
Синтаксис мой показывает желание продемонстрировать идею, больше ничего.
>Вместо js используется быстрый код на Си++ (соответствующая поддержка нового
>стандарта в браузере и сервере). И тогда уже не нужно думать, как ускорить js-код,
>всё работает. Да и сам код проще, и миллионы вебмастеров вздыхают с облегчением.
Миллионы вебмастеров C++ не изучали. Они не вздохнут с облегчением, а подохнут :)
>стандарта в браузере и сервере). И тогда уже не нужно думать, как ускорить js-код,
>всё работает. Да и сам код проще, и миллионы вебмастеров вздыхают с облегчением.
Миллионы вебмастеров C++ не изучали. Они не вздохнут с облегчением, а подохнут :)
Э-э-э… Вы действительно, поняли ту мысль, которую я описывал?
Абсолютно не понял. С++ кто должен писать?
Авторы браузеров/вебсерверов.
Я думаю, что назрела необходимость в новом протоколе, более высокоуровневом. Если что-то подобное появится, то, скажем, 80-90% кода на JavaScript будет реализовано в рамках протокола создателяеми браузеров/вебсерверов.
И 20 строчек кода на js превратятся в одну. А 400 в 20. Тогда вопрос быстродействия снимается.
Я думаю, что назрела необходимость в новом протоколе, более высокоуровневом. Если что-то подобное появится, то, скажем, 80-90% кода на JavaScript будет реализовано в рамках протокола создателяеми браузеров/вебсерверов.
И 20 строчек кода на js превратятся в одну. А 400 в 20. Тогда вопрос быстродействия снимается.
:) если мне надо каждую вторую строчку таблицы перекрасить — мне это как надо сделать? Искать в api браузера именно эту функцию?
Мне не очень понятно, что Вы считаете протоколом. Есть уровни OSI, какой именно уровень Вы хотите переписать?
Мне не очень понятно, что Вы считаете протоколом. Есть уровни OSI, какой именно уровень Вы хотите переписать?
Вероятно, я несколько сумбурно написал.
Мне кажется, переписывать имеет смысл HTTP плюс DOM. HTTP, если я правильно помню, это верхний уровень, приложений. DOM скорее всего в OSI просто не входит.
По поводу каждой второй строчки — вероятно, так же, как и сейчас. Впрочем, могут быть интересные оптимизированные решения. Надо отдельно подумать.
Мне кажется, переписывать имеет смысл HTTP плюс DOM. HTTP, если я правильно помню, это верхний уровень, приложений. DOM скорее всего в OSI просто не входит.
По поводу каждой второй строчки — вероятно, так же, как и сейчас. Впрочем, могут быть интересные оптимизированные решения. Надо отдельно подумать.
>И 20 строчек кода на js превратятся в одну. А 400 в 20. Тогда вопрос быстродействия снимается.
Это легко сделать через два этапа: 1) проиндексировать DOM, 2) использовать jQuery — и скорость, и строк будет сколько Вы хотите. Но DOM индексировать по каким-то причинам создатели браузеров не хотят.
Это легко сделать через два этапа: 1) проиндексировать DOM, 2) использовать jQuery — и скорость, и строк будет сколько Вы хотите. Но DOM индексировать по каким-то причинам создатели браузеров не хотят.
>И пусть в меня первым бросит камень тот, кто считает, что загрузка
>сотни килобайт (бывает и меньше, не спорю) для ajax — решение, а не костыль.
А зачем 100 килобайт грузить? Когда Вы постите сообщение — передаётся только оно.
>Вы только представьте себе: сессии основываются на протоколе (а не на
>печеньи), то есть решается основная, на мой взгляд, проблема HTTP в
>нынешнем виде — неумение «узнавать» пользователей.
Этой проблемы нету! Откуда Вы её взяли? Вы сейчас на хабре — вас узнаёт сервер. Нету проблемы. что такое cookie? Это идентификатор, структуру которого определяете Вы, который передаётся от клиента к серверу. Что Вы хотели бы получить от протокола для пометки сессий? Тоже какой-то идентификатор.
>Многие нужные функции (те же асинхронные запросы, которые
>используются сейчас на 7 сайтах из 10) работают на основе всеобщего
>стандарта. И вместо 20 строк кода + библиотеки для такого запроса вы
>пишете одну строку. Почему тысячи сайтов используют похожие
>решения, а эти решения не считаются и не признаются стандартом (и не
>поддерживаются протоколом «по умолчанию»)?
Каким протоколом? HTTP выполнет всё что сейчас необходимо. Я так и не могу получить объяснения что Вы хотите получить того, чего нет сейчас. Сессии — отлично эмулируются куками, асинхронные запросы jQuery выполняет просто и как раз в одну строку.
jQuery, в большой степени, занимается эмуляцией CSS3 — и рано или поздно CSS3 появится. Это тоже решаемая проблема.
>Почему бы просто не прикручивать к новым версиям браузеров те же
>jQuery, prototype и иже с ними? Это, конечно, тоже костыль, но… мы тут
>сами протокол не изменим :)
Потому что они есть и без прикручивания. К тому же jQuery и prototype — разные библиотеки, и не уникальные.
>сотни килобайт (бывает и меньше, не спорю) для ajax — решение, а не костыль.
А зачем 100 килобайт грузить? Когда Вы постите сообщение — передаётся только оно.
>Вы только представьте себе: сессии основываются на протоколе (а не на
>печеньи), то есть решается основная, на мой взгляд, проблема HTTP в
>нынешнем виде — неумение «узнавать» пользователей.
Этой проблемы нету! Откуда Вы её взяли? Вы сейчас на хабре — вас узнаёт сервер. Нету проблемы. что такое cookie? Это идентификатор, структуру которого определяете Вы, который передаётся от клиента к серверу. Что Вы хотели бы получить от протокола для пометки сессий? Тоже какой-то идентификатор.
>Многие нужные функции (те же асинхронные запросы, которые
>используются сейчас на 7 сайтах из 10) работают на основе всеобщего
>стандарта. И вместо 20 строк кода + библиотеки для такого запроса вы
>пишете одну строку. Почему тысячи сайтов используют похожие
>решения, а эти решения не считаются и не признаются стандартом (и не
>поддерживаются протоколом «по умолчанию»)?
Каким протоколом? HTTP выполнет всё что сейчас необходимо. Я так и не могу получить объяснения что Вы хотите получить того, чего нет сейчас. Сессии — отлично эмулируются куками, асинхронные запросы jQuery выполняет просто и как раз в одну строку.
jQuery, в большой степени, занимается эмуляцией CSS3 — и рано или поздно CSS3 появится. Это тоже решаемая проблема.
>Почему бы просто не прикручивать к новым версиям браузеров те же
>jQuery, prototype и иже с ними? Это, конечно, тоже костыль, но… мы тут
>сами протокол не изменим :)
Потому что они есть и без прикручивания. К тому же jQuery и prototype — разные библиотеки, и не уникальные.
>Это явный костыль, ибо тот же mootols (22 килобайта) у всех
>одинаков, но все грузят его снова и снова (конечно, js файлы кешируются).
Не у всех одинаков. Разные версии, разные производители. Сколько версий jQuery должен нести FF? Я, например, использую две или три версии.
>Я хочу получить отсутствие эмуляции и решения проблем, которые
>можно просто не создавать.
Но любой другой способ будет делать ровно то же что и кукисы — передавать идентификатор сессии. Как бы это не реализовывалось. По сути cookies — часть http протокола в его прикладной части.
>Я уверен, если Opera, FF и Safari при загрузке с любого узла
>широкоизвестных библиотек будут подключать к странице
>соответсвующие локальные версии этих библиотек, то затраты
>пользователей на трафик в мире упадут на пару сотен тысяч
>долларов в год как минимум. За такие деньги можно
>специфицировать 10 протоколов.
Даже если все включат компрессию gzip — уже будет гораздо больший эффект. Но Ваша идея уже реализована — google предлагает грузить библиотеки с него. Всё уже сделано!
>А в целом, HTTP это Hypertext Transfer Protocol и предавать он
>должен гипертекст (коим тогда называли sgml, html и иже с ними).
А картинки это гипертекст? Кто их должен передавать?
>одинаков, но все грузят его снова и снова (конечно, js файлы кешируются).
Не у всех одинаков. Разные версии, разные производители. Сколько версий jQuery должен нести FF? Я, например, использую две или три версии.
>Я хочу получить отсутствие эмуляции и решения проблем, которые
>можно просто не создавать.
Но любой другой способ будет делать ровно то же что и кукисы — передавать идентификатор сессии. Как бы это не реализовывалось. По сути cookies — часть http протокола в его прикладной части.
>Я уверен, если Opera, FF и Safari при загрузке с любого узла
>широкоизвестных библиотек будут подключать к странице
>соответсвующие локальные версии этих библиотек, то затраты
>пользователей на трафик в мире упадут на пару сотен тысяч
>долларов в год как минимум. За такие деньги можно
>специфицировать 10 протоколов.
Даже если все включат компрессию gzip — уже будет гораздо больший эффект. Но Ваша идея уже реализована — google предлагает грузить библиотеки с него. Всё уже сделано!
>А в целом, HTTP это Hypertext Transfer Protocol и предавать он
>должен гипертекст (коим тогда называли sgml, html и иже с ними).
А картинки это гипертекст? Кто их должен передавать?
Вы никак не можете сообщить, чего нет в http и что Вы хотите в него добавить.
>Если большинство сайтов используют ajax например
А зачем? C какой целью? Браузер должен показывать, http — обеспечивать доставку, cgi — выполнять запросы, js — организовывать логику. Пока всё на своём месте. Как только какая-то часть будет перенесена на другого исполнителя — возникнет опасность, что он с ней не справится.
Говорят, у директоров атомных станций есть правило — на все предложения по усовершенствованию давать положительные отзывы, и никакие предложения не выполнять.
>Если большинство сайтов используют ajax например
А зачем? C какой целью? Браузер должен показывать, http — обеспечивать доставку, cgi — выполнять запросы, js — организовывать логику. Пока всё на своём месте. Как только какая-то часть будет перенесена на другого исполнителя — возникнет опасность, что он с ней не справится.
Говорят, у директоров атомных станций есть правило — на все предложения по усовершенствованию давать положительные отзывы, и никакие предложения не выполнять.
Сессии уже есть. Сервер уже знает что это за пользователь. Текстовые (или не текстовые) файлы создавать всё равно придётся при любой реализации для поддержки не-сеансовых сессий (живущих после выключения браузера). Я не вижу никаких аргументов за то, чтобы менять существующее положение вещей, только декларации «хочу». Аргументы есть? Не вижу.
Я ничего смело вписывать не буду — это Вам хочется изменений.
Стандарт на HTTP уже пересматривался. 0.9, 1.0, 1.1. Чего Вы хотите в него добавить — непонятно.
Если хотите обсудить — пишите, давайте аргументы и опровергайте мои возражения. Пока опровержений и контраргументов нет.
Я ничего смело вписывать не буду — это Вам хочется изменений.
Стандарт на HTTP уже пересматривался. 0.9, 1.0, 1.1. Чего Вы хотите в него добавить — непонятно.
Если хотите обсудить — пишите, давайте аргументы и опровергайте мои возражения. Пока опровержений и контраргументов нет.
Мне кажется, проблема с производительностью в следующем: нет ясности что такое JavaScript — отдельный язык, использующий интерфейс с DOM, или сам интерфейс к DOM. Если первое — то непонятно, почему не появились альтернативные языки — а они не появились. Если второе — то нельзя рассуждать о производительности JS отдельно от структуры и реализации DOM.
Первое, первое.
> Если первое — то непонятно, почему не появились альтернативные языки — а они не появились.
Был VBScript. Но он успешно сдох.
> Если первое — то непонятно, почему не появились альтернативные языки — а они не появились.
Был VBScript. Но он успешно сдох.
Успешно сдохший VBasic — tlbединвенный способ добраться до некоторых свойств ActiveX в самом распространённом браузере, так что об издыхании говорить рано. Но всё равно остаётся открытым вопрос — а почему не появились другие языки? Наверно, всё-таки, интеграция с DOM и с браузером плотнее чем хотелось бы.
Мне кажется, проблема с производительностью в следующем: нет ясности что такое Pilat — идиот, использующий русский язык или сам идиот. Если первое — понятно, почему появились альтернативные идиоты — а они появились. Если второе — то нельзя рассуждать о русском языке судя по идиотам.
радуйтесь что с выходом нового сервиса в интернете вам не приходинтся старый проц нести на свалку
просто вместо того чтобы использовать flash некоторые разработчики норовят все написать на JS, будучи очарованными популярностью слов AJAX и jQuery (а как эти слова любят менеджеры!) а, возможно, и не владея более подходящим для этой цели flash A S.
вообще молодые кодеры часто большие в этом смысле фетишисты (не в обиду молодым разумным кодерам будет сказано). кто-то аплологет реализации всего чистыми средставми backend, кто-то любит JS, а нектороые вообще все делают во Flash, есть и такие :)
как показывает практика, JS нужен только для AJAX запросов и несложной интерактивной перекомпоновки DOM. если дело касается демонстрации анимированных эффектов и прочих уловных «слайд-шоу с элементами аркадных игр», испольуйте flash. эта технология как раз для того и придумана. тем более что, как я понимаю, у вас как раз тот самый случай.
хороший сайт одинаково хорошо открывается и работает и на слабых машинках. (и с выключенными JS и flash! :)
вообще молодые кодеры часто большие в этом смысле фетишисты (не в обиду молодым разумным кодерам будет сказано). кто-то аплологет реализации всего чистыми средставми backend, кто-то любит JS, а нектороые вообще все делают во Flash, есть и такие :)
как показывает практика, JS нужен только для AJAX запросов и несложной интерактивной перекомпоновки DOM. если дело касается демонстрации анимированных эффектов и прочих уловных «слайд-шоу с элементами аркадных игр», испольуйте flash. эта технология как раз для того и придумана. тем более что, как я понимаю, у вас как раз тот самый случай.
хороший сайт одинаково хорошо открывается и работает и на слабых машинках. (и с выключенными JS и flash! :)
Все комменты читать времени нет, но посмотрите на gmail.com.) сложный интерфейс, и не забивает мой одноядерный проц гипертрединга в ноль.
Весь вопрос в прямых руках руках программиста. )
Весь вопрос в прямых руках руках программиста. )
У меня другой вопрос, хрен с ними с тормозами :) Почему ТАК сложно делаются на первый взгляд элементарные вещи...? Выпадающее меню — 50 строк кода :))
сразу предупреждаю, я пока не знал JavaScript, только планирую изучать… но страшно становится от того, как на нем писать интерфейсы…
сразу предупреждаю, я пока не знал JavaScript, только планирую изучать… но страшно становится от того, как на нем писать интерфейсы…
тормозит-то не яваскрипт, а CSS renderer
или вы думаете, что перерисовкой дрыгаемых яваскриптом DOM-элементов тоже яваскрипт занимается?
или вы думаете, что перерисовкой дрыгаемых яваскриптом DOM-элементов тоже яваскрипт занимается?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько простых вопросов про JavaScript