新浏览器中的老技巧 – jQuery UK 2012 的演讲

上周五,大约 300 名开发者前往英国牛津参加 jQuery UK 大会,并学习他们最喜欢的 JavaScript 库的所有最新动态。想象一下,当我走上舞台告诉他们,如今 jQuery 用来做很多事情其实并不需要它的时候,他们有多么惊讶。如果你想了解更多关于演讲本身的信息,有一个 详细的报告、幻灯片和音频录制 可供参考。

我想表达的是,像 jQuery 这样的库首先是为了给开发者提供一个公平的竞争环境。我们不应该需要了解每个浏览器的怪癖,而使用库可以让我们专注于手头任务,而不是它在 10 年前的浏览器中如何失效。

jQuery 革命性的网页设计新思路基于两大要点:通过 CSS 选择器而不是笨拙的 DOM 方法访问文档,以及 JavaScript 命令的链式调用。然后,jQuery 继续简化事件处理和 Ajax 交互,并实现了 缓动方程 以实现流畅而美丽的动画。

然而,这种简洁性是有代价的:开发者似乎忘记了一些非常简单的技巧,这些技巧允许你编写非常简洁易懂的 JavaScript,而无需依赖 jQuery。其中,最强大的技巧包括事件委托和为父元素分配类,并将主要工作留给 CSS。

事件委托

事件委托 意味着,与其为元素中的每个子元素应用事件处理程序,不如为父元素分配一个处理程序,并让浏览器为你完成剩下的工作。事件在文档的 DOM 中冒泡,并在你想要获取的元素及其每个父元素上发生。这样,你只需与事件的目标进行比较,即可获取你想要访问的元素。假设你的文档中有一个待办事项列表。你需要的全部 HTML 代码是

  • Go round Mum's
  • Get Liz back
  • Sort life out!

为了向这些列表项添加事件处理程序,jQuery 初学者可能会尝试执行 $('#todo li').click(function(ev){...}); 或——更糟糕的是——向每个列表项添加一个类,然后访问这些类。如果你使用事件委托,那么在 JavaScript 中你只需要

document.querySelector('#todo').addEventListener( 'click',
  function( ev ) {
    var t = ev.target;
    if ( t.tagName === 'LI' ) {
      alert( t + t.innerHTML );
      ev.preventDefault();
    }
}, false);

较新的浏览器具有 querySelectorquerySelectorAll 方法(此处查看支持情况),它们允许你通过 CSS 选择器访问 DOM 元素——这是我们从 jQuery 中学到的东西。我们在这里使用它来访问待办事项列表。然后,我们为列表应用 click 的事件监听器。

我们使用 ev.target 读取出哪个元素被点击,并将其 tagNameLI 进行比较(此属性始终为大写)。这意味着当用户例如点击列表本身时,我们永远不会执行其余代码。我们调用 preventDefault() 以告诉浏览器不要执行任何操作——我们现在接管了。

你可以在 此 fiddle 或下面的嵌入中尝试一下:

JSFiddle 演示.

事件委托的好处在于,你现在可以添加新项目,而无需重新分配处理程序。由于主要点击处理程序位于列表上,因此新项目会自动添加到功能中。请在 此 fiddle 或下面的嵌入中尝试一下

JSFiddle 演示.

将样式和 DOM 遍历留给 CSS

jQuery 的另一个主要用例是同时访问大量元素,并通过使用 jQuery 的 css() 方法操作其 styles 集合来更改其样式。这看似很方便,但也令人烦恼,因为你将样式信息放在 JavaScript 中。如果以后需要重新品牌化怎么办?人们在哪里找到要更改的颜色?为有问题的元素添加一个类并将其余工作留给 CSS 要简单得多。如果你仔细想想,很多时候我们在 jQuery 和样式文档中重复相同的 CSS 选择器。这似乎是多余的。

过去,添加和删除类有点像噩梦。执行此操作的方法是使用 DOM 元素的 className 属性,该属性包含一个字符串。然后,由你决定在该字符串中查找某个类名,并通过添加到或对字符串使用 replace() 来删除和添加类。同样,浏览器从 jQuery 中学习,现在拥有一个 classList 对象(此处查看支持情况),它允许轻松操作应用于元素的 CSS 类。你可以使用 add()remove()toggle()contains()

这使得为大量元素设置样式并将其单列出来以进行不同的样式设置变得非常容易。例如,假设我们有一个内容区域,并且希望一次显示一个。我们可能会想遍历这些元素并进行大量比较,但我们真正需要的只是分配类并将其余工作留给 CSS。假设我们的内容是一个指向文章的导航。这在所有浏览器中都能正常工作

Profit plans

Step 1: Collect Underpants

Make sure Tweek doesn't expect anything, then steal underwear and bring it to the mine.

Step 3: Profit

Yes, profit will come. Let's sing the underpants gnome song.

现在,为了隐藏所有文章,我们只需为文档的 body 分配一个“js”类,并将内容部分中的第一个链接和第一篇文章存储在变量中。我们为每个元素分配一个名为“current”的类。

/* grab all the elements we need */
var nav = document.querySelector( '#nav' ),
    content = document.querySelector( '#content' ),

/* grab the first article and the first link */
    article = document.querySelector( '#content article' ),
    link = document.querySelector( '#nav a' );

/* hide everything by applying a class called 'js' to the body */
document.body.classList.add( 'js' );

/* show the current article and link */
article.classList.add( 'current' );
link.classList.add( 'current' );

结合简单的 CSS,这会将它们全部隐藏在屏幕外

/* change content to be a content panel */
.js #content {
  position: relative;
  overflow: hidden;
  min-height: 300px;
}

/* push all the articles up */
.js #content article {
  position: absolute;
  top: -700px;
  left: 250px;
}
/* hide 'back to top' links */
.js article footer {
  position: absolute;
  left: -20000px;
}

在这种情况下,我们向上移动文章。我们还隐藏了“返回顶部”链接,因为当我们隐藏和显示文章时,它们是多余的。要显示和隐藏文章,我们只需为要显示的元素分配一个名为“current”的类,该类会覆盖原始样式。在这种情况下,我们将文章向下移动。

/* keep the current article visible */
.js #content article.current {
  top: 0;
}

为了实现这一点,我们只需要对导航进行简单的事件委托即可

/* event delegation for the navigation */
nav.addEventListener( 'click', function( ev ) {
  var t = ev.target;
  if ( t.tagName === 'A' ) {
    /* remove old styles */
    link.classList.remove( 'current' );
    article.classList.remove( 'current' );
    /* get the new active link and article */
    link = t;
    article = document.querySelector( link.getAttribute( 'href' ) );
    /* show them by assigning the current class */
    link.classList.add( 'current' );
    article.classList.add( 'current' );
  }
}, false);

这里的简洁性在于,链接已经指向具有这些 ID 的元素。因此,我们只需要读取被点击的链接的 href 属性即可。

请在 此 fiddle 或下面的嵌入中查看最终结果。

JSFiddle 演示.

将视觉效果保留在 CSS 中

结合 CSS 过渡 或动画(此处查看支持情况),可以通过非常简单的方式使其更加流畅

.js #content article {
  position: absolute;
  top: -300px;
  left: 250px;
  -moz-transition: 1s;
  -webkit-transition: 1s;
  -ms-transition: 1s;
  -o-transition: 1s;
  transition: 1s;
}

现在,过渡只需一秒钟即可从没有“current”类的状态平滑地过渡到具有该类的状态。在我们的案例中,向下移动文章。你可以通过编辑 CSS 添加更多属性——无需更多 JavaScript。请在 此 fiddle 或下面的嵌入中查看结果

JSFiddle 演示.

由于我们还在链接上切换 current 类,因此我们可以做更多的事情。通过使用 CSS 生成的内容和 :after 选择器(此处查看支持情况),可以轻松添加诸如“您当前所在位置”之类的视觉效果。这样,你就可以添加视觉上的增强功能,而无需在 JavaScript 中生成 HTML 或使用图像。

.js #nav a:hover:after, .js #nav a:focus:after, .js #nav a.current:after {
  content: '➭';
  position: absolute;
  right: 5px;
}

请在 此 fiddle 或下面的嵌入中查看最终结果

JSFiddle 演示.

此技术的好处在于,我们将所有外观和感觉都保留在 CSS 中,并使其更易于维护。通过使用 CSS 过渡和动画,你还可以利用硬件加速。

请试一试,好吗?

所有这些内容都适用于我们如今使用的浏览器,并且可以使用 polyfill 使其在旧浏览器中也能工作。但是,并非所有内容都需要应用于旧浏览器。作为 Web 开发人员,我们应该着眼未来,而不是迎合过时的技术。如果我上面展示的内容在 IE6 中回退到服务器端解决方案或页面重新加载,没有人会知道的。让我们构建自动扶梯解决方案——当技术有效时,它会很流畅,但在技术无效时,它仍然可以作为楼梯使用。

翻译

关于 Chris Heilmann

HTML5 和开放 Web 的布道者。让我们来修复它!

更多 Chris Heilmann 的文章…


30 条评论

  1. Vladimir Carrer

    总有一天,我们可以使用 querySelector 和 querySelectorAll 而无需担心浏览器支持,并替换所有当前的选择器引擎(如 Sizzle 等),我们也不再需要 jQuery 等大型框架,所有操作都可以用几行纯 JavaScript 完成。

    关于事件委托,我还构建了一个基于 querySelectorAll 的脚本,可以同时处理多个区域。

    语法如下

    delegate($(“.wrapper”), $(“ul>li>a,#paragraph>a”), “click”, function () {
    alert(“Bang!!!”);
    });

    所有代码都可以在此处找到:http://www.vcarrer.com/2011/05/event-delegation-javascript.html 或此处 https://gist.github.com/986000

    2012 年 2 月 13 日 上午 08:52

  2. Draeli

    感谢您提供这份清晰易懂且展示良好实践的摘要。

    2012 年 2 月 13 日 上午 09:25

  3. Mustafa

    我真的很喜欢 classList :) 谢谢您的演讲,我一直都在尝试使用它 :)

    2012 年 2 月 13 日 上午 09:31

  4. Chris

    事件委托很好 :) 但不幸的是,它在不同浏览器中的工作方式不尽相同,某些事件在 IE 中的某些元素上不会冒泡。:( change、submit
    因此,js 框架仍然是不错的选择。

    2012 年 2 月 13 日 上午 11:56

  5. Mustafa

    那么,您是否认为 js 框架最终会像 Flash 一样,因为它们不是标准?

    2012 年 2 月 13 日 下午 12:40

    1. Simon

      这两者实际上并不可比,是吗?随着原生 Javascript API 的改进,像 jQuery 这样的框架可能会变得不必要,但它们永远不会与 Flash 这样的外部插件属于同一类别…

      2012 年 2 月 13 日 下午 15:42

      1. Mustafa

        没错,但我更关注整个行业的观点,即框架。它们在我们现在使用它们的方式以及我们最初使用 Flash 的方式上有点相似。

        2012 年 2 月 14 日 上午 02:23

        1. Buzu

          不一定。面向 DOM 的框架会消失,但还有一些其他框架会在一段时间内继续存在。例如,模板框架。

          2012 年 2 月 14 日 上午 10:36

  6. Mohamed Jama

    不错,一个小错误 @ $(‘#todo a’).click(function(ev){…});
    它不是一个锚点,是吗?

    2012 年 2 月 13 日 下午 16:06

    1. Chris Heilmann

      已修复。我内心的无障碍专家对将 click 应用于 LI 元素感到畏惧 :)

      2012 年 2 月 15 日 上午 04:09

  7. Drew

    jQuery 在合并最快原生方法(如果可用)方面做得非常好,但仍然在所有浏览器中规范化所需的效果。从很多方面来说,它正在部分地成为 DOM 基于 Javascript 的 modernizr+polyfills 引擎。

    2012 年 2 月 13 日 下午 17:08

    1. Buzu

      有些事情 jQuery 做不到。它将如何实现比手动编写更好的 CSS 动画?此外,将 CSS 保留到 CSS 文件中应该是真正开发人员的生活方式。我必须承认,我并不总是这样做,但从现在开始我会尝试。

      2012 年 2 月 14 日 上午 10:38

    2. Chris Heilmann

      没错,而且它在这方面非常出色。jQuery 正在发生变化,甚至有人在讨论将所有旧版浏览器支持移到插件中。但这将意味着许多现有的实现需要进行大量重新设计。

      2012 年 2 月 15 日 上午 04:08

  8. Neil Rashbrook

    我仍然更喜欢 document.getElementById(‘todo’) 而不是 document.querySelector(‘#todo’)。

    2012 年 2 月 14 日 上午 04:51

    1. Chris Heilmann

      后者当然更灵活。前者在所有浏览器中都受支持,尽管方式有些问题(IE6 也将具有名称属性 todo 的元素报告为元素)。

      2012 年 2 月 15 日 上午 04:07

  9. Jim

    @Chris + 所有

    “你想要获取的元素及其每个父元素”。
    一个元素只有一个父元素。
    早在 Web 出现之前,人类就通过引入“祖先和后代”的概念以及“轴”的概念来递归地解决了这个问题。
    因此,人们更准确地说法应该是
    “该元素及其祖先”,
    但仍然没有指定顺序。让我们来修复它
    “该元素及其沿着祖先轴”。

    @Chris
    这个错误经常出现,我认为这通常是由于试图简化解释造成的。但由于这些是基本概念,甚至是一些普遍概念,每个人都已经很好地理解了,因此在一定程度上简化到丢失相关信息是不合适的,可能会尤其让初学者感到困惑,在这种情况下
    可能会想象循环遍历 elem.parents 以找到它包含的 div,或者认为事件被分派到 elem.parentNode 和 elem.offsetParent。

    请广而告之!

    2012 年 2 月 14 日 上午 08:15

    1. Chris Heilmann

      说得对。感谢您指正。我不确定这是否真的有问题,因为您会更详细地解释事件委托(以及插图),但很高兴看到有人关心正确的语义。我将在将来注意这一点。

      2012 年 2 月 15 日 上午 04:05

    2. thinsoldier

      “在这种情况下”
      可能会想到循环遍历 elem.parents 来查找它所在的 div

      = (

      我做过太多次了。真是羞愧。

      2012年2月16日 09:09

  10. pd

    你的第一个例子有缺陷。你的 jQuery 甚至无法工作

    $(‘#todo a’).click(function(ev){…});

    你的 HTML 中甚至没有 a 标签。

    无论如何,你的整个前提对于普通开发者来说都是错误的

    “较新的浏览器有” …

    生活在 HTML5 标准、所有实现都匹配的福音使者仙境中一定很不错。你上次在当前的实际情况中为现实世界的客户进行开发是什么时候?

    我每天都感谢 Firebug 和 jQuery 背后的现实世界传奇人物,因为他们取得了所有浏览器供应商在网络存在的三分之一时间里顽固地未能做到的事情:倾听并为当今的开发者提供工具!最新的例子是 Mozilla 对 Firebug 的可耻待遇。这是一个将 Web 开发从猜测转变为逻辑的工具。在这样做的过程中,它为其母公司 Mozilla 产品赢得了很多信誉,无论是在开发者喜爱度还是市场份额方面,当所有这些开发者告诉他们的朋友 Firefox 有多么好时。但是 Firebug 有一个很大的缺点:内存泄漏或“僵尸隔间”。Mozilla 正在采取什么措施来解决这个问题?什么也没做。相反,它正在投资开发者时间来重新设计 Firebug 的轮子。

    停止向只想让 Firebug 变得正常的开发者宣扬未来的或“现代的”或“较新的”代码!如果你真的关心开发者和开放网络,就像你的福音使者工作所暗示的那样,你将在我们所有人迁移到 Chrome 之前照顾好开发者(如果像我这样还没有迁移的人还剩下的话)!

    2012年2月15日 02:45

    1. Chris Heilmann

      正如您可以在开发者工具团队的每周笔记中阅读的那样,Mozilla 为 Firebug 项目配备了一名全职员工:https://wiki.mozilla.org/DevTools/2012-02-09 – 您也可以在博客上愉快地看到 Firebug 的进展http://blog.getfirebug.com/。欢迎您提供反馈 - 只要您保持建设性,停止人身攻击并浪费一半时间在讽刺上。至于我们为何在浏览器中构建开发工具的决定 - 这只是使浏览器成为开发平台的过程的一部分。如果您想依赖附加组件来实现这一点,那是您的选择。

      推进 Web 技术的意义在于,我们使开放网络与商定的技术成为新开发者的起点,而无需求助于库和解决方法。如果您不相信这一点,并且更喜欢做“真正的工作”,谢谢您,在我们可以解决潜在问题的同时,有人需要这样做。但请不要妨碍进步,仅仅因为您找到了一种感觉熟悉但远非舒适的工作方式。我们在这里谈论的所有技术都是开放的,并随时准备接受反馈。如果您的所有反馈都是“解决我的问题”,并且您指责人们没有做“真正的工作”和“与仙女一起生活”,为什么要浪费时间发表这样的评论?这无助于事业,而且会花费您大量宝贵的时间,而这些时间您本可以继续使用多年来的相同解决方法。如果那是您感到满意的开发环境,那就太好了。我个人已经花费了太多年的时间在有缺陷且笨拙的开发环境中工作。我认为我们有责任让未来的开发者生活更轻松。我们不会通过保持现状并保持冷静和继续前进的方式来做到这一点。

      2012年2月15日 04:01

      1. pd

        我刚刚写了超过 4000 个字符来回复这个,但我不知道它是否像需要的那样有效。因此,本着努力取得成就的精神,我将再试一次。

        > Mozilla 为 Firebug 项目配备了一名全职员工

        一个,单数,不是复数,一个。我知道这一点,这是一个常见的
        辩护。Mozilla 内部的人似乎认为一名全职
        开发者是 Mozilla 向开发者社区提供的慷慨礼物。
        是时候醒醒了
        有更多开发者正在开发原生工具而不是 Firebug。
        这需要立即解决,因为 Honza
        无法独自搬运大山或关闭僵尸隔间。

        > 正如您可以在开发者工具的每周笔记中阅读的那样
        > 团队:https://wiki.mozilla.org/DevTools/2012-02-09 – 您
        > 也可以愉快地看到 Firebug 的进展
        > 博客http://blog.getfirebug.com/

        有趣的是,你假设我不熟悉
        这些信息来源。与其假设我的回复
        只不过是另一个喷子,也许你可以把它
        看作是我在经历了多年的
        阅读此类进度报告后所能做到的最大程度的克制?为什么我会很高兴看到
        每两周修复几个小错误就被当作
        进步?也许我可能会有点生气,一个巨大的
        错误每天都比 IE6 或 HTML4 更困扰我,
        没有获得所需的资源?

        Firebug 会导致不朽的僵尸隔间

        以及

        创建一个工具来分析隔间为何还活着

        > 欢迎您提供
        > 反馈 - 只要您保持建设性,停止
        > 人身攻击并浪费一半时间在讽刺上。

        我已经提供了大量的非讽刺性、非人身攻击的反馈
        结果就是 Honza 提到了上述
        错误,即他正在等待一位开发者
        有足够的时间专注于 695348,然后 Honza *可能*,
        可能能够解决这个问题。

        你认为这足够好吗?对不起,我不认为!叫我
        人,我感到沮丧。你和你的建议一样,
        “已经花费了太多年的时间在
        有缺陷且笨拙的开发环境中”。

        我的意思是,我真的读对了吗?我们在说
        完全相同的事情,只是用不同的方式表达,并得出
        某种程度上 - 并非完全 - 不同的答案。这
        你提到的环境,你用过去
        时态来描述。仅此一项就让我想知道你是否
        现在还在积极编码,如果是,你使用的
        环境是什么?如果它仍然有缺陷,我们生活
        在这个世界上。如果你没有编码,而是宣扬 HTML5 作为解决方案,而不是修复现在正在使用和依赖的日常工具,例如 Firebug,这似乎是我们意见不一致的地方。但是我们并没有那么大的区别。

        你是一位或曾经是一位活跃的开发者。我也是。你深度参与了 Mozilla、开放网络等等。我也是。你想看到开放网络向前发展。我也是。你对 HTML5 感到兴奋,并希望它现在就出现。我也是。

        希望这可以解释我的意图并非旨在人身攻击,并且我们并没有那么大的区别。如果说有什么不同的话,我是在/曾经在攻击你的角色。Mozilla 与开发者之间的沟通太少了。hacks.mozilla 作为例外是很棒的,除了我们从它那里听到的都是未来如何做事的方法或如何做我们已经能够做的事情的替代方案。这似乎是你们内容的大部分,而这正是我感到沮丧的地方,而不是你个人。

        > 至于我们为何在浏览器中构建开发工具的决定
        > 开发 - 这只是使
        > 浏览器成为开发平台的过程的一部分。如果您想
        > 依赖附加组件来实现这一点,那是您的选择。

        这是一个多么错误的陈述。首先,欢迎来到派对!Mozilla 一直很乐意依赖附加组件,它确实如此,它已经依赖了,它将永远依赖。如果你真的认为开发者可以或应该在没有附加组件的情况下工作,那么 Firefox 多年来一直是最糟糕的浏览器,因为 Mozilla 将我们限制在通过附加组件进行开发,并且多年来对此一无所知!我个人不想依赖任何未得到积极支持的东西。这基本上就是我论点的全部内容。Mozilla 声称 Firebug 不会消失,但现实,正如你所暗示但 Mozilla 没有人诚实或有勇气承认的那样:似乎 Firebug 基本上被抛弃或重新归类为由一位 Mozilla 开发者帮助的第三方工具。

        > 推进 Web 技术的意义在于,我们使
        > 开放网络与商定的技术成为
        > 新开发者的起点,而无需求助于
        > 库和解决方法。

        新开发者?你的意思是,在某个时刻 Web 开发者社区将会冻结,并且会有新的开发者和旧的开发者,而旧的开发者不再是你的关注对象?

        > 如果你不相信这一点
        > 并更喜欢做“真正的工作”,谢谢您,有人需要
        > 在我们可以解决潜在问题的同时这样做。

        我相信开放网络。你为什么认为我长期以来一直在折磨自己支持和宣扬 Firefox?在你的脑海里,你已经把我写成了一个不接受变化的顽固分子。你的想法立即转向这种假设,也许是问题的征兆。我和其他人一样支持 Web 的发展。事实上,每当 Mozilla 在 W3C 之前进行开发时,我都会觉得很可疑(当然,W3C 的行动速度比气候变化慢)。对我来说,你要么符合标准,要么不符合。但是,我可以看到这有点清教徒式,而且不太有效。

        我提到真正的工作是为了表达像你这样的人,在你定义的角色中,似乎没有过多关注现在。它并非旨在贬低未来思考工作并非真正工作的必要性。

        > 但请不要妨碍进步,仅仅因为
        > 您找到了一种感觉熟悉但远非
        > 舒适的工作方式。

        定义“进步”?我没有妨碍进步,我妨碍了你和 Mozilla 眼中的进步。在过去的 8 个月里,我们看到了 MemShrink 上的伟大工作,但这一进步未能解决 Firebug 僵尸隔间的问题。现在,我们正在看到“进步”的形式是原生开发者工具,它们远不如 Firebug,而且在相当长一段时间内似乎都会如此。除非你当然喜欢网页的(基于附加组件的)倾斜视图?除此之外,与 Firebug 相比,原生工具提供的功能很少是新的,并且在可比性或比 Firebug 更好的功能方面提供的很少。如果进步是重新发明轮子,并且让那些使用轮子的人轮胎漏气,那么是的,我反对。但你再次把我贴上害怕变化和问题的一部分而不是解决方案的标签是错误的。这只是试图驳回和贬低你不同意的观点,基于对你观点的误解。

        >我们在这里谈论的所有技术
        > 是开放的

        以及展望未来?

        你随意使用“开放”这个词,好像我曾经暗示我反对开源一样。奇怪。

        如果这个博客背后的这些人能从我的评论中得到一件事,而不是其他任何事情,请让他们知道,更多关于解决开发者现在面临的日常问题的解决方案的文章将受到热烈欢迎。

        > 并随时准备接受反馈。如果您的所有反馈
        > 是“解决我的问题”

        我的问题?我什么时候说过?你为什么要用引号?我从未写过这是一个只属于我的问题,我要求解决。你再次误解了我的评论的性质和意图。我正在为现在在 Drupal 中编写 HTML5 的同事而战,他的 Firefox 每天至少崩溃一次。他不是一个大型附加组件用户,但他是一个开发者,所以他使用 Firebug。我为他而战是否自私?我也在为那些正确地看到了 Firefox 两年来的灾难性性能/内存灾难(正如 MemShrink 专家承认的那样)的开发者而战,这场灾难是集成所有这些 HTML5 功能的同时忽略了其间的巨大内存问题。阅读 Nick Nethercote 未经 Mozilla 公关批准的(我预计)评论,回复有关 Firefox 什么时候才能再次像 3.6 一样好的问题。他说版本 10!有点好笑的是,疯狂的主要版本每 6 周发布一次会反过来咬你一口,对吧?需要 6 个版本才能回到 3.6 的内存性能?好吧,无论主要版本编号如何,已经过去 2 年了!这两年发生了什么?Chrome 占据主导地位。

        所以,不,我说的不是“我的问题”,就像我不是一个害怕变化的顽固分子一样。我谈论的是开发者问题以及如何解决它们 - 现在!而不是在原生工具需要几个月才能与现在的 Firebug 在功能上进行比较的时间。而不是第三方开发者需要几个月才能将原生工具的怪异 UI 拥挤特性转换为类似于现在存在的更有效的 Firebug UI 的时间。

        > 并且你指责人们没有
        > 做“真正的工作”和“与仙女一起生活”,为什么要浪费时间
        > 发表这样的评论?

        我晚上会阅读 Planet Mozilla。与你不同,我没有被付钱为 Mozilla 工作。我使用我所能获得的方法,以及看起来最合适的方法(假设这个博客和其他博客比谷歌群组更 *开放* 和可见,我在这里发布而不是在 mozilla.deve.* 上发布)。

        > 这无助于事业

        我多年来一直对内存性能采取同样的方法。我在一篇博文中建议了现在被接受的 about:memory(并非声称我是它的推动力)。我建议这个问题非常严重,需要专门的资源。最后,MemShrinks 开始了(并且感谢另一个直言不讳的澳大利亚人领导)。

        所谓的喷子作为值得社区放逐的对象的概念正在逐渐被接受http://bryonycole.com/2011/12/10/the-value-of-a-troll/

        我并没有浪费时间。我在展示我对 Mozilla 和 Firefox 的忠诚和热情。Mozilla 声称自己是开放的,但可能无法容忍(诚然,比我之前的帖子写得更好,更不个人化,更有建设性)反馈,这一点一直让我担心。当然,就像 Linux 一样,“开放”的描述在 Mozilla 内部是一个神话,因为它通常只像优点或技术统治一样开放。这使得它像任何其他结构一样容易受到某种类型的人的支配。但我离题了……

        > 而且它花费了你很多宝贵的时间,你可以用来做
        > 你这些年来一直在做的同样的变通方法。

        我从未说过我的时间是宝贵的,那是你的假设。但是,我确实认为我的时间是有价值的,但我仍然愿意将其花费在 Mozilla 星球上,并通过撰写此类帖子,如果这意味着现状有所改变(我只能希望这是可能的)。

        你如此热切地谈论 HTML5 并提到我的时间管理,这很有趣。巨大的讽刺在于,我对 HTML5 感兴趣,但在工作中没有时间去研究它——因为我浪费了太多时间等待 Firefox 执行某些因 Firebug 的僵尸隔间而减慢速度的操作!

        一个很好的例子是,像你这样的布道者类型的开发者喝了 HTML5 的 Kool-Aid,并使用 section 和 aside 以及所有这些其他美化的标签建立了一个最近的项目,这些标签除了提供比具有相同 id 或类名的 div 标签略微更多的语义含义之外,什么也没做。瞧,谁最终应该修复 IE7 中的大量显示错误?IE7 不识别所有这些新标签。你猜对了,我!虽然我本可以研究和查看 normalize.css 之类的解决方案,但我却在围绕一位开发者误导性的“解决方案”进行破解,这位开发者过分关注了 HTML5 布道者所负责的那种炒作。

        所以,不,我不需要关于我的时间使用的建议,谢谢。

        > 如果那是你乐在其中的开发环境,
        > 太好了。

        呃,快乐?你再次完全忽略了我论点的前提,因为你把我贴上了“老”开发者标签,认为我是问题的一部分而不是解决方案。

        我和你一样,并不乐意“花费我生命中太多年的时间在一个有缺陷且笨拙的开发环境中工作”,但与你不同的是,我无法放弃这种生活去追求 HTML5 的梦想。我必须坚持下去,它远非快乐的状态……除非……Mozilla 修复该死的 Firebug 僵尸隔间!

        这就是我的重点!

        我需要的不多!

        > 我个人花费了我生命中太多年的时间
        > 在一个有缺陷且笨拙的开发环境中工作。
        >

        我想你指的是 Firebug 让它变得好多了吧?尽管它有缺点。如果 Mozilla 将更少的资源投入到 HTML5 等方面,而将超过*一个*资源投入到修复 Firebug 轮胎上的漏气问题,那么几年前它会更好得多?如果你对上述问题回答“是”,你就理解了我的意思。虽然我无法回到过去,而你“乐意”展望未来,但我所要求的只是将更多资源投入到当前的现在!

        求求你 Mozilla,现在修复 Firebug 僵尸隔间问题。如果你仍然怀疑我的动机,也许可以阅读我提供 MemShrink 评论的地方,我在那里主动提出用我自己微薄的开发者收入来帮助解决这个问题?

        > 我认为我们有责任让
        > 接下来的开发者更容易地工作。

        我认为 Mozilla 也应该帮助现在的开发者。

        > 我们不会通过保持现状并保持冷静和继续前进来做到这一点。

        这种二元对立的思维方式在 IT 行业中太常见了,也许并不奇怪。未来还是过去?不止于此。Mozilla 的一些人甚至现在也相信这一点。见证快速发布流程。我建议的是更多关注当前的问题。在证明原生工具比 Firebug 更受欢迎之前,至少将相同的资源分配给两者并非不合理。正如 Mozilla 始终在谈论浏览器市场:竞争至关重要。为什么不让 Firebug 和原生团队竞争,看看谁能生产出最好的产品?Mozilla 在与 Google 的交易中获得了更多资金。虽然我相信有很多方法可以花费它,但如果 Mozilla 真的关心开发者,仍然重视附加组件以及支持它们的*志愿者*开发者社区,那么增加 Firebug 的资源并不是一个困难的决定。

        2012 年 2 月 15 日 上午 06:02

        1. Chris Heilmann

          我已经将你的评论转发给了开发者工具团队,因为这实际上是你在这里讨论的内容——好吧,实际上是 Firebug。这有点偏离主题,并且没有对眼前的问题有任何帮助。

          你让我思考了要在这里放置什么内容——不是改变,而是思考,我将在未来的几篇文章中解决这个问题。

          至于我据称把你归类,这似乎是一个双向误解。我永远不会停止成为一个“梦想家”——抱歉。

          2012 年 2 月 15 日 上午 07:04

        2. Kevin Dangoor

          嘿 pd,

          我确实感谢你对这个主题的热情,尽管我们显然意见不一,我认为我写的任何东西都无法改变这一点。

          负责 Mozilla 开发者工具的人与负责 Memshrink 的人并非同一人。Memshrink 项目有很多活动部件,这是一个复杂的系统。从我在错误中看到的情况来看,他们在不同的角度努力追踪问题。Memshrink 非常重要并且正在引起关注,但我相信这些开发者除了还有一些其他的功能正在开发中。

          关于 Firebug,我已经清楚地听到你说,你认为我们应该在 Firebug 上投入更多资源。重复断言并不能证明这一点。

          > 在证明原生工具比
          > Firebug 更受欢迎之前,至少将相同的资源分配给两者
          >

          是的,这实际上是不合理的(至少在我看来)。我们选择了一条我们认为符合项目最大利益的道路,并且我们知道到达那里需要大量的努力。在传说中的“人月神话”和可用资源的限制下,我们希望尽快到达那里。

          我在 Firefox 10 发布后阅读了*大量*的反馈,并且很多人赞赏我们前进的方向。有些人,比如你,不赞赏。这很好,每个人都有自己的看法。

          使用你喜欢的工具。

          Kevin

          2012 年 2 月 15 日 上午 07:08

  11. Marcus Tucker

    我发现很难调和你早期评论中“jQuery[最初]存在的首要目的是为我们开发者提供一个公平的竞争环境。我们不应该了解每个浏览器的怪癖,而使用库可以让我们专注于手头任务,而不是它如何在 10 年前的浏览器中失败。”与你后来提出的放弃使用 jQuery 的 .addClass/.removeClass/等函数并改用新的浏览器原生 classList 对象的建议之间的隐含矛盾,因为根据https://mdn.org.cn/en/DOM/element.classList#Browser_compatibility,它不受任何当前版本的 IE 支持,尽管它可以使用 polyfill,但这会增加很大的复杂性,同时与继续使用 jQuery 提供的函数相比,提供的实际好处微不足道。

    事实上,具有讽刺意味的是,我认为这是一个 jQuery 能够简化我们工作、消除此类差异的完美示例,即在存在的情况下内部检测并使用本机 classList 对象,而在不存在的情况下继续操作 className。

    Drew 的评论“jQuery 非常善于在可用时合并最快的本机方法,但仍然在所有浏览器中规范化所需的效果。在很多方面,它正在部分地成为 DOM 基于 JavaScript 的 Modernizr+Polyfill 引擎。”反映了我自己的想法,当然,jQuery 永远不会成为浏览器兼容性的灵丹妙药,也不应该尝试对所有功能进行 polyfill,必须找到平衡点。

    2012 年 2 月 15 日 上午 06:13

    1. Marcus Tucker

      PS——虽然可以肯定地说,在没有 jQuery 的情况下执行事件委托已被许多熟悉 JS 的人(包括我自己)所“遗忘”,但 classList 对象是相对较新的,因此它也不符合你关于“遗忘”的一般主题/抱怨。

      2012 年 2 月 15 日 上午 06:20

    2. Chris Heilmann

      我从未声称当你使用 jQuery 时,你应该用它代替 jQuery 方法。我想要表达的是,如果你需要支持所有浏览器,那么请使用 jQuery。但这并不意味着你需要用 jQuery 编写所有内容。我们需要在这里找到一个使用平衡点——当人们不使用这些功能时,浏览器为什么要费心添加对这些功能的原生支持?IE6 已经阻碍了我们足够长的时间。

      2012 年 2 月 15 日 上午 06:25

      1. Marcus Tucker

        那么听起来我们都同意在 jQuery 是最佳方法时对其进行平衡和务实的运用,而不是盲目地将其用于所有事情——这篇文章给我的感觉并非如此。

        并且对 IE6 令人痛苦的缓慢死亡表示赞同!;)

        2012 年 2 月 15 日 上午 06:55

  12. Hannes Hirzel

    我认为这篇文章作为一种提醒非常有用,即使用事件委托和 querySelector 以及 querySelectorAll(https://mdn.org.cn/en/DOM/document.querySelectorAll)涵盖了 jQuery 应用程序的很大一部分。“toDo”示例具有说明性。让我们使用这些可能性。
    David Flanagan 在他的书《JavaScript 权威指南》第 6 版中有一个完整的 classList polyfill。它只有一页多一点(第 438 页)。

    评论“jQuery 在很多方面正在部分地成为 DOM 基于 JavaScript 的 Modernizr+Polyfill 引擎”也很有帮助。

    2012 年 2 月 20 日 上午 01:46

  13. Billy

    网络现在乱成一团糟,我们还在用 CSS3 中无用的下雪效果、供应商前缀、HTML5 样板文件、我们可以想到的每一件小事的 JavaScript 回退、新的无意义 JS/CSS 库、新的这、新的那、Coffeescript、Less、乱七八糟、Sass、屁股……等等等等……东西、东西,还有更多的东西!

    网络、互联网和墙壁插座都是建立在标准和协议之上的。遵循标准,忽略所有其他干扰!

    2012 年 3 月 23 日 下午 18:38

  14. Abolfazl Beigi

    非常感谢。非常有用。

    2012 年 9 月 6 日 下午 13:51

本文评论已关闭。