asp.net - 在服务器端呈现 javascript。好主意还是坏主意？

Question

现在是社区 Wiki!

我想先说清楚:这不是与服务器端 Javascript 或运行 Javascript 服务器端有关的问题。这是一个关于从服务器端代码呈现 Javascript 代码(将在客户端执行)的问题。

话虽如此，请看下面的 ASP.net 代码示例:

hlRemoveCategory.Attributes.Add("onclick", "return confirm('Are you sure you want to delete this?');")

这是在服务器端指定客户端 onclick 事件。

反对在客户端编写 Javascript:

$('a[rel=remove]').bind('click', function(event) {
    return confirm('Are you sure you want to delete this?');
}

现在我想问的问题是:从服务器端代码渲染 javascript 有什么好处？或者反之亦然？

我个人更喜欢将客户端 UI/行为连接到 HTML 元素的第二种方式，原因如下:

• 服务器端已经完成了它需要做的一切，包括数据验证、事件委托(delegate)等；和
• 服务器端视为事件的过程在客户端不一定是相同的过程。也就是说，客户端有更多的事件(只看自定义事件)；和
• 在事件发生期间，客户端和服务器端发生的事情可能完全无关和分离；和
• 客户端发生的事情发生在客户端，服务器不需要知道。服务器应该处理和运行给他们的东西，如果发生客户端事件，这个过程如何实现并不真正取决于他们的决定；等等。

这些显然是我的想法。我想知道其他人是怎么想的，是否有关于这个话题的讨论。

从这个论点分支出来的话题可以到达:

• 代码管理:从服务器端呈现所有内容是否更容易？
• 关注点分离:如果将客户端逻辑与服务器端逻辑分离，是否会更容易？
• 效率:编码和运行哪个更高效？

在一天结束的时候，我试图让我的团队转向第二种方法。这支球队中有很多老家伙害怕这种变化。我只是想用正确的事实和统计数据来说服他们。

让我知道你的想法。

更新 1: 看来我们所有参与这篇文章的人都有共同的想法；很高兴知道还有其他人的想法相似。现在去说服大家 ;) 谢谢大家。

Answer 1

您的第二个示例远远优于第一个示例。 Javascript 是您的行为层，应该与您的语义标记(内容)和 CSS(表示)分开。这是更好的架构的原因有很多:

• 鼓励渐进增强。正如您提到的，后端代码在没有 JS 的情况下应该可以正常工作。你不能依赖你的客户有可用的 JS。这样你就可以在没有 JS 的情况下构建它一次，然后可以增强那些使用 JS 的人的体验(例如，通过添加客户端验证和服务器端验证，以便客户端可以获得即时反馈)
• 更清晰的标记。通常减少下载大小。一个单独的 JS 文件中的可重用选择器，可以在页面之间缓存和共享，而不是每个元素上的处理程序。
• 您所有的 JS 都集中在一个可重复使用的地方。例如如果您的代码正在打开一个弹出窗口，并且您决定更改窗口的尺寸，您将在 JS 文件的代码中更改一次，而不是必须在每个单独的内联处理程序上更改它。

还有很多其他的论点和理由，但它们应该让你开始......

此外，从您的示例来看，您的文档中似乎有一个可以删除内容的正常链接。这也是一种不好的做法。任何删除或更新内容的操作都应该在 POST(而不是 GET)请求上完成。所以应该是提交表单的结果。否则例如googlebot 可能会通过抓取您的页面而意外删除您的所有内容(搜索引擎机器人不执行 JS，因此您的警报无济于事)