侵入性JavaScript可以吗？

我当时在想，如果要求网站的所有用户都启用JavaScript，那么使用干扰性JavaScript可以吗？

我全力支持渐进式增强，但是如果高级Web应用程序禁用了旧的浏览器或JavaScript，那么当用户反弹时又有什么意义呢？

我们的目标受众非常渺茫，我们可以告诉目标受众他们需要具备哪些浏览器和插件/功能。所以我的问题是，在这种情况下，是否可以混合使用JS和HTML？就像使用onclick属性一样。

这是业务决策，而不是设计决策。

提供不使用JavaScript（或Flash或Silverlight）的网站版本是有代价的。该企业有权决定收入/人次的损失是否值得与否。

因此，如果编写此版本的成本为10,000美元（数字可能很大，但仅在此示例中存在），那么企业会在网站的整个生命周期内收回这笔费用吗？如果没有，则不要提供该版本。

但是，如果编写此版本仅花费$ 100，则可以合理地进行降级。

做出业务决策后，仅将目标对准了启用JavaScript的浏览器，并期望您的用户将启用JavaScript，那么使您的应用程序充分利用您现在可用的那些功能就非常有意义。您唯一需要做的是（就像Stack Overflow本身一样）被警告，如果用户未启用该站点，该站点将无法正常运行。

到目前为止还没有其他人提出……

99％的网站欢迎特定的访问者，其中几乎没有JavaScript。该访问者的名字为：Googlebot。

_{每个人都应该关心盲人游客的一个重要原因也是……}

如果您是完全不关心搜索引擎流量的极少数人之一，那是您的特权-但这当然并不构成一般规则。

人们为特定的内部环境编写东西是IE6仍然存在的重要原因。

考虑一下

如果您是在仅使用JS的网站（在这种情况下，“应用程序”也许是一个更好的词），那么当您需要从容地降级为非JS版本。

但是：以不引人注目的方式编写的JavaScript通常更易于编写（并且至少我以这种方式找到）并易于维护。将不破坏JS的HTML布局更改引入到JS中，而不必担心破坏HTML的更改会更容易。

如果您要建立一个网站，我将保持JavaScript的吸引力。但是，如果您要构建某种形式的应用程序（例如Google Docs），则JavaScript会很麻烦。

如果需要，JavaScript和HTML5非常适合构建应用程序，但这确实是一种商业选择。

大多数用户（我的用户，我不知道您的用户）都已启用并启用了JavaScript。让我们为这些用户带来出色的用户体验。但是，您仍然需要提供不使用Javascript即可运行的网站版本。我知道构建2个版本很麻烦，但这就是Web开发的方式。（实际上，您可能必须构建多个版本，第三个可能是网站的移动版本）。

您不希望做的是使用最小公分母进行设计：“好吧，有些用户禁用了Javascript，因此我们将设计我们的网站以使其对他们正常工作-没有Javascript，所有东西都击中了服务器。” 这只会对大多数拥有Javascript的用户造成不利影响。

您提到使用onlick属性。您是否打算使用JavaScript事件处理程序进行页面导航？

我建议这样做的原因有一个：中断中间点击。

对于常规的链接单击，假设启用了JavaScript，则它们在功能上等效：

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

如果尝试单击第一个示例，将获得空白页，而不是myPage.htm。

除了该示例之外，如果对您来说有意义，我认为可以使用侵入性JavaScript。编写（但不必维护）内联JavaScript所需的时间更少，并且渐进增强功能的丧失在您所处的情况中可能并不重要。

生硬的JavaScript 是好10年前。如果您是业余爱好者，或者正在构建一个废弃的原型，或者有某种情况需要它，例如依赖于遗留代码或数据驱动的代码，而且这只是简单的花费方式，那也没关系。太多无法修复

如果您要从头开始构建某些东西，请遵循标准，编写良好，干净，可维护的代码。写一些让您感到自豪的东西，一年后，当一些糟糕的施密克因为不了解您所做的黑客工作而向您求助时，您就不会感到不适。编写一些内容，以确保您的Web设计人员可以轻松地换出CSS，而不必通过混乱的HTML和JavaScript挖掘自己的方式。

构建应用程序，使其具有增长的空间，以便任何开发人员都可以进入并维护它。现在投入的时间可以节省将来的时间，如果不是您的时间，那么可以节省别人的时间。

确保可以在其他上下文中重用JavaScript。确保完整的网站重新设计可以仅仅是重新设计，而不是对已经存在但并非很难构建的内容进行完全重新设计。

想象一下，与原先进行设计时一样，在重新设计上花费相同的时间会是多么令人尴尬的事情。

凭经验相信我，Unobtrusive JavaScript将防止您犯一些代价高昂的错误。

好吧，在我做的所有坏事上都叫我“地穴守护者”，但我从未真正理解过它的真正价值。从历史上可以断言，“不引人注目的JavaScript”，或者通过尽可能不链接到文件的内联HTML事件处理程序属性和脚本标签使JS不受HTML的影响是一个巨大的关键要素：

• 无障碍问题
• 搜索引擎优化
• 并逐步增强

谎言！（好吧，现在他们会）

事实的真相是，您可以使用技术上令人讨厌的JavaScript，但仍然可以完成上述三项工作。除非您动态地构建HTML内容，否则这在当今是一个很大的SEO。

但是停下来想一想...关于您！

确实，维持分离的最大好处，最大也是最不足的一向是开发者从中获得的直接好处。您可以在方便的情况下，在同一事件的同一html元素上设置任意数量的事件处理程序。这意味着，如果一个标签class="some_class"始终在id="bonus_behavior"div 内时具有某种特定行为，但同时也具有一些额外的行为，那么我们就不必开始迷惑我们允许的事件处理程序中的逻辑以进行分支了。我们可以根据上下文添加或不添加处理程序。

太容易阅读

另一个好处是可读性。当浏览器工具包含IE专有的错误消息（告诉您[object]IMO 出了点问题）时，这是一个更为关键的问题，但这仍然很重要。这里是CSS，那里是JS，HTML是服务器和服务器相遇的地方。将所有这些东西放在一个地方，依靠钩子（ID，类和层次结构）来创建一层抽象层，所有东西都用于连接到HTML是很有意义的。

IMO，您可以将HTML，CSS和JS分开的越多，不仅阅读而且修改和了解正在发生的事情也变得更加容易。我看到一个空的div类，其中包含“ dynamic_combo_box”，并且我有一个很好的主意是正在做一些精美的选择来动态加载数据。我将领导如何在JS和CSS中找到它们，如果遇到这些问题，我将很好地了解它的含义以及如何在HTML中找到它。

太容易使马虎

当然，易读性往往与可维护性息息相关。当您直接通过将所有内容都直接转储到相关HTML所在的脚本标签中直接执行操作时，人们可以更轻松地将脚本剪切并粘贴到他们正在处理的另一页的HTML中。他们想要类似的功能，这意味着您现在拥有一件事，最终很可能会变成两个令人讨厌的相似但并非100％相似的事物，这些事物的行为可能会因违反期望而随着时间的流逝而出现问题，并且需要添加更多无意义的分支来处理一个需要满足的异常另一个没有。

因此，将行为绑定到这些HTML挂钩会鼓励以聪明的方式重用代码。如果需要分支行为以实现替代实现，则只需转到相同的函数并使用HTML层次结构处理该函数，或者通过数据属性触发某些替代行为即可。对于任何想了解某种类型的UI元素如何工作的人来说，这都是一站式购物，而那些似乎很懒惰的剪切和粘贴类型将做正确/更易维护的事情，只是因为这是最简单的事情。现在就做，这是实现可维护性的最佳方法。即使对于那些由于恐慌或冷漠而不在乎的人，也要使其成为最简单的“ duh”操作。

但是2014年呢？

在现代单页应用程序中，其中一些棘手的事情可能不应该像过去那样被教条式地固定，但是当我说我不认为我是唯一的一个人时，请相信我，这可能是一个合法的观点。之所以被出售是因为它最终使工作变得更容易。我很懒（我希望）是个好方法。当我只需要在一个地方更改事物以在整个应用程序中进行更改时，当我只需要查看一个地方找出错误所在以及轻松地了解到底是什么时，我就喜欢上它。以及如何最好地重用该代码来完成非常相似的操作。

就像拆分数据库或数据层一样好。最终，这就是为什么我不花时间去节省时间，例如前一天晚上花五分钟去洗衣服，而不是第二天早上花10分钟时间让拳击手轻轻松松地进行偏执气味检查。

对我来说，正是那些自私的动机一直是为什么我不仅坚持不引人注目的JS还是要坚持风格/行为/内容关注的分离的主要观点，即使WHAT-freaking-WG尽其所能以令人敬畏的，酷的/方便的方式来混淆这些问题。

既然每个人都在执行SPA，并且几乎要说服业务我们要关心那些不使用JS的人（现在可以使用JS生成的内容来处理可访问性），这简直是愚蠢的事情，似乎下一代JS开发人员就不在乎关于这一点，但IMO仍然有一个胜利，这主要是给您的，开发人员编写和维护这些东西。实际上，获胜本来应该一直是最强调的点，但由于某种原因从未如此，因为通过更轻松的调整/修改/调试，它最终使您以及最终产品受益于偶然的意外。

可以吗？

好吧，我猜。在用于比赛或其他事情的一次性应用中。但是我仍然会这样做，只是因为我已经习惯了，实际上并不难做。

如果您知道目标操作环境，那么Javascript和类似jQuery的框架可能是真正的天赐之物。例如，在SOE具有Javascript和IE8的企业环境中，它比编写密集的客户端浏览器应用程序更安全。

使宽容降级更容易只是众多因素之一，这些因素使不引人注意的JavaScript成为有吸引力的选择，而且我认为这并不是最重要的选择。

从个人经验来看，我想说的是，如果您谈论的是一个更大的项目，这个项目可能会随着时间的流逝而发生很大的变化，那么使用通俗易懂的样式将使该应用程序更易于维护，调试和重构。这就是为什么即使在要求为所有访问者启用JavaScript的网站上，我们也始终使用低调风格的最大原因。

通常，如果您要开发一个传统的“网站”，该网站可以匿名使用，由搜索引擎建立索引并且可以通过广告产生收入，则应提供适当的降级功能。这种网站的想法是通过可访问性生存和死亡，因此限制可访问性意味着损失大量的页面浏览量，从而损失广告收入。

受限制的访问（通常是不可索引的和基于非收入的“站点”（Web应用程序））可以更加灵活。这取决于支持范围，功能深度和开发成本之间的决定。可以将其视为开发传统应用程序：您支持什么平台，最低规格是多少？如果您仅针对一个平台和有限的规格，则可以专注于以降低的潜在市场份额为代价，以较少的开发和支持成本提供优质产品。

示例：Google搜索是一个网站。Google文档是一个网络应用程序。Google搜索没有多余的装饰，并且在没有JavaScript，CSS和/或图像等的情况下也可以完全相同...-它在文本模式浏览器中的工作方式与在最新的GUI浏览器中一样。Google文档在禁用JavaScript的情况下根本无法使用，甚至无法正常降级-甚至没有启用JavaScript的警告。

我更喜欢用CSS处理大多数布局和导航。是的，Lynx可能不支持它，但是我所知道的所有功能齐全的浏览器都无法将其关闭。然后，可以将JavaScript用于更华丽的内容，而不是必需的内容。为此，我也喜欢Ruby on Rails。只要您不需要动态页面更新，它就可以完成服务器端JavaScript所需的很多工作。

更针对该问题的答案：我不喜欢JavaScript，但正如ChrisF所指出的，有一个商业案例需要JavaScript。

当涉及到客户端交付的任何动态内容时，Javascript是Defido标准，如果他们没有JS，那么他们可能就不会拥有Silverlight。

然后，您必须考虑一下您的市场/受众群体，您是Programmer.stackexchcange还是bbc.co.uk/news？截然不同的观众。

由于您可以在网上浏览并在许多站点上看到“令人讨厌的javascript”，因此可以回答您的基本问题，是的，可以，许多受欢迎的站点都可以使用，甚至包括Google。

然而，更重要的是功能的正常降级，即使您坚持要让用户启​​用Java脚本，也必须为非js用户提供良好的体验，否则他们将永远不会回来。