原型开发工具_开发工具的未来原型

原型开发工具

by Konrad Dzwinel

通过Konrad Dzwinel

开发工具的未来原型 (Prototyping the Future of DevTools)

12 years ago web development had almost no tooling. There was no easy way to inspect the DOM, monitor the network or even console.log things.

12年前，Web开发几乎没有工具。 没有简单的方法可以检查DOM，监视网络甚至console.log 。

These dark times can be summed up by this quote from Joe Hewitt, creator of Firebug and the Console API:

Firebug和Console API的创建者Joe Hewitt的这段话可以概括这些黑暗的时期：

“I’m always surprised to hear people call FireBug ‘innovative.’ It shows just how weak the web developer’s toolbox has become that something as old school as a console would be considered novel.”

“听到人们称FireBug为“创新”，我总是感到惊讶。 它显示了Web开发人员的工具箱变得多么脆弱，以至于像控制台这样的老派东西都被认为是新颖的。”

The creation of Firebug in 2006 marked the beginning of modern web development tooling. Today, each major browser ships with fantastic built-in tools for web developers. Behind each DevTools there is a dedicated team of developers, designers and product managers pushing it forward.

Firebug于2006年创立，标志着现代Web开发工具的开始。 如今，每个主流浏览器都为Web开发人员提供了出色的内置工具。 每个DevTools的背后都有一个专门的开发人员，设计师和产品经理团队，将其推向前进。

As DevTools became important, they started competing with one another and gaining tons of new capabilities while trying to keep up with the evolving platform.

随着DevTools变得越来越重要，他们开始相互竞争并获得了无数新功能，同时努力跟上不断发展的平台。

Firebug的遗产 (Firebug’s legacy)

I believe that nowadays, we are blessed to have one of the best tools in the industry. In fact, our tooling got so good that it is constantly forked and adapted to work with other platforms.

我相信，如今，我们很幸运拥有业界最好的工具之一。 实际上，我们的工具是如此出色，以至于它不断地被派生并适合与其他平台一起使用 。

One thing that always struck me though is how the original concepts introduced by Joe in Firebug still live on, almost unchanged, in today’s DevTools.

尽管让我印象深刻的一件事是，乔在Firebug中引入的原始概念如何在如今的DevTools中仍然存在，几乎没有改变。

These similarities sure make our lives much easier when switching between the browsers, but I always wondered — were these concepts ever challenged? Or were they just copied over without much thought? And if they were, can I somehow challenge them myself?

这些相似之处无疑使我们在浏览器之间切换时的生活变得更加轻松，但是我一直想知道-这些概念曾经受到挑战吗？ 还是他们只是不加思索地复制过来？ 如果是的话，我可以自己挑战一下吗？

受到启发 (Getting inspired)

Motivated by the invitation to speak at Front-Trends, I decided to build a couple of prototypes showing some alternative paths that our tooling could follow in the future. In a search for inspiration, I thought about getting to know applications used in other professions. I hoped to identify some patterns and ideas worth borrowing.

受邀请在Front-Trends演讲的激励，我决定构建几个原型，这些原型展示了我们的工具将来可以遵循的一些替代途径。 为了寻找灵感，我考虑过要了解其他专业中使用的应用程序。 我希望找出一些值得借鉴的模式和思想。

Going through the manuals of random tools, without understanding the context, didn’t sound like a good plan though. Thankfully, I have a couple of good friends who are not web developers and agreed to introduce me to their tooling. And so, I met with: Kasia — a structural engineer, Bolko — photographer and a filmmaker, Ola — scientist and measurement and control systems designer, Kuba — game designer and programmer and Patrycja who is a graphic designer. I asked them to walk me through their usual workflow, talk about what they like and dislike about their tooling and how they learn about new features.

在不了解上下文的情况下浏览随机工具的手册，听起来似乎不是一个好的计划。 值得庆幸的是，我有几个不是Web开发人员的好朋友，并同意向我介绍他们的工具。 因此，我遇到了：Kasia –结构工程师，Bolko –摄影师和电影制片人，Ola –科学家和测量与控制系统设计师，Kuba –游戏设计师和程序员，Patrycja是图形设计师。 我要求他们引导我完成他们通常的工作流程，谈论他们喜欢和不喜欢他们的工具，以及他们如何学习新功能。

These interviews brought some intriguing insight into how others work. Here are some of the ideas I gathered that could be brought to browser DevTools.

这些采访为其他人的工作方式带来了一些有趣的见解。 这是我收集的一些想法，可以带入浏览器DevTools。

想象未来 (Imagining the future)

灵活性 (Flexibility)

All the applications that I was introduced to (DaVinci Resolve, Autocad, Sketch, LabView, Unity) have much more flexible layouts than our DevTools. Each panel, tab, and window can be moved around, closed and resized. This is something that helps personalize the tool and fit it to your needs. Unity even allows you to save and manage multiple layouts with ease. Meanwhile, in our DevTools, it’s impossible to have Performance and Sources panels side by side.

我所介绍的所有应用程序(DaVinci Resolve，Autocad，Sketch，LabView，Unity)都比我们的DevTools灵活得多。 每个面板，选项卡和窗口均可移动，关闭和调整大小。 这有助于个性化工具并使之适合您的需求。 Unity甚至允许您轻松保存和管理多个布局。 同时，在我们的DevTools中，不可能同时具有Performance和Sources面板。

To show how a flexible layout would look like in Chrome DevTools I build a prototype based on the golden-layout:

为了展示灵活的布局在Chrome DevTools中的外观，我基于golden-layout构建了一个原型：

从块建筑 (Building from blocks)

One thing that I loved about Sketch and LabView is how they allow you to build bigger blocks out of smaller ones. In Sketch, you can create a library of symbols (e.g. buttons, labels, inputs) from which you can then build a complete design of a webpage. If you decide you want to change how a button looks, you can quickly go from a “webpage” view to editing a specific “symbol”. And when you are done, all buttons on your design are updated accordingly.

我最喜欢Sketch和LabView的一件事是它们如何让您从较小的块中构建更大的块。 在Sketch中，您可以创建符号库(例如按钮，标签，输入)，然后可以从中构建完整的网页设计。 如果您决定要更改按钮的外观，则可以快速从“网页”视图转到编辑特定的“符号”。 完成后，设计上的所有按钮都会相应更新。

If you had a chance to build an app or a website using modern framework, all this talk about “symbols” probably rang a bell. With so many new apps built with web/react/etc. components I believe that we could greatly improve our DevTools by making them understand these concepts better.

如果您有机会使用现代框架来构建应用程序或网站，那么所有有关“符号”的讨论都可能会大声疾呼。 通过web / react / etc构建了如此多的新应用。 组件我相信，通过使他们更好地理解这些概念，我们可以大大改善我们的DevTools。

To show what a better integration with components could look like, I created a prototype that allows the developer to seamlessly switch between working on a particular page/screen and a single component:

为了显示与组件更好的集成效果，我创建了一个原型，使开发人员可以在处理特定页面/屏幕和单个组件之间无缝切换：

上下文感知检查器 (Context aware inspector)

Unity has a very neat inspector tool that presents you with different options depending on the element being inspected (3d model, sound file, scene). You don’t have to change tools whenever you switch from modifying a 3d model to modifying a sound file — inspector just adapts itself based on the context.

Unity有一个非常简洁的检查器工具，根据被检查的元素(3D模型，声音文件，场景)为您提供不同的选项。 从修改3D模型切换到修改声音文件时，您不必更改工具-检查器仅根据上下文进行调整。

In our DevTools, we get the same “Styles” panel no matter what node in the DOM tree we are currently inspecting. For some things, like a META tag, SVG path, script tag etc. “Styles” panel is not that useful, so in my next prototype I tried to address that:

在我们的DevTools中，无论我们当前正在检查的DOM树中的哪个节点，我们都将获得相同的“样式”面板。 对于某些事情，例如META标签，SVG路径，脚本标签等。“样式”面板不是那么有用，因此在下一个原型中，我尝试解决此问题：

时间线 (Timeline)

When editing a video, e.g. using DaVinci Resolve, you operate on a timeline that allows you to easily jump between various parts of your project. This ease of going back and forth got me thinking how incredibly useful that feature would be to have in our tooling.

在编辑视频时，例如使用DaVinci Resolve，您可以在时间轴上进行操作，从而可以轻松地在项目的各个部分之间跳转。 这种来回简单的操作使我想到了该功能在我们的工具中将具有多么难以置信的实用性。

Animation finished before you managed to inspect it? You clicked “Next” in the debugger too many times and missed the code that you wanted to debug? Right now you have to reload the page and try again, but with a timeline tool it would be a breeze:

在检查动画之前完成了动画？ 您在调试器中单击“下一步”的次数过多，而错过了要调试的代码？ 现在，您必须重新加载页面并重试，但是使用时间轴工具会很容易：

If this prototype seems a bit too futuristic to you, you should know that we already made a step to make it possible —Edge’s JavaScript engine supports Time Travel Debugging.

如果这个原型对您来说太过未来了，您应该知道我们已经采取了使之成为可能的步骤-EdgeJavaScript引擎支持Time Travel Debugging 。

无限的画布 (Infinite canvas)

Almost every tool that I was introduced to implemented an idea of an “infinite canvas”. The idea is to give you a space on which you can freely arrange your drawings, designs, components, etc. And if you want to focus on any of those things everything is just a scroll and zoom away.

我介绍的几乎所有工具都实现了“无限画布”的概念。 想法是给您一个空间，您可以在上面自由地布置图纸，设计，组件等。并且，如果您想专注于所有这些东西，那么一切都只是滚动和缩小。

A developer working on a website is definitely not interacting with it in the same way as a regular user does. Maybe it’s time to rethink how the main browser window could be improved to better accommodate needs of developers. I believe that “infinite canvas” idea fits here perfectly. What if you could keep multiple devices, browsers and screen sizes all on the same canvas? How nice it would be to be able to quickly preview all pages of your application? What about dumping browser tabs all together and switching completely to the scroll and zoom navigation?

在网站上工作的开发人员绝对不会像普通用户那样与它进行交互。 也许是时候重新考虑如何改进浏览器主窗口以更好地满足开发人员的需求了。 我相信“无限画布”的想法非常适合这里。 如果可以将多个设备，浏览器和屏幕尺寸都保留在同一画布上怎么办？ 能够快速预览应用程序的所有页面会有多好？ 将浏览器选项卡全部一起转储并完全切换到滚动和缩放导航该怎么办？

将想法变为现实 (Turning ideas into reality)

Hopefully, you liked some of the ideas presented above, and agree with me that they would make our tooling even better. I’m sure you have some good ideas of your own to. But now what? Should we just wait and hope for these ideas to be implemented?

希望您喜欢上面介绍的一些想法，并同意我的看法，他们将使我们的工具变得更好。 我确定您有一些自己的好主意。 但是现在呢？ 我们是否应该等待并希望这些想法得以实施？

If you don’t want to wait, I have some good news. Firefox and Chrome DevTools can be easily extended via browser extensions. It’s also possible to contribute to Firefox DevTools, Chrome DevTools or Safari Web Inspector directly as all of them are open source. Finally, if you’d like to create a tool that integrates with a browser, but is separate from it (just like VS Code), you can build it on the top of the DevTools Protocol. For more inspiration and examples of what's possible, I suggest checking awesome-chrome-devtools.

如果您不想等待，我有一些好消息。 Firefox和Chrome DevTools可以通过浏览器扩展轻松扩展。 由于它们都是开源的，因此也可以直接为Firefox DevTools ， Chrome DevTools或Safari Web Inspector做出贡献。 最后，如果您想创建一个与浏览器集成但又独立于浏览器的工具(就像VS Code一样 )，则可以在DevTools Protocol的顶部构建它。 有关更多启发和可行示例的建议，建议检查awesome-chrome-devtools 。

(Big thanks to Kenneth Auchenberg, Jonathan Garbee, Umar Hansa and Jason Laster and for reviewing this post)

(非常感谢Kenneth Auchenberg ， Jonathan Garbee ， Umar Hansa和Jason Laster并感谢审阅了这篇文章)

翻译自: https://www.freecodecamp.org/news/prototyping-the-future-of-devtools-f54ba4d51891/

原型开发工具