Chromium Blog

10 Years of Chrome DevTools

Thursday, September 6, 2018

* { 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; } Chrome is turning 10! Thank you for making the web development community so open, collaborative, and supportive. DevTools draws inspiration from countless other projects. Here’s a look back at how DevTools came about, and how it’s changed over the years.

In the beginning, there was Firebug Imagine for a moment that browsers didn't ship with developer tools. How would you debug JavaScript? You'd basically have 3 options:

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.

What about layout issues? Network errors? Again, all you could really do is conduct painstaking experiments in your code. This was the reality of web development up until 2006. Then a little tool called Firebug came along and changed everything.

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.

A screenshot of the Web Inspector, taken from Web Inspector Redesign (source and license) Like the Net panel of Firebug, the original Web Inspector probably looks familiar. Much of its functionality lives on to this day as the Elements panel in Chrome DevTools. Web Inspector launched a few days after Firebug, and Safari was the first browser to bundle developer tooling directly into the browser.

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.

"Inspect Element" in 2010
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

For the first few years of the DevTools project, we essentially added chapters to the stories that Firebug and Web Inspector started. The next big shift in how we approached DevTools happened when it became clear that smartphones were here to stay.

Our first mission in this brave new world was to enable developers to debug real mobile devices from their development machines, which we call remote debugging. DevTools was actually well-positioned to handle remote debugging, thanks to another consequence of Chrome’s multi-process architecture. Early on in the DevTools project we realized that the only way a debugger could reliably access a multi-process browser was through a client-server protocol, with the browser being the server, and the debugger being the client. When mobile Chrome came around, the protocol was already baked into it, so we just had to make the DevTools running on your development machine communicate with the Chrome running on your mobile device over the protocol. This protocol still forms the backbone of DevTools today, and is now known as the Chrome DevTools Protocol.

Remote Debugging

Remote debugging was a step in the right direction, and to this day is still the primary tool for making sure that your sites behave reasonably on real mobile devices. Over time, however, we realized that remote debugging could be a bit tedious. When you're in the early phases of building out a site or feature, you usually just need a first-order approximation of the mobile experience. This prompted us to create a set of mobile simulation features, such as:

Precisely emulating the mobile viewport, simulating touch-based input and device orientation.

Throttling the network connection to simulate 3G and CPU to simulate less-powerful mobile hardware.

Spoofing user agent, geolocation, accelerometer data and more.

We collectively refer to these features as Device Mode.

An early prototype of Device Mode

Device Mode in 2018

The performance era

While the mobile era unfolded, big apps like Gmail were pushing the limits of the web's capabilities. Gmail-scale bugs called for Gmail-scale tools. One of our first major contributions to the tooling ecosystem was to show a play-by-play breakdown of exactly everything that Chrome had to do in order to display a page.

The original Timeline panel, as announced in Do More with Chrome Developer Tools

The Performance panel in 2018

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.

Performance suggestions in the Audits panel

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.

Node Connection Manager

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:

chrome-remote-interface provides low level JavaScript access to the protocol

Puppeteer brings it to the next level of abstraction and enables automation of the evergreen headless Chrome browser with modern JavaScript API

Lighthouse automates the process of finding ways to improve the performance and quality of pages

We're excited to see thousands of projects depend on these packages to enable rich interaction with Chrome. If you’re in the tooling or automation business, it’s worth checking out the protocol to see if it opens up any opportunities in your domain. For example, the VS Code and WebStorm teams both use it to enable JavaScript debugging within their respective IDEs.

What's next?

Our core mission is to build tools that help you create great experiences on the web. We very much rely on your feedback to help us determine what products or features to build.

Stay up-to-date on new features with our What's New posts

Propose new features on the mailing list

File bugs in Chromium Bug Tracker

Follow us on Twitter to discover new features and bite-sized workflows

Ask questions on Stack Overflow to get help with using DevTools

Take matters into your own hands and contribute to DevTools

Thank you for creating such a vibrant community. We look forward to another 10 years of building the web with you.

Posted by the Chrome DevTools team

The ‘Capable Web’: A 10 Year Retrospective

Tuesday, September 4, 2018

When we introduced Chrome in 2008, our goal was to “keep evolving with the web and continuing to build a solid foundation for modern web applications.” In honor of our tenth year, we’d like to highlight some of the major changes in the web’s rich capabilities that we feel lucky to share with other browser vendors.
As the very first pages were served on the open web in 1990, people recognized that the ability to deliver dynamic content would make the web unique—you could provide information and function just by sharing a URL. The Common Gateway Interface standard released in 1993 defined a simple interface for web servers to run code in response to web requests. It brought a new era of experience and capability to computing, accessible at the click of a link. Hop forward two short years to JavaScript, then another year to frames, specifically the <iframe> tag. These innovations let developers dynamically load content into pages, brought a new level of interactivity to the web, and increased user expectations of what could be done in the browser.
Accessibility, linkability, indexability, and universal reach have always been the web’s core strengths. Alongside these super powers, users want ever richer and more-engaging experiences. “Ajax” was coined in 2005 to describe the combination of asynchronous JavaScript and XML, which shaped a more interactive, modern web. It led to the creation of such services as Google Maps, cementing the web as the best way to deliver experiences available to anyone, on any device.

2008 – 2014: Web applications, HTML5, and the start of the mobile era

Chrome saw huge progress in its early years, with a large number of what are now considered “core APIs” coming to the web after the WebKit implementation. The video, audio, and canvas elements were some of the first “modern web” features that many of us distinctly remember (and who can forget border-radius?). These features brought a new level of interaction to web experiences, and meant developers no longer needed plugins such as Adobe Flash or Java, to build interactive media and graphical experiences. Chrome experiments have captured great examples of rich experiences that are a direct result of the web’s improved performance.

The “Mobile Web” really hit the world in 2010, and we saw a slew of new platform primitives introduced for the platform (many inspired directly by Google Gears) to help make building web apps easier. We could now make responsive, offline-enabled applications with AppCache and WebSQL, request permission to access the user's geolocation, and even understand the orientation of the user’s device.
WebSocket landed on the platform the same year, heralding a change in the types of experiences developers could deliver on the web. No longer did they have to use long polling to enable a bi-directional channel between the user and a service; developers now had a two-way channel with a simple API to provide real-time communication.

Plink is an interactive music experiment synchronising player state via websockets.

Four major APIs came to Chrome in 2011. WebGL, Web Audio, and the Fullscreen API let us build rich and immersive experiences that could take advantage of the entire screen. IndexedDB — a new “web-first” storage mechanism — us store and query serializable JavaScript objects such as Strings, Objects, Arrays, Files, and Blobs more effectively.

Chrome Web Lab was an experiment that bridged the physical and digital worlds. It used Web Socket, video, real-time streaming, WebGL, and Web Audio to create an immersive world.

A bumper year for game-changing experiences on the web arrived in 2012. On the back of WebGL and Fullscreen, the Pointer Lock and Gamepad APIs let us build games and other web experiences that felt really interactive. The game-changing collection of WebRTC APIs truly set the web apart from all of the other platforms: It let us build P2P video-chat and real-time data sharing, without any plug-ins or proprietary stack, and accessible by simply clicking a link.

One of the first Chrome on Android to Chrome on Android WebRTC calls (March 2013)

In just seven years, the web changed drastically. Browsers got significantly faster and more capable, letting developers build richer experiences on the desktop. Users started to consume even more content on mobile, meaning we all had to rethink how our experiences would work across devices and form-factors, even when the user had no connectivity.

2015-2018: PWA, The Extensible Web, and deeper integration era

In 2015, we experienced a fundamental change in how we thought about integrating capabilities into the web platform. The Extensible Web manifesto asked browser engineers to consider a layered platform that offered lower-level primitives that were easier to explain, more efficient to implement, and allowed web developers to easily build higher-level abstractions, thus increasing the cadence and availability of compelling new features. Service Worker is an example of building on these APIs to follow these principles. Service Worker is a small piece of JavaScript that sits between the browser and the network, and lets the developer decide what to do with any web requests.

The combination of Service Worker and a handful of new APIs allowed marked the beginning of the Progressive Web Apps (PWA) era. PWAs are high-quality sites that combine the reach of the web with the user expectations that come with native platforms. Specifically, PWAs are...

Fast—they load instantly
Reliable—they never show the “downasaur,” even in uncertain network conditions, by taking advantage of the Service Worker and Cache APIs

Engaging—they respond quickly to user interactions with silky-smooth animations and no janky scrolling

Capable—the sites feel like natural extensions on the device, with immersive user experiences provided by features such as “fullscreen” and standalone mode through Web App Manifest; they deliver capabilities for meeting specific business goals, such as re-engagement through the Add to Homescreen feature and Web Push notifications

As PWAs became more established, so did the capabilities of the platform. The Background Sync API brought increased opportunities for developers to improve the resilience of their applications. We also got a better understanding of the network capabilities with extensions to the Network Information API.

Pointer Events, a critical component for any web site or app, came to Chrome after a long wait. Pointer Events presented a unified model for handling all forms of gesture-based input, ranging from touch to pens to mouse pointers.

In 2017, deeper integration of web apps with the host operating system and secure access to devices around the user arrived..

The Image Capture and Media Capture APIs provided full-frame access and control over a phone camera, as well as from other input sources such as a canvas. The Web Share API let sites share data directly with the operating system’s native sharing systems.

The Web Bluetooth API let a user securely select a Bluetooth LE device and have a webpage interact with the device. The Web USB API enabled the same level of connectivity, but to devices connected to the user's machine.

WebAssembly (WASM) opens up many possibilities. It brings a runtime that can execute code at near-native performance. Plus, it opens a new world of experiences on the web by letting developers use existing codebases built for other platforms on the web platform.

Web VR came to the web at roughly the same time it came to native platforms. It let us deliver immersive experiences without installing an app, significantly reducing the gap between a new native primitive arriving on platforms and being available across the web platform.

Forward to the future

We’re excited about the possibilities of the web platform. The web can (and should) be feature-rich, but new capabilities don't always have to be more complex. Web development should be predictable, manageable, and pain-free. Coming APIs such as Feature Policy are great examples of additions that will help developers create amazing sites in a more predictable way, and provide more control and customization over the UX of certain browser features. Feature Policy is the browser's built-in guide rails to help web developers avoid common pitfalls and use best practices.

Layered APIs is another initiative that we're excited about. With it, developers will be able to load and use high-level features shipped directly into the browser as JS modules. For example, instead of building a custom virtualize-scrolling component, developers can just import and use <virtual-scroller> in a site. Layered APIs can be quickly iterated on by the standards bodies and implemented by browser vendors, and will help create a pay-as-you-go standard library for the web. And looking further, the Houdini and Web XR APIs will radically change experiences we can build on and with the web.

Over the last 10 years, we’ve seen a massive increase in the rate at which new primitives and capabilities can be introduced to the web. We can thank all the browser vendors for their continued work to create and iterate on specs, using streamlined processes like those defined by the WICG and based on the principles in the Extensible Web Manifesto. We’ll continue our commitment to work with browser vendors and the developer ecosystem to prioritize features that users need, and to ensure that those capabilities arrive in a “webby” way. By doing so, we can uphold our original mission, while also prioritizing user safety, discoverability, instant access, and universal reach for everyone on the planet.

Here’s to the future of an even-more-capable open web.

Posted by Paul Kinlan, the Wizzy Web Warrior.

Charting Browser Interoperability

Thursday, August 30, 2018

At this year's Google I/O, Ben Galbraith and Malte Ubl presented a chart during the Web keynote showing how the web is getting more interoperable:

This trend is really important to the Chrome team: web developers should be able to target the web platform, not four different (though overlapping) platforms. The chart was gleaned from the data in our Web API Confluence Dashboard. This project, originally designed for browser engineers, provides insights into web interoperability by tracking page-visible JavaScript APIs across many releases of the four major browser engines. Here’s an example:

Caption: Count of browser-specific APIs goes up when browsers are first to ship a new API, and down when either (i) a second browser implements a new API, or (ii) an API that failed to build consensus is removed by the one browser that implemented it. This chart plots a count of APIs shipped by only one of the four browser vendors over time. Interacting with the chart on the dashboard lets you open the list of APIs that corresponds to each count:

This information helps browser vendors prioritize work that will make the web more interoperable by either removing old browser-specific APIs or working with other vendors to implement APIs that are not yet widely supported. How APIs are collected In order to count APIs on the web, we first had to define what counts as a “web API”. The web is full of useful features, some of which are hard to define let alone detect. For this analysis we focused on JavaScript APIs that are visible to the developer when the page first loads. This leaves out several classes of feature, like CSS properties, HTML attributes, and APIs that are not available on page load (e.g., APIs are surfaced through interaction user/API interactions, or only available in certain types of workers). Nevertheless, it gives us a general view of programmable browser capabilities. Our JavaScript API-finding algorithm inspects the JavaScript object graph exposed on the global window object. Check out the link for details on how we managed to extract APIs from JavaScript prototypes. With the help of BrowserStack’s 1000+ browser/operating system configurations, we were able to gather API data for browser releases going back as far as 2012.

Determining if the web is healthy

Take a look at the metrics page on the dashboard and you’ll see a few different charts we’ve generated about the shape of the web. These metrics, and the APIs they represent, give web platform implementers insights into which APIs are fragmenting the web. APIs that fragment the web are:

Shipped by almost every browser, but not quite;

Removed by one browser, but not others; or

Shipped by one browser, but not others.

For example, our data shows that Safari is the only major browser that does not ship CSSStyleDeclaration#backfaceVisibility, Chrome has removed a number of SVGSVGElement APIs that are still shipped by all major browsers, and Edge is the only major browser shipping a number of BhxBrowser APIs. Querying the raw data yourself The dashboard isn’t intended to replace tools like MDN Docs or caniuse.com, but rather to illustrate trends that help browser vendors keep evolving the web towards interoperability. That said, the catalog page on the dashboard can give developers another source to corroborate interop info from manually curated sources. Try playing around with the search box above the API catalog. It supports some basic structured queries like in:firefox60 or notin:chrome66 for APIs in Firefox 60 or missing from Chrome 66, or RTCPeerConnection count:2 for RTCPeerConnection-related APIs shipped by exactly two of the browsers currently in view. Clicking the vertical ellipsis icon lets you add or remove dozens of browser releases from the grid, and the URL bar always contains a link that will get you back to the current query. Validating MDN browser compat tables We’ve also started using the data to help tech writers programmatically check their contributions to MDN’s excellent browser compatibility database. Try this out: # Clone MDN’s browser compatibility database git clone https://github.com/mdn/browser-compat-data.git cd browser-compat-data # Install dependencies npm install # Load confluence data for ServiceWorker npm run confluence -- --interfaces=ServiceWorker # Take a look at the differences that have been applied to your working tree git diff # Read the full list of parameters you can try on `npm run confluence` npm run confluence -- --help ConclusionWe hope both browser engineers and web developers can benefit from the dashboard. Check it out and let us know what you think over at the GitHub project that hosts the code.
Posted by Mark Dittmer, Software Engineer working on Web Ecosystem Infrastructure

Chromium Blog

10 Years of Chrome DevTools

The ‘Capable Web’: A 10 Year Retrospective

Charting Browser Interoperability

Labels

Archive

Feed