客户端 XSLT 的当前状态答案

【问题标题】：Current state of client-side XSLT客户端 XSLT 的当前状态
【发布时间】：2011-06-03 13:53:50
【问题描述】：

我上次听说，暴雪是少数几家将客户端 XSLT 付诸实践的公司之一（2008 年）。 2011 年仍然如此，还是现在有更多的人在生产中探索这种技术？

现代浏览器（IE9、FF4、Chrome）和客户端处理能力似乎已准备好利用此标准在大规模属性上显着节省服务器 CPU 功率和带宽。我错过了什么吗？

我知道的负面影响包括

额外的渲染时间
非缓存页面加载需要额外的资源
额外的复杂性层
开发人员的经验明显少于服务器端模板技术

我认为的好处包括

在客户端卸载模板组合
缓存在客户端卸载的常见模板片段
文档结构和数据的逻辑分离
所有现代浏览器都支持文档完善的网络标准

最后，虽然我知道无法预测未来，但我很想知道关于客户端 XSLT 的日子是否会到来的意见。由于对 HTML5 的兴趣促使用户升级他们的浏览器和开发人员探索新技术，我很想看看会发生什么。

提前致谢，

凯西

编辑：

对于 Google 如何看待转换后的 XML 以及它对 SEO 的影响的任何见解，我们也很感激。

【问题讨论】：

你写道：我会说是的。你呢？ 这可以被认为是主观的和争论的。如果今天想要stackoverflow.com/questions/274290/… 的答案，您应该为此添加赏金
好点亚历杭德罗——我已经消除了我的个人想法，因为它们记录在你的评论中:) 我看过你链接的那篇文章（我在创建自己的之前发布了一些 cmets）但是我不知道我可以为其他人的问题或已经接受答案的问题开始赏金。下次我会考虑这种方法。谢谢！
好问题，+1。有关事实和最新发展，请参阅我的答案。 :)

标签： html xml xslt

【解决方案1】：

我在 kulesh.info 上使用客户端 XSLT。我在 IE 6-9、Chrome、Safari 和 Firefox 中没有发现任何差异。 XSLT 转换发生得非常快。我没有进行任何速度测量，但与纯 HTML 版本相比我没有发现任何差异（即使在第一代 iPod Touch 上也是如此）。

mail.yandex.ru（俄罗斯的大型邮件提供商）也在客户端使用 XSLT。

【讨论】：

【解决方案2】：

我上次听说，暴雪是其中之一很少有公司将客户端 XSLT 付诸实践（2008 年）。这还是 2011年的情况，还是更多的人现在正在探索这项技术生产？

这里有一些例子：

Jenni Tennison's site 完全由 XSLT 客户端站点驱动，并且多年来一直如此。
此商业网站完全由客户端 XSLT 驱动：http://www.skechers.com/
我们已经在浏览器中实现了 XQuery：XQIB
Michael Kay 在博客中谈到了他制作XSLT 2.0 in the browser的尝试，很快就会有一些工作。

有些人认为 XSLT 不是为“大型编程”而设计的——例如，它缺乏任何单独的编译功能。让我们希望即将到来的 XSLT 3.0 能够改变这一点。

【讨论】：

【解决方案3】：

我可能不知何故在翻译中迷失了方向，但我想 SEO 问题是主要原因，阻止了很多人使用客户端 XSLT。

我不知道搜索机器人能够解析 application/xml 而不是普通的 html 甚至是 flash。

对于高负载的 Web 应用程序来说，在客户端部分使用 XSLT 仍然是一种很好的做法（mail.yandex.ru 确实是一个值得注意的例子），因为流量很大并且不需要对 SEO 友好。

【讨论】：

有趣，我认为 Google 转换了 XML。如果不是这种情况，那么这是一个非首发
我很想从熟悉搜索系统的人那里看到更多信息。我的担忧可能不是最新的。
别忘了谷歌并不是唯一的。在许多国家，它甚至没有领先的市场份额。
哪些国家？根据这个网站，谷歌无处不在：gs.statcounter.com/#search_engine-ww-monthly-200912-201012
尚未查看这些特定统计数据，但您应该算上中国、俄罗斯、韩国等等。

【解决方案4】：

Web 上 XSLT 的问题在于，有很多其他的东西可以用来代替它，这对开发人员来说更容易。我从来没有真正看到 XSLT 以您所描述的形式在网络上占据一席之地，事实上，我相信暴雪在最近进行了一些重新设计以巩固他们的品牌时，实际上从他们的网站上撤下了客户端 XSLT 翻译。

相信我，我希望如此，我为我过去工作过的一家公司编写了一个解决方案，该公司的所有前端模板都使用 XSLT 翻译。它没有使用客户端翻译，因为那是在 2005 年，当时仍然有很大的市场份额不支持客户端 XSLT 的浏览器。我们在使用该系统时遇到的最大问题之一是寻找可以帮助开发它的开发人员。当您找到可以使用它的人时，他们会大量使用模板，因为 XSLT 开发与现有的任何其他模板语言不同。

虽然使用 XSLT 的好处是巨大的（在 google 上搜索 symphony，一个使用 xslt 作为模板系统的优秀 cms），但我不认为它在前端开发中占据了更多的份额。

【讨论】：

感谢您的想法，并指出暴雪的更新——很高兴我摆脱了对魔兽世界的沉迷。我真的很想知道他们为什么会偏离它；太糟糕了，他们没有开发博客。我看过 Symphony CMS，这似乎是一个好主意——如果/当客户端 XSLT 确实变得可取时，您将准备好进行无痛切换。

【解决方案5】：

在决定 XSLT 的使用时，通常归结为开发人员的时间成本与 CPU 周期的感知收益。对于一个小客户来说，它几乎普遍意味着：XSLT，如果存在的话，就在服务器端。找出所有客户问题根本没有足够的好处。

如果即将出现突破，它将出现在大型网站上，例如：facebook 或 google。在这些方面，卸载给客户端的 CPU 周期将构成一个可观的 $$$ 数字，足以证明聘请开发人员来解决客户端问题是合理的。我会观察那些球员，看看是否会发生变化

【讨论】：

是的，大鱼肯定会推动这种变化——想想维基百科这样的网站的好处。我想我的部分问题是——是什么阻止了主要参与者今天这样做？
@Casey：我不知道......我想这是同样古老的“足够好”的方法。收益可能不会显着超过成本。

【解决方案6】：

几年前，我为学校的一个项目创建了一个 XML - XSLT 网站，发现了一个错误：Firefox 不支持禁用输出转义。

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

【讨论】：

是的。最近讨论过stackoverflow.com/questions/4492303/…。 AFAIR，这并不是一个真正的错误，因为 DOE 支持对于实施者来说不是强制性的。
@Flack：你是对的，这不是错误。他们没有实现 XPath namespace axe...但是对于真正的生产样式表来说这应该不是问题。
@Alejandro，他们是否以某种方式解释了命名空间轴的缺失？因为这在我看来是个错误。
@Flack：在 XSLT 1.0 和 XSLT 2.0 之间，W3C 已就弃用 namespace axe 达成共识。
@Alejandro，谢谢，我不知道。我完全陷入了 1.0 的世界:(