Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 92
Статья чем-то напомнила мне не столь давний топик про сжатие JS в PNG файлы :-)
А примерчик-то JS ошибку выдаёт :)
А по сабжу, слишком много чести юзерской части. Такой подход может быть оправдан в скрытых online интерфейсах типо вконтактов или gmailа.
Автору конечно респект за разработку.
В минусы: Далеко не каждый сможет повторить написанное.
Автору конечно респект за разработку.
В минусы: Далеко не каждый сможет повторить написанное.
Действительно. Исправил.
Забыл исправить trace_skin_file на trace в 2х местах. Плюс, в ajax_load вместо parcer(par) необходимо сделать return parcer(par).
Забыл исправить trace_skin_file на trace в 2х местах. Плюс, в ajax_load вместо parcer(par) необходимо сделать return parcer(par).
"Невозможность без введения дополнительных средств работать с URL"
я не ошибаюсь полагая, что эта строка означает, что пользователь не сможет дать ссылку на конкретный продукт/категорию другому пользователю.
будет так: "привет, мне тут один товар приглянулся zcn.ru/market. как пройдешь по ссылке там во второй раздел и третий подраздел, товар Мухобойка."
я не ошибаюсь полагая, что эта строка означает, что пользователь не сможет дать ссылку на конкретный продукт/категорию другому пользователю.
будет так: "привет, мне тут один товар приглянулся zcn.ru/market. как пройдешь по ссылке там во второй раздел и третий подраздел, товар Мухобойка."
Такие вещи обычно решаются выводом ссылки рядом с товаром (типа "как его найти"). По аналогии с "решеткой", которая на Хабре около каждого коммента.
Эта проблема общая для AJAX-решений и пока напрямую не обходится, насколько я знаю.
Эта проблема общая для AJAX-решений и пока напрямую не обходится, насколько я знаю.
Обходится. Недавно на Хабре был топик про это. Сейчас найду ссылку.
Спасибо за ссылку, полезная информация там. Пропустил, пока был в командировке наверное :)
Однако, мне кажется не стоит столько страдать просто ради применения AJAX'а где только хотим.
В конце концов, отдельные вещи (личные настройки, голосовалка, комментарии) очень логично сделать в Ajax'e, а вот переход между статьями, например, ИМХО лишнее. Попахивает маньячеством и садомазохизмом :)
Однако, мне кажется не стоит столько страдать просто ради применения AJAX'а где только хотим.
В конце концов, отдельные вещи (личные настройки, голосовалка, комментарии) очень логично сделать в Ajax'e, а вот переход между статьями, например, ИМХО лишнее. Попахивает маньячеством и садомазохизмом :)
Gmail нашёл выход. Правда тоже в стиле якорей...
Зачем использовать технологию, предназначенную для обновления контента страницы, для генерации самом страницы?
Как устроено кэширование на стороне клиента? И чем вас кэш сервера не устроил?
В чем преимущество перед серверными шаблонами? Все плюсы, указанные Вами, вроде как и для php актуальны. Кстати,
Исправьте меня, если я ошибаюсь, но и в php-шаблонах происходит разделение, и большинство php-кода отвечает за содержимое страницы, а не за вид сайта. А css, js и tpl менять все равно придется.
Как устроено кэширование на стороне клиента? И чем вас кэш сервера не устроил?
В чем преимущество перед серверными шаблонами? Все плюсы, указанные Вами, вроде как и для php актуальны. Кстати,
- Для изменения вида сайта не требуется никакой доработки PHP-кода - только ccs/javascript и шаблоны.
Исправьте меня, если я ошибаюсь, но и в php-шаблонах происходит разделение, и большинство php-кода отвечает за содержимое страницы, а не за вид сайта. А css, js и tpl менять все равно придется.
Вопрос ребром: чем предложенная технология лучше клиентского XSLT?
работает медленнее, но даже там, где поддержки xslt ещё нет, а js уже есть
хотя не могу назвать пример такого браузера : )
имхо: очередной велосипед
хотя не могу назвать пример такого браузера : )
имхо: очередной велосипед
Те же яйца только в профиль.
- и то и другое жрет ресурсы и тормозит
- и там и там проблемы с поисковыми машинами (без применения доп.мер.)
но в одном все-таки лучше. Реализация XSLT в основных броузерах сильно урезанная и в разных броузерах отрабатывается по разному, в отличие от JS. Можно конечно использовать js-библиотеки XSLT-парсинга, но это уже перебор.
- и то и другое жрет ресурсы и тормозит
- и там и там проблемы с поисковыми машинами (без применения доп.мер.)
но в одном все-таки лучше. Реализация XSLT в основных броузерах сильно урезанная и в разных броузерах отрабатывается по разному, в отличие от JS. Можно конечно использовать js-библиотеки XSLT-парсинга, но это уже перебор.
мне кажется, что самый главный минус - вероятность отключенного JS у пользователя.
уважаемая общественность, у меня давно уже назрело пару вопросов по данной тематике:
первый - каков реальный процент людей с выключенным javascript и кто они в большинстве своем?
второй - мне кажется, сейчас слишком много возлагается на javascript и ajax, в результате чего рядовой пользователь в лице меня наблюдает стопроцентную загрузку процессора браузером, выполняющим этот код. Не глупо ли вталкивать javasript даже там, где вполне можно было обойтись препроцессингом php и парой-тройкой лишних http запросов?
первый - каков реальный процент людей с выключенным javascript и кто они в большинстве своем?
второй - мне кажется, сейчас слишком много возлагается на javascript и ajax, в результате чего рядовой пользователь в лице меня наблюдает стопроцентную загрузку процессора браузером, выполняющим этот код. Не глупо ли вталкивать javasript даже там, где вполне можно было обойтись препроцессингом php и парой-тройкой лишних http запросов?
мне тоже интересен данный процент, присоединяюсь к вопросу.
отключенный js, вроде, у 5%
очень зависит от аудитории сайта
очень зависит от аудитории сайта
Когда я пару месяцев назад задавался этим вопросом, то на зарубежных ресурсах нашёл цифру 6%. Правда 3-4% могут приходиться, например, на Opera Mini (хотя, четвёртая версия этой программы JS «поддерживает»).
Мне кажется, что проблема больше не в том, что js может быть отключен, а в том, что он может сломаться по вине разработчика/браузера/НЛО, и в таком случае возможность работы с интерфейсом без js спасёт пользователя от проблем.
По поводу второго вопроса- JS+AJAX vs HTML.
Я сейчас занимаюсь разработкой игры. Игра у меня не статическая, а динамическая - тоесть всё полностью с самого начала и до конца генерируется браузером. Многие вещи уже оптимизированны, по этому 100% процессора JS занимает доли секунды.
XSLT пользоваться я не имею возможности. Так как он не умеет по полученным данным расчитывать маршрут корабля и пускать их в плавание по экрану.
Добавлять каждый корабль методом ".innerhtml='< img...'" не универсально. По этому я разработал библиотеку Шаблонов и сейчас уже использую её.
Плюс ко всему, разработал ещё интерфейс взаимодействия между JS и PHP. В результате, получилось клиент-сервер приложение в нормальном его понимании. :)
Я сейчас занимаюсь разработкой игры. Игра у меня не статическая, а динамическая - тоесть всё полностью с самого начала и до конца генерируется браузером. Многие вещи уже оптимизированны, по этому 100% процессора JS занимает доли секунды.
XSLT пользоваться я не имею возможности. Так как он не умеет по полученным данным расчитывать маршрут корабля и пускать их в плавание по экрану.
Добавлять каждый корабль методом ".innerhtml='< img...'" не универсально. По этому я разработал библиотеку Шаблонов и сейчас уже использую её.
Плюс ко всему, разработал ещё интерфейс взаимодействия между JS и PHP. В результате, получилось клиент-сервер приложение в нормальном его понимании. :)
safari 3.1.1@mac показывает просто пустую страничку
1) Насколько я понимаю такие шаблоны не поддерживают циклы, операторы ветвления и т. д. Вообще есть неплохая библиотека trimpath JavaScriptTemplates.
2) Думаю существенным минусом будет необходимость подгружать сразу несколько шаблонов. Можно было бы объединять их в один файл или вставлять на страницу. JavaScriptTemplates рекомендует использовать для этого невидимую textarea, однако такая страница может неправильно индексироваться поисковиком (у меня код js шаблона выводился в результатах поиска).
Лично я использовал js шаблоны в сложном скрытом интерфейсе, код шаблона вставлялся на страницу, так же при загрузке скрипта на страницу вставлялась первая порция данных ввиде js массива, чтобы пользователь при загрузке основного скрипта не ждал результатов ajax запроса.
Посколько страница не индексировалась поисковиком и не было особой необходимости в прямых ссылках и навигации вперёд/назад, получилось весьма удачно, но для внешнего открытого интерфейса лучше такую технику не применять.
2) Думаю существенным минусом будет необходимость подгружать сразу несколько шаблонов. Можно было бы объединять их в один файл или вставлять на страницу. JavaScriptTemplates рекомендует использовать для этого невидимую textarea, однако такая страница может неправильно индексироваться поисковиком (у меня код js шаблона выводился в результатах поиска).
Лично я использовал js шаблоны в сложном скрытом интерфейсе, код шаблона вставлялся на страницу, так же при загрузке скрипта на страницу вставлялась первая порция данных ввиде js массива, чтобы пользователь при загрузке основного скрипта не ждал результатов ajax запроса.
Посколько страница не индексировалась поисковиком и не было особой необходимости в прямых ссылках и навигации вперёд/назад, получилось весьма удачно, но для внешнего открытого интерфейса лучше такую технику не применять.
1. а с чего вдруг шаблоны должны их поддерживать?
1) см. пример DrawInfo
2) Всё находится в одном шаблоне, который разбит внутри на несколько.
2) Всё находится в одном шаблоне, который разбит внутри на несколько.
Прошу прощения за невнимательность.
Как я понял, чтобы применить часть шаблона несколько раз, нужно эту часть вынести в отдельный блок файла skin, а цикл делать снаружи шаблона. А если мне, к примеру, нужно в этом цикле вывести ссылку на товар, если с ним ассоциирована картинка и вывести название товара без ссылки, если картинки нет? Как я понимаю придётся создавать два новых блока в файле skin и подставлять результат обработки в блок вывода товара. Мне кажется что чем сложнее логика исходного шаблона, тем запутаннее будет файл skin.
С другой стороны JST наверное работает медленнее и в отладке гораздо сложнее.
Как я понял, чтобы применить часть шаблона несколько раз, нужно эту часть вынести в отдельный блок файла skin, а цикл делать снаружи шаблона. А если мне, к примеру, нужно в этом цикле вывести ссылку на товар, если с ним ассоциирована картинка и вывести название товара без ссылки, если картинки нет? Как я понимаю придётся создавать два новых блока в файле skin и подставлять результат обработки в блок вывода товара. Мне кажется что чем сложнее логика исходного шаблона, тем запутаннее будет файл skin.
С другой стороны JST наверное работает медленнее и в отладке гораздо сложнее.
Да, просто появится ещё одно поле.
<!SKIN 'PIECE.IMG'><tr id="%GOODS_ID%"><td class="order_name">%GOODS.NUM%. <img src='%GOODS.IMG%'></td><td>%GOODS.PRICE%</td></tr><!END 'PIECE'>
Либо:
<!SKIN 'PIECE'><tr id="%GOODS_ID%"><td class="order_name">%GOODS.NUM%. %GOODS.NAMEIMG% <!SKIN 'IMG'><img src='%NAME%'><!END 'IMG'><!SKIN 'NAME'>%NAME%<!END 'NAME'></td><td>%GOODS.PRICE%</td></tr><!END 'PIECE'>
<!SKIN 'PIECE.IMG'><tr id="%GOODS_ID%"><td class="order_name">%GOODS.NUM%. <img src='%GOODS.IMG%'></td><td>%GOODS.PRICE%</td></tr><!END 'PIECE'>
Либо:
<!SKIN 'PIECE'><tr id="%GOODS_ID%"><td class="order_name">%GOODS.NUM%. %GOODS.NAMEIMG% <!SKIN 'IMG'><img src='%NAME%'><!END 'IMG'><!SKIN 'NAME'>%NAME%<!END 'NAME'></td><td>%GOODS.PRICE%</td></tr><!END 'PIECE'>
А насколько быстро будет работать сайт сделаный таким образом на среднем компьютере при большем числе элементов в шаблоне?
Это зависит от программиста.
Перефразируем:
А насколько быстро будет работать сайт сделаный таким образом средним программистом на среднем компьютере при большем числе элементов в шаблоне? :D
А насколько быстро будет работать сайт сделаный таким образом средним программистом на среднем компьютере при большем числе элементов в шаблоне? :D
Ну или насколько быстро оно будет работать на среднем железе, если программистом будет автор.
Всё зависит от конкретной задачи и конкретного браузера.
Браузерная игра, которую я разрабатываю, сейчас не тормозит на 1Ghz машинах. Но там уже были не раз использованны оптимизация JS под IE, оптимизация графики под Opera...
Браузерная игра, которую я разрабатываю, сейчас не тормозит на 1Ghz машинах. Но там уже были не раз использованны оптимизация JS под IE, оптимизация графики под Opera...
не зависит от программиста :) если уж на простой рендеринг страницы уходит от 10мс, то на рендеринг с помошью JS будет уходить от 1000мс (с подгрузкой всех данных). Имхо, стоит использовать только для внутренних проектов
Имхо - 1000мс вы выдумали. :) Не желаете, не пользуйтесь, я никого не заставляю - просто делюсь своими мыслями и методами решений.
По скорости - на первую загрузку выйдет несущественно больше. (особенно на модеме) Зато на следующие подгрузки будет уходить намного меньше времени, нежели на загрузку всей страницы.
По скорости - на первую загрузку выйдет несущественно больше. (особенно на модеме) Зато на следующие подгрузки будет уходить намного меньше времени, нежели на загрузку всей страницы.
склонен с Вами не согласиться: время на инициализацию JS-решений сравнимо со временем загрузки/парсинга HTML
"шаблоны на JS"
сеньор, вы знаете толк в извращениях:-)
сеньор, вы знаете толк в извращениях:-)
В классике фигурировали «гусары» ) А так, абсолютно согласен с Вашим комментарием.
Если вы что-то не используете - это не значит, что никто это не использует. На Javascript`e достаточно много шаблонизаторов и их активно используют. Конечно смысл применять их в стандартных сайтах нет, это скорее шаг к созданию описательной модели интерфейсов для развернутых веб-приложений (пример, отдельные гуглевские сервисы).
Особо весело он работает с выключенным джаваскрипт.
У многих секретуток JS выключен по умолчанию в браузере, или очень ограничен (безопасности в опасности © ИЕ) потому данный сайт будет представлять интерес только для деверов :) как очередное извращение :)
У многих секретуток JS выключен по умолчанию в браузере, или очень ограничен (безопасности в опасности © ИЕ) потому данный сайт будет представлять интерес только для деверов :) как очередное извращение :)
По моему опыту написания интерфейсов без graceful degradation нерешаемые проблемы возникали очень редко, хотя большую часть аудитории составляли не разработчики, правда и не секретарши. Но если бы делал сейчас, всёравно сделал бы nojs версию.
вы ошиблись разделом - вам надо смотреть ветку http://habrahabr.ru/tag/NoJavaScript/
за подсветку кода отдельное спасибо
KISS
все чаще и чаще встречаются подходы на JavaScript по отделению данных от их визуализации , взять тотже ExtJS: вся визуализация вынесена в скрипты, а данные запрашиваются динамически - потом это все дело смешивается на стороне клиента. Данный подход применяется в современных веб-приложениях.
Все кте кто орут что такие варианты реализации извращение и т.п. в скором будущем окажутся за бортом. Такие люди ленивы и "льют грязь" на других оправдывая и успокаивая свою лень.
По поводу данного примера который описан в статье: мое субъективное мнение, которое родилось из опыта - более оптимальным все же является шаблонизация на стороне сервера с применением AHAH. Т.е. все же подгружается уже готовый HTML, отсюда плюсы: можно сделать нормальную индексацию, история, ссылки, исполнение подгружаемых скриптов.
Все кте кто орут что такие варианты реализации извращение и т.п. в скором будущем окажутся за бортом. Такие люди ленивы и "льют грязь" на других оправдывая и успокаивая свою лень.
По поводу данного примера который описан в статье: мое субъективное мнение, которое родилось из опыта - более оптимальным все же является шаблонизация на стороне сервера с применением AHAH. Т.е. все же подгружается уже готовый HTML, отсюда плюсы: можно сделать нормальную индексацию, история, ссылки, исполнение подгружаемых скриптов.
В ExtJS последней версии есть такая штука, как XTemplate - вот уж где действительно очень удобная штука и колесо изобретать не надо. Впрочем, у ExtJS один недостаток - чтобы использовать хоть какую-нибудь финтифлюшку оттуда, приходится грузить половину этой объемистой библиотеки, так как там все связано мужду собой.
В те далёкие времена, когда только что появился gmail, я сделал 100% ajax интернет-магазин:
www.s98.ru
Года эдак 4 назад))) Примечательно, что сейчас эти идеи преподносятся как нечто невероятно новое))))
www.s98.ru
Года эдак 4 назад))) Примечательно, что сейчас эти идеи преподносятся как нечто невероятно новое))))
хорошо сделано, для роботов тоже предусмотрено. работает шустренько. история работает нормально в ФФ2,ИЕ6,ИЕ7,Safari3. В Опере 9.23 история не пашет.
вообщем приятно работает магазин.
а чего 4 года назад ничего не публиковали? чегото не слыхать было про s98.ru
вообщем приятно работает магазин.
а чего 4 года назад ничего не публиковали? чегото не слыхать было про s98.ru
Да, хорошая работа. Правда, не ожидал, что товары в категориях (левое меню) загружаются в тело страницы заранее. Обычно это в первую очередь AJAX'уют :)
я видел аяксовые магазины еще в 2001г. (на iframe)
распространение технологий определяет правильный маркетинг :)
распространение технологий определяет правильный маркетинг :)
Использование регулярных выражений в данном контексте вызывает очень большие вопросы касательно производительности
Напомнило Smarty - там тоже логика представления выносится из PHP. Ну там она выносится в шаблон, а здесь в JavaScript...
Учитывая то, что логика представления не ресурсоемка(это не сложные расчеты и не работа с тормозной базой), а браузеры вполне могут быть тормозными, поэтому целесообразность такого подхода может заключаться, имхо, только в удобстве использования, что весьма субъективно.
Учитывая то, что логика представления не ресурсоемка(это не сложные расчеты и не работа с тормозной базой), а браузеры вполне могут быть тормозными, поэтому целесообразность такого подхода может заключаться, имхо, только в удобстве использования, что весьма субъективно.
Я бы хотел иметь шаблонизатор на жаваскрипт, но мне необходима там поддержка изменяемых значений - чтобы в шаблоне они прописывались и завязывались на что-то еще.
Как универсальное решение я думаю этот подход достаточно нерационален, но для использовании в частных случаях подходит, главное чтобы было что=то такое, ради чего его было целесообразно применять, чем методы генерации страниц на сервере (например какой-то сложный очень динамичный интерфейс).
Web-интерфейсы и средства реализаций потихоньку развиваются и становятся более приятными и навороченными. :)
С такого рода Шаблонным интерфейсом, легко поддерживать интерактивность сайта, обновляя лишь необходимые участки станицы.
С такого рода Шаблонным интерфейсом, легко поддерживать интерактивность сайта, обновляя лишь необходимые участки станицы.
Да, но тоже самое возможно и при традиционной системе шаблонов
Я про JS. Как пример - можно посмотреть на изменение товара в корзине на http://zcn.ru/market/.
давно такой чущи невидел :)
Я непонимаю, зачем писать мега парсер и заганять язык в xml если можно использовать масивы в качестве шаблона и обьекты в качестве языков.
js файлы с нужным языком и темплейтом подгружать динамически при надобности.
js файлы с нужным языком и темплейтом подгружать динамически при надобности.
В вашем случае теряется ясность шаблонов. Становится сложно ориентировать в этой кучи значений.
Для поддержки различных языков - я согласен, можно загрузить и .js. Только xml-файл универсальнее: он не завязан на переменных относительно проекта на .js, его в случае чего, можно использовать в любом другом приложении.
Зачем уходить от парсинга, который и так занимает доли секунды?
Ну и может быть ситуация, когда необходимо загрузить конфиг для определенного пользователя (которых в вашей системе будут тысячи) - неужели вы будете генерить JS файл, когда можно просто сгенерить JSON'м и передать в скрипт?
Для поддержки различных языков - я согласен, можно загрузить и .js. Только xml-файл универсальнее: он не завязан на переменных относительно проекта на .js, его в случае чего, можно использовать в любом другом приложении.
Зачем уходить от парсинга, который и так занимает доли секунды?
Ну и может быть ситуация, когда необходимо загрузить конфиг для определенного пользователя (которых в вашей системе будут тысячи) - неужели вы будете генерить JS файл, когда можно просто сгенерить JSON'м и передать в скрипт?
Как показал опыт, вполне удобно и читаемо)
['div', {id : '1'}, [
['span', {className: 'class1'}],
['label', {'for' : 'name'},[
['span', {className : 'title', innerHTML : 'title'}],
['input', {type : 'text', name : 'name'}]
]]
]];
Мы щас говорим именно о шаблонах в js, а не например html, если нужно перенести шаблон в html то это делается за 5 минут, посредетвом firebug или webdev'a лиса.
Я не беде генерить темлейт на стороне сервера, он уже лежит готовый, я туда через модуль создания проставлю нужные значения ) Между прочим темлейт который закешируется на стороне клиента, и к нему не будут ходить каждый раз темлейты под юзверя, к нему будет приходить только нужная инфа для прорисовки. Зачем использовать AJAX если вы всеравно ганяете теже объемы данных?
['div', {id : '1'}, [
['span', {className: 'class1'}],
['label', {'for' : 'name'},[
['span', {className : 'title', innerHTML : 'title'}],
['input', {type : 'text', name : 'name'}]
]]
]];
Мы щас говорим именно о шаблонах в js, а не например html, если нужно перенести шаблон в html то это делается за 5 минут, посредетвом firebug или webdev'a лиса.
Я не беде генерить темлейт на стороне сервера, он уже лежит готовый, я туда через модуль создания проставлю нужные значения ) Между прочим темлейт который закешируется на стороне клиента, и к нему не будут ходить каждый раз темлейты под юзверя, к нему будет приходить только нужная инфа для прорисовки. Зачем использовать AJAX если вы всеравно ганяете теже объемы данных?
Не думаю, что данный подход правильный. Он противоречит модели клиент - сервер, или, по-советски, терминал - мейнфрейм, к которым всё и идёт, всё новое - хорошо забытое старое.
Еще есть Google Ajaxslt, тоже вариант)
Согласен с l2k за AJAX будущее. Волнует вопрос, как подружить динамическое содеожимое с поисковиками. Пока работоспособным представляется вариант предложенный terex, #. Однако, имхо, не гибко.
Есть бредовая мысль: а нет ли инструмента, позволяющего при необходимости отрабатывать JS на сервере, а на клиента отдавать чистый HTML? Т.е. заходит поисковик на сайт а ему HTML отдается, или если клиент совсем хилый, может попробовать без JS работать. Никто с подобной весчью не сталкивался?
Я смотрел в сторону ExtJS server side proxy, типа Aptana Jaxer, но что-то не то...
Есть бредовая мысль: а нет ли инструмента, позволяющего при необходимости отрабатывать JS на сервере, а на клиента отдавать чистый HTML? Т.е. заходит поисковик на сайт а ему HTML отдается, или если клиент совсем хилый, может попробовать без JS работать. Никто с подобной весчью не сталкивался?
Я смотрел в сторону ExtJS server side proxy, типа Aptana Jaxer, но что-то не то...
по секрету тебе раскажу — используй например инфу из переменной оружения юзер-агент, для получения инфы о том кто ломится на сат твой и выдавай ему контент соотсветсвующий.
Проблема не в том, как засечь кто ломится на сайт, а нельзя ли, по минимуму меняя код ExtJS, который работает на клиенте в барузере, получить 'plain html' представление того же на серверной стороне.
Т.е. — основное желание не дублировать то, что делает ExtJS код в серверных скриптах.
Кстати, гугл выложил JS движок V8 (вместе с браузером chrome), есть мысля его заюзать.
И еще кстати, раз уж зашла речь. Мы анализировали работу ExtJS прикладухи (галерея картин) в разных браузерах chrome оказался лучшим и по использованю памяти и по скорости отработки.
Для сравнения: по памяти IE 6.5 — 83mb, chrome — 60, по скорости сравнивали время загрузки дерева компонентом Ext.tree.TreeLoader в IE и Лисе порядка минуты (дерево порядка 200 элементов), в хроме — 3-5 секунд!
Так что заюзать движок JS от гуглов представляется весьма заманчивым…
Т.е. — основное желание не дублировать то, что делает ExtJS код в серверных скриптах.
Кстати, гугл выложил JS движок V8 (вместе с браузером chrome), есть мысля его заюзать.
И еще кстати, раз уж зашла речь. Мы анализировали работу ExtJS прикладухи (галерея картин) в разных браузерах chrome оказался лучшим и по использованю памяти и по скорости отработки.
Для сравнения: по памяти IE 6.5 — 83mb, chrome — 60, по скорости сравнивали время загрузки дерева компонентом Ext.tree.TreeLoader в IE и Лисе порядка минуты (дерево порядка 200 элементов), в хроме — 3-5 секунд!
Так что заюзать движок JS от гуглов представляется весьма заманчивым…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шаблоны