Html 客户端XSLT的当前状态

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

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

我所知道的消极方面包括

• 附加渲染时间
• 未缓存页面加载时需要的其他资产
• 额外的复杂性
• 与服务器端模板技术相比，开发人员的经验要少得多

我感觉到的好处包括

• 在客户端上卸载模板合成
• 缓存卸载到客户端上的公共模板片段
• 文档结构与数据的逻辑分离
• 所有现代浏览器都支持的文档丰富的web标准

最后，虽然我知道不可能预测未来，但我很想知道关于客户端XSLT时代是否会到来的看法。随着对HTML5的兴趣驱使用户升级浏览器和开发人员探索新技术，我急切地想看看会发生什么

提前感谢,

凯西

编辑：

---

对于谷歌如何看待转换后的XML以及它对搜索引擎优化的影响的任何见解都值得赞赏。

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

不过，相信我，我希望它会，我为一家我过去工作过的公司编写了一个解决方案，该公司将XSLT翻译用于所有前端模板。它没有使用客户端翻译，因为这是在2005年，当时仍有很大一部分浏览器不支持客户端XSLT。在使用该系统时，我们遇到的最大问题之一是寻找能够帮助开发该系统的开发人员。当你们找到一个可以使用它的人时，他们会杀掉很多模板，因为XSLT开发和其他模板语言不同

虽然使用XSLT的好处是巨大的（在google上搜索symphony，这是一个利用XSLT作为模板系统的优秀cms），但我认为它在前端开发中并没有占据太多的位置。

我使用客户端XSLT。我在IE6-9、Chrome、Safari和Firefox中没有发现任何差异。XSLT转换发生得非常快。我还没有做过任何速度测量，但与纯HTML版本（即使是第一代iPodtouch）相比，我没有看到任何差异

---

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

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

---

如果一项突破即将到来，它将出现在大型网站上，如：facebook或谷歌。在这些情况下，转移到客户机上的CPU周期将构成一个重要的$$$数字，足以证明雇佣开发人员来解决客户机问题是合理的。我会观察这些玩家，看看是否会发生变化，我可能会在翻译过程中不知怎么迷失方向，但我想SEO问题是主要原因，阻止了很多人使用客户端XSLT

我不知道搜索机器人，它能够解析应用程序/xml而不是普通的html甚至flash

---

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

几年前，我在学校的一个项目中创建了一个XML-XSLT网站，并注意到一个bug：Firefox不支持禁用输出转义

据我所知，暴雪是其中之一 很少有公司使用客户端XSLT 付诸实践（2008年）。还是这样吗 2011年的情况是，还是有更多的人 现在，我们正在探索这项技术 生产

以下是一些例子：

是完全由XSLT客户端站点驱动的，并且多年来一直如此

此商业网站完全由客户端XSLT驱动：

我们已经在浏览器中实现了XQuery:

迈克尔·凯（Michael Kay）已经在博客上发表了他试图制作的作品，很快就会有效果

---

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

您写道：我会说是的。你呢？这可以被认为是主观的和有争议的。如果你想要一个“今日更新”的答案，你应该在这一点上加上一个悬赏亚历杭德罗——我已经消除了我的个人想法，因为它们记录在你的评论中：）我看到了你链接的那篇文章（我在创建自己的评论之前发表了一些评论），但我不知道我可以为其他人的问题提供悬赏，或者已经有了公认答案的问题。下次我会考虑这个办法。谢谢好问题，+1。有关事实和最新发展，请参见我的答案。：）谢谢你的想法，也谢谢你指出暴雪带来的新鲜感——很高兴我戒掉了魔兽世界的瘾。我真的很想知道他们为什么会偏离它；太遗憾了，他们没有开发bl