Upgrading DevTools' architecture to the modern web

The Chrome DevTools codebase is around 150,000 lines of first-party JavaScript, with some parts being over ten-years old. As with any large, legacy codebase, there are a range of challenges to navigate, whether it be testing, code style and consistency, or simply understanding what the code is doing! This session steps through how we plan, implement, and maintain code migrations in Chrome's DevTools.
Resources:
Migrating to JavaScript module → goo.gle/devtools-js-modules
Speakers: Paul Lewis, Tim van der Lippe, Jack Franklin
Watch all Chrome Developer Summit sessions here → goo.gle/cds20-sessions
Subscribe to Google Chrome Developers here → goo.gle/ChromeDevs
#chromedevsummit #chrome #chromedevtools
event: Chrome Dev Summit 2020; re_ty: Publish; product: Chrome - General; fullname: Paul Lewis, Tim van der Lippe, Jack Franklin;

[@chirag2005]

Thank you so much for making this video, this gives a very good insight into the pain points of code migrations of any major project. If you can, please do make more videos like these.

[@VinayAggarwal]

I agree!! this is a gem!

[@MaxCoplan]

Probably my favorite talk of the conference so far. Great work

[@victornpb]

I myself migrated a large codebase containing about 4mb os first party js, it was written using backbone and requirejs runtime modules, migrating it to a more modern webpack build, with all the modern transpiling and longing tools has been a ongoing project for a couple years. I can relate to all the issues mentioned but I had to mostly figure out everything by myself like, regressions because we still deploying on avg ~1.2 times a day in the past year. I had to implement a custom intermediary layer so new features could land without having the codebase fully migrated. New components are being written using VueJS components and they still operate with previous non reactive backbone views. Properties and events are dispatched according by the custom layer. Now replacing the App shell is the remaining last step.

[@berndeckenfels]

Thanks for the insight

[@VinayAggarwal]

This video was uploaded a week ago and I've already watched it. why upload date is today's. By the way great content, enjoyed watching every bit of it.

[@adasjdaksjdlkasldjas]

Dev tools have a big advantage, that it will always have the latest Chrome/Chromium browser to run on. Meanwhile the rest of us need to make sure our code works on exotic browsers like Opera mini, browsers on old Android phones, Internet Explorer, Safari, Firefox, Qt webengine, and Webkit. Why do you have to support these other browsers you ask? So that we can avoid a browser monopoly.

[@ahmadhosafy]

That awesome moment when you find out that you share the same methodologies as top tier Google engineers 😁

[@Textras]

We learned the hard way 🙇‍♂️ follow 👆

[@mayo2001]

Why not eat you own dog food google and use Dart instead, so we can believe Flutter has a future for example? ;) Rewrite was ideal and missed opportunity here.

[@saithisx]

They didn't rewrite the devtools. They just refactored some things. The blog article they mentioned is worth a read ;)

[@yogeshkad6928]

Thank you so much but I don't understand what is devops tool please anybody tell me what is devtools

[@iyanello]

Devtools it's a special page in the chrome browser which helps developers to debug web applications and pages.

[@yogeshkad6928]

Thank you very much sir thank

[@adasjdaksjdlkasldjas]

Just don't do what the Firefox dev tools team did and rewrite using React, making it 500x slower, making the browser lock or even crash when dev tools are open. To be fair my use case for dev tools is showing a lot of console.log messages (yeh, I debug using console.log)

[@rand0mtv660]

How many console messages you have to show in order for dev tools to crash? I never had that happen even with console.log and all the warnings that are popping up about cookies and other stuff.

[@adasjdaksjdlkasldjas]

@@rand0mtv660 It has happened, the dev tools on Chrome now crashes/freeze for several minutes with 20.000+ console.log messages. Meanwhile Firefox dev tools seem to have got some optimization on that part and is now actually usable. I now have to use alert() messages for debugging in Chrome. Yeh I should probably clean up my console.log's but I'll just use Firefox dev tools instead. (Firefox dev tools freeze for about 10 seconds, while Chrome dev tools freeze for about a minute) A wild guess is that all formatting is slowing down the console log, I could live without the formatting if there where a way to just put raw text (no formatting) to the dev tools console.

[@rand0mtv660]

@@adasjdaksjdlkasldjas I still cannot see why would you actually need "few thousand console.log messages"? To me that seems like you have an infinite loop in your project and that's crashing dev tools

[@adasjdaksjdlkasldjas]

@@rand0mtv660 It's when there are problems in the app and you need to debug you need the dev tools the most. Before they made it slow, it was very handy to have the console.logs, as I could easily see where the problem loop was, as it could (before they made it slow) handle about 250.000 console.logs before it started pagination, I've had like two million console.logs and it was fine before.

[@rand0mtv660]

@@adasjdaksjdlkasldjas I also use console logs, it's not like I have anything against them. It's just that I never ran into a case where I needed to log out something like 100-200k times. It only happened if I accidentally created an infinite loop of something.