将XML发送到浏览器并让它们应用XSLT有什么缺点？
语境 作为自由开发人员，我经常使网站完全基于XSLT。换句话说，在每次请求时，都会生成一个XML文件，其中包含我们需要了解的有关页面内容的所有信息：当前登录的用户名，顶部菜单项（如果此菜单是动态/可配置的），文本显示在页面的特定区域等。然后XSL将其处理（缓存等）到HTML / XHTML页面以发送到浏览器。 这样做的好处是可以简化创建小型网站的工作，尤其是使用PHP。它是一种模板引擎，但是我比其他模板引擎更喜欢它，因为它比大多数模板引擎要强大得多，并且因为我对此更加了解并且喜欢它。如果需要，还可以根据需要提供对原始XML数据的访问权，以进行自动访问，而无需创建单独的API。 当然，它将在任何中型或大型网站上完全失败，因为即使使用良好的缓存技术，XSL仍会降低网站的整体性能，并需要更多的CPU服务器端。 题 现代浏览器具有获取XML文件并用XML声明的关联XSL文件（如）转换的能力<?xml-stylesheet href="demo.xslt" type="text/xsl"?>。Firefox 3可以做到。Internet Explorer 8也可以做到。 这意味着可以将50％的用户的XSL处理从服务器迁移到客户端（根据我可能要实现此目的的多个网站上的浏览器统计信息）。这意味着，这50％的用户在每次请求时将仅接收XML文件，从而减少了其和服务器的带宽（XML文件比其处理的HTML模拟物短得多），并减少了服务器的CPU使用率。 这种技术的缺点是什么？ 我考虑了几个，但不适用于这种情况： 实施困难，并且需要根据浏览器请求选择何时发送原始XML，以及何时将其转换为HTML。显然，该系统不会比实际系统困难得多。唯一要做的更改是将XSL文件链接添加到每个XML，并添加浏览器检查。 IO和带宽使用更多，因为XSLT文件将由浏览器下载，而不是由服务器缓存。我认为这不会有问题，因为XSLT文件将由浏览器缓存（例如图像，CSS或JavaScript文件实际上已缓存）。 可能是客户端方面的一些问题，例如在某些浏览器中保存页面时可能出现的问题。 难以调试代码：不可能获得浏览器实际使用的HTML源，因为唯一显示的源是下载的XML。另一方面，我很少去看客户端的HTML代码，在大多数情况下，它是直接不可用的（已删除空格）。