Ben Galbraith的Killer Web开发工具

Mozilla Labs的Ben Galbraith在Web Directions South '09上关于“浏览器工具的状态”的演讲。 我有机会就他的Web Directions会议，Bespin项目和一般的浏览器工具采访了他。

我相信，受Firebug兴起的启发，浏览器制造商对开发人员工具的关注是Web开发行业中令人欢迎且令人兴奋的。 人们对您的Web Directions会议有什么期望？

最近，我听到有人声称“开发人员永远不能有太多选择！ 网络真是太棒了！” 尊重，我不同意。

尽管我是自由的热情支持者，但我们在反思网络的状态及其未来时，我认为我们需要在尊重自由的恩惠（选择）与Barry Schwartz所做的出色研究之间取得平衡。 “更多的选择会使我们不快乐。” 我们必须花费更多的精力在细微差别的选项之间进行选择，而我们享受的选择就越少。 更糟糕的是，如果我们花时间想知道如果我们选择另一条道路会发生什么，它可能会完全剥夺我们的享受。

在我的演讲中，我想通过帮助与会人员切入众多选择来解决这个问题，以发现一些可用来帮助他们创建出色的Web应用程序的工具。

现在我们有了DOM和CSS检查器，以及在浏览器中广泛使用的JavaScript调试和基准测试。 您认为开发人员工具将从何处去？ 您认为开发人员工具世界中目前正在探索的最令人兴奋的想法是什么？

我最激动的趋势是浏览器调试工具的开放，以便可以轻松地将它们与外部工具集成在一起。 在Mozilla，我们许多人都为这个方向而着迷，我们正在努力寻找如何最好地以这种方式打开Firefox。 我非常支持Sun在这方面对其Java平台调试器体系结构（JPDA）所做的工作。 它确实为运行时应公开的各种调试服务设置了标准。

与此相关的是，我很高兴看到将浏览器视为复杂的应用程序运行时所必需的工具的出现，例如我们在Mozilla Labs正在使用的新内存工具以及Google自己完成的工作Chrome中的内存工具。

我认为，在未来几年中，我们将在这两个领域看到大量令人振奋的发展。

自从不得不使用警报功能进行调试以来，我们已经走了很长一段路。 借助现代浏览器中高水平的标准支持，开发人员现在可以选择，并且经常拥有喜欢的浏览器来进行大部分开发工作。 托马斯·福克斯（Thomas Fuchs ）表示，他偏爱的浏览器是Safari4。我们自己的技术总监凯文·扬克（Kevin Yank）表示，由于Firebug，他更喜欢Safari进行日常浏览，而更喜欢Firefox进行开发。 您是否在工作中发现可用的开发工具的质量会影响特定浏览器对开发人员的普及程度？

我不确定浏览器的开发人员工具与开发人员用来浏览Web的浏览器之间的关系。 在某些情况下，将不同的浏览器用于这些不同的活动实际上会更加方便。 当然，对于Firefox，我怀疑在3亿左右的Web开发用户中所占的百分比是…相当低。

话虽如此，我们在Mozilla致力于开发人员工具领域，非常希望Firefox的开发人员工具出色。 这对浏览器的普及并不是那么重要-您可以说，如果这是我们的目标，那么我们可以进行更多的生产性投资-但因为我们认为这对于整个Web是正确的。 我们喜欢Safari，IE，Opera和Chrome在此领域中发挥出色的作用，我们希望我们在这一领域的工作能够与他们一起共同为每个人提高标准。

至于Safari和Firebug，我对此进行了仔细的研究。 我喜欢Safari的工具的原因是他们对时尚和细节的关注（Apple对此并不感到惊讶）。 例如，我喜欢他们的调试器的源代码查看器在您将鼠标悬停在当前行上时突出显示当前行的方式，而我对于他们的网络计时信息的美感是痴迷的。 但是，另一方面，当您将鼠标悬停在某个项目上并且具有更丰富的JavaScript调试器功能（例如，提供更有用的堆栈列表和中央断点列表）时，我非常喜欢Firebug对网络时序的详细分解。

Firebug当然也有缺点。 我们正在与Firebug的主要维护者-出色而多产的John J. Barton合作，以帮助解决这些问题。

即使开发人员可能会喜欢，但仍需要在所有浏览器中进行测试。 能够窥视浏览器的渲染引擎内部发生的事情非常重要，但为每个浏览器使用不同的开发人员工具集会增加复杂性。 您认为拥有这么多开发人员工具对开发人员有好处吗？ 我们真的可以做些什么吗？ 有没有更好的办法？ 开发人员工具是否都收敛于相同的使用模型？

我在前面提到了浏览器运行时打开调试器API的趋势时对此进行了介绍。 但是，直到我们进入一个神奇的世界，在那里我们有了可以在浏览器中使用的工具并使用了不同的平台调试器API之前，大多数工具实际上都是通过遵循Firebug的领导而融合在非常相似的用户体验上。 尽管不同浏览器的细节可能有很大不同，但是基本用法模型却几乎相同。

Opera Dragonfly具有远程调试功能，在移动设备上为Opera开发时非常有用。 您是否认为这是开发工具的扩展领域？ 对开发人员更有用的是：在真实设备上进行实时测试或在模拟器上进行测试？ 开发人员工具实验室对移动开发工具有什么计划？

再次，我之前谈到了其中一些问题，但最后一个问题是：是的。 Bespin已经进行了一些工作，以专门考虑移动浏览器平台来远程连接到浏览器。 将此功能连接到Firefox，Fennec，Chrome或其他在台式机或移动设备上运行的浏览器，仅需完成少量工作。

贝斯平立即令人印象深刻，但也令人困惑。 仅仅是代码编辑器吗？ 它是一种协作工具吗？ 它是托管服务吗？ 它是一个应用程序平台吗？ 是所有这些，还是都不是？ 您对Bespin的愿景是什么？

这些都是这些。 目前，Bespin是一个实验，因此其定义和界限有点模糊。 但是自几个月前我们启动该项目以来，出现的情况是Bespin需要成为（1）可嵌入的编辑器，（2）基于该编辑器构建的基于Web的完整社交编码环境，以及（3）托管服务提供基于Web的体验。

我们已经看到很多人嵌入了编辑器，启动了自己的Bespin实例，并使用了在bespin.mozilla.com上实验性提供的当前服务-我们非常感谢所有这些用户，他们的反馈，尤其是他们的补丁！

我们的愿景是Bespin通过（1）将我们的编码环境移至云端，使其可以从任何浏览器（包括移动浏览器）中使用，（2）使体验变得非常社交化，以及（3）来改变您和我编写代码的方式。 ）减少为开源项目做贡献的摩擦。

利用canvas元素是一个有趣的决定。 canvas元素内有多少Bespin接口？ canvas元素的通用性如何？ 您为什么选择这样做？ 您认为微软会支持canvas元素吗？ 您认为它有潜力成为应用程序接口平台吗？ 这是Thunderhead背后的想法吗？

我们最初选择画布来增强编辑器的功能，因为我认为这是获得高质量文本编辑体验所需的性能和控制的唯一途径。 即使是在旨在支持自定义文本编辑组件的平台上开发的代码编辑器，其自身的文本编辑器也不断滚动滚动，因此，朝着这个方向迈出的步伐似乎并不大。 碰巧的是，我在画布之类的API（Java的Java 2D API）方面拥有丰富的经验，因此我能够在一两个小时内完成Bespin的基本原型。 其余的自然地从那里流出。

我希望微软支持画布。 我们只需要拭目以待。 该决定背后的政治取决于Silverlight，Windows，Internet Explorer以及其他以非显而易见的方式相互关联的动力。 如果我不得不猜测，我会说他们将等着看是否有大型的网络媒体资源使用它，并积极鼓励用户切换到IE之外的其他东西，然后再推出。 我不知道它将如何为他们的Windows或Office特许经营权主动实施它。 毕竟，微软的动机是相当透明的。

在Bespin生命的早期，我们尝试使用canvas做更多的事情，而不仅仅是成为一个代码编辑器。 我们还实现了一个文件浏览器组件。 作为该练习的一部分，我们创建了Thunderhead，这是一个JavaScript GUI工具箱，可使用画布进行渲染并与DOM元素进行互操作。 当时，有些人说我们正在重新发明轮子，但是我们有一种实现2D渲染中功能和效果的愿景，而这是使用DOM API不可能实现的。 但是发生了两件事，使我们确信这是一个错误的转弯。 首先，Apple开创性的CSS效果获得了长足的发展，并被许多人普遍接受为将花哨的2D和3D效果集成到DOM API中的有效模型； 其次，我们意识到构建通用UI工具包需要花多少精力。 我以为我知道这会有多困难，但是我差了一个数量级。 这是非常艰苦的工作。 实施出色的功能所获得的任何好处，等等，都因正确获取一千个小细节所需的时间投入而被抵消了。

因此，我们正在应用从Thunderhead获得的经验教训； 它将在范围上进行缩减，成为驱动Bespin的代码编辑器的框架（很长一段时间内将成为画布），并且我们可能会将DOM元素用于系统中的所有其他UI片段。 但是我们可能仍会在需要定制，动态呈现的UI的小部分中使用它。

稍微走了弯路：我对这个名字[Thunderhead]有疑问。 我一直在航海方面思考“头部”。 有没有更好的名字？ Tibanna，Lobot或我的最爱：Ugnaught怎么样？

畏惧怎么样？ ;-)

在Bespin视频中，您提到了能够实现的性能优化。 微软发布了一份报告，详细说明了它们所表示的浏览器性能基准测试工具的“局限性”，并且“现实世界”的性能并未体现在JavaScript运行时性能测试结果的微秒差异中。 您同意吗，为什么或为什么不呢？ 什么是对浏览器性能的良好测试？ 您在开发Bespin时遇到的主要性能障碍是什么？如何克服它们？

最终，我只关心感知的性能。 使界面保持响应状态，单击后阻塞不超过50-100毫秒，并将更长的延迟推入后台。 JavaScript为我们提供了执行此操作所需的工具，所以很好。 而且，由于有网络工作者的帮助，我们现在实际上可以在浏览器客户端上的单独线程中为用户界面执行昂贵的计算，从而为更多类的应用程序在浏览器中运行开辟了道路。

通常，对应用程序开发人员而言，以微秒为单位衡量性能是没有意义的。 只有运行时平台工程师才应该关心这种粒度。

我们与Bespin的主要性能障碍一直是并保持尽可能快的保持文本编辑器的渲染循环（需要时对其进行重画的代码）。 似乎不断向该关键路径添加代码，这导致Bespin的响应速度不如我们期望的那样快，我们必须进入并将其推离主要路径。 JavaScript运行时变得越快，这个问题就越少。 但是当混搭键盘时，您可以感觉到延迟降低到10毫秒，因此原则上我们尝试使该路径尽可能平滑。

其他方面的性能通常不是问题。

在Bespin的开发过程中，哪些开发人员工具有用？

萤火虫！ :-)

我们对Mozilla开发人员工具实验室还有什么期望？

现在，我们将重点放在我上面描述的领域：Bespin，通过公开调试API来打开浏览器运行时，帮助开发人员选择正确的工具，并改进Firebug。 但是，我们是实验室，您永远都不知道还有什么可能逃脱！

From: https://www.sitepoint.com/interview-ben-galbraith/