我记得之前看过 Tom Dale 的这条推文。它实际上是关于浏览器在首次接收文档时查看其 HTML 的能力。现在这条推文引发了新一轮的讨论。
Jonathan Snook 有点像小熊维尼的态度
我们能够检查原始 HTML 源代码及其解释后的表示形式。我们能够检查从其压缩和优化版本映射的 JavaScript 和 CSS 文件的源代码。我们能够检查渲染管道。我们能够逐行停止和单步执行 JavaScript 代码。
尽管工具的复杂性日益增加，但这并不否定早期简单工具的必要性。
有些人构建的网站可能是简单的静态网站，适合使用简单的“查看源代码”。有些人构建的网站可能是编译和捆绑的，需要使用更深入的工具。仅仅因为您不需要这些工具，并不意味着 *其他人* 不需要这些工具。
对于一个简单的网站，所有内容都包含在一个文档或几个链接的脚本和样式表中，这已经足够了。
但我认为现在已经不再是这样了。即使在开发者工具中浏览网站的简单源代码也比查看一个巨大的文本块有趣得多。如今，我们可以右键单击元素并直接跳转到它。在查看其 CSS 时，我们可以看到级联是如何工作的，甚至可以看到附加的事件和悬停状态。
当然，开发者工具比查看文档更难学习，但您也可以从中学习到更多东西。“查看源代码”的优点是它随浏览器免费提供。这使得它成为任何想要成为 Web 开发人员的人的首选工具。无需下载和学习 IDE——您的开发环境就是使用环境。
好吧，这就是如今开发者工具的现状。它们是免费的，随浏览器提供，并且不难理解。如果有什么不同的话，我喜欢它们能够让您更深入地了解代码的功能，而不是代码本身。
为了好玩，我在这里采取强硬立场：我根本不在乎“查看源代码”，如果它从浏览器中移除，我也不会想念它。我生活在开发者工具中，我相信您也是。它完全取代了“查看源代码”，因为如果您愿意，您可以在其中查看源代码。但这并非重点。
我不希望我的源代码对人类可读，不是出于保护的原因，而是因为我更关心 Web 性能。我希望我的网站能够以光速在网络数据包的微小碎片上加载，并变成一个完整的网站。或者做任何计算机科学认为是发送网站数据在计算机之间最快的方式。我更担心 Web 性能的状态，而不是 Web 教育。但即使我非常担心 Web 教育，我认为网络也没有义务提供可教性。
如果我错了，请纠正我，但使用开发者工具时，您检查的是 DOM，而不是源代码。浏览器对 DOM 做了一些奇怪的事情，例如自动关闭您遗漏的标签，有时会导致非常奇怪的错误。这时我就会切换到“查看源代码”。计算开始标签和结束标签
你说的没错。通常您查看的是 DOM，因为这是最有用的。但源代码也在那里。
确实，可以通过开发者工具访问源代码，但它比简单的
cmd+opt+u或ctrl+u或者右键单击 > 查看源代码要麻烦得多。有时，我只是想快速查看原始 HTML，而不必在开发者工具中搜索和展开树。我主要生活在开发者工具中，但我绝对会使用“查看源代码”。但是，我主要是一名后端开发人员。我需要查看我的服务器发送到网络上的内容，在浏览器开始对其进行修改之前。“查看源代码”对我来说非常重要，因为当出现问题时，我需要查看我的服务器是否发送了一些导致渲染的网站出错的内容。
尽管随着我越来越多地构建 API，我几乎和使用“查看源代码”一样频繁地使用 Postman 或 HTTPie
我认为，网络选项卡对此更有用，因为它提供了更多关于发送了什么以及如何发送的信息。
了解通过请求传入的内容与检查器工具的插值之间的区别至关重要。
“查看源代码”可以快速了解网站开发人员的方法和态度。Web 开发人员不会编写 DOM 部分，他们编写标记。查看标记与查看开发者工具的关系，就像勘察某人的客厅与阅读其详细内容清单的关系一样。
我发现它在您想要查找特定代码片段时仍然有用（它是 WordPress 吗？Cmd+Opt+U + Cmd+F wp，搞定！——当然，开发者工具也可以做到，我只是觉得它没有那么“快速”），或者在移动设备上查看一些源代码。这种情况发生过不止一次，例如，当朋友让我在旅途中查看某个网站的源代码，而我没有任何花哨的应用程序/工具时。我使用它的频率很低，但仍然觉得它很有用，并且看到它消失会有点难过。
是的，在调试 WordPress 脚本和样式加载顺序时，我会使用“查看源代码”。我打开两个标签页，在代码更改后刷新一个标签页，然后将它们进行 A-B 对比，以查看是否有任何行发生了变化。
我肯定在这里遗漏了一些东西。
从浏览器中删除一个有助于检查原始 HTML 源代码的功能，这对用户来说有什么好处呢？
至于可读代码与不可读代码，压缩 HTML 和 CSS 类名可以减少微不足道的有效载荷大小。事实上，使用 GZIP 时，这些都不应该成为问题。如果压缩类名可以节省大量数据，那么您可能拥有大量的 CSS，在这种情况下，真正的问题显然是其他东西。
只是试图理解这背后的原因。作为性能权衡，使源代码不可读（除了丑化 JS）似乎并不实用。
终生使用“查看源代码”。我无法相信有人会主张删除它。这是一个简单但非常有见地的功能，如果删除它，对任何人都没有好处。
实际上我同时使用这两种工具。我需要处理的 Javascript 窗口小部件越复杂，就越需要了解页面在某些远程脚本插入新的 DOM 节点、插入类或更改属性之前是什么样子的。
这实际上取决于我想做什么。如果我想查看应用于网站特定区域的 CSS，那么开发者工具是首选。如果我想解释网站是如何构建的，那么我会从“查看源代码”开始，然后下一步再转向开发者工具。
我喜欢检查发送到浏览器的原始文档。正如 Chris 指出的，他希望他的源代码快速，而不是对人类可读。允许人们查看该原始输出可以帮助他们了解我们在使内容快速之前是如何处理的，然后再将其更新到开发者工具中的 DOM 中。
“查看源代码：https://www.nasa.gov/”与开发者工具版本之间存在很大差异。
我数不清有多少次想帮助其他开发者，我让他们查看源代码……他们查看DOM树……然后我不得不告诉他们使用CTRL+U来快速轻松地获取完整的原始源代码，并以全屏视图显示（如果可用，可以拖动到辅助显示器上）——好的，现在我们开始行动了！看看那个在元标签之前注入的格式错误的HTML或链接/脚本/基本/样式标签……没错，这就是IE失败的原因……或者那个在body标签之前的div/span/?……没错，这就是你遇到问题的原因。我喜欢DOM树，但那是解析完整DOM的结果。如果我深入挖掘开发者工具，能否看到基本上相同的内容？是的，差不多……但在一个更小的窗口中，而且没有快捷键。在Firefox和Chrome中，它也是一个实时窗口（F5/CTRL+F5）来重新加载，并且所有链接都是可导航的（例如，到包含的脚本、样式、iframe）。在Firefox中，无效内容以红色突出显示，并带有工具提示，说明为什么它是一个问题。最后，我实际上可以通过在URL前面添加“view-source:”来访问源代码，而无需使用开发者工具，例如view-source:https://www.google.com/ 当页面上有一些重定向/自闭合或其他损坏的JS导致内容在开发者工具打开之前发生更改或关闭时，这非常方便。#LongLiveViewSource！
正如Chris指出的，你仍然可以从开发者工具中查看源代码。“查看页面源代码”被点击时，为什么不直接打开那个视图呢？两全其美。