Текущее состояние XSLT на стороне клиента - PullRequest
8 голосов
/ 04 января 2011

В последний раз я слышал, что Blizzard была одной из немногих компаний, внедривших XSLT на стороне клиента (2008).Это все еще имеет место в 2011 году, или сейчас все больше людей изучают эту технику в производстве?

Похоже, что современные браузеры (IE9, FF4, Chrome) и вычислительная мощность клиента призваны использовать этот стандарт для ощутимой экономии ресурсов процессора и пропускной способности сервера при крупномасштабных свойствах.Я что-то упустил?

Отрицательные аспекты, которые мне известны, включают

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

Я вижу следующие преимущества:

  • композиция шаблона, выгруженная на клиент
  • кэширование общих фрагментов шаблона, выгруженных на клиенте
  • логическое разделение структуры документа и данных
  • хорошо документированный веб-стандарт, поддерживаемый всеми современными браузерами

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

Заранее спасибо,

Кейси

Редактировать:

Любое понимание того, как Google рассматривает преобразованный XML и его последствия для SEO, также приветствуется.

Ответы [ 6 ]

3 голосов
/ 05 января 2011

Последнее, что я слышал, Blizzard - одна из немногих компаний, которая внедрила XSLT на стороне клиента (2008).Это все еще имеет место в 2011 году, или сейчас все больше людей изучают эту технику в производстве?

Вот несколько примеров:

  1. Сайт Дженни Теннисон полностью основан на XSLT-клиенте и работает так уже много лет.

  2. Этот коммерческий сайт полностью ориентирован на XSLT на стороне клиента: http://www.skechers.com/

  3. У нас уже есть реализация XQuery в браузере: XQIB

  4. Майкл Кей написал в блоге о своей попытке создать XSLT 2.0 в браузере , и скоро что-то будет работать.

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

3 голосов
/ 04 января 2011

Я использую клиентский XSLT для kulesh.info . Я не нашел каких-либо различий в IE 6–9, Chrome, Safari и Firefox. XSLT-преобразование происходит очень быстро. Я не делал никаких измерений скорости, но не вижу никаких различий по сравнению с чистой версией HTML (даже на первом поколении iPod Touch).

mail.yandex.ru (крупный почтовый провайдер в России) также использует XSLT на стороне клиента.

2 голосов
/ 04 января 2011

Я, возможно, почему-то теряюсь в переводе, но я думаю, что проблемы с SEO - главная причина, мешающая многим людям использовать клиентский XSLT.

Мне не известны поисковые роботы, способные анализировать приложение / xml вместо обычного html или даже flash.

Тем не менее, хорошей практикой (mail.yandex.ru - действительно яркий пример) для высоконагруженных веб-приложений частично использовать XSLT на клиенте, потому что трафик большой и SEO-дружелюбие не требуется.

2 голосов
/ 04 января 2011

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

Поверьте мне, хотя, я бы хотел, чтобы я написал решение для компании, в которой я работал в прошлом, которая использовала переводы XSLT для всех своих шаблонов внешнего интерфейса. Он не использовал переводы на стороне клиента, потому что это было в 2005 году, когда все еще существовала большая доля браузеров, которые не поддерживали XSLT на стороне клиента. Одной из самых больших проблем, с которыми мы столкнулись при работе с этой системой, был поиск разработчиков, которые могли бы помочь с ней работать. И когда вы нашли кого-то, кто мог бы работать с ним, они убили бы много шаблонов, потому что XSLT-разработка отличается от любого другого языка шаблонов.

Несмотря на то, что преимущества использования XSLT огромны (выполните поиск по симфонии в Google, отличный cms, использующий xslt в качестве системы шаблонов), я не вижу, чтобы он занимал намного больше места для разработки интерфейса.

1 голос
/ 04 января 2011

Несколько лет назад я создал сайт XML - XSLT для школьного проекта и заметил ошибку: Firefox не поддерживает экранирование с отключением-выводом.

https://bugzilla.mozilla.org/show_bug.cgi?id=98168

1 голос
/ 04 января 2011

Принимая решение об использовании XSLT, оно обычно сводится к затратам времени разработчика по сравнению с ощутимой выгодой в циклах ЦП. Для небольшого клиента это почти универсально означает: XSLT, если он существует, идет на стороне сервера. Выяснить все проблемы клиентов просто не достаточно.

Если произойдет прорыв, он будет на крупных сайтах, таких как: Facebook или Google. На них циклы ЦП, выгруженные на клиент, составят значительную цифру в $$$, достаточную для того, чтобы оправдать наем разработчика (-ей), который решит проблемы клиента. Я бы наблюдал за этими игроками, чтобы увидеть, произойдут ли изменения

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...