BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

jQuery作者John Resig:WebKit就是浏览器引擎中的jQuery

| 作者 彭超 关注 0 他的粉丝 发布于 2013年2月15日. 估计阅读时间: 9 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

JavaScript领域的神级人物,jQuery、《Pro JavaScript》与《JavaScript Secrets》的作者, Khan Academy计算机科学学院的院长John Resig,在看到Opera浏览器切换到WebKit引擎的新闻,以及Twitter上许多咬牙切齿的争论后,忍不住在自己的博客发表了一番见解,英文原文在此。他觉得大家对这件事的反应让他感觉回到了2008-2009年,而现在已经是2013,Chrome/Chromium团队已经通过自己的成绩向大家证明了当使用WebKit的时候,可以不用担心发生停滞的步伐或者创新的缺失,反而还能在实现通用Web标准的时候少花很多时间。他还认为,WebKit在这一点上发挥的作用,就像jQuery对JavaScript一样。

在Opera切换浏览器引擎这件事上,John总结了他见到的几种典型言论,并一一加以点评:

浏览器切换到WebKit会导致浏览器引擎发展停滞

很明显这不是真的。KDE创立了KHTML,在KHTML的基础上Apple创立了WebKit,而Google在它的基础上创立了WebKit/Chromium。我相信任何人都能指出,相比Safari来说,Chome/Chromium比Safari更好,而Safari比Konqueror更好。Chrome团队已经证明了在选择使用WebKit时,作为WebKit的项目贡献者,他完全有能力将WebKit驶向你想要去的方向(一般来说是去更好的方向)。我完全相信拥有高素质开发团队的Opera也会做类似的事情。他们完全可以在WebKit上实现相当数量的Opera独有特性,这些特性之后又非常可能会流向其他也使用WebKit作为引擎的浏览器。

这会帮助WebKit成为一个事实上的标准

我没看到比这更中肯的观点了——WebKit已经是事实上的标准。比如,每个人都清楚浏览器早就实现了带有诸如‘-webkit’这样的特性。很显然,WebKit成为事实标准这件事儿早已经深入人心。当然,Bugs也是。WebKit是一个由许多浏览器厂商贡献代码的公共代码库,然而,每个浏览器厂商都可以改变他们自己的代码分支。我认为已经拥有事实标准的WebKit的bug们肯定会被浏览器厂商修复,但引擎中有bug并不代表浏览器厂家没有修复能力——他们可能故意不去修复这些bug(就像浏览器厂家们目前正故意克隆那些-webkit前缀一样)。

就像JavaScript库一样,事实上大家都已经把jQuery当作了标准。但是这并没有导致发展的停滞。这还导致出现了很多构建在jQuery之上的,高层流行框架的产生,比如Twitter BootstrapHTML5 Boilerpalte,和Backbone.js

这会妨碍Opera影响Web标准的能力

我不认为Opera切换到WebKit会导致这个情况发生。但我确实看到Anne van Kesteren从Opera跳槽到Mozilla确实是Opera推进Web标准能力的巨大打击。但我对内幕一无所知,但是如果他的跳槽是源自这次浏览器引擎的切换,那么Opera影响Web标准的能力确实遭受到了损失。

Opera切换到WebKit是在走下坡路/Opera份额太小,如果Firefox或者IE切换到WebKit那会是一个大问题

我认为有一点已经非常清楚了:目前WebKit在移动端已经非常明确的大获全胜。包括即将切换到WebKit上的Opera Mini/Mobile,WebKit几乎是市面上绝大多数移动浏览器所选用的唯一渲染引擎。如果任何其他浏览器想要在移动世界占据一席之地,那它必须和WebKit在功能上保持一致。让我们在此得到一个逻辑上的结论:在移动世界已经被WebKit统治的情况下,为了保持同步,Mozilla和Microsoft将会感受到巨大的压力来迫使他们将自己的浏览器也切换为WebKit。Google已经通过Chrome证实了使用WebKit并不会导致发展停滞,其他公司更没有理由不来继续打造WebKit(有可能会创造WebKit的混合体,比如WebKit+IonMonkey)。

这些问题都归结到这个大问题:他们(Mozzila,Microsoft)应该切换引擎吗?

老实说,在这一点上,对Mozilla和Microsoft来讲,这成了一个商业问题,或者是工程问题。如果你的一些开发者要花他们所有精力去实现别人正在实现的相同标准,那么切换到一个公共的代码库(指WebKit,编者注)将会解放你的劳动力,让你可以做点儿别的事情。你可以看到Chrome的例子:他们解放出的生产力全面投入到了性能的竞赛上。这个打造最快浏览器的比赛促进了大家共赢的结局。

最后,我们一定要了解,WebKit并不是一个完整的实体。他是一个有多家公司贡献代码的共享代码库。(从这方面来说,这和jQuery并不相同:几乎所有的jQuery代码贡献最终都回到它的主代码库,而WebKit的有些更新则只保留在分支之中)。使用一个共同的代码库并不意味着这是浏览器开发的一切,更不是浏览器开发的终结。在一个共享的代码库中仍然可以有持续不断的创新,它的性能也当然会一直提升下去。

在原文评论中我们看到,即便是这种重量级人物的发言,也会引来大量吐槽。大家赞同John对WebKit的认可,但是不少人对于jQuery的部分却不那么满意。用我们熟悉的词来形容,就是“楼盖偏了”:

mitch:我很了解John和jQuery,所以我不得不承认这是一个负面评论:我认为jQuery只是JS框架中的IE7而已。所有我见到在使用jQuery的人都把代码搞的一团糟,毫无结构可言。毫无疑问,jQuery非常强大,但是它被自己局限住了。我可不认为WebKit是浏览器中的jQuery。

michael camden :@mitch我可不太赞同你的观点。jQuery把代码结构的问题完全留给了程序员。jQuery非常灵活,它只是并不像那些庞大的框架一样去强制要求你按照固定格式书写代码而已。

Mark V :完全同意Mitch对jQuery的观点。

jQuery只是在JS的顶层做了一些事情,而为了这一点,它向很多短视的利益屈服了。而这是很多大的JS项目根本不看中的。如果所有的浏览器都向WebKit迁移,这可能还不错(比如没有IE7-9的烦恼了,真棒),但是长期来讲这伤害到了整个Web开发产业。

还记得IE6吗?当它刚发布的时候吗?当时它还是一个相当不错的浏览器。最起码比IE5强多了。所以当时所有人都在IE6下写代码,和bugs为伍,适配网页布局和引擎的怪异模式。一片祥和,不是吗?而10年后,它却成了Web开发行业里最沉重的负担。

当人们开始在单一环境下编写代码,并开始利用它的bug来实现各种特性的时候,标准就不再重要了。各种实现成了新的标准。

特别说明:Backbone是可以脱离jQuery运行的。(编者注:这位仁兄最后还不忘吐槽。)

Rob :一个更恰当的比喻应该是Linux内核。Chrome就像Ubuntu,Safari是Fedora,Opera,我估计应该算Mint或者Arch。

更多有趣的留言,大家可以点击此处查看英文原文

对于此事现在业界众说纷纭,JavaScript的另一位大神Douglas Crockford怎么看?敬请继续关注InfoQ的后续报道。也欢迎各位留言讨论。

友情提示:InfoQ中文站现在已支持Google和MicroSoft账户登陆。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

翻译问题 by shi mike

原文“@mitch I can’t disagree with you more”,我觉得不是“@mitch我真是太赞同你的观点了。”,而是“我很不赞同你”的意思。同样的,后面的“Code structure is ultimately left to the developer. jQuery is flexible in that it doesn’t force you in to a structure like a more monolithic framework would.”应该说的是jQuery的优点,就是不强迫你一定要符合某种结构,非常自由的意思。

另外,Mark的“所以当时所有人都在IE6下写代码,和bugs为伍”,原文是“So everyone and his dog were coding to IE6, working around bugs”,这里work around应该是绕开,排除(错误)的意思,而不是“为伍”的意思。

当然,我英文一般,仅作交流用。可能是我理解的错误。

Re: 翻译问题 by Peng Chao

Hi Mike,第一个确实是我翻译错了,非常感谢,马上修改。第二个我刚才又琢磨了一下,觉得并不像是明确在说绕开bug的感觉。因为在当时的编程环境下,也确实有很多写法是在利用bug来实现。欢迎继续讨论:)

Re: 翻译问题 by Wei Zijun

"I can’t disagree with you more" 就是 非常赞同 的意思吧? 没翻译错吧

Re: 翻译问题 by Wei Zijun

work around 可以理解为"绕开", 但是我觉得在这个上下文里就是"围绕...展开/进行工作"的意思. 翻译成与bug为伍没什么不妥吧.

另外“Code structure is ultimately left to the developer. jQuery is flexible in that it doesn’t force you in to a structure like a more monolithic framework would.”

这个回复 结合前面" I can’t disagree with you more" , 应该是说jquery的不足,引申一下, 作者可能是想表达的是: jquery在强化编码规范和代码结构上什么工作都没有做, 把一切的难题都丢给了程序员, 这就导致如果程序员的水平参差不齐,那么写出来的代码也会乱七八糟.

Re: 翻译问题 by Peng Chao

I can't agree with you more = 我完全同意你说的。-> I can't disagree with you more = ?
从flexible和force这两个词的感情色彩上来看,我也认为这是对jQuery的肯定。

Re: 翻译问题 by Wei Zijun

囧... 我看错了 哈哈哈

Re: 翻译问题 by Peng Chao

哈哈 我之前也看错了 多亏mike同学指出。 大家如果有兴趣也可以申请加入InfoQ译者团队。

Re: 翻译问题 by shi mike

不了,俺的英语水平是看任何英语文档都离不开字典的程度。另外,建议也补充一下John对Mark的i回应,我觉得加上那个回应这篇才完整。

@Mark: I really don’t see how the current situation is anything like IE6. IE6 was a stagnant, closed-source, proprietary codebase. WebKit is an Open Source, highly-collaborative, widely-used codebase. Browsers will continue to compete on quality and performance, just as they have always done.

Re: 翻译问题 by lucifer lu

can't agree more翻译完全没问题。这是标准用法。
work around也没问题,无论从英文本身,还是语境都是对的。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

9 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT