A bit of history

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.

Tools

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).

Device toolbar

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!

DOM Breakpoints

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 sources tab already contained breakpoints for JavaScript, which I use every now and again, but the DOM breakpoints were new to me. These breakpoints halt execution when a particular DOM node is changed. As such, they are not really traditional breakpoints, as they are not placed in the code that changes the node. Even so, such breakpoints are extremely useful when trying to find the code that causes a bug in your visual design, as it helps identifying the event that triggers this particular change, which can be a lot easier than trying to identify all code that could possibly change this element and placing breakpoints on those.

As a sidenote, chrome also allows for JavaScript breakpoints at a particular position on a line. I have never before seen this, but have often wished such a thing existed. Maybe this is already widely available in other languages, but I was impressed anyways.

Filmstrip

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.

Not too long ago I had to solve an issue that stated that "the screen flickers". I didn't understand what the testers meant by that, but eventually found out they meant that, if the JavaScript had not yet been cached, some elements are briefly shown before being hidden by the script. Thus, they saw some elements for a fraction of a second, which annoyed them. Had I known about the filmstrip back then, I would probably have understood the bug a lot sooner, and perhaps I'd even been able to find out which elements caused that effect, thus arriving at a better fix than the one being used now (which I won't disclose; it is ugly).

Flame chart

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.

Sources

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.

Conclusion

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!