10 Years of Chrome DevTools
source link: https://chinagdg.org/2018/09/10-years-of-chrome-devtools/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
10 Years of Chrome DevTools
Source: 10 Years of Chrome DevTools from Chromium
* { line-height: 1.38 !important; white-space: initial !important; } ul { font-size: 11pt !important; } li { line-height: 1.38 !important; } img { margin-bottom: 0 !important; } i { text-align: center !important; }
In the beginning, there was Firebug
- Sprinkle window.alert() calls throughout your code.
- Comment out sections of code.
- Stare at the code for a long time until the JavaScript gods bless you with a solution.
A screenshot of Firebug’s Net panel, taken from Saying Goodbye to Firebug (source and license)
Firebug was a Firefox extension that let you debug, edit, and monitor pages in real-time. As a web developer suddenly you went from having no visibility into your pages to having what are essentially the core features of modern developer tools. The ability to understand exactly why Firefox was behaving as it was unleashed a flood of creativity on the web. Without Firebug, the Web 2.0 era wouldn’t have been possible.
WebKit Web Inspector
Around the same time as Firebug’s launch, a few Google engineers started working on a project which would eventually lead to Chrome. From the start, Chrome was a mashup of different code libraries. For rendering the Chrome engineers opted for WebKit, which is the open-source project that still powers Safari to this day. An added bonus of using WebKit was that it came with a handy tool called the Web Inspector.
The “Inspect Element” era
Chrome brought many innovative ideas to the browser ecosystem, such as the omnibox that combined search and the address bar, and a multi-process architecture that prevented one hanging tab from crashing the entire browser. But the innovation we like the most was providing developer tools in every build to every user, exposed with the click of a mouse.
Before Chrome, developer tooling was an opt-in experience. You either had to install an extension, like Firebug, or enable some flags, as is still the case in Safari today. Chrome was the first browser to make developer tooling accessible from every browser instance. We’d like to claim that we had a grand vision for creating a developer-friendly browser from the start, but the reality is that Chrome had a lot of compatibility issues in its early days (which makes sense, since no one was building for it) and we needed to give web developers an easy way to fix these issues. Web developers told us that it was a useful feature, and we kept it.
The mobile era
An early prototype of Device Mode
The performance era
These tools were a step in the right direction, but in order to spot optimization opportunities you needed to learn the nitty-gritty details about how browsers work and sift through a lot of data. Lately we’ve been building on this foundation to provide more guided performance insights. The new Lighthouse engine powers the Audits panel, and is also available as a Node module for integration with CI systems.
The Node.js era
Up until 2014 or so, we mainly thought of DevTools as a tool for building great experiences on Chrome. The rise of Node prompted us to rethink our role in the web ecosystem.
For the first few years of Node’s existence, Node developers were in a situation similar to that of web developers before Firebug, or Gmail developers before the Timeline panel: the scale of Node apps outpaced the scale of Node tools. Given that Node runs on Chrome’s JavaScript engine, V8, DevTools was a natural candidate to fill the gap. Support for debugging Node with DevTools landed in 2016 and includes the usual DevTools features, such as breakpoints, code stepping, blackboxing, source maps for transpiled code, and so on.
The DevTools protocol ecosystem
The name Chrome DevTools Protocol (CDP) suggests an API that only DevTools can use. The reality is more general than that: it’s the API that enables programmatic access to Chrome. Over the last few years, we’ve seen a few third-party libraries and applications join the protocol ecosystem:
What’s next?
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK