javascript - 为什么分离 JavaScript 和 HTML 是一种好的做法？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.


7年前关闭。







Improve this question




我一直在阅读有关 JavaScript 的一些好的做法，其中之一是 Unobtrusive JavaScript .第一点引起了我的注意

Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation

在 wiki 页面上，示例之一是您应该将操作绑定(bind)到 JS 文件而不是 HTML 中的事件。这个例子

<input type="text" name="date" id="date" />
...
window.onload = function() {
    document.getElementById('date').onchange = validateDate;
};

被青睐

<input type="text" name="date" onchange="validateDate()" />

但是，我会说我更喜欢带有 onchange 的第二个代码。属性超过第一个。我这样做的原因是

它易于阅读并立即清楚该元素的更改(或任何其他事件)会发生什么。

我不必浏览 JavaScript 文件并查看 onchange 的位置(以及是否)事件是否绑定(bind)以及是否还有其他一些事件，例如 click为 #date 定义.

AngularJS 等框架有 ng-click并且正在将 HTML 结构与 JS 混合。为什么我不应该？

我读过的不使用不显眼的javascript的缺点是

污染全局命名空间。

创建长且不可读的内联代码。

如果事件的代码发生更改，您只需在一个地方更改它 - 即在 JS 文件中。

但我认为缺点是可以解决的。

不要污染命名空间，而是在一个变量中创建应用程序，使代码看起来像 onchange="app.validateDate()"并且不会发生污染。

内联代码不会被写入，而是在 JS 文件中的一个函数中分离，然后它会被称为 onclick="app.action();" .

是不是和onclick中使用函数一样？属性？因为最后你必须在两种方法中的一个函数中进行更改，无论它是 $('input').change(function () {/* ... change ... */});或 app.action = function () {/* ... change ... */} .

那么它实际上仍然被认为是一种好的做法吗？

Answer 1

这是一个非常广泛的主题，并且很大程度上基于意见。每件事都没有一个答案。但是，这里有一些观察:

无论你做什么，你都在污染命名空间。 app.validateDate就像 validateDate 一样污染命名空间确实如此，只是因为需要有一个全局可访问的函数名。在复杂的现代网站中，有大量脚本争夺全局名称。理想情况下，您永远不会在全局范围内公开任何名称，甚至不会公开命名空间名称。

.onclick = handler也不是很好。你会想要:

document.getElementById('date').addEventListener('change', function () { .. });

这更不显眼，并允许多个脚本将事件监听器绑定(bind)到同一个元素。同样，在复杂的现代站点中，您可以拥有的最高优先级之一是确保没有人踩到其他人的脚。您永远不知道还有谁可能对 change 感兴趣将来发生该元素的事件。

与其他地方相比，内联编写它仍然需要更多的代码。更长的 HTML 代码。 HTML 可能已经非常冗长了。任何你可以移动到其他地方的东西。减少任何特定文件中的代码量本身就是一门艺术，对可读性很重要。是的，它“只是多了一个属性”......在所有其他属性和元素以及您也没有避免的内联声明之上。它只是堆积起来，这就是代码变得困惑、不可读和不可维护的原因。

可重用性:document.getElementById(..).addEventListener可以在外部文件中编写一次，并在许多不同的页面中自动重用。 <.. onclick="..">每次都需要重复写入。干燥你的代码。

对于小型项目，它通常并不重要。但同样，网站变得越来越复杂。业务需求需要不断变化。只需再添加一个分析脚本，再添加一个基于 Javascript 的社交小部件，现在将其全部改回，现在保持所有版本的依赖项同步，现在再次将其全部删除，并为下周发布的 2.0 重新设计。与其他 10 个人并行完成所有工作，而无需在每次构建时都互相攻击代码，也无需长时间解决 git-merge 冲突。在这样的环境中，每一点解耦、间接和灵 active 都会有所帮助。

既然你提到了 Angular:

Angular 通过使用完全不同的模板解析模型避免了其中的一些问题。当你写 onclick=foo ，那么你需要绑定(bind)一个全局函数名。然而，当 Angular 执行 ng-click=foo , foo是 ng 范围内的本地范围实体。这不是一个全局名称。 Angular 将 Controller 和 View 分开， Controller 本质上在 $scope 上公开了特定的 API。 View 可以使用的对象；只要保持指定的 API 契约， Controller 和 View 仍然可以互换(意味着只要 $scope 对象保持相同的属性)。

全部 ng指令根据自定义范围和评估引擎进行评估，该引擎与 Javascript 的默认操作方式没有太大关系。