jQuery 1.8 版本征集意见

关于“jQuery 1.8 版本征集意见”的 108 个想法

1. Greg Surrett 于 2011 年 11 月 22 日 下午 1:39 说：

   我认为应该有一个“answerToTheUltimateQuestion()”函数，当调用它时，它返回数字“42”。我认为这将使 jQuery 变得完整。
2. Gustaff Weldon 于 2011 年 11 月 22 日 下午 1:54 说：

   模块化的 jQuery，带有 require() 和（自动）延迟加载所需的依赖项。
3. Josh 于 2011 年 11 月 22 日 下午 2:10 说：

   jQuery 被誉为将 JavaScript 从灭绝边缘拯救回来，这主要是因为它满足了三个关键需求：跨浏览器支持、易于使用的语法和通过 CSS 选择器访问 DOM。

   在跨浏览器支持方面，如果没有开发人员理解 JScript 和 JavaScript 之间的根本区别以及 IE 之间的错误和内存泄漏，JavaScript 开发将非常困难甚至不可能进行。此功能对于“弥合差距”和使在任何浏览器上都能正常工作的交互式网站的开发成为可能至关重要。

   如今，浏览器支持矩阵实际上更加复杂，在 Android、iPhone 以及即将推出的 Windows Phone 和桌面客户端 JavaScript 支持（例如 Windows 8）上存在大量变体。虽然旧版浏览器的使用量确实在下降，但仍然有足够多的用户使用旧版浏览器（例如 IE6-8），因此有必要在 jQuery 中继续支持它们。

   基于此，我提出两条建议

   1. 不要放弃对旧版浏览器的支持。

   2. 添加或增强移动浏览器和现代浏览器的功能，特别是在增强 DOM 和 JS 性能方面。
4. Thomas Jane 于 2011 年 11 月 22 日 下午 2:10 说：

   请放弃对旧版浏览器的支持！
5. Thomas Jane 于 2011 年 11 月 22 日 下午 2:13 说：

   如果我们仍然支持旧版浏览器，那么人们永远不会升级它们。IE6 的开发者肯定不会使用 jQuery 1.8。
6. Matthew 于 2011 年 11 月 22 日 下午 2:28 说：

   我最近在 Adobe AIR 应用程序中使用了 jQuery，不是因为我需要消除浏览器不一致性（当然），而是因为它使用起来很熟悉，有很棒的辅助函数，而且它允许使用一些 jQuery 插件。

   所以，从开始做“针对性捆绑”的 jQuery 会很棒，这样我就可以选择运行时环境。例如，我只需要最新的 Webkit。其他人可能只为 iOS 做 PhoneGap 应用程序（这又只会是 Webkit）。虽然可能不会减少很多代码，但每一部分都有帮助，不是吗？
7. ivan quintero 于 2011 年 11 月 22 日 下午 2:30 说：

   保留对旧版浏览器的支持。有时大型公司有他们自己的（愚蠢的）理由继续使用旧版浏览器，而删除对旧版浏览器的支持将意味着我们中的一些人将无法再使用 jQuery。
8. Thomas Jane 于 2011 年 11 月 22 日 下午 2:41 说：

   这些所谓的公司可以使用早期版本的 jQuery，它们不会死。为什么他们强迫我们看 3D 影院里的黑白电影？
9. lynn eriksen 于 2011 年 11 月 22 日 下午 2:55 说：

   考虑创建一个“遗留”的 .js 脚本，允许向后兼容，同时仍然能够清理 jQuery 本身。
10. Paul Irwin 于 2011 年 11 月 22 日 下午 3:05 说：

    我也不相信放弃对其他浏览器的支持，除非这样做能带来显著的性能或大小优势。从这篇文章的语气来看，没有这种优势，所以没有充分的理由放弃 IE6，只是为了折磨人们让他们升级。

    在今年参加了波士顿的 jQuery 大会之后，我希望看到类似于 AmplifyJS（我从大会上最喜欢的演讲）的发布/订阅模型被构建到 jQuery 核心之中。这是一种将你的 JS 代码松散耦合的非常平滑的方式，我认为 jQuery 应该更好地鼓励人们通过各种模式来编写更好的 JS 代码。我认为 jQuery 唯一的缺点是，虽然它易于接近，但它却微妙地鼓励新手编写难以维护的 JS 代码，例如在 $(document).ready() 块（或多个块）中包含所有内容。发布/订阅鼓励更清晰的职责分离，例如将 UI 逻辑与业务/验证逻辑和 AJAX 逻辑分开。
11. Ulysses 于 2011 年 11 月 22 日 下午 3:24 说：

    请解决问题 7442！
12. Daniel Herman 于 2011 年 11 月 22 日 下午 3:39 说：

    我赞成添加一个官方认可的发布/订阅插件（基本上将 $.Callbacks 文档页面上的内容复制粘贴到一个插件中，然后获利）。

    虽然文件大小是一个重要的因素，但我认为性能应该更重要。随着移动网络越来越流行，也许关注性能增强将极大地有利于 jQuery Mobile，并使普通的 jQuery 应用程序更快。
13. Dylan Greene 于 2011 年 11 月 22 日 下午 4:31 说：

    帮助我们减少代码量，尤其是在代码缩短器无法帮助的地方。

    例如

    $(…..).on(‘click’, function() {
    var element = $(this); // <- 为什么不能将此或其中一个参数作为 jQuery 对象？
    });

    或者

    $(…).on('click', { a: handle1, b: handle2, c: handle3 });
14. gianlucaguarini 于 2011 年 11 月 22 日 下午 4:35 说：

    为什么不使用 window.requestAnimationFrame 来进行动画？当然，添加 setInterval 作为回退。
15. Dylan Greene 于 2011 年 11 月 22 日 下午 4:38 说：

    一种详细的调试模式，可以向开发人员显示他们何时没有正确/理想地使用 jQuery 库/使用最新的 API。

    理论上，这将有助于我们编写更好的代码，并找出我们应该丢弃或重写的插件。

    库的最小化版本将不包括调试模式代码。

    （类似的东西几年前就存在，但作为一个独立的项目难以维护。）
16. Berserk 于 2011 年 11 月 22 日 下午 7:57 说：

    @Thomas Jane

    > IE6 开发人员肯定不会使用 jQuery 1.8。

    这与开发人员无关，而是与用户有关。开发人员说（正如我们在工作中所做的那样）不支持 IE6 是一回事，但 jQuery 暴露给使用 IE6 的这么多人，所以它还没有权利（还！）删除 IE6/7 的特例。
17. shawn 于 2011 年 11 月 22 日 下午 8:28 说：

    你们应该创建一个类似于 uservoice 的网站，让用户可以在上面公开投票/评论问题，而不是通过博客评论和 Google 电子表格来完成。
18. Seth 于 2011 年 11 月 22 日 下午 8:55 说：

    作为一个在企业环境中使用 jQuery 的人，我可以说像 .attr() 到 .prop() 这样的重大更改阻碍了我们升级。这些更改可能需要我们花一年时间才能完成，如果我们能确定正确的优先级的话。请确保无论你做什么，都不要做得太快。我们仍在使用 1.5.3……我们正在努力升级！:)

    只要更改不需要我们进行除 .attr() 更改之外的任何重大改动，我们应该能够应对。
19. Seth 于 2011 年 11 月 22 日 下午 8:58 说：

    我还希望看到更多对移动设备事件的支持，例如滑动、方向、按住时间等。我们被要求支持 iPad 和 iPhone，并且必须使用第三方才能处理简单的事件。
20. sun 于 2011 年 11 月 22 日 下午 9:10 说：

    对于 IE，你只需要支持 IE8+
    对于 Firefox 和 Chrome 以及其他浏览器，你只需要支持最新版本。
21. Shawn 于 2011 年 11 月 22 日 下午 9:41 说：

    同意 Seth 的说法，在最近的几个主要版本中，几个关键模块已经更新，例如 ajax、attribute、event，不知道下一个是什么。对于这些版本，已经做了一些重大更改，从代码库和插件方面来说，我们需要修改和测试，这将是一项相当大的工作量。所以对我们来说，停留在 1.5.2 是正确的选择，从功能上来说，它已经足够了。
22. quiz 于 2011 年 11 月 22 日 下午 10:42 说：

    创建两个版本的 jQuery：一个适用于所有浏览器，另一个适用于新（或不久的将来）的浏览器。第一个用于兼容性，第二个用于性能和 html 5。第一个包含所有功能（旧的和已弃用的），第二个包含较小的功能子集，但具有相同的名称和参数。这两个版本可以在同一个网站上使用。
23. Eko Kurniawan Khannedy 于 2011 年 11 月 23 日 上午 1:23 说：

    支持所有 HTML 5 功能：D
24. Stefano Zoffoli 于 2011 年 11 月 23 日 上午 4:33 说：

    你看到这个了吗？https://github.com/mythz/jquip
25. Tim Wright 于 2011 年 11 月 23 日 上午 8:12 说：

    当然要模块化库，像 modernizr 这样的构建器会很棒。触摸事件是必须的。
26. David Sparks 于 2011 年 11 月 23 日 上午 10:26 说：

    我不是 jQuery 高级用户，但我尽力而为。我难以使用 .change 函数。需要有更健壮、更通用的方法来监视像下拉框这样的对象是否发生了变化。不知道这是否有帮助：)

    然后插嘴

    两个版本的 jQuery 听起来很糟糕。我理解背后的逻辑，但这只会造成混乱。更新的浏览器只需要在旧的浏览器上进行分层。渐进增强等等。不得不自己构建脚本将是一件痛苦的事情。
27. Phillip Senn 在 2011 年 11 月 23 日上午 10:31 说：

    如何创建一个图标，上面写着“本网站使用 jQuery！”？当您将鼠标悬停在其上时，该图标可以像独角兽跳过彩虹一样进行动画。
28. Andrée 在 2011 年 11 月 23 日上午 11:11 说：

    我认为某些区域应该被弃用（并在 2.0 中删除）或更改以简化 API 方法。

    * .size() – 删除，只是一个 ‘return foo.length’ 的包装器；
    * .stop() – 更改为 .animate(‘stop'[, true])
    * $.browser – 删除并移至插件（如前所述）
    * 发布/订阅 – 在核心代码中添加轻量级（+ 可扩展）功能，或许可以重构事件系统，以便在没有事件开销（事件对象等）的情况下实现此功能。
    * 使用 requestAnimationFrame 返回（如果可以解决，我认为可以解决）
    * 将项目中的不同 js 文件模块化，例如，只加载 core+ajax、core+dommanip 等。

    这些是我能想到的。
29. Robert 在 2011 年 11 月 23 日上午 11:27 说：

    作为 jQuery 的企业/网页设计师用户，我只希望 jQuery 具备两点：速度和便利性。这两点对我们来说密切相关。我们总是从 CDN 使用 jQuery，因为它的大小——而加载它速度最快的办法就是从 CDN 获取它，并希望它已经缓存在其他地方。

    我真正想要的是 jQuery 模块化，就像 jQuip 的初始工作 https://github.com/mythz/jquip 一样。这样，如果需要，我就可以包含/加载所需的功能。
30. Nathan Campos 在 2011 年 11 月 23 日下午 12:20 说：

    我希望 jQuery 的所有核心过渡和效果使用 CSS3 而不是 Javascript 定时器。
31. Blaise Kal 在 2011 年 11 月 23 日下午 1:58 说：

    我认为模块化应该是即将发布的版本的主要重点，因为我认为 jQuery 的功能已经很完善了。

    您只能通过弃用路线抛弃 jQuery 的一小部分。模块化，用户将包含他们需要的功能。

    我读过 jQuery 团队关于模块化的担忧，但我不同意。

    – CDN 可以托管“完整”的 jQuery，包含所有模块。（顺便说一句，Google 也托管模块化的库）
    – 插件应该指定它们的 jQuery 模块依赖项
    – 异类功能仍然应该作为单独的 jQuery 插件

    当然，模块化在文档、插件使用和调试方面需要额外的工作。但这正是我们付钱给你的……哦，等等……
32. Robert 在 2011 年 11 月 23 日下午 2:36 说：

    我不同意不创建类似 jQueryUI 或 Modernizr 的模块化下载生成器的理由。

    如果我下载了完整版或链接到 CDN，我当然希望世界上所有的插件都能正常工作。

    ..但是，如果我构建了一个模块化的下载，当然意味着我非常清楚自己在做什么以及我的网站正常运行需要哪些依赖项，对吗？:)

    我唯一希望下载生成器能正确完成的事情是管理 jQuery 本身对自身的任何内部依赖项。

    您甚至建议最终通过 closure compiler 的高级选项提供此功能，这与您关于破坏插件的第一个声明相矛盾……如果有人使用它，这将导致这种情况：)

    我非常希望选择模块化。

    ..只是我不希望通过 github 安装 linux/ant 来检出项目并开始配置 closure compiler 之类的东西。

    我只希望在一个网站上勾选 5 个复选框，然后点击下载：)

    插件兼容性，我毫不关心。几乎任何您想完成的事情，都可以用几行 jQuery + css 来完成（这确实是 jQuery 的闪光点！）。更不用说，那里 90% 的插件……代码质量很差 :(……您网站上的模块越少，您的网站越不容易出错。
33. Matthew Nuzum 在 2011 年 11 月 23 日下午 3:58 说：

    两个有用的功能

    1. 如上所述，简化触摸事件的使用，以便更容易使用手势和长按

    2. 像 Knockout.js 这样的功能，与 Ajax 相连，简化了对服务器数据的监视。这将提高使用 jQuery 的大型应用程序的可维护性。
34. Daniel Herman 在 2011 年 11 月 23 日下午 4:10 说：

    这是一个更大的想法，很可能应该推迟到 2.0，因为它会导致非常糟糕的破坏性

    将 jQuery.each 更改为委托给本机 .forEach（如果可用）。

    这将使任何在原型函数中使用 this.each(..) 的操作更快，并且任何在代码中使用 .each 执行其他目的的人也将从中受益。

    迭代器函数中反向参数的问题导致了现在的糟糕情况 :(
35. Xavier 在 2011 年 11 月 23 日下午 6:24 说：

    删除对旧浏览器的支持将是一个严重的错误！

    虽然它们得到维护并占据相当的市场份额，但它们必须得到支持。正如上面评论中所说，这仅仅是为了用户。

    性能很重要，但用户至上。

    此外，jQuery 的模块化似乎是必须的。如果以 AMD 模块的形式提供，它甚至可以避免对 jQuery 和 $ 全局变量的需求，这始终是一件好事，它甚至可以允许使用不同版本的 jQuery，以实现向后兼容性。
36. Petah 在 2011 年 11 月 23 日晚上 10:01 说：

    outerHtml()
37. Petah 在 2011 年 11 月 23 日晚上 10:02 说：

    哦，还有模板。
38. Cil 在 2011 年 11 月 24 日上午 9:48 说：

    我希望看到 ajax 事件（‘ajaxError’，‘ajaxSuccess’，……）在 ajax 命名空间中。
39. Jack 在 2011 年 11 月 24 日上午 11:42 说：

    提供用于与文件交互的内置函数。例如，您现在甚至可以在没有 apache 的情况下获取 txt 文件，为什么不提供更多现成的函数来获取文本呢？

    添加更多有关命名空间的示例也是一件好事。
40. Robert 在 2011 年 11 月 24 日下午 12:35 说：

    Jack，您想要文本吗？
    尝试 $.load() 和 $.get()（参见文档），再简单不过了。
41. foobar 在 2011 年 11 月 24 日下午 1:42 说：

    代表所有真正重视访客的网页开发者，感谢您保持对旧浏览器的支持。继续努力！
42. raziel057 在 2011 年 11 月 24 日下午 1:57 说：

    jQuery 在功能方面似乎已经很完善了！您可以尝试使其更快，但它已经是非常棒的 JS 框架了。

    我建议你帮助开发 jQuery UI，它似乎进展缓慢……尽管这是一个广泛使用的库。
43. JohntheFish 于 2011 年 11 月 24 日 下午 2:45 说：

    jQuery 对我来说已经足够快了，硬件和通信速度越来越快，而不是越来越慢。

    另一方面，浏览器应用程序越来越复杂，因此我们需要更多帮助来测试和调试它们。

    正如已经提到的，我希望看到一个带有内置诊断、日志记录、参数检查和有用错误消息的开发版本。 使用它来使代码正确，然后切换到没有所有诊断膨胀的正常 jQuery 用于生产。
44. lior 于 2011 年 11 月 24 日 下午 5:32 说：

    请支持 jqtouch。我不知道到底是什么问题，但从 1.4.2 开始，更新版本与它配合得不好。
    我知道 jqtouch 应该与 jQuery 配合使用，而不是 jQuery 与 jqtouch 配合使用。
    但之前是可行的，所以如果你能解决这个问题，那就太好了。
    无论如何，谢谢。
45. Robert 于 2011 年 11 月 25 日 上午 4:10 说：

    @lior jQTouch 已经死了（并且是非官方的），创建者后来被 Sencha 聘用。jQuery Mobile 是官方的。

    * 关于模块化下载

    如果模块化真的不可行，我至少希望看到一些努力来获得 jQuery 的移动专用版本。

    你可以将所有旧版浏览器内容（嗯……与实际上只在桌面系统上可用的浏览器相关的所有内容）移动到另一个模块，然后能够为需要的人生成完整版本，以及为需要更轻量级版本的人生成轻量级移动专用版本（如 zepto）。

    我们公司刚来了一位新主管，他在移动市场拥有 30 年的经验，更确切地说是在移动 JavaScript 小部件方面。

    他就像所有人一样：jQuery 和其他库很糟糕，因为存在性能问题，而且我们必须手动完成所有操作，并针对每个手机进行精确的优化。

    虽然我同意 jQuery 的体积开始变得很大，但我一直看到你们疯狂地尝试跨浏览器使 API 标准化，并花费大量时间进行优化（从 1.2 开始使用它，从不回头）。

    我无法想象尝试支持移动设备上的 20 个不同浏览器带来的编码噩梦，更不用说每个版本的特定错误了。 这也是 jQuery 发光的地方……它就是有效，让我们专注于重要的事情：构建产品！

    继续努力，希望将来看到更多速度/大小优化！
46. Marush Denchev 于 2011 年 11 月 25 日 上午 5:55 说：

    首先我必须说我非常喜欢 jQuery – 它让我的生活更轻松！

    模块化是你们（我们）应该认真考虑的事情。 例如：我有一些项目只能用选择器引擎（Sizzle）和事件处理核心完成。 我不需要效果或 DOM 操作。

    我知道实现这一点并不容易，但这值得付出努力。

    另一方面，我认为 jQuery Mobile 不应该依赖于 jQuery 核心，它应该有自己的生命。

    干杯！
47. Phil Ricketts 于 2011 年 11 月 25 日 上午 8:40 说：

    不要删除旧版浏览器支持。

    有人说，为 IE6 制作的网站不需要最新的 jQuery。

    如果您的新网站由于过时的政府/教育部门而需要 IE6 支持，为什么您要拒绝这些用户使用最新 jQuery 版本带来的更快的下载和性能优势？
48. Foo bar 于 2011 年 11 月 25 日 上午 9:58 说：

    尖锐的批评。 不要开始对我大喊大叫，进行一场涉及人身攻击的火焰战。 这些是您的库存在的严重问题，也是我开始慢慢讨厌它的原因。

    1. 删除一堆导致页面迟钝/缓慢的无用垃圾。 你支持事件委托，停止支持单个事件绑定。 停止坚持对象树结构是字符串。 不要鼓励人们编辑大型 CSS 对象，而他们应该只编写 CSS 类。 停止在 for 循环内使用 sizzle 进行查询，因为人们没有缓存元素。 这是大多数人使用您的库的方式，它正在使网络成为所有人的缓慢污秽之地，而且不知何故，“计算机越来越快”被认为是对这个问题的可以接受的答案。

    2. 在某处，“少写”变成了“停止理解代码的真正含义”。 这必须停止。 jQuery 不应该试图取代 DOM 方法。 看，.attr 只是为了后来回来使用 .prop 而创建的——当很多人花了很大力气在最初创建这些方法时，但不知何故 element.checked=true 比 $(element).attr(“checked”, “checked”) 更令人困惑，这破坏了语义，对于许多使用过这个库的人来说仍然是一个问题。

    3. API 非常荒谬，文档充满了噪音，你已经是 PHP 的小弟了。 这应该成为优先事项。
49. Raynos 于 2011 年 11 月 25 日 上午 10:21 说：

    Foo bar +1
50. Heinrich Göbl 于 2011 年 11 月 25 日 上午 11:04 说：

    1. Underscore.js
    集成 Underscore.js 库会很棒。
    它很小并且非常方便，但某些方法存在于不同的名称下。

    2. 在 jQuery-Base（无头，例如用于 Node.js）和 jQuery 用于浏览器环境中模块化 jQuery。

    3. 在 Selenium 中作为替代选择器进行完全集成。
    好的，这对于 1.8 来说有点跑题，但这只是一个愿望 ;-)