Jakieś duże witryny korzystające z XSLT po stronie klienta?

Nie mogłem szczegółowo powiedzieć, jak to jest zaimplementowane, ale World of Warcraft jest dość duży i duży ruch, a ich strona internetowa jest zaimplementowana tak, jak opisujesz.

Nie znam żadnych dużych publicznych stron internetowych, które używają transformacji XSLT po stronie klienta (no, poza World of Warcraft wspomnianym przez Joela :-). Więc nie mogę odpowiedzieć bezpośrednio na twoje pytanie.

Jednak od czasu do czasu zastanawiałem się nad tym samym pytaniem i mam hipotezę, że liczba takich stron w Internecie musi być bardzo bliska zeru. :-)

Krótka wersja mojej teorii stojącej za tą hipotezą jest taka: z wyjątkiem niektórych dość egzotycznych przypadków, przepis opcja XSLT po stronie klienta po prostu nie jest warta zachodu. :-)

Firma, w której pracowałem w 2001 roku wydała produkt serwerowy, który zaimplementował dokładnie architekturę, którą opisałeś. Mieliśmy bardzo dobry sukces, przenosząc przetwarzanie na klientów. Ponadto, wykonując wykrywanie klientów za pomocą agenta użytkownika HTTP, byliśmy w stanie użyć przetwarzania xsl po stronie serwera, aby zaspokoić bardzo konkretnych klientów, takich jak Japońskie telefony komórkowe. Myślę, że strony / usługi / produkty, które używają tej techniki zrobić to dość przejrzyście dla klientów. Jednak myślę, że trend ostatnio jest zrobić przetwarzanie po stronie serwera, tak, że nie trzeba polegać ani testować na poszczególnych implementacji XSL dla różnych klientów i uzyskać wsparcie dla niektórych rozszerzeń XSL, które nie byłyby w stanie używać podczas obsługi zdecydowanej większości przeglądarek.

Wiem, że nie odpowiadam bezpośrednio na twoje pytanie o nazwanie niektórych dużych witryn, ale mam nadzieję, że oferuję coś wartościowego dla problemu. Więc, w zasadzie chodzi mi o to, że chyba oszczędności wydajności robi swoje przetwarzanie szablonów jest bardziej wartościowe niż QA, wsparcie i rozwój dla trzech lub czterech przeglądarek bez rozszerzeń, wtedy powinieneś trzymać się przetwarzania po stronie serwera.

Obecnie uruchamiam kilka pomniejszych stron z XSLT po stronie klienta, wszystkie po szwedzku (lillemanfestivalen.se, resihop.nu i projekty beta). Moim największym zmartwieniem było to, że google nie indeksuje zawartości moich stron, tylko XML bez transformacji. Jednak od kiedy uruchomiłem resihop.nu tydzień temu pojawił się w google z transformacją! : D

Teraz moim drugim zmartwieniem jest facebook i inne serwisy społecznościowe, które nie rozumieją, jak sobie z tym poradzić. Nadal jednak uważam, że boki górne są większe niż boki dolne. Fantastyczna prędkość i separacja, które dostaję jest awsome. I z resihop.nu, nawet nie rozwijam osobnego API, po prostu kieruję programistów do samej strony. (Więcej pracy będzie tam potrzebne, aby to dobrze chociaż)

Zgadzam się z odpowiedzią Elijaha. Myślę, że korzystanie z XSLT po stronie klienta jest trudną pracą. Musisz zrobić dużo QA za to. Ale z serwerem po stronie, nie masz tego QA. Musisz dbać o wszelkiego rodzaju klientów i możliwości podczas korzystania z client side. Istnieje możliwość, że Twój kod może się zepsuć podczas korzystania z XSLT po stronie klienta.

Mogę być stronniczy, gdy to mówię, ale praca na aplikacji internetowej, która to robi, nienawidzę tego. Jedynym powodem, dla którego jest to nawet opłacalne, jest to, że klienci są tylko IE6+. Nawet wtedy, są z tym problemy. Uważam, że XSLT jest bardzo trudne i sugerowałbym, jeśli masz zamiar to zrobić, aby uzyskać dobre narzędzie do debugowania i edycji XSLT. Dlaczego nie użyć JSON i jquery? Musi bardziej standardowe i mniej zmienności po stronie klienta.