JavaScript何时应生成HTML？

我尝试从JavaScript生成尽可能少的HTML。相反，我更愿意在可能的情况下操纵现有的标记，并且仅在需要动态插入不适合使用Ajax的元素时才生成HTML。我相信，由于标记更易于阅读和跟踪，因此可以更轻松地维护代码并快速对其进行更改。我的经验法则是：HTML用于文档结构，CSS用于表示，JavaScript用于行为。

但是，我已经看到了许多生成HTML堆的JS代码，包括整个表单和内容繁多的模式对话框。通常，哪种方法被认为是最佳实践？在什么情况下应使用JavaScript生成HTML，何时不使用HTML？

每当我在javascript中遇到大量HTML生成时，它几乎完全是在独立的UI插件中。这很有意义，因为它允许将整个插件封装在单个.js文件中（+ .css来定制样式），从而使其易于重用，分发并独立于应用程序中使用的框架。

因此，如果您要编写一个独立的javascript插件或一个通用的UI组件，并希望在不同的应用程序中使用它，那么这种方法就有其优势。否则，当您使html生成远离javascript和在服务器端时，我认为它既更干净，更易于编写，也更易于维护。

我认为问题在于，您正在将写得很好的服务器端模板与写得不好的临时客户端HTML生成进行比较。当然，编写清晰的代码更易于阅读，维护和跟踪。

您称客户端代码为“ HTML之堆”，但是无论生成何处，它都是相同的HTML。“土堆”确实是一大堆代码。

那里有很多客户端模板库。它们的工作方式与服务器端的类似。至于您应该首选的性能折衷比较复杂，但是JSON通常比它变成的HTML更紧凑，并且在客户端上具有模板可以消除一些服务器调用。另一方面，客户端可能禁用了JS，或者太慢而无法实用，因此它也取决于您的目标受众。总的来说，我认为这些方法具有相当的可比性，其中最大的因素是目标受众的浏览器功能。

但这取决于您正在执行的操作，是否在服务器环境中首选JS，首选的模板解决方案等。

有使用客户端模板的趋势，在极端情况下，您需要服务器在提供所有客户端渲染的同时仅提供RESTful API（例如JSON格式）。这种方法的优势在于，JS代码和模板是静态资源，可以通过CDN进行缓存，代理和分发。如果您具有服务器端生成的动态HTML，则无法完成。此外，仅以轻量级格式从RESTful API返回数据将使用更少的服务器端资源，从而加快响​​应速度。而且重量更轻，网络传输更少，这又使其更快。这样，即使在3G之类的连接速度较慢的情况下，您也可以具有响应迅速的低延迟应用程序。因此，这种方法在移动页面和应用程序中很流行。

有执行JS模板众多的图书馆，流行的一个是纯粹的， 胡子和dust.js。后来被LinkedIn使用，他们在文章“将JSP抛在脑后：将LinkedIn迁移到dust.js客户端模板”中描述了优点。

在客户端上生成HTML的好处是，您可以将渲染工作分担给每个客户端，而客户端通常等待响应。释放更多服务器资源以仅交付JSON数据和静态内容（HTML，JS和CSS）。

我们制作了一个网络应用程序，专门使用Javascript生成HTML。服务器命中的87％是JSON数据，静态内容通常会加载一次，然后再从浏览器缓存中加载。

但是，如果您需要SEO，就不能使用它-至少不容易-至少不容易。或者，如果您的目标人群是禁用了Javascript的人群，但我不确定这是否与Youtube，Twitter，Facebook，Gmail等相关，...自然会迫使人们启用它。

关于动态页面加载，应该意识到在所有“ JQuery AJAX云！”背后。魔术，只有两种可能发生的事情：

1. 元素的代码正在div中插入（错误），或者
2. 内容正在iframe中加载（更好，但这并不相同...）

关于原始问题，只有在创建某种类型的Web应用程序来读取存储在服务器上的XML或JSON数据的Web应用程序时，我才会通过Javascript创建HTML内容。

使用Java脚本将静态内容加载到页面上并没有多大意义，因为总是有可能无法正确加载，否则客户端将其禁用（“讨厌的广告！”）。此外，当将HTML内容涂抹在难看的document.write()或一连串的document.createElement()s中时，它真的很难更改。

所以，你是对的。输入原始HTML，或者如果需要动态内容，则使用服务器端脚本输出必要的内容。仅当该网站在没有互联网连接或类似情况下可以正常工作时，才使用Javascript注入HTML。

最后一点，如果您确实想在网站中实现xmlhttprequests或AJAX，则最好/最安全的方法是将数据存储为数据格式（如XML），然后加载并相应地输出在客户端上。document.write而element.innerHTML真的不是去操纵内容的最佳方式，并必将在未来造成潜在的麻烦（为什么不是这个脚本运行？我破碎的<i>标签斜体一切！等）。

我的口头禅是：什么时候更轻松并且没人在乎标记。

您还可以利用这两者并定义一个限制，以至于它太难于关心标记了，而您宁愿关注DOM树。例如，具有动态行的表单（例如“添加另一个附件”），您可能想要HTML形式的表单，“添加行”按钮和“提交”按钮……您可能不想生成带有服务器端语言或其他内容的HTML。

另一个经验法则是可重用性。如果您的解决方案可以应用于客户端的其他问题，请将其封装在js中。

我们构建的是单页应用程序（即Google Mail），实际上我们的应用程序中根本没有服务器端生成的HTML。相反，我们使用Backbone.js构造客户端，使用Handlebars将JSON呈现到进入页面的模板中。它确实运行良好，我们即将使用它的第一个应用程序即将结束，将来我们将处理更大的项目。

任何一种仅用于服务器持久存储数据并返回查询结果的胖客户端都是您希望JavaScript生成HTML的时期的典型子代。只需确保使用良好的模板引擎即可使其变得简单易用。

我正在jquery中生成html代码，因为我正在使用portlet，并且在执行jsp代码后，我需要使用html代码进行循环，而无法在其中包含一些javascript代码的java for循环中进行操作。所以我在一个JavaScript数组中呈现Java arraylist，并使用字符串生成html。