It was a very pragmatic move on our end. As a developer tools team we want to reach as many developers as possible and get feedback from people using our tools. Over the last few years, Chromium has become the main platform for web related tooling. It powers browsers like Google Chrome, Samsung Internet, Brave and others and is also at the core of Electron. The latter is also the base for Visual Studio Code, our Editor and probably biggest success story in Open Source for the company in the last years. So we saw this as an opportunity to play a big part in the web tooling space of today and with our contributions make it better for all involved. When it comes to developer tools, we innovate in the open and bring all the features back into the Chromium core. When it comes to innovation in the browsers space and with my personal background (ex-Mozilla, W3C Member, etc...) I was worried about one less engine to validate new standards on, but as you already mentioned, the developers have spoken. So, the sensible and pragmatic thing to do is to support the platform developers use and want and improve that one. So far, I think this helped the open web, too. We put a lot of work into making developer tools keyboard and screenreader accessible, localised them to different languages and fixed a lot of bugs that the original team didn't have the bandwidth to work on. I'm happy we have choice in browsers, but a lot of what makes up a browser isn't the engine. It is also the UX of the browser interface and the services that a browser incorporates. And this is how end users choose which browser to use. And the more open the engine driving that browser is, the better.

There is a confusion about the Edge Platform and developer tools here. The short of it now is that we don't have any extra features not in the Chromium platform and that our work in that area will be part of the Chromium core.

When it comes to Service Worker tooling, the story is the same, and my colleague Erica is working on that features, so if there is something ready to talk about, she'll chime in here. For now, you can see the new Service Worker Network features as part of the "What's New" in Edge 85.

What do you currently miss in the implementation of Service Workers in Chromium? What would be really good to have from a tooling point of view you can't do right now?

Performance and file size is something people seem to underestimate. Whilst it is true that you don't work on the open web, but in a more defined development environment on device, you still need to be diligent to make sure that your code performs fast and doesn't use up many resources. People debug huge applications in browsers these days and your code needs to not be a bottleneck when it comes to finding that one bug. Another thing a lot of people don't know yet is that the interface of developer tools is written in HTML/CSS/JavaScript, so you can easily extend them. You can test this yourself. If you open the developer tools with CTRL/CMD+Shift+I, undock them into an own Windows and press the keyboard shortcut again, you get a second devtools window that debugs the current one - there you can see all the HTML and CSS used. To me the biggest challenge is restraint. It is tempting to add more and more features because competitors have them or you seen a great presentation about something that seems useful. The developer tools as they are right now are already pretty complex, and it needs some diligence to do some real user testing first to validate if the "awesome feature" really is something that people need. Developers come in all shapes and environments and all of them with different needs. Often a vocal minority demands things that won't get much use whereas people who do amazing work don't demand or speak up. Finding the unspoken needs of users via user testing and telemetry is a an interesting challenge and on a personal level I really want developer tools to become easier. Currently we have tools for experts, but I'd rather have tools that teach you how to become an expert by repeatedly using them. A developer tool shouldn't make you feel inadequate or stupid, it should guide you towards creating better products by flagging up issues and offering solutions. We're not there yet, bit that is the main challenge I want to tackle.

I hear you. We spent a lot of time making the tools accessible and we learned a lot during that period. Now we're ready to go further and start adding more accessibility tools in the nearer future. Currently I am conducting user testing on validating some of these and see how they make the most sense to roll out. A few of the things brewing are high contrast simulation, source order viewer for CSS Grids and a few more. The great thing is that everyone in the Chromium project is on board with that and there are quite a few things brewing. Mathias Bynens of the Chrome team for example lately added simulation for different colour deficits to the rendering pane and it was great to see that.

Specifically what are you missing? What would be a game changer in that space to you?

Hey Galuh, there is such a thing already in the browser, but it may be a bit hidden. If you go to the ... above your profile, select "More Tools" and "Browser Task Manager" you get a task manager for each tab/process:

The good news is that if you're familiar with the Chrome ones, you know these. They are both the same code base.

We're really interested in learning about your current experience testing your web content across different browsers and making it as easy and straight-forward as possible to include Edge in your testing matrix. We have a new MsEdgeDriver that drives the Chromium-based version of Microsoft Edge for easy migration of your Selenium tests and we also support Puppeteer and Playwright via the executablePath parameter.

Check out our docs for WebDriver and Puppeteer! Additionally, we partner with the Playwright team that is building one API to test the Chromium, Gecko, and WebKit platforms so check out their repo as well.

+1 what Zoher said. A few of us on the Edge DevTools team are also core contributors to webhint (webhint.io), which is an open-source web linter that provides feedback for best practices on a number of areas, including cross-browser compatibility. As of Edge 85+, webhint is integrated directly into DevTools (in the Issues panel), so you can get real-time feedback about certain HTML/CSS features that aren't compatible with certain browsers. Kind of like MDN or caniuse, but directly in the DevTools. :)

There are some video links at the top of this AMA that have demos of Playwright, webhint, and more if you want to check them out!

Hey Saurabh,
sorry about that experience. This is nothing I can control or comment on as it isn't my department. I'll try to reach out to colleagues to see who can take that on but I am not sure if this here is a good place to discuss this.
Could you do me a favour and send feedback directly in the browser? This would be triaged to the right people.

Love this question! As Chris mentioned, the developer tools are written in HTML/CSS/JavaScript so we're able to use the same suite of automation tools for testing that you may use for your web content. We run both unit tests and end-to-end tests on our PRs and currently, our e2e tests use Puppeteer, Mocha, and Chai.

How you work with others is as important as what you know yourself. A big part of your career in Microsoft is not only what you know, but also how you inspire others and how you work well with others to ensure the product you work on isn't in trouble should you get sick or have to take some time off. The great thing about the job world these days is that you can exercise and learn these skills by joining open source communities. I've always shared a lot and I always tried to find people who have skills that I lack to work with to form teams. That got me to where I am now. And don't be afraid to publish things. That blog post you think isn't interesting or "too basic" might actually be the one that someone who hires finds to answer their question.