超越 jQuery（五）
十三、后记
这很有趣，但是，可悲的是，超越 jQuery 最终还是要结束。已经投入了大量的时间和研究来向您展示浏览器和 JavaScript 本身中存在 jQuery 的可行替代方案。事实上，甚至我在整理这本书时偶然发现了一些新知识。即使您决定依赖一个熟悉且方便的选项，比如 jQuery，您现在也能更好地理解这个特定的抽象是如何工作的。这些知识不仅可以为您的下一个项目做好准备，还可以帮助您解决在仍然与 jQuery 相关的现有项目中遇到的性能或行为问题。
正如我在本书开篇指出的，我们都是软件开发人员、web 开发人员和 JavaScript 开发人员，而不是 jQuery、Zepto、AngularJS 或(在此插入您喜欢的库或框架)开发人员。图书馆来了又走，但是网络和将它结合在一起的语言将会存在更久。
我们该如何利用这些新发现的知识呢？我知道我要做什么，但你知道吗？对一些人来说，你的下一步行动可能是显而易见的。对其他人来说，就没那么多了。可能不清楚你的选择是什么，或者你应该如何进行当前和未来的项目。你应该改变什么吗？你有什么问题是本书中没有回答的呢？您如何跟上不断发展的形势？
这最后一章为超越 jQuery 之后的生活提供了一些建议和指导。
现在怎么办？
如果你在阅读本书时对 JavaScript 和 web API 的了解只有我写这本书时的一半，那么你可能有很多东西要思考。对于这本书的内容和基调，你可以有很多选择，也可能有很多不同的反应。实际上，我认为读者有四条共同的前进道路。虽然有些人可能会选择其中一条道路，但其他人可能会发现这一部分概述了本书完成后的四个连续阶段。
选项/阶段 1:忽略一切
也许你仍然目中无人，甚至读完了整本书(或者你只是浏览了一下)。语言和 DOM API 都很难看。jQuery 仍然是最好的选择。我们都有权表达自己的观点。使用 jQuery 并没有错，只要不是在不知道其他选择的情况下做出的选择。除非这仅仅是一个以开悟结束的过程的第一阶段，否则不太可能有太多的事情会改变你的想法。我只能希望你至少从这本书里受益了一点点。也许你学会了一个新的 CSS 选择器，或者对承诺有了更好的理解。不管怎样，如果 Beyond jQuery 为您提供了一些新知识，让您成为一名更强的开发人员，那么我当然很高兴。
选项/阶段 2:将 jQuery 从所有项目中剥离出来
一些读者可能有冲动采取与选项 1 相反的方法。取代自由放任的态度，你可以决定对你所有的活动(和非活动)项目进行重大的重构。您的口头禅可能是“删除所有的 jQuery，用普通的 JS 替换。”我当然可以尊重这种观点(我自己也一度有这种感觉)，但我会建议你退后一步，深呼吸，先思考一下这个决定的后果。你的项目有一套全面的自动化测试吗？你有相当多的空闲时间吗？你没有其他更重要的事情要做了吗？如果其中一个或多个问题的答案是否定的，那么我建议你不要节外生枝，对现有的代码库进行大量不必要的修改——除非下面至少有一个是正确的:
- 这个项目相当小。
- 您实际上没有任何(或许多)用户，这更像是让您开始走普通 JS 道路的学术练习。
- 由于其他原因，一个主要的重构已经在进行中，或者你已经计划好了。
- 在对项目进行概要分析之后，您当前对 jQuery 的使用导致了显著的性能问题。
如果这些描述了你的情况，祝你编码愉快，并祝你好运！Beyond jQuery 将成为您探索过程中的有用参考。
选项/阶段 3:在一个角落里来回摇晃，哭泣
“我不能或者不应该再使用 jQuery 了？!"对于许多人来说，jQuery 是他们整个职业生涯中每个 web 项目的核心组件。一想到要放弃这样一个可靠和熟悉的帮手，对一些人来说可能是毁灭性的。但是不用担心，你不必放弃 jQuery，正如我在本书中已经多次提到的，除非你真的想放弃。因此，如果你更喜欢脱离自己，一点一点地慢慢转向更接近金属的解决方案，那就尽管去做吧。jQuery(可能)不会去任何地方。让这一阶段成为你走向读后过程中最后也是最重要的一步时的一小段颠簸。
选项/阶段 4:决定变得更有洞察力
如果你在这里结束(或开始)，那么我已经完成了我用这本书设定的目标之一。它不仅仅是那些希望超越特定库的人的指南——它的目的还在于让你开始更批判性地思考库、框架和浏览器端的依赖关系。就个人而言，我发现这种思维方式阻止了我(尽管不一定是我周围的人)在新项目中不必要地复杂化依赖树。这种心态帮助我变得更节俭、更谨慎，并迫使我花更多的时间思考，花更少的时间编码。我不确定这是可以教授的，但是也许，通过足够的灌输，你可以自己采用这种精神状态。
Web 开发的未来
当然，确切地预测软件开发的未来是不可能的，尤其是因为技术在不断发展，通用工作流变化得如此之快和频繁。不过，想想我们的世界在遥远的未来会是什么样子还是很有趣的。当你思考(并经历)web 开发的未来时，我认为记住一套可靠的最佳实践是很重要的。你不能因为有人告诉你就简单地遵循一套实践。你自己必须相信他们。
有些人会说“最佳实践”会随着时间的推移而发展，这在某种程度上是正确的。虽然在开发一个复杂的项目时，有一套既定的目标和指导方针是很重要的，但是很少有硬性的规则，并且在决定什么样的最佳实践最合适时，上下文是关键。放弃既定的最佳实践可能有很多原因。一旦你决定遵守一套特定的指导方针，重要的是不要仅仅因为方便(或懒惰)而抛弃它们。抄近路“仅此一次”是很容易的，尤其是当软件技术领域以当前极快的速度发展时，你将面临令人眼花缭乱的选择。以下是我喜欢遵循的一些公认的“最佳实践”，其中一些在本书中有所提及:
- 保持关注点的分离，不一定是在 HTML、CSS 和 JavaScript 之间，而是在行为和角色方面。尽管我承认这种特殊的最佳实践有各种各样的解释。比如 React 有没有违背这个原则？既然 vue.js 在 HTML、CSS 和 JavaScript 之间保持了更清晰的分离，那么它是不是更好的选择？严格地说，在代码的上下文中，关注点不一定需要按照文件来划分。虽然我确实相信这个特殊的例子说明了这一点，但这可能是另一本书的一个更大的争论。
- 开发专注于做一件事的小组件，并把它做好。
- 保持依赖的轻松和集中。谨慎使用外部依赖。并且要有眼光。
- 在依赖任何依赖项之前，先探索它的代码库。设计的好吗？保养的很好？考得好？该依赖关系的开发人员是否认同同一套最佳实践？
- 使用依赖项时，优先使用垫片和聚合填充，而不是库和框架。这并不是说所有的库和框架都不好，应该避免，但我倾向于更小、更专注的库和框架。
- 只要可行，随时随地编写自动化测试。这将减少重构的风险和痛苦。一些开发人员坚持认为测试驱动开发是编写测试的唯一方法，但是我不同意。根据我的经验，TDD 可能让人不知所措，而且并不适合所有情况。重要的是你写的测试可靠全面，不一定是你怎么写的。
当然，还有其他的，但是这代表了我遵循的最著名的最佳实践的列表，它们对我很有帮助。但是为什么我在“Web 开发的未来”一节中花了这么多时间来讨论最佳实践呢？简单:我觉得有一套指导原则来让你在不断变化的新技术中导航是很重要的。
正如我在本章(和本书)中多次提到的，网络技术似乎正在以令人难以置信的速度变化和发展。我自己发现很难跟上最新的发展。但是我们关注的进步往往局限于库和框架。这些通常是我们不断发展的行业中最“有趣”的方面。正如 web 和 JavaScript 规范是 jQuery 发挥其魔力的基石一样，所有最新的华丽的库和框架也是如此。随着标准的发展，库和框架也能够随之发展。Web 的未来在于 W3C、WHATWG 和 ECMAScript 规范。遵循最新的库和框架，但也要密切关注标准。对现有规范的补充和新规范的诞生将使您和其他人能够为复杂问题创建更强大、高效和高性能的解决方案。
进一步阅读和参考
学习永远不会停止，尤其是在我们这个行业。无论何时，当您想重温 DOM 操作、Ajax 请求、一般的 JavaScript 或这里涉及的任何其他主题时，Beyond jQuery 可以而且应该成为您的新参考。但这本书不能成为你唯一的参考。它从来都不是 web 和 JavaScript 的详尽来源。这本书的重点一直是 web API 和语言与 jQuery 重叠的领域。这使得大范围的材料被讨论，但无可否认的是，也有其他主题不得不被排除在外。
对于本书中未涉及的所有内容，我会推荐一组资源，因为我自己也非常依赖它们。下面的一些内容也是为了让你的 web 开发和 JavaScript 知识保持最新，这是一本书所不能提供的。对于每一个推荐的资源，我都解释了所有值得注意的限制和优势。
官方网站和语言规范
规范本身——WHATWG、 1 W3C、 2 和 ECMA-2623——在 web API 和 JavaScript 方面掌握了最多的信息。它们包含了令人难以置信的大量细节，可以被视为本书中讨论的所有原生 API 的真实来源。我在第三章中介绍了这些标准文档。不幸的是，这些文档对大多数人来说也有点难以理解。如果你真的想了解某个特定方法或特性的每一个细节，并且愿意并且能够花时间去破译这些文档中的深奥语言，那么官方规范是一个理想的资源。不然还有更合适的选择。
TC39 小组负责管理 JavaScript 规范，维护着一个 GitHub 组织。 4 在那里，他们记录着自己的会议笔记、议程和提案。这是一个了解 ECMA-262 最新进展的好地方，有时提案和会议记录比官方标准文档本身更容易理解。在这个组织中，我最喜欢的参考资料是建议书存储库中的 README.md 文件 5 。 6 在那里，你可以看到每个提案的最新进展，从阶段 1 到阶段 3。这个文档甚至链接到一个 0 阶段提案的列表，它提供了关于语言遥远未来的可能性的洞察力。
Mozilla 开发者网络
毫无疑问，Mozilla Developer Network 是官方标准文档的最清晰、最简洁的替代品。如果我在寻找一个特定的 web API 或 JavaScript 方法的细节，这通常是我的第一参考选择。除了易于解析的语言和代码示例之外，MDN 还包括几乎所有界面的浏览器支持矩阵。对于跨浏览器不太支持的 API 项，MDN 通常包含一个聚合填充的代码，您可以简单地将它放入项目中。如果您真的想看一看底层的规范文档，每一页都包括一个表格，其中详细说明了某个特定特性首次推出的时间，以及到官方文档的链接。Mozilla Developer Network 被许多人(包括我在内)认为是当今 web 开发人员最好的综合参考资料。
Caniuse.com
如果你正在寻找浏览器支持某个特定功能、一组相关功能，甚至一组不相关功能的更多细节，caniuse.com 是最终的资源。对于任何特定的界面或功能，caniuse.com 以表格的形式描述了浏览器支持，每个流行的浏览器都有单独的一列。对每个特性的支持都可以追溯到古代的浏览器(甚至是 Internet Explorer 6)。表中还注明了例外情况。以 FileReader API 为例——can use 包括链接到一篇文章(由我撰写) 8 的注释，该文章描述了在 iOS 8 中实现该 API 时引入的关键 bug。每个功能都跟踪这些类型的问题和其他相关资源，例如 MDN 页面的链接、规范文档、特定于浏览器的支持文档，甚至重要的特定于浏览器的实施说明。例如，在 SVG favicons 支持表上，有一条注释指出 Firefox 要求所提供资源的 MIME 类型为“image/svg+xml”。
Caniuse 还允许您按浏览器、功能类别和浏览器类型(桌面、移动等)对信息进行分组。一个简洁的功能是将支持表呈现为一个条形图，它根据每个浏览器版本的相对使用情况来确定特定浏览器下每个浏览器版本条的高度。并且如果需要，该相对浏览器版本数据也可以是区域特定的。虽然我更喜欢 MDN 对 web 和 JavaScript 特性的易懂解释，但在浏览器支持信息方面，caniuse 是无可匹敌的。
堆栈溢出
我们大多数人已经在堆栈溢出上花费了相当多的时间。毕竟，似乎大多数软件开发问题，当输入你选择的搜索引擎时，会在结果列表的顶部显示堆栈溢出。一个严肃的问答网站也是如此，它有一套严格的规则和一个致力于执行这些规则的社区。SO 社区保持的这种纯粹和完美的水平经常让新的或临时的贡献者感到沮丧，但它也使该网站成为所有编程的惊人有效的资源。
甚至看似微不足道的话题也会在堆栈溢出上表现出来，比如这个问题，“你遇到过的源代码中最好的注释是什么？”但是要注意的是，这些天这种性质的新问题令人皱眉。尽管如此，如果您(令人惊讶地)无法找到关于堆栈溢出的不寻常编程问题的现有答案，庞大的社区可以回答您的格式良好的查询。对于 javascript 相关的问题尤其如此，因为“JavaScript”是网站上使用最多的标签。
推特
就了解网络开发的最新进展而言，Twitter 是我的头号资源。我个人并不关注 Twitter 上的许多开发人员，但我仍然设法淹没在似乎永无止境的有趣讨论、关于新 web 和 JavaScript 特性的新闻以及让 web 的未来看起来更像现在的著名库之中。Twitter 是一个经常被忽视的传播和吸收微小软件相关信息的媒介。根据我的经验，一些更有趣的与网络开发相关的讨论发生在 Twitter 上。简单地追随最有影响力或最多产的开发者并不重要。如果你能找到一些愿意分享有趣观点和文章的工程师，你会发现你的知识范围会增长得相当快。
无论您选择更新哪种资源，或者探索现有的 API，最重要的目标是不断学习。第一步是超越 jQuery，但不要止步于此。安逸是停滞的标志。如果你已经习惯了自己的方式，不愿意保持开放的心态，并且拒绝考虑超越你当前的工具和过程，那么作为一个软件开发人员，你将会停止成长。
Footnotes 1
2
3
www.ecma-international.org/publications/standards/Ecma-262.htm
4
5
https://github.com/tc39/proposals/blob/master/README.md
6
https://github.com/tc39/proposals
7
https://developer.mozilla.org/en-US/
8
http://blog.fineuploader.com/2014/09/10/ios8-presents-serious-issues-that-prevent-file-uploading/
9
