当一项任务无法通过任何其他技术完成时，你就知道应该使用 JavaScript 了。
当我向 Doug 询问我脑海中某个想法的更优雅表达方式时，他提出了这个建议。
JavaScript：如果它**可以**用其他语言完成，那么它**就应该**用其他语言完成。
这句话听起来很**消极**，这绝对不是我想要表达的意思。但我想强调一个观点。JavaScript 能够完成其他语言也能完成的任务。JavaScript 也能够完成其他任何语言都**无法**完成的事情。一些例子可能是有序的。
表单验证
您可以使用 JavaScript 来验证表单。通过这种方式，您可以创造出很棒的用户体验，但当然，在处理表单数据之前，您不应该忘记再次使用服务器端语言验证所有输入。如果您必须二选一，请选择服务器端。**如果它可以用其他语言完成，请使用其他语言。**
插入内容
我最近遇到一个情况，需要将一段动态导航加载到由 CMS 创建的网站主页上，该主页位于网站的子目录中。理想情况下，此导航将在一个文件中创建，该文件可以在主页和其他需要它的任何地方进行服务器端包含。长话短说，我无法实现它。相反，我使用了 jQuery 的 load 函数来获取该代码块。效果很好，除非您不使用/无法使用 JavaScript。**如果它可以用其他语言完成，请使用其他语言。**
同样，AJAX 的整个概念通常被认为是一种变通方法。它是在为单向传递而构建的技术中模拟双向通信的一种方式。当出现更自然地适应浏览器与服务器之间双向通信的新技术时，AJAX 就消失了。**如果它可以用其他语言完成，请使用其他语言。**
样式
JavaScript 能够将样式应用于页面上的元素。这也是 CSS 的工作。在 JavaScript 中包含大量的样式信息会使代码变得混乱。它使 JavaScript 更难阅读，并且样式更新更难以跟踪。**如果它可以用其他语言完成，请使用其他语言。**
JavaScript 库流行的主要原因之一是它们开辟了一些很棒的设计可能性。您可以淡入淡出元素、动画大小和位置，并以流畅和时尚的方式实现。但这些都是与设计相关的，而不是（通常）与功能相关的。因此，我们看到 CSS 开始适应做这些完全相同的事情。我认为 CSS 是适合此目的的地方，而不是 JavaScript 库使用的某种“快速更改 DOM”技术。**如果它可以用其他语言完成，请使用其他语言。**
何时使用
好了，关于“不使用”的情况就说这么多。还有很多其他情况下，使用 JavaScript 是唯一的选择。比如事件？JavaScript 是唯一可用于让您的网站与浏览器通信并监视事件的语言：点击、双击、鼠标进入、鼠标离开、按键、浏览器窗口大小调整……等等。如果您需要访问这些事件，那么您就需要使用 JavaScript 了。
我说的对吗？这是狭隘的想法吗？
不，这绝对不是狭隘的想法。
我的工作方式如下，我的基本设计理念是网站应该在任何情况下都能优雅地降级。
1) 我用 HTML 设计页面。它应该看起来不错、易于访问且逻辑清晰。
2) 我编写所需的 PHP 脚本/功能。
此时，网站应该对所有人完全可用。
3) 我用 CSS 样式化页面。
4) 我编写所需的 JavaScript。
步骤 4 可能会覆盖一些 CSS 或 PHP，但这没关系，因为如果禁用了 JavaScript，它将回退到这些功能。
CSS 也适用同样的原则，如果禁用了 CSS，页面仍然可以查看、阅读和使用。
对我来说，CSS 和 js 中的所有内容都是“额外的糖果”。
我很少偏离这个工作流程（但有时也无法避免）。所以这不是一个硬性规定，但我确实努力遵循它。
“JavaScript 能够将样式应用于页面上的元素。这也是 CSS 的工作。在 JavaScript 中包含大量的样式信息会使代码变得混乱。”
在这里，您是正确的。
但是，当您说
“JavaScript 库流行的主要原因之一是它们开辟了一些很棒的设计可能性。您可以淡入淡出元素、动画大小和位置，并以流畅和时尚的方式实现。”
您不同意
“如果它可以用其他语言完成，请使用其他语言。”
它可能会使代码变得混乱，但如果您想要拥有最前沿的设计，现在确实没有其他方法……
您绝对是对的！
我认为 JavaScript 被过度使用了，并且库通常代码量太大，导致页面下载时间过长。例如，Mootools 是一个重量级的框架，网站访客通常为了一个简单的动画而下载它，而这个动画可以用更简单的方法实现。但是，如果您必须使用 JavaScript，则应将其放在外部文件中，并将杂乱的代码从页面中移除。
“当一项任务无法通过任何其他技术完成时，你就知道应该使用 JavaScript 了。”
我会引用你们的话！
您提出了一些有效的观点，但我将不得不在这里采取不同的立场（尊重地）。
我同意依赖 JavaScript 来执行应用程序的主要操作是错误的做法。
我喜欢使用 JavaScript。我认为它是一种很棒且优秀的语言。如果您以非侵入式的方式使用它，它就会变成一组很棒的工具。（即使是 Ruby on Rails 也利用了一些 JavaScript 来实现其一些内置功能）。
当我想使用 JavaScript 时，我想到的是将其与我的主要代码结合使用。如果用户启用了 JavaScript，它就在那里增强我的网站，而不是执行其主要功能。
客户端验证是为了方便您的用户，让他们不必等待整个页面刷新才能看到他们错过了什么，并且如果您不想让他们丢失数据（或者将状态保存在 .NET 中，这会带来大量开销），您将不得不重新填充他们的字段。
一个很好的例子是在 John Resig 的著作《Pro JavaScript Techniques》中，他描述了一个图像库的设置。图像链接会弹出一个模态窗口以查看图像；但是，对于没有 JavaScript 的用户，页面会优雅地降级。
使用非侵入式 JavaScript，您可以将所有脚本放在一个单独的文件中，这样您的主页就不会变得混乱。使用事件委托，您可以将模态窗口功能附加到所有图像链接。
总而言之，我想说这篇文章很好，您提出了一些很好的观点，但我认为您看待问题的方式是错误的。
只是一位 JavaScript 传道者的两分钱。:P
我不同意这些内容，所以我不确定我们的立场有何不同。
在模态示例中，希望有一个图像的模态弹出窗口。JavaScript 是实现此目的的唯一方法，因此当然需要使用它。当然，使其优雅降级是理想的，但使用 JavaScript 是整个模态概念的必要条件。
嗨，Chris，
不知道你是否看过这个页面，但有人想出了如何在没有 JavaScript 的情况下实现类似灯箱的功能。不过，没有那种漂亮的淡入效果。
感谢你的文章！
这真是太聪明了=)
哎呀，这种技术甚至保留了浏览历史！
我认为“如果可以用另一种语言实现，就使用另一种语言”的说法与优雅降级和马修指出的内容有些冲突。例如，表单验证完全可以在服务器端完成，但目前最好的方法是服务器端和客户端验证。这样，如果启用了 JS，您就可以获得更简洁、更响应式的 UI 的所有好处，同时在 JS 未启用时仍然可以回退到服务器端验证。“如果可能，使用另一种语言”的说法意味着，如果有一种 JS 替代方案可用，您应该始终选择它，然后就结束了。另一方面，优雅降级意味着“使用 JS 增强体验，只需确保在没有 JS 的情况下仍然可以正常工作”。
你应该看看 Stu Nicholls 的 CSS 灯箱
CSS 灯箱.
它在 Safari 或 Chrome 中无法正常工作，但仍然非常令人印象深刻。
我完全同意这篇文章！
另一个需要强调的问题是，程序员经常使用 JavaScript 而没有充分考虑如果 JavaScript 无法运行（例如，用户已关闭 JS）会发生什么。
当 JS 使用不可避免时，这是一回事，但当有替代方案可用时使用它，而不提供回退（尤其是对于正确操作至关重要的功能），这仅仅是不好的设计。
JS 常用操作之一是在新窗口中弹出链接。避免那些难看的 <a href=”#”></a> 链接 演示了一种提供优雅回退的方法。
确实有比 JavaScript 差得多的语言，但其中许多可以用一个好的选项替换（极端的例子：Malbolge）
是的，没错，当您需要时应该使用 JavaScript，但如果您说表单验证可以用 PHP 完成，没错，但对于复杂的表单，您应该同时使用 JavaScript 和 PHP，因为在复杂的表单中，一小段 JavaScript 可以节省您和您的用户的带宽。我说的对吗？
我认为您应该两者都使用，但服务器端是必须的。
@Hitesh：您应该依靠 PHP 来验证表单，但您可以使用 Javascript 使表单更易于使用和更美观（这可能包括另一层客户端验证）。但是我确信您仍然希望即使禁用 javascript 也可以完全验证您的表单，对吧？
我倾向于同意。谢天谢地，你没有进行传教……最近我经常看到人们坚持“用 CSS 做，而不是用 JavaScript！”，并且对此感到非常自以为是。
我个人认为，如果它在使用 JavaScript 的情况下看起来不错并且工作良好，我不介意使用它。我通常会关闭 JavaScript 以查看它是否优雅地降级，但有时我即使在没有 JavaScript 的情况下也会使用它。
在我的个人网站上，我可能会删除很多 JavaScript（它目前正在使用一个滑块，坦率地说，这个滑块没有多大用处）；但在我的公司网站上，如果客户没有启用 JavaScript，他们可能永远不会访问我们的网站——我们制作了由 JavaScript 加载的 Java Applet。;-)
又一票赞成“你没有狭隘”。
在我看来：仅仅因为你可以做到，并不意味着你应该这样做。
还有人记得 Flash 开场动画吗？blink 标签？光标轨迹？
网页应该*始终*首先关注内容。
它们应该始终为那些
– 没有/不想使用 Flash 的人提供一个像样的页面。
– 无法显示图像的人。
– 没有/不想使用 Javascript 的人。
– 无法正确显示 CSS 的人。
我大体上同意上面大多数评论；我只是想指出：并非每个人都同意“非侵入式 JavaScript”可能是什么。
好文章，Chris。我认为，随着 Javascript 库的发展，未能认识到你的前提将成为*更大的*问题。如果我们不建立对每项技术在网站上的位置（CSS/PHP/等）的良好理解，那么用一种语言做所有事情的诱惑力将会很大。
但是，在超级动态的 Web 应用程序中，我认为 JavaScript 可以承担我们传统上放在服务器端语言上的大部分工作量是可以的。话虽如此，解决业务需求的 Web 应用程序与面向大量用户的公共网站之间的区别是巨大的。
您在这里提出的绝对是应该只在非常具体、经过计算的使用案例中打破的规则……而不是相反。
虽然我同意你的前提，但我们需要弄清楚如何教育客户。
由于保密协议，我无法说得那么具体，但我正在构建一个 Web 应用程序，它在最初版本中几乎全部是 PHP 和 MySQL，当然还包裹在一些 HTML 和 CSS 中。我大约有 10 行 javascript 用于一些客户端表单验证。
然后客户开始对设计内容提出具体要求。突然之间，出现了可以点击的按钮、隐藏或显示的内容、各种内容的实时更新……JavaScript 从一个不错的、小巧的文件变成了一个庞然大物（尽管它仍然比加载 jQuery 小）。
如果我用 Ruby 或 Python 编码，我可能会返回并以这种方式编写它，但 PHP/Javascript 的组合正在完成工作。
说如果你有其他选择就不要这样做是好的，对于我能够控制的网站，我不会这样做。我同意你的观点。但在我们教育客户不要要求那些花哨的东西之前，JavaScript 和/或 AJAX 往往是最好的解决方案。
尽管我不喜欢过度复杂化我的代码，但我认为 JavaScript 几乎是每个 Web 项目的必备。除非您试图节省大量时间和金钱，并且用户体验不是首要任务；始终使用 JavaScript。但是请记住，这样做时，您的页面加载速度仍然与没有 JavaScript 时一样快。
不错的文章。在我的工作中，我使用 Javascript 帮助用户确认他们应该做什么（如表单验证），但我始终用 PHP 或我正在使用的任何服务器端语言对其进行备份。对我来说，Javascript 主要用于外观，而不是功能，尤其是安全性。
这可能是一个过于“基本”的陈述，但一个简单的“滑块”可以用 Flash 完成，但我讨厌 Flash，因此在这种情况下，“如果可以用另一种语言完成……”的说法是不可取的。在这里不使用 Flash 是否错误？（如果是这样，我将做错）。
Flash 使用不同的 goto 语句
“不要使用它”。
（也就是说，除非您有超级充分的理由并且没有替代方案。）
哈哈，我喜欢。我完全同意。除非您使用视频或音频，否则我看不到使用 Flash 的很多充分理由。
我不同意。正确使用 Flash 对用户的影响可以是普通 HTML 的一千倍。不仅仅是视频或音频（对于音频，您见过雅虎媒体播放器吗？它完全没有使用 Flash！），还有动画。以及 Web 应用程序！Flex 是我见过的最强大的。
我（以及许多其他精通 Web 的）用户默认会阻止 Flash。在我看来，将其用于任何类型的实际内容都是荒谬的（除了常规用途，例如视频/音频）。我见过一些使用 Flash 进行导航（？！）的网站，不用说，我没有再访问该网站。
我 100% 同意这一点。我有时会在 PowerPC Mac 上工作。它非常适合使用 Photoshop，速度非常快。我的 1.0GHz G4 比我的 2.8GHz 双核 AMD Athlon 运行得更快。我不会解释原因，因为这是一个很长的主题……
但是！PowerPC Mac 的 Flash 播放器非常糟糕。它极其缓慢，而且我访问的任何使用 sIFR 的网站都会导致 Safari 崩溃。
我喜欢人们喜欢 Flash，这很好。我在业余时间是一名 Flex 开发人员，但我确实认为它只适用于利基网站（您 99% 确定目标受众或内部开发）或将其包装在 AIR 中并将其放在桌面上。
如果有适合 JS 的本地替代方案，请使用它。如果您的客户可以使用 Javascript 而不是 Flash，在 90% 的情况下都可以做到，请使用它。
我可以为 Flash 的大多数功能提供 Javascript（框架化）替代方案。
非常有趣，我喜欢在我的项目中融入一种理念，即“为手头的任务使用正确的工具”。
我更愿意将 HTML 与 CSS 结合起来以实现效果，因为它更轻便，用户禁用它的可能性也更小（如果可以禁用其他技术的话）。
在表单方面，服务器端语言是最佳选择。人们不仅会始终获得服务器端的东西，而且您还无需担心安全漏洞。
JavaScript 脚本也可能导致网页加载时间过长，我一直认为最好适度使用该技术，并在使用 JS 或 CSS 时认识到功能和样式之间的模糊界限。
如果我可以依靠 HTML/CSS/PHP，那么我就采用这种方法。我希望我的访客能够访问我的网站，美观应该放在其次。自然，确保 JS 不影响您的网站才有意义。将其用于增强功能，而不是核心功能，因为如果用户没有它，核心功能就会失效。
不同意“表单验证”部分的内容！
对于表单验证，无论出于何种原因，您都必须将验证逻辑放在后端。例如，要构建一个安全的应用程序，恶意用户可以轻松绕过您的前端验证并通过简单的 HTTP POST 发布无效数据。此外，如果您正在构建大型项目，您可能会拥有不同的前端、网页、桌面应用程序、Java Web Start 等。验证将成为逻辑的一部分，必须在后端完成。
那么后端验证就足够了吗？绝对不是！为了获得良好的用户体验，我真的想不到有任何理由不在前端进行验证。无论您对服务器端验证做了多好的工作（保留所有输入的数据并突出显示错误字段等），用户都需要花费 2 秒才能看到结果，更不用说某些网站会丢失所有捕获的信息。
JavaScript 验证，它只是一项很小的工作，却能带来巨大的收益。 :)
这篇文章很棒，Chris。JavaScript 不应该承担应用程序功能。也许效果和动画是使用 JavaScript 的良好候选者。JavaScript（jQuery）另一个有用的领域是快速原型设计 :)
我完全同意你的观点。但是，我不同意一些关于避免使用 JS 框架的评论。（我曾经也是其中之一）您必须面对这样一个事实，即这是 Web 的发展方向，我非常确定 JS 框架很快就会直接包含在浏览器中或缓存到所有网站中（例如，您今天可以使用 Google 项目链接来实现此目的）。此外，良好的压缩和分布式内容网络的使用也有助于加快网站速度。这些框架的大小和分发仍然需要关注，但这是未来的发展方向。我离不开它们，因为它们开辟了一个更好的可用性新世界（以及向后兼容性！）
我将采用相反的方法来处理“如果用户禁用了 javascript”和整个优雅降级问题。
嗯……2001 年打电话来——它想要收回它的优雅降级。
说真的，现在有多少人在没有 JavaScript 的情况下浏览网络？地球上每个浏览器都默认支持它——甚至移动浏览器——无需下载或插件（如 Flash）。此外，让 JavaScript 完成一些工作可以减轻服务器的负担。我的网站使用一些 CMS 和许多 php 包含文件——这对服务器造成了负担。（我知道有 memcache 等）
我使用的框架——jQuery——很好地处理了许多与浏览器相关的问题，并将编写 JS 代码简化到几乎很有趣的地步！
JS 曾经被视为一种做花哨但无用之事的奇特方式。这种情况不再存在了。如今，JS 处理了许多网站的工作负载，使页面看起来和行为更加专业。
至于 AJAX 是否是黑客行为——嗯，什么不是黑客行为？它彻底改变了 Web，并且运行得非常好。同样，如今框架使它成为一项三年级水平的任务——非常简单。喜欢它。
我认为优雅降级和避免使用 javascript 的论点对我来说已经过时了。是的，优雅降级将使您的网站能够访问最广泛的用户群体——但您是否支持没有鼠标的用户？视力不好的用户？没有显示器的用户（好吧，我疯了）——但您明白我的意思。
我可能会使用“避免使用 Flash”的论点来代替避免使用 javascript。当今，您可以使用 jQuery 或其他库来完成许多事情，但似乎没有人担心避免使用 Flash。我同意 Jeremy 的观点——javascript 框架是未来的发展方向。
“说真的，现在有多少人在没有 JavaScript 的情况下浏览网络？”
比你想象的要多！仅仅因为你的全新 iPhone 与你的 JS 配合得很好，并不意味着一些过时的 S40 诺基亚也能做到。
作为这样一部旧手机的所有者，您不能真的期望获得完整的 Web 浏览体验。直到 Opera mobile 9.5 和 iPhone 浏览器出现后，手机才真正开始用于浏览。您无法支持每一部旧手机，否则我们如何才能进步呢？
“否则我们如何才能进步呢？”
通过遵循“渐进增强”范式，而不是完全锁定旧服务和浏览器。
许多用户使用非浏览器用户代理。如果您从下往上工作，您始终可以确保您的页面在任何 UA 中加载，而不仅仅是在具有所有花哨功能的浏览器中加载。
我不这么认为。
在大多数情况下，至少对于我的普通受众而言，可能每 1000 人中只有 1 人不会启用 JavaScript 或使用非常旧的浏览器。此外，他们中的大多数拥有相对较新的计算机，这些计算机在客户端处理方面没有任何问题。
也就是说，如果使用 jQuery/JavaScript 更容易，即使我可以用其他语言做到，我也通常没有问题。
好文章！
“如果它可以用其他语言完成，请使用其他语言。”
在我看来，Javascript >>> Flash
<3 JQuery :D !!
JavaScript 全部关于用户体验（UE、UI、UX、UIE……）。它不应该依赖于任何东西，而应该用于增强用户的体验。把它想象成豪华汽车后视镜中嵌入的温度计。它是一个很好的东西，但它无助于汽车的运行。
再说一遍，2001 年打电话来了……他们想收回他们的“不要使用 javascript——它只用于不必要的 UI 内容，而且不能依赖它”的政策。
我想，如果您正在为使用 IE5 或 8 年前手机的人构建网站，那么您就说服我了。您赢了——不能依赖 javascript。否则，我真的很想知道为什么你们觉得除非绝对必要，否则永远不应该使用 javascript。我一直听到“不要使用它”和“不要依赖它”，但没有听到原因。
每个现代浏览器都支持它很多年了——它不再仅仅是一种用于“无用的 UI 内容”的语言——它近年来发展迅速，库也在进一步突破极限——甚至跨浏览器抽象也是如此。
您是否真的要根据 1000 名访客中只有 1 人使用 2001 年之前的浏览器或禁用了 javascript 的事实来决定要使用的编程语言和技术？真的吗？
我的意思是，嘿——萝卜青菜各有所爱。但是“仅用于 UI 增强”的论点对我来说似乎完全过时了。我认为我们已经远远超出了那个阶段。
如上所述，除了浏览器之外，还有更多类型的 UA。但即便如此，问题不在于“不要使用它”，而在于“明智地使用它”。大多数执行 UI 内容以外操作的 javascript 程序都可以在 PHP 或 ASP 中完成。那么为什么不使用它们呢？
Javascript 有其用途，甚至可以用于非 UI 内容。但使用它不应该破坏页面……这就是问题的全部。并且该页面可能被手机、掌上电脑、盲文阅读器、屏幕阅读器、机器人、……等等查看。它们都有 javascript 吗？没有。
我 99.5% 的用户
——启用了 Java 脚本
——使用宽带连接
——IE 5？谁在我的网站上使用它？
——IE 6，我的脚本在 IE 6 上运行没有问题。
– 喜欢网站上使用 JavaScript 做出的更改：手风琴和简单的隐藏和显示选项，用于清理界面。
– Lightbox 改善了用户体验，减少了服务器请求。
– 对于那些禁用 JavaScript 的“外星人”，网站仍然可用。;D
表单验证
应该使用服务器端和客户端验证的混合方式进行。关于效率，为什么要用简单的请求来轰炸服务器以验证电话号码、邮政编码等简单的事情，这些可以在客户端验证？让高级验证由服务器完成。
样式
我使用 JS 将 CSS 类重新分配给内容。
CSS 定义在 css 文件中。但它允许用户更改内容的显示方式（切换内容的位置……动态修改 css）。在某些类型的社区和网站上，可自定义的界面几乎是必须的。
例如：Gmail、Facebook
插入内容
好吧，如果这是唯一的方法……那么使用 JS 和 Ajax。
如果使用 JS/ajax 有益且减少了服务器负载，好的，使用 JS。
如果 JavaScript 实现得当，它在网页设计/开发中并不是一种罪过，如果它不会让你的网站像荷马·辛普森（X 先生）一样臃肿。;D。
Javascript != Midi != Flash
这是一个很好的经验法则，但它有失去细微差别并被视为金科玉律的风险。
我不需要重复关于出色用户体验是必需品而非锦上添花的论点。（但我想我刚刚重复了！）
我还要补充一点，随着越来越多的设备和用户代理访问我们的内容，让网站或应用程序优雅降级再次变得重要。
我完全不同意以下说法：“同样，AJAX 的整个概念通常被认为是一种hack。它是在一种为单向传递构建的技术中模拟双向通信的方式。当出现更自然地适应双向浏览器-服务器通信的新技术时，AJAX 就消失了。”
AJAX **是**浏览器实现的技术，它支持双向通信（无需重新加载页面——你始终可以使用简单的请求/响应来实现，这是 HTTP 的核心）。如果你想要双向通信并且不想使用 AJAX，你可以使用 Flash 或 iframe。那才是hack。
完全同意。Ajax 不需要使用，但它 **是** 当前的双向通信……老实说，它运行良好。如果你的服务器端响应速度足够快，ajax 可以成为你网站不可或缺的一部分，并且使用 js 或 js 库（例如 Dojo（我是粉丝））可以为用户提供无缝且酷炫的外观。
等一下……
一些支持优雅降级的人（至少本文中的一条评论，以及其他无数评论）认为 JS 应该用于 FX/视觉效果。
什么……？
JavaScript 是一种编程语言，而不是 FX 编辑器。仅仅因为 jQuery 和 MooTools 等非常棒的库专门用于（滥用）JavaScript 进行以前棘手的 DOM 操作，并不意味着 JavaScript 的目的是用于 FX。
你是否认为网站应该优雅降级是另一回事。但不要因为对 JavaScript 的误解而持有这种观点！
我部分同意。Javascript 不仅仅用于 FX 和视觉效果。然而，世界上任何技术都是最终用户（在本例中是 Web 开发人员）对其进行的处理。他们决定“什么是 Javascript”。因此，如果分支仅将 Javascript 用于 FX 和视觉效果，那么它就是那样，而不是工程师几年前希望它成为的样子。
在表单验证方面，我倾向于服务器端验证，但这可能是因为我在 Ruby on Rails 上工作，在那里只需要很少的代码进行验证。
我同意你提出的大多数观点，但是 Ajax 是 hack？？？我希望你在开玩笑，Chris。目前还没有可以被认为“不是 hack”的 Ajax 替代方案。
确实没有超实用的替代方案。我并不是说 AJAX 不好。我认为它运行得很好，而且非常酷，但它绝对是一种 hack，我对此一点也不开玩笑。从“我们设法非常有效地将它塞进去了”的角度来说，它是一种 hack，而不是从“我们真的不应该使用它”的角度来说。如果我们可以从头开始编写所有不同的 Web 协议和语言，你可以肯定双向通信的内容会大不相同。
是的，我们设法很好地将 AJAX 塞进去了——就像我们如何将表格、CSS 支持、DOM 等塞进去一样。也许它 *确实* 是“塞进去的”，因为在第一个 HTML RFC 中没有它，或者也许它是技术的自然发展。
如果我们从头开始重写整个东西，很多事情都会有所不同。Javascript 和 CSS 支持将位居首位。我们不必处理跨浏览器问题、IE 条件注释、基于表格的设计……但我们必须利用手中的牌。
你见过 Stu Nicholls 的这个 CSS 灯箱吗？
http://www.cssplay.co.uk/menu/lightbox-click.html
我认为在大多数情况下，你提出了一个有效的观点。客户端和服务器端语言旨在按原则服务于特定目的，并且以这种方式效率最高。
然而，这并不关乎工程师多年前想出的什么，而是关乎用户/客户的需求。如果你的客户想要一个拥有出色的可访问网站的在线个性，那么优雅降级就是正确的方法。但也存在其他情况。
如果你的客户需要一个仅在公司内部使用的强大后端，你可以更有创意。服务器负载是系统性能的一个巨大因素，因此，如果你可以在客户端做一些事情，那么值得研究一下。使用“现代浏览器”（感谢 Google！）并启用 javascript 可以只是系统的一个规范。由于你的最终用户是你的客户，因此这是完全有效的。
了解最终用户的需求非常重要，这是你优化其可用性/功能的唯一途径。
我认为这里部分问题在于构建带有某些视觉效果的静态网页与 Web 应用程序之间的区别。如果我正在创建带有几个可以显示或隐藏的 div 的前十名列表，那么没问题——很容易让它优雅降级。
但如果我正在构建一个复杂的基于 AJAX 的 Web 应用程序——如果没有编写 50 倍数量的代码，它怎么可能优雅地降级？尝试构建一个动态的、交互式的和最先进的 Web 应用程序（例如一个使用多个 API 的混合应用程序——例如 Google 地图、Facebook 和 Twitter 在一个页面上，以及在你的数据库之间存储和检索动态数据）并使其优雅降级，这将是荒谬的。祝你好运！！！
因此，说“禁用 JavaScript 不应该破坏页面”根本不合理。说“不要让 JavaScript 破坏你的在线杂志文章”是可以的——但如果你正在编写从不依赖 JavaScript 的页面，那么你构建的不是复杂的 Web 应用程序——你构建的主要是带有某些视觉效果的静态页面。差别很大。
我并不是说无法实现——我说的是，你能投入多少资源来处理如今 1000 人中只有 2 人不使用 JavaScript 的情况？
我认为没有人会不同意你不能总是抛弃 javascript 的事实。而且你不应该。
好的，我部分同意你的观点，但也许我们应该在网页设计和网页开发之间做出更好的区分。我个人是一名网页设计师，因此我与 Web 应用程序几乎没有关系。此外，在我看来，Web 应用程序与网页几乎没有关系。网页是一个包含信息的页面，而 Web 应用程序是在互联网上运行的应用程序。
话虽如此，我可以用 javascript 和 php 编程，并且在 javascript 中几乎没有什么不能做的事情也可以在 php 中完成。而且代码量不是 50 倍。它可能不太漂亮，但功能相同。因此，至少对我来说，javascript 仍然是一种“美化语言”。
最后，为了说明白。我绝不是这方面的布道者，我实际上经常使用 javascript，但这并不意味着我不 **也** 确保我的页面在没有 javascript 的情况下也能正常工作。（除了偶尔客户不在乎并想要“最前沿”的东西（无论那是什么）的情况）。
这是一个很好的观点。在理论上争论这些事情是很难的，这就是为什么示例很重要的原因。
我同意，在编写大型应用程序时，情况完全不同。你很早就做出了这样的选择，即这个东西将严重依赖 JavaScript，这很好。你做出这个选择是因为它最符合你的资源、专业知识、实用性或其他任何东西。这使得它成为“唯一的选择”。
这可能是这篇博文中我最同意的评论。
我个人非常喜欢并积极推广渐进增强和优雅降级，因为我有点像可用性狂热者，并且坚信使用基本原则进行设计和开发从长远来看可以简化很多事情。
然而，浏览器在某种程度上已经走完了它的使用目的的循环，它最初是处理简单的 HTTP 和其他协议的界面，然后随着“网页设计”和“网站”的兴起，它变成了提供“页面”的工具。
现在，编码有效的 HTTP 请求变得容易多了，正如 Brett 所说，我认为定义诸如 Web“应用程序”之类的概念与 Web“页面”截然不同非常重要，盲人不会坚持使用 Photoshop 的方法！
我完全同意你的帖子，
这就是我尝试工作的方式 :-)
这太荒谬了！
很棒的帖子，我同意。随着 jQuery 和 Mootools 等库的流行，许多人开始过度使用 JavaScript，尤其是在不必要的时候。我喜欢这些库以及它们提供的额外功能，但是 JavaScript，尤其是基于浏览器的 JavaScript，并不适合高度动态的 Web 脚本。
如果不是 JavaScript，你会说“适合”高度动态的 Web 脚本的是什么？JavaScript 的“预期用途”是什么？
如果你正在构建一个 Web 应用，并且你有一个使用多个 API 的混搭应用，并且你正在使用自己的数据库生成、保存、创建和显示内容，并在用户输入和不断变化的条件下在不同的网站之间移动数据——比如实时显示来自其手机的多个不同司机的 GPS 数据，同时在 Google 地图上绘制其路线的变化、实时聊天、流媒体视频、“谁已登录”功能——所有这些都在实时进行——你如何在不依赖 JavaScript 和 AJAX 的情况下收集和显示所有这些实时数据？每次数据更改（每 1-2 秒）你都要重新加载整个网页吗？你如何在允许页面优雅降级的同时使用获取 GPS 数据和操作 Google 地图的 JavaScript API？
我很想知道这些老派思维的“JavaScript 仅用于可爱的花哨效果，绝不应该依赖它”的人如何构建我正在构建的应用，同时允许它优雅降级并仍然完成其任务并提供良好的用户体验。
关键是，浏览器确实正在成为操作系统，并且将在 Web 应用中与用户完全交互。浏览器不再仅仅用于显示文本和图像供客户端阅读。
我应该保持沉默，让所有像 2001 年一样思考的人通过避免使用 JavaScript 来束缚自己，而我和其他具有前瞻性思维的开发者则构建无法以其他方式完成的 Web 应用——但我喜欢这些讨论——它们最终教会我很多东西。
我同意这里提出的大多数观点。我认为值得对 JavaScript 库的滥用发表评论。
这些库正在被滥用，我开始担心整个 DHTML 时代会再次出现。我仍然试图忘记那些糟糕的动画。
JavaScript 的论点似乎没有考虑到商业应用。我敢保证，一家为网站支付高价的企业希望该网站在任何情况下都能正常工作。
我部分同意你的观点。我认为任何企业都不希望知道他们的网站在某个地方无法正常工作。但是，你想纳入的支持人数越多，项目的成本和时间就越大。我认为，尤其是在商业案例中，概述应该和不应该支持的内容（或谁应该和不应该支持）非常重要。
部分不同意两点，完全同意一点
1. 是的，你应该始终在服务器端进行验证。如果你想要好的数据，这几乎是不言而喻的。但是，JS 有助于在无需服务器往返的情况下提供快速的验证反馈，从而向用户快速发出信号，表明他们的输入是否有用。例如：如果用户在模糊“电子邮件”字段时对其进行验证，则可以在它是非法的电子邮件时将其突出显示为红色。这减少了错误的表单提交。JS 表单验证应该始终补充服务器端验证。
2. Ajax 并不是真正的“黑客”，而是一种在需要请求页面内容而无需完全加载页面时应使用的工具。
例如：在我工作的某个站点上，每个页面上都有一个菜单，在用户将鼠标悬停在菜单项上之前，该菜单是隐藏的。菜单中的内容来自一个缓慢的 Web 服务。我不想通过强制每个用户等待 Web 服务来减慢每个页面的加载速度，因此我仅在用户调用该菜单时才请求该内容。AJAX 的良好用法。
话虽如此，我看到很多开发者在他们本可以将其他内容隐藏在页面中并在适当的时候显示时发出 AJAX 请求。
3. 是的！JS 不应该应用样式。我经常使用的一种模式是让 JS 应用一个类并将规则与我所有静态内容规则一起保存在样式表中。这样，你就不必在脚本中搜索样式，它都只在你的 CSS 中。
在新的 YUI 3 中试试这个，它非常容易。