to push my engineering career forward and improve my overall wellbeing

This year ends up being a turning point for me. For the past couple of years I’ve been working like crazy… but not always in the most smart or effective way, whereas recently I have managed to implement several things from what I’ve learn before in a better way.

So if this article comes across as a pat on the back… well, it may be so, a little bit. I believe it is worthwhile to be grateful to other people and, yes, to yourself too. Also it’s not like I don’t have any regrets. Basically any point on the following list may be reworded as: “I regret that I haven’t done [ABC] earlier”. There is also a point on that near the end.

But most importantly I’m writing this in hope that at least one or two of these points will resonate with you and inspire you, or help you realize that you did couple of things in 2018 right too!

1. Left a well paying project (for a good reason)

For quite a long time I have been working on a project that, I must admit, paid distinctly more than any job I had had before. It was frustrating though. And I don’t mean it in a “we’ve had some ups and downs” fashion. It may have started as that but after a while time it was 95% bad. I felt like I wasn’t making any progress, I was doubting myself and… resenting programming altogether.

Thankfully, I had several outside signals that it’s not necessarily me. More likely it’s that me and the project are just a bad fit. It’s extremely important to have some kind of support, both in your personal, and in professional life too.

I decided to leave. How I did that was another new thing for me.

2. I did it assertively

In over a decade of my professional career I had several jobs. Most of them I landed in a pretty passive way:

I’d work in a quite good job. Then, after a while, a significantly better offer would appear, usually presented to me by a headhunter. I’d go for it but… always having this thought in my mind: man, if this more or less random offer is this good, I could have started to look for interesting companies myself earlier and have much more choices by now.

Well, this year I finally did it. Not only have I decided to be the one who initiates the process, but I also went one step further and first informed my employer that I’m leaving and only then started looking. (Of course not everyone can afford such decision, but I do speak from a perspective of a seasoned engineer working in a popular technology).

What it allowed me to do was, amongst others, to simply post this tweet:

Tomek Sułkowski on Twitter

Please help me find work: 🅰️ Angular 🧙‍♂️ Senior level 🏖️ Remote ⏱️ 20-40h/week About me: 🎓 IT Trainer (>2000 hrs) 🗣️ Conference speaker 📅 Community organiser 🚀 Willing to travel 🎨 Creative skills ✍️ Loves sharing knowledge Retweets appreciated ❤️ DMs open 📨

Twitter is an amazing community and, in my opinion, it’s a much better chance to find a cool, progressive projects here than on, say, LinkedIn.

In the end it did lead to some great conversations and contacts, and one of the results was that I am now a part of StackBlitz — the project I’ve been admiring for a really long time. I don’t believe it would’ve happen otherwise.

3. Didn’t buy the best iPhone

Disclaimer: Ok, I know, this is such a first world issue… Treat it as an example and distinctive illustration of a more general issue, I think it can be scaled down or up, depending on your circumstances.

This year my old iPhone just started dying. I had it for over 3 years too, which, for a geek’s smartphone, is a fairly long time. I was considering what to get next and I had a means to buy “the latest and greatest” — which at the time was the $1000 iPhone X.

Thousand bucks gave me a pause though. I started considering the actual improvement that it would bring to the the quality of my life.

In the end I bought the cheapest new phone available (iPhone SE)…

… and a frickin’ quality digital piano — for the same total.

I use it to relax after a day in code and to have fun times playing with my son.
And my new phone works fine.

4. Started using Twitter

I’ve created my Twitter account in 2008 but until this year I haven’t posted anything, haven’t read it and, frankly, haven’t understood it much either. I was kinda getting a feeling that it’s just a messy soup of humans and bots shouting at each other. Ok, in a part I was right ;-) but I have also found that if you choose carefully who to follow it becomes a valuable resource of first-hand knowledge.

You get the latest from the libraries’ authors, in that nicely condensed form, so it’s a pretty light way of staying up to date.

You can also engage in direct conversations. From my experience you have much better chance of getting a response here than by any other digital means.

And finally, if you have something to share, it’s the easiest place to start. Doesn’t require much involvement or production values. Just write your message and hit “Tweet”. Additional value is that often someone will take your idea and improve upon it — so you’ll end up learning even more:

بهنام محمدی on Twitter

@sulco this code is great. but i think this code need AbortController for abort fetch request. e.g:

In my case, at the beginning of the year, with just a single digit of Twitter followers, I decided to work on opportunities to spread my programming knowledge to more people — so I started to tweet “dev tips” every couple of days. Today there are more than 2100 people who seem to like the content I’m putting out there. I am extremely grateful for that, since it helped me to reevaluate my role in the community, combat my strong imposter syndrome (ongoing battle btw. if anyone’s interested) and even find a job (vide point 2.).

And if you think you don’t have anything valuable to share, see the next point.

5. Kept the ideas list

Almost every self-help book and even more articles tell us about the importance of writing lists. In my experience this is most useful in 2 areas:

• groceries
• content creation ideas

This year I finally went over that threshold of having a big enough need and finding an easy enough tool to keep it.

Often, during the programming workshops I lead, or when discussing something with a colleague I realize that the thing we’ve just been talking about is a great idea for an article or a tweet. I write it down immediately. Yes, even during a workshop: one or two words is often enough for it to don’t slip your mind.

For that reason I needed something that is extremely simple and always available, no matter the device and internet connection. Would be nice if it could store images and formatted source code. A pleasantly looking UI also wouldn’t hurt. What fit all these requirements for me is Bear (if you’re looking for recommendation).

At this point in time I have a backlog of more than 60 ideas for dev-tip-tweets and quite a few for blog articles as well. A lot of them are… not that good, but some are pretty cool — and that’s subjective anyway. The important thing is that now, whenever I have a moment to put something online, I just open these lists and pick and idea that I feel like working with.

6. Went ahead with a cold shower experiment

Ok, this one is pretty random.

One sweltering August day my wife told me about some couple doing an experiment that involved taking cold showers for a whole month to see if that decreases sweating. Or something — I didn’t really follow that story. I decided to try that myself though.

[ No illustration for this section, sorry 🥶]

To be honest, I never really got used to the icy cold, but… what has surprised me is that I couldn’t get myself to stop too. Finally after 2 months when I got a stomach flu (high fever and such) I had to take a break and didn’t go back.

But what I got from it was a new conviction that I can actually easily handle much more discomfort that I’d have given myself credit before, and it’s worth exploring in more areas of my life — the ones that could improve it. Maybe smarter diet? Some healthy habits?

7. Took the family on the road and to a conference talk

For the past 4 years I’ve been travelling a lot (~2 times a month) doing workshops and talking on conferences & meetups. I was getting fed up with the realization that all that my kids, who are 4 and 6, see their dad doing is just me sitting in front of screen reading colorful letters. Also, I was just missing them.

So this year I took my family to couple of my work trips so we could explore new cities together and have an adventure. They also went to one of the conferences to see their “old man” giving a talk— which somehow was double nerve wracking for me 😅

In any case it was definitely a great bonding experience.

8. Started — and finished — an advent calendar project

With everything going on in 2018 — the regular tweets, new jobs, trainings & conferences, I stopped having time for the blog.

And don’t get me wrong: some things have to end to make place for others, and some things just don’t work out. But I feel that my blog isn’t one of those things. I knew there is a value there, I just lost the flow.

To get back on the horse I decided to put some condensed effort into it and gain a momentum that would allow me to ease up into a steady pace of writing in 2019.

Also, I had a pretty huge backlog of tips related to Chrome DevTools.

That’s how the idea of DevTools Advent Calendar was born: for every day between December 1st and 24th I was publishing one new article related to this great set of tools.

I won’t lie: after few fist days it was already difficult to keep up. But in the end it made me improve my skills in preparing visuals well and quickly (several people asked me about it, so I’ll do a write-up of my setup soon).

It also made me learn the hard way that given a clear objective I still have 1–2 hours in my busy day to do… something. Something constructive.
I’ll definitely have a use for that newly gained confidence in 2019!

Epilogue

I hope you’ve found a couple of ideas, inspirations or maybe a reflection of your own experiences in this random set of .

As said before, I don’t regret doing anything specifically… but on the other hand, I do have several things that I wish I had started doing even well before 2018.

Therefore the next article that I intend to put here will deal with what are my ideas about 2019. Yes, that’s right, I have a resolution list and it so happens to come together around the time of new year. ¯\_(ツ)_/¯

As always, if you’ve liked this article, please:

→ smash that👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve talked about code coverage and changes panels and today…

It’s the last day of the DevTools advent calendar! It went so quick! Let’s do a couple more random tips, shall we?

67. Use console.log in callback directly

Often I find myself in a situation where I’m not entirely sure what gets passed into a callback function. In such case I add a console.log inside to check that.

It can be done in two ways though: either use console.log inside a callback function or use console.log as the callback. It’s not only less typing but also it may be that the callback receives more than 1 argument which you could miss in the fist solution:

68. Find in elements, logs, sources & network

Each of the first 4 main DevTools panels supports [ctrl]+[f] shortcut which you can use to find pieces of information using relevant ways of querying:

• in the Elements panel — by a string, selector or XPath
• and in the Console, Network and Sources panels — by strings, optionally case sensitive or treated as regular expressions

69. Use live expressions

2 months ago DevTools introduced a pretty nifty addition to the Console panel, a tool called Live expression. Just press the eye symbol and you can define any JavaScript expression there. It will be constantly updated so the result of that expression will be always, well, live :-)

You can define several of those at the same time:

70. Stay up to date

If I could summarise these 24 days of tips in one sentence it would read something like:

“DevTools is a powerful software that’s easy to underestimate. It has a lot of hidden features that we often don’t even suspect we need.”

Ok, that’s two sentences. Anyways, it can be overwhelming to think how many tools are the part of this suite. And to keep track of new ones constantly being added!

70.1. Google Chrome Developers

I highly recommend subscribing to the Google Chrome Developers YouTube channel where new things are being demoed as they appear in Chrome. Not only that but you can go there to find discussions on best practices, evolution of JavaScript etc, etc. A lot of valuable content for any front end developer.

70.2. Developers.google.com

When I was working on this articles series I did keep a backlog of favourite features and techniques, but other than that I was also heavily browsing through the official Google Developers website which allows you to look informations about specific updates (“By Year”) or technologies (“By Tag”), like this one, about recently released Chrome 71:

New in Chrome 71 | Web | Google Developers

70.3. This isn’t over

And finally, even though the “Advent Calendar” is over, I haven’t run out of that backlog of tips! Not by far.

I definitely won’t be publishing it every day, but there’s no way that the tips would stop — I’m simply too excited about this multitude of possibilities we have to make our work easier and more fun :-)

I will keep publishing these here on Medium, on my Twitter account, and soon also on YouTube (yeah, gifs are kinda limiting 😅)

So, if you’re into JavaScript / TypeScript / CSS / React / Angular / Chrome — let’s keep in touch! Follow me on here or/and on Twitter. And finally…

Merry Christmas & Happy Holidays to you all!

Tomek Sułkowski (@sulco) | Twitter

DevTools tips — day 23: coverage and changes

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve had a couple of Network tips; today let’s continue the Drawer tips we started the other day and talk about 2 more of the useful tools hidden in there:

65. Check the code coverage

A lot of the code that ends up on your page is not actually needed. Maybe it’s a some big chunk of JavaScript from an external library, maybe some CSS rules on forgotten selector that doesn’t match anything anymore.

To get a nice summary — and details—of that redundant code use the Coverage panel. To open it use the Drawer menu or, quicker, Command Menu:

DevTools’ Coverage tool can track which lines of the currently loaded JS & CSS files are being run and displays the percentage of unused bytes.

It also marks the lines that were run in green and the ones that weren’t — in red. Let’s see it on a simple example:

66. Check what you’ve changed

Designing in browser, adjusting those css values, playing with the code where it’s evaluated — it’s both convenient and fun. But at some point you might want to compare what you’ve changed with the originally loaded stylesheet.

For that purpose use the Changes tool that resides in the DevTools’ Drawer.

It will not only show you the changes in the form of a diff that you may be familiar with from using a source control tool like Git, but also allow to undo them. See that in action:

And that’s it for today. If you’ve learned something useful, please:

→ smash that👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:
(I write on stuff like this and all things TypeScript, Angular, and React)

Tomek Sułkowski (@sulco) | Twitter

Also, the 24th day is already published, read it here:

DevTools tips — day 24: the last day

DevTools tips — day 22: network tips

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve played with snippets, today let’s talk about network:

61. Hide network overview

Are you usually looking into the Network panel to:

• see that requests timeline
• or maybe just the requests list — to check the statuses, sizes and responses?

My bet is that it’s the latter. If that’s the case there really is no point in the Overview section taking around half of the Network’s real estate. Hide it.

62. Request initiator shows a call stack

The Initiator column in Network panel shows which script and its line triggered the request. It shows the last step of the call stack that caused the request to be made so unless you are using e.g. a native fetch API, it will point show some low level library code — for example xhr.js when using Axios library or zone.js when working with Angular.

More than those vendor libraries you probably want to see which part of your code triggered the request. To get that information just hover over that displayed initiator (i.e. the vendor library) and you will see the full call stack, including your file:

63. Filter requests by method

The filter input in the Network panel can take a string or regular expression that you type there and only show the requests that match. But you can also use it to filter by, well, a lot of properties.

Just type e.g. method: or mime-type: there and see for yourself!

To get a full list of possible keywords press [ctrl] + [space] on the empty input.

64. Customise the requests table

In the requests table you can see several pieces of information about each request, such as: Status, Type, Initiator, Size and Time. But you can also add more (e.g. I usually add a Method). Much more actually:

To customise which columns are displayed, just right-click anywhere on the requests table’s header. Note that Response Headers is a whole submenu with even more options, and even a possibility to define your own:

And that’s it for today. As always, if you’ve learned something new, please:

→ smash that👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 23rd day is already published, read it here:

DevTools tips — day 23: coverage and changes

DevTools tips — day 21: snippets

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we have seen some DevTools Workspace magic, today we’ll play with snippets:

59. Snippets

Sometimes I use JavaScript as automation tool to work with 3rd party websites and apps.

Let’s say for example that I’d want to see how many people clapped on all of my Medium posts. Medium doesn’t provide such total number, so I’ve put together this small script:

$$('td:last-child .sortableTable-number')
    .map(el => parseInt(el.innerText))
    .reduce((total, value) => total + value);

When I go into my stats page and type it into the Console, it will return the number:

Now, granted, it didn’t take me that much effort to write that, but if I were to do it once in a while it would certainly be annoying to remember the right selectors etc.

This is where Snippets come in: it’s a way to store pieces of your JavaScript code into DevTools so you can easily reuse them later.

To create such snippet, go into Sources panel and in its Navigator sidebar choose Snippets tab. Press “New snippet”, type your code, save it and you’re all set! You can now run the code from right-click menu or by pressing [ctrl]+[enter] shortcut:

60. Run snippets from wherever

Once you have a set of awesome snippets set up, you don’t even have to visit Sources to run them. The quickest way, as we’ve already discovered several times this week, is to use Command Menu. If you type ! in its input, you can pick one of your snippets by name:

And that’s it for today. As always, if you’ve learned something new, please:

→ smash that👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 22nd day is already published, read it here:

DevTools tips — day 22: network tips

DevTools tips — day 20: workspace

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve covered several panels hidden in the DevTools Drawer, today it’s a Workspace day:

55. Edit your source files from Chrome

Sometimes it’s easiest to edit the code right where it’s evaluated — in the browser. If you just drag and drop your project’s folder into the Sources panel, DevTools will synchronise the changes you make there with the actual file system.

This is super handy for those quick fixes! (I actually knew a dev who preferred to do most of his coding in such fashion)

But wait, it gets better…

56. Workspace allows an instant styles sync

So as we’ve just said, once you have your DevTools workspace set up, you can edit your HTML and JavaScript (or actually even TypeScript, if you have sourcemaps) files in the Sources panel and after pressing ctrl+s it will be saved in the file system.

But it’s get even better in case of styles. Because now, even when you edit your style rules in the Styles section of the Elements panel… it will just sync right up. Instantly!

What kind of magic is that?!

57. Select a target location for new selector

If you want to add a new style to an existing selector it’s easy: just find that selector in the Elements panel’s Styles section and start writing your css. But if there is no such selector yet, you need to press that New Style Rule button.

When you are working with workspaces though, the default location of that new style rule — that "inspector-stylesheet:1" place—is not exactly where you’d want the rule to appear. In such case just hold the New Style Rule button and you will see the options will all your css files listed. Just choose your destination and new rule will be saved there!

58. Workspace allows css injection!

With workspace set up not only are the changes made in your browser persisted into the file system, but also your CSS changes save in the file system (i.e. your VSCode, WebStorm, Notepad…) are immediately picked up by the browser and show on your page. Without refreshing it.

Let me be clear: there is no external tool used here — no Webpack hot module replacement or nothing — it’s just any local server and DevTools’ workspace.

Phew! I don’t know about you, but for me these tips were actually exciting if not a bit crazy 😅
Anyways. As always, if you’ve learned something new, please:

→ smash that👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 21st day is already published, read it here:

DevTools tips — day 21: snippets

DevTools tips — day 20: workspace was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

DevTools tips — day 19: drawer tips

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve started looking into the drawer, today see a couple of interesting tools hidden in there.

52. Control the sensors

If you are using a geolocation API in your application and want to test it, you probably wouldn’t want to drive around all over the world just to do that (there are far better reasons to travel 😉).

Sensors panel located in the Drawer lets you emulate a specific location. You can choose from the predefined places, add your own, or just type latitude/longitude by hand. The selected values will be the ones that navigator.geolocation.watchPosition (or .getCurrentPosition) will report.

If your app uses accelerometer, the Sensors panel allows to emulate the position of your device in 3D space too!

53. Simulate network conditions

Just as with faking your location you can use the Network conditions drawer panel to simulate a specific network behaviour: pretend the internet is a typical 3G network or even offline! That should help appreciate the size of your page’s assets.

Or test the offline capabilities of an app.

The Network conditions panel has also a possibility to impersonate a specific user agent.

54. Have the source by hand

In a similar way to how it’s useful to peek into Console while simultaneously having a different panel opened, I sometimes want to see my source code when e.g. I’m mainly focusing on the Elements panel. And just as with the drawer console, you can show Sources in the drawer.

As you can notice it doesn’t have all the bells and whistles of the “main” Sources panel, e.g. there is no call stack or control (pause, step over, etc.) buttons. And if the breakpoint will be triggered it won’t be shown in the drawer’s Quick sources but in the main Sources.

But it’s still useful to have that quick look at the code and for setting up breakpoints.

If you like this article series, please:

→ clap 👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 20th day is already published, read it here:

DevTools tips — day 20: workspace

DevTools tips — day 18: hidden in a drawer

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve seem some ways to improve logs readability in the console. Today let’s talks about the powerful set of functionalities hidden in the DevTools drawer:

50. The DevTools drawer

Chrome DevTools has a lot of great number of apparatuses divided into its 9 tabs (Elements, Console, Sources, Network, etc…) — but that’s actually just a part of it! There is a “parallel” set of tabs, that are hidden below the main window. This set is called the Drawer.

To access it, when you are in DevTools (any tab), press [esc].
Press [esc] again to hide it:

By default you will see a Console tab there. That’s the same exact console as the main Console panel. That’s why it will show for every main tab (Elements, Sources, Network…) except the Console one — for which it doesn’t really make sense.

It’s handy to have such console visible at the same time as e.g. the Elements panel. But that’s not all that is hidden in the Drawer.

51. The other tools in the drawer

There are so many other functionalities hidden in the drawer that you likely won’t need most of them most of the times, that’s why they are hidden and you can just pick and choose which one you want to show there.

To open the full list of these possibilities click the menu icon (⋮) placed before the drawer console panel’s tab. Alternatively, you can also use the Commands Menu and type in “Drawer”:

Ok, let’s see all the options once more:

Animations, Changes, Console, Coverage, Network conditions, Performance monitor, Quick source, Remote devices, Rendering, Request blocking, Search, Sensors and What’s new

Phew, that’s… [counts quickly] a total of 13 new areas to explore!

As have probably guessed, I will show more tips for the things we can find here… but let’s leave this till tomorrow (here), when we’ll look into couple of the coolest of the bunch.

In the meantime, if you like this article series, please:

→ clap 👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 19th day is already published, read it here:

DevTools tips — day 19: drawer tips

DevTools tips — day 18: hidden in a drawer was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

DevTools tips — day 17: back to the console

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve covered DOM and Ajax breakpoints. Today let’s start the week by going back into console!

48. For more readable logs— add brackets!

If you console.log even a single variable you might forget (or get confused about) which one was that. Things get event less readable if you have multiple variables to log.

To make that much more readable, log an object instead — just wrap all your console.log parameters in curly brackets. Thanks to the enhanced object literal introduced in ECMAScript 2015, that’s all you really need:

Can’t get much clearer than this! Or can it…?

49. Brackets + table = 🤯

Remember that console.table tip from the Day 3 of our series?
Let’s add that too!

The ultimate log.

And that’s it for today! As usual, if you’ve learned something new, please:

→ clap 👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 18th day is already published, read it here:

DevTools tips — day 18: hidden in a drawer

DevTools tips — day 16: breakpoints

part of the “Advent calendar for front-end developers” series

Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve had some “guest tips”. Today let’s look into some ways to trigger a breakpoint.

45. DOM breakpoints

Is Some script changing a part of your DOM and you’re not quite sure which one or when? Add a DOM breakpoint. You can listen to node being added or removed, or its attribute being changed:

The breakpoints are remembered between page reloads. Once you’ve set up one — or a couple!—of them, you might forget where specifically they’re attached. How to find them? There are visual cues in the Elements view and a dedicated list in the Sources for this very purpose.

And don’t worry if the element you’ve attached a breakpoint to is hidden in some collapsed parent ancestor element—it will still show in the Element, just in a lighter color.

46. MutationObserver

This tip is not exactly related to DevTools but since it’s a nice expansion upon the previous one, I hope you can forgive me this digression.

Anyways, did you know about MutationObserver? It’s an object that’s just a part of browser API and allows to listen to similar changes as the previously mentioned DOM breakpoints do:
childList, attributes and subtree — but this time from your JavaScript code.

And it’s actually quite well supported, starting with IE11.

47. XHR/fetch breakpoints

If you want to catch the specific moment an “ajax” request is being sent, use this XHR/fetch breakpoint. These you can only set up in the Sources panel (I’d hope for Network panel as well, but that doesn’t seem to be the case).

You can add a partial URL as a trigger or listen to any request:

And that’s it for today! As usual, if you’ve learned something new, please:

→ clap 👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:

Tomek Sułkowski (@sulco) | Twitter

Also, the 17th day is already published, read it here:

DevTools tips — day 17: back to the console