Way back when browser vendors weren't aware of the existence of webdevelopers at all (pre 2006), somebody smart (Joe Hewitt)) came up with the FireBug extension for Firefox. This was pretty revolutionary in the way it allowed programmers access to the inner workings of their website in that browser, so everybody starting using it. A couple of years later, when the Chrome browser entered the playing field, they did so with similar tools already integrated into the browser itself, resulting in a (very) significant increase in performance as compared to Firebug. As far as I know, most webdevelopers have been using Chrome as their main development browser since.
Personally, I still daily use the tools that were already available in Firebug, but only very feq of the newer ones. As a backend developer, knowing whether the response data (content and headers) sent are the proper ones is usually enough. However, for frontend developers, a lot of options have apparently been added since I last did any real work in that domain.
The list is too long to run through myself (Prashant went through his talk at an epic speed), so please find the link to his notes on our meetup, but I liked a few of the options enough to name separately. Please note that some of the options may be "experiments". To view them, you might need to use chrome canary, enable experiments, or even enable "very experimental experiments" by shift-clicking 6 times somewhere (I forgot where, but googling it should work).
I love this one. Ever wondered what your website looked like on an iphone, but just wondering was not worth buying one? Chrome can render it for you in the correct format! Just click the phone/table icon placed in the top left (second icon) of the chrome dev tools dock. It allows the developer to render the site in a responsive format, with several devices already preconfigured. It is not a perfect rendering, but it is close enough for government work.
As such, this was not new to me; I almost never needed it, except for understanding certain bug reports. But Prashant showed us that the device toolbar also contained an option (top right) to show a device frame. While otherwise completely useless, it is one of those little options that makes stakeholders go "wow, that is cool!". And even one of those moments can be the difference between a good and a great product demo!
Most developers know about breakpoints; somehow (usually in an IDE) the developer tells the application to pause execution if a particular line of code is reached. This allows for detailed inspection of program state, and thus makes debugging a lot easier.
The filmstrip is a part of the network tab —the tab I use the most— so none of the options that were mentioned here were new to me. None but the filmstrip that is. It makes screenshots of the browser content at every redraw of the browser content. Most importantly, it can do this during page load. So using the filmstrip, I can see exactly what my users would see, even if it only shows for a fraction of a second. It can be enabled through clicking the camera icon in the network tab.
The flame chart is presented in the timeline tab. I remember being impressed with the possibilities of this tab, even if I don't quite remember why anymore. It contained a lot of pretty colors that had something to do with identifying the slow components in your code. I also remember thinking to myself that I had to look deeper into this tab when I ever needed to debug speed issues in frontend code. However, I haven't needed to do that in a long time (at least 5 years), so I have not yet looked deeper into this tab. If I ever do, I'll consider dedicating a separate blog post to it, because I think this chart is complex enough to dedicate a full post to anyways.
The sources tab shows the source of the files received in by the browser. Which is the most basic option dev tools must have. However, Chrome canary takes this a step further by allowing the developer to map these source locations onto files on his disk, thus automatically saving changes in the dev tool not only in the code being used by the browser at that moment, but also in the original code! This is actually a huge step towards an integrated development environment (or: IDE, as most developers know the term). Which is huge!
A lot of IDEs have at the very least tried out internal browsers to view code changes in, which makes sense: an IDE should be able to show the result of your code, or it is not really "integrated". However, I never liked the way they worked. We all know about the problems arising from having to support various browsers, so why would I want to primarily code for a browser version only developers using the same IDE as me will ever use? Granted, the emergence of webkit may have simplified this issue a bit, but still, I prefer directly coding for a browser that is being used by end-users.
However, if chrome, the browser with the largest market share, can suddenly become a proper IDE, this will change the playing field significantly. As far as I could see from the demonstration given, it is not yet at the level of real IDEs from e.g. JetBrains, but it is definitely closing the gap.
There is a lot I didn't know about the power of Chrome as a development aid. I probably still don't. And if I were a frontend developer, I'd be extremely happy with the additional power I was given over my code through this talk.
However, I have to admit I probably won't use most of the options we were shown. Since the technight, I have only used the iphone frame of the responsive view; not because it is particularly useful, but it looks cool, so who cares anyways 😁. Otherwise, most options are too frontend specific for a pretty much dedicated backend developer like me.
Nevertheless, if I ever find myself lacking an experienced frontender, I'll be happy to know I've gained a few more tools with which to gain insight into my application!