与 Paul Irish 的五个问题

Avatar of Chris Coyier
Chris Coyier

DigitalOcean 为您旅程的每个阶段提供云产品。立即开始使用 200 美元的免费额度!

Paul 在这里可能不需要介绍。 他是一位才华横溢、成功的网页前端开发人员,他的工作激发了我们 内心的批判精神。因此,我不会做冗长的介绍,而是直接提供一些链接,这样我们以后就不用担心了。

在 Google 的 Chrome 开发者关系团队工作。 Modernizr 的首席开发者。 HTML5 Boilerplate 的创建者之一。 jQuery 团队 成员。创建了 许多 有用的 单页网站。在 Twitter 上分享了许多很酷的东西。 不喜欢乐队

以下是我认为很有趣的五个问题,我想听听 Paul 的回答。

*Chris:如果 Internet Explorer 决定长期或短期使用 WebKit 渲染引擎,我们会更好还是更糟?

Paul:很难说,但由于这种情况永远不会发生,我只会避开您问题的核心。Gecko、WebKit 和 Trident 将会存在,并且永远不会合并。永远!

不过,在这一点上,IE 工程团队非常投入,因此优先事项并不是将 WebKit 集成到 IE 中,而是修复 IE 的现状。我们正在关注 IE 的年度版本发布,这看起来非常好。但每个版本预计将在实际环境中使用 10 年。(IE8、9 和 10 将获得支持,直到 2020 年)将其与 Chrome 和 Firefox 相比,后者在新版本发布后 6 周就会停止支持旧版本……这意味着我们将不得不同时支持多个版本的 IE。因此,实际上,我们的痛苦不是 IE 新版本发布时的标准合规性和开发人员的痛苦,而是处理多个版本的 IE 以设计我们的体验、针对其进行质量保证,并在发布后数年内处理它们。

*Chris:WebKit 中的开发者工具是如何开发的?Chrome 团队是否积极改进它们,然后贡献回 WebKit 项目,进而被 Safari 使用?还是有多个团队在那里进行协作?

Paul:Chrome 拥有一个规模相当大的团队积极致力于 Chrome Devtools 的开发。虽然我通常称它们为 Chrome DevTools,但我也可以称它们为 WebKit Inspector;实际上,所有工作都直接提交到 WebKit 上游,因此 Safari 和其他 WebKit 端口都可以从中受益。我的朋友 Peter Beverloo 创建了 一个不错的 Inspector 提交 RSS Feed,如果您想每天观看工具的改进,可以查看它。

Chrome DevTools 中的一些功能是 Chrome 独有的:脚本的实时编辑和堆分析就是两个主要的例子。但我对团队在 远程调试 方面所做的工作感到非常兴奋,因为现在所有移动 WebKit 端口都可以使用它,这意味着您能够在设备上分析、查看网络详细信息和实时编辑 CSS。对此我感到非常兴奋。

*Chris:Chrome 使用 6 周的发布周期。因此,明年春天 Chrome 将达到“版本 20”。这种发布周期有什么优势?对于那些没有如此快速和规律的发布计划的浏览器,您会怎么说?对于那些嘀咕着“版本发布曾经意味着一些东西”的旁观者,您又会怎么说?

Paul:这个话题可以分成三个部分

  • 浏览器发布频率
  • 版本控制
  • 浏览器版本半衰期

发布频率:Chrome,现在还有 Firefox,每六周就会发布一个新版本。这对 浏览器工程师 以及 用户安全用户在 Chrome 中的体验 都有好处。

版本控制:Jeff Atwood 最近写了一篇关于无限版本的文章,并详细介绍了 Chrome 更新架构背后的部分工程工作。Web 应用迭代速度很快(Github 每天向生产环境发布 10+ 次);我认为浏览器以快速迭代的方式发布是可以的,版本号仅仅是跟踪的一种方式。除非我们回到过去,并且 Knuth 要求每个人都遵守,否则 将语义应用于版本号 是行不通的。(FWIW,WebKit 的版本为 535)。

半衰期:如果 Chrome 在每次发布时都没有更新所有用户,那么所有 1.2 亿 Chrome 用户将分散在 16 个版本中。然而,随着 IE 团队新的工程活力,我们看到他们每年都会发布一个很棒的新浏览器,但没有清楚地说明如何将用户迁移到最新最好的版本。 我最近写了很多关于这方面的内容

*Chris:这幅图描绘的景象相当严峻。您真的认为会变得那么糟糕吗?如果 IE 能加入自动更新浏览器的行列,这个问题应该会很快消失,对吧?

Paul:这很棘手。即使 IE10+ 能够自动更新(*祈祷*),我们仍然会看到 IE8 的缓慢消亡(非常非常缓慢的消亡。我认为我们总是会遇到很多痛苦。因此,为了让自己保持持续的理智,请务必开发很棒的东西。

哦,我还没有提到移动端的状况,那里有许多具有独特功能集的不同浏览器。我想我现在应该提到功能检测的价值。这无疑是创建能够适应所有查看您作品的各种浏览器的出色体验的关键。编写您自己的功能检测很困难,因此我建议您访问 Modernizr 的网站,并创建一个小型的自定义版本,其中仅包含您需要的少量测试。

*Chris:给人们一些建议吧。如今,前端开发人员需要做些什么才能“做对”?

Paul:很多!对吧?首先,您需要决定:我是在制作 Web 应用还是网站?是针对移动设备还是桌面设备?使用自上而下的媒体查询实现响应式设计,还是使用自下而上的样式实现移动优先响应式设计?哦,等等,我听说内容优先是最好的。要跟踪所有这些内容很困难,因此我非常支持不在每个项目中都重新发明轮子。

理想情况下,您会使用 HTML5 Boilerplate 启动新项目,使用 Bootstrap 或您自己的自定义等效项。充分利用 SASS 等预处理器也是一种巨大的时间节省器,而使用 Compass 意味着您可以让它为您管理所有前缀知识。此外,您希望尝试使用新功能来保持领先地位。浏览器中已经有很多令人兴奋的功能,但还没有人探索过。就像您一样,Chris,我很高兴看到人们写下他们发现的内容;这有助于每个人,包括您自己。:)

*Chris:谢谢 Paul!