构建更精简的 jQuery

发布于 作者

jQuery 现在已经超过五年了！在这段时间里，它随着它所服务的浏览器、网站、设备、开发者和用户一起发展。它也，嗯，增长了不少。 jQuery 添加了许多有用的功能，但也积累了一些我们不愿意永远支持的累赘。在台式机上使用高速连接可能不是问题，但我们希望 jQuery 也是移动设备上的良好解决方案。

除了我们对更高性能的持续推动外，我们对未来版本的优先事项是更小的压缩文件大小。当每个新功能或错误修复也必须保留所有现有功能和行为时，要做到这一点很难。因此，今天我们想开始讨论通过弃用一些功能来精简 jQuery API 的问题。以下是我们的弃用指南

  • 我们不相信该功能代表了当前使用 jQuery 的最佳实践。
  • 该功能已被证明在实际使用中不受欢迎、令人困惑、效率低下或无效。
  • 增强功能或解决其局限性是不切实际或不可行的。
  • 在未来某个时间将其移除可能会带来显着的可用性、大小或性能优势。

弃用只是您可以参与的流程中的第一步。我们的目标是

  • 解释弃用特定功能的原因，如上所述。
  • 在弃用和移除之间提供至少一个主版本，通常更多。
  • 为弃用的功能提供替代方案，以便迁移不会很痛苦。
  • 倾听社区关于弃用和移除的反馈。

偶尔，像 1.7 版本中的 event.layerX/layerY 那样，如果我们判断立即移除功能比保留它带来的痛苦更少，我们会提前较短时间通知进行重大变更。这些希望只是罕见的例外。

1.7 版本弃用

考虑到这些因素，我们认为以下功能从 1.7 版本开始已被弃用。使用它们的现有代码仍然可以工作，但建议的替代方案是与未来版本兼容的更好选择。

.live() 和 .die()：我们继续收到许多错误报告，并看到用户对 .live() 方法怪癖感到困惑。常见问题现在已记录在其更新的 API 页面上。我们强烈建议在新代码中使用 .on() 或 .delegate()，因为它们是更好的 API。鉴于其广泛使用，我们不太可能在 1.8 版本中移除此 API，但请尽快更新您的代码。

非标准事件属性：作为我们提高事件处理程序性能的一部分，我们还弃用了将几个事件属性从原生事件对象复制到 jQuery 事件对象的行为，并在 1.8 版本中移除它们：attrChange、attrName、relatedNode 和 srcElement。您无需通过 event.NAME 访问它们，而是可以根据需要通过 event.originalEvent.NAME 访问它们。

$.ajax() Deferred 别名：在 1.5 版本中，我们在 jqXHR 对象上定义了 .error()/.success()/.complete() 作为 Deferred 的 .fail()/.done()/.always() 方法的别名。尽管当时这看起来是个好主意，但它使 jqXHR 成为非标准的 Deferred。这不好。在可能的情况下，优先使用 deferred/promise 方法名称，而不是 jqXHR 方法名称。我们仍有一些工作要做，以提供完整的迁移路径，因此我们可能会在 1.8 版本之后继续支持别名。

deferred.isResolved() 和 deferred.isRejected()：现在 Deferred 和 Promises 具有进度通知和方便的 .state() 方法，我们弃用了这些较旧的方法，并将在 1.8 版本中移除它们。使用 N-1 个布尔方法获取 N 状态对象的 state 是“二十个问题”的残酷代码版本。基于 Deferred 的代码很少需要检查状态，现在返回的字符串对于调试场景更方便，在这种场景中它经常被使用。

.attr(“value”) 用于输入：为了向后兼容，我们一直在返回这里的当前值（如“输入框中当前的内容”），而不是真实属性（HTML 中的 value 属性是什么）。这让我们无法提供真实的属性值，并且令人困惑，因为 W3C 选择器使用的是属性，而不是当前值。因此，我们弃用了这种行为，并将在 1.8 版本中移除它。始终使用 .val() 方法获取输入元素的当前活动值。在我们能够重新获取属性之前，您可以使用 $("selector")[0].getAttribute("value")，除了在 IE 6/7 上，它仍然会返回当前值。（我们的 1.8 版本解决方案将在所有浏览器上获取属性值，这也是我们急于更改此行为的另一个原因。）

.closest(Array) 返回 Array：此签名有点奇怪，它是为旧的 live 事件代码创建的，但它返回的是 Array，而不是 jQuery 对象。从 1.8 版本开始，我们计划移除它。.closest() 的其他签名将保留，不会受到影响。

.data(“events”)：jQuery 将其与事件相关的 data 存储在每个元素上名为（等等）events 的 data 对象中。这是一个内部数据结构，因此在 1.8 版本中，它将从用户 data 名称空间中移除，因此它不会与同名项冲突。jQuery 的事件 data 仍然可以通过 jQuery._data(element, "events") 访问，但请注意，这是一个未记录的内部数据结构，不应修改。

$.sub() 作为插件：尽管 $.sub() 对于为插件创建无干扰区域很有用，但它没有被 jQuery 核心使用，也没有被其他代码广泛使用，因此我们打算在 1.8 版本中将其转换为插件以节省空间。

展望 jQuery 1.8

鉴于我们对精简 jQuery 的推动，1.8 版本中新功能的筛选将很严格。即使是与性能相关的提案也需要与它们使用或节省的空间相平衡。可以通过插件、特殊事件、属性钩子或其他 jQuery 扩展机制实现的功能可能会暂时保留在核心之外。

这就引出了一个问题，我们可以在 1.8 版本中弃用什么，并最终移除以简化和精简库。这些东西不必完全消失；例如，它们可以转移到单独的插件中，并且只有在需要时才包含。看看你如何使用 jQuery，并与你的同事讨论一下。

几周内，我们将通过另一篇博客文章发布关于 jQuery 1.8 的创意征集 - 所以现在就开始思考吧！

编辑：不，我们还没有移除 IE6 支持，我们也不可能。正如 John Resig 在每次 jQuery 大会上提到的，IE6 的大多数罪过也降临到了 IE7 和 IE8 上，它们加在一起仍然占有超过三分之一的台式机浏览器市场份额。在我们可以同时干掉 IE7 和 IE8 之前，移除 IE6 支持是没有意义的。

关于“构建更精简的 jQuery”的 113 条想法

  1. Nick 于 说：

    做 modernizer 所做的事情，让 jQuery 的核心真正精简，然后允许我们选择不同的功能/插件添加到包中，这些功能/插件将被组合成一个自定义的 jquery js 文件。jQuery 在移动设备上绝对是可笑的，我试过它，即使是官方演示也是个笑话……动画会卡顿，而且很生硬……没有人可能使用 jquery mobile 并感到满意……

  3. VividAlex 于 说：

    我同意将 ie 6/7/8 兼容性作为插件或不同的构建方式将对我们有很大帮助。

    我们的一些应用程序是主流的，我们需要跨浏览器支持，尽管我们很讨厌它。
    但对于其他一些项目，我们有一个技术人员群体，他们非常感谢使用现代浏览器的快速加载应用程序。

    这个简单的功能会让我成为 jQuery 的坚定拥护者，因为它暗示着更美好的网络。整个经济体系都在一定程度上依赖于这种选择。你真的可以在这里有所作为。

  5. browndog 于 说：

    弃用和删除不是解决任何问题的办法，它只会制造新的问题。如果你必须这样做，请模块化，但不要删除。我可以理解，如果有人在一个小型网站或页面上使用 jQuery，从一个版本到另一个版本出现的破坏性更改并不算什么大问题，但是对于一个大型的实现来说，包含数百甚至数千个使用公共头部设置哪些 js 文件被包含的独立页面呢？如果你有一个大型的部署网站，任何破坏性更改都需要工作才能修复破坏性更改，然后需要大量的测试来重新认证和重新部署新版本（用户验收测试始终是工作量最大的部分）。

    此外，功能并不是人们迁移到新版本唯一的理由，还有错误修复和性能改进。再加上 SOX/审计要求所有生产代码都必须得到供应商的完全支持，并且必须处于当前版本/错误修复/安全修复级别。这样的决定意味着当一个网站选择使用某个框架时，它会承担巨大的责任。我认为，如果你每六个月就引入破坏性更改，你会冒失去大量开发人员支持的巨大风险。

    例如，.live() 的移除，为什么要移除它？为什么不保留该函数，而是将其变成 .on() 的辅助函数？这样你就可以获取 live 函数的参数，并使用传递的参数调用 .on()。我认为引入破坏性更改比在整体下载大小中增加几 KB 更令人不齿。请记住，带宽和计算能力一直在不断提高。而且我始终可以使用 jQuery Mobile 来处理移动设备。

  6. Hardcore 在 说道：

    微软已经声明 IE6 已死，它是一个已停止支持的产品。
    继续支持已停止支持的产品会消耗开发人员资源。
    由于所有添加到库中的新功能都需要确保它们不会破坏任何现有的功能，因此这需要将测试资源从更重要的任务中转移出来。

    将库固定在 <2.0 以支持 IE6，然后从 2.0 开始创建不包含 IE6 的新库。
    还要考虑这样一个事实，即全世界浪费了数百万 KB 的带宽，用于 jQuery 支持 IE6，而实际上它并不需要。

  7. DaisyD 在 说道：

    我认为 jQuery 2 应该

    1. 只支持 HTML5/CSS3/JS1.9
    2. 为可怜的 IE 用户推荐 ChromeFrame（是时候说再见了，IE10 或再见，IE，这样我们才能真正进行创新）
    3. 使用 AMD 来实现模块化支持

    我现在正在为我们的企业客户宣传以上 3 个要点，我认为 jQuery 以其目前的形态，在这种环境下将变得越来越不相关。

  8. Mitch 在 说道：

    我必须附议强烈希望有一个模块化的 jQuery，或者至少有一个没有遗留 IE 支持的 jQuery 版本。

    虽然我理解在某些基于 Web 的应用程序中对它的需求，但也同样有很多应用程序，人们不想支持 IE，更糟糕的是，不想承担与它相关的臃肿——以至于人们已经开始为 jQuery 制作替代品，仅仅是为了满足这个目的。

    如果 jQuery 能够站出来，掌控局面，并为人们提供选择，而不是疏远越来越多的用户群，并将开发工作转移到其他地方，那就太好了。

  9. Tibor 在 说道：

    +1 支持模块化。开发人员应该能够自己决定库的哪些部分他们需要，哪些部分他们不需要，例如整个 ajax 模块。对于压缩后的未解压缩版本，91k 并不太漂亮。

  10. Ramin 在 说道：

    “请不要放弃 IE6！它对于某些项目来说仍然很重要。至少再给它一年时间！”

    如果你需要 IE6 支持，只需使用旧版本的 jQuery。1.8+ 版本不需要专门支持 IE6。我相信一些在企业内部网门户网站上工作的超级兴奋的开发人员会很有动力去构建一个与 1.8+ 兼容的 IE6 插件，或者足够聪明，只是不使用 1.8+

  11. Ramin 在 说道：

    我不明白为什么有些人如此担心移除/弃用功能。如果你需要这些功能，只需使用/坚持使用旧版本的 jQuery 即可。如果它在你的网站上正常工作，那么现在也会正常工作。如果你仍然在为旧网站开发和提供支持，并且这些网站旨在在旧浏览器上运行，那么升级到新版本毫无意义。这是一个无稽之谈。

  12. JC 在 说道：

    我知道这是一个老话题，但我支持它。

    不需要它是模块化的，但能够像下面这样包含一些文件会很好：

    jquery-2.0.js
    jquery-1.4-support.js
    jquery-ie6-support.js