Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for September, 2022.

Archive for September, 2022

Dear Console,…

Thursday, September 29th, 2022

The browser developer tools Console is so much more than a place to log your messages. It is a way for you to programatically access the currently shown document and window, read out values and change them. On top of that, it has a powerful API of helper methods to make that easier than with vanilla JavaScript.

Over the years, I wrote dozens of helper scripts that I use in the Console or as Snippets in the browser to make my day to day work easier. And lately I started tweeting about them using a “Dear Console,…” moniker. People seemed to like that so I started to collect these links on a Dear Console,… web site.

The Dear console web site.

On this site you can:

  • see all the scripts with explanations what they do
  • either click each of them to see the code, or copy them directly using the copy icon
  • paste them into the Console on web sites you want to query or change and hit enter

Here’s what that looks like in action:

screen recording of how to interact with the page

You can also filter the scripts by tag and you can use them in your own snippets .

The site is hosted on GitHub , and I welcome any issues and pull requests there.

Developers as an audience is a hard sell – part one “developers are influencers”

Monday, September 26th, 2022

When I wrote the developer advocacy handbook and advertised my new role as “Developer Evangelist” to my company one of the main points I made was how developers are an incredibly important audience for any company to covet. Not only do they build your own products, they are also influencers for other people. Developers are early adopters of technology and are often the people non-technical folk go to for advice what new computer/phone to buy or product to use. Developers are also on the more affluent side of the user spectrum and are OK to spend money on things they like and find useful.

Whilst many of these things are still the case, having managed a product that is solely for developers in 2020+ gave me a slightly different impression.

“Developers are influencers” doesn’t work in a consumer space

Over the last decade computers, the internet and mobile usage has evolved from a hard to grasp and not that desired thing to a commodity. Whilst computer literacy is still quite low, the need for it also became a lot less than it used to. Rampant consumerism doesn’t want people to tinker with products or even understand how they work.

Hardware is a closed, black hole that consumers are OK with.

Mobiles and laptops these days aren’t there for people to understand and customise. They are there for people to consume things on, buy things on and discard them when they get too slow. It’s pretty much impossible to repair or upgrade any of them and often you find that a 10 year old machine in pristine condition that would be “good enough” doesn’t even get the lastest OS upgrades.

This also interestingly seems to lead to developers not chasing the newest and coolest. I know many a developer that has skipped the last four upgrade cycles of phones and laptops as what we have now feels more developer focused than the newer machines you can’t even upgrade.

We also became weary of explaining things that aren’t developer centric at all. Apple does an amazing job getting people into their ecosystem and give them what they need without having to think about it. Even on Android copying content from an older to a newer phone is a breeze compared to the days of having to connect the phone via USB and finding a way to copy things over. In essence, the developer and consumer market has diverged a lot in recent years, and the saying that “if developers love your product they will tell all their non-techie friends about it” becomes a lot harder to prove. What makes end users happy – not having to understand any of the things their machine does – drives developers nuts as we feel locked out. In the past developers were much welcome experts to help you understand why something doesn’t work. These days as a developer you are as clueless, but even more frustrated as you know how things should work.

Browsers have become invisible

Especially in the browser market making developers happy was paramount. The story was that Google won the browser space because they made developers happy. They innovated the platform, they integrated excellent developer tools and the browser was ridiculously fast and small compared to others. The great news is that by now, the differences in browsers for the end user have become negligible. Most end users don’t even know what a browser is. Especially on mobile they often don’t realise that they don’t use “their browser” but some in-built browser of the app. On iOS, there is only one browser engine anyways – no matter what interface you put on it.

So whilst in the past developers were a good advisor for people on which browser to choose, this need has evaporated. Most of the time it is the browser that comes with the OS, or the one that people used for years anyway. There is a much deeper affiliation of users to the services browser companies provide than to the browser itself. It just feels natural that you use the browser of the same company that provides you with a great email and maps experience.

Sure, we now complain that “Safari is the new IE” as it isn’t as fast in adopting experimental technology and hot off the press standards. But if you look around what really ends up in products that people use then these standards have a 1-2 year adoption cycle and not the four weeks we have upgrading the browser.

Conclusion: making developers happy doesn’t automatically increase the number of end users

It is undoubtedly a good thing to make developers more efficient and give them the tools they need to find out how to debug and optimise the products they build. You can’t expect a great developer experience to automatically convert into a massive end user success though. You need to find other ways to measure and get support and investment of your company in developers.

A great developer experience of a tool only converts into more end users and more money coming in when you sell directly to developers. And even then you need to be lucky to hit a sweet spot of affordability and usefulness. There are other, less tangible or obvious ways in which you can measure success, and I will cover them later in this series.

In part two I will cover trying to increase developer adoption of a product and how hard that is to test and measure.

Quick reminder: HTML5 required and pattern are not a security feature

Thursday, September 22nd, 2022

Using the required and/or pattern attribute on HTML input elements stops users from submitting forms with invalid values, but you can work around that using the Console tool.

In HTML5, you can provide a `required` attribute to ensure a certain field has been filled out before a form can be sent off.

<input id="tac" required name="tac" type="checkbox">
<label for="tac">I have read the terms and conditions</label>

You can go even further and define a `pattern` that the value of the field needs to comply with before it can be sent off. For example, the following only allows entries that are either upper or lowercase a to z letters.

<label for="pkey">Product key (A-Z only)</label>
<input id="pkey" required name="id" pattern="[a-z|A-Z]+">

You can read up more on MDN and see some more examples.

Whilst this is an excellent way to get the browser to provide feedback to your users, it is not a security measure. Any form that relies on this feature alone can be defeated by using the Developer Tools Console and using JavaScript to submit the form.


You can see it here in action:

Screen recording of a demo of a form preventing submission and Console working around it

In any case, you always need to check the validity of any incoming data on the server side and, if necessary sanitise the data.

Celebrating 1M installs of Edge DevTools for VS Code

Thursday, September 15th, 2022

The Edge DevTools for Visual Studio Code extension has over 1M downloads, time to recap a bit how it came to be

the extension showing what it does inside visual studio code

When I started my current role in Microsoft one thing that ailed me was that the browser developer tools are great for debugging, but they aren’t changing the original code. It is quickly possible to find out why something doesn’t work and it is convenient to use visual tools to fix the problem but you still need to remember what you changed and repeat those changes in your editor.

One of the engineers on our team showed me an idea he had. As both the browser and the editor (in this case Visual Studio Code) are based on the same platform (Chromium), it would be possible to integrate the convenient debugging experience of the browser developer tools right into the editor and not only change what is shown in the browser but also the source code that generates it.

I immediately latched onto this idea as a great one and after writing quite a few presentations and many an internal meeting we got funding for the product.

Fast forward to now and the DevTools for Visual Studio Code extension just broke the 1M installs mark.

Header of the extension listing showing the amount of installs

We also have around 30,000 daily users and get a lot of great feedback on the GitHub repository.

I want to thank everyone involved in this project from the beginning to now. I am always humbled by how much talent the developer team has and how fast you can iterate on a product when you play fully in the open. I also want to thank the Visual Studio Code and the Visual Studio teams to be great partners to integrate with. It’s been a wild ride and it is great to see people be super excited about your work .

If you haven’t tried the extension yet, here is what it does for you:

  • Highlights issues in your code with explanations what the issue is and how to fix it. This is live – so while you develop your product you get information about what you are doing and what damage it causes.
    Code problems in the document being flagged up and explained
  • Shows your product in a browser preview with emulation options (emulate different devices, modes like dark/light/high contrast) and test some of its accessibiltity.
    browser preview showing the current project in a simulated mobile resolution
  • Syncs changes in the developer tools – like fixing CSS issues live with your source code
    a change in the styles using the visual tool affects the source code
  • Adds a Console for testing JavaScript
    The browser console inside VS Code
  • Adds the Application tool to inspect storage and services running in the background
  • Allows you to inspect the network traffic of your product
  • Allows to set breakpoints in your source code and get the in-context debugger

Whilst all of this gets the web developer in me super excited, the PM in me is also very happy about what it means to the Chromium developer tools project (which are in use in all the browsers based on it, Chrome, Microsot Edge, Brave…) all up:

  • We cleaned up a >10 year old code base to be not a monolithic box in the browser but allowed to use the different tools in the Developer Tools App separately.
  • We upgraded the browser screencast of Chromium to a fully fledged panel inside VS code, that can be moved to anywhere you want and has all the interaction you have in a main browser window when it comes to overlays and showing CSS features.
  • We integrated the functionality of the issues panel into your code to show you live issue reporting including customisability

Many of the learnings we got from releasing this extension can roll back into the developer tools themselves, with the biggest one being a new emulation/responsive web design toolbar in the main browser window .

There is a lot more to be gained from taking the Chromium Developer tools and embedding them in a different context, and I am excited that we managed to do this and reach this landmark. More to come.

Quick tip: embedding YouTube Videos in GitHub pages

Wednesday, September 14th, 2022

A youtube video embedded into a markdown file showing up on GitHub pages

GitHub Pages is a great way to host some of your content online. All you need to do is to write some markdown files and tell GitHub to create it as a page.

The problem is that you can’t just add some HTML into your markdown to – for example – embed a YouTube video. It does work if all you include is the YouTube iframe, but when you work with professional markdown repos, this will be flagged up as an error or security problem.

A workaround that many people use is to embed a linked preview of the video :

If your YouTube URL is the important part is the ID after the `v=`, in this case `JLMbpiywVxQ`.

You can then use the following markdown to embed a link to the video with a preview image of it. YouTube automatically creates these preview images.

[![Final video of fixing issues in your code in VS Code]

Final video of fixing issues in your code in VS Code

If, however, you want to embed the video in markdown files, you need to do a bit more.

1. Go to the root of your GitHub repo with the markdown files and create a folder called `_includes`.
2. In this folder, create a file called `youtube.html`. Paste this HTML and CSS and save it.

<div class="embed-container">
    <iframe width="640" height="390" 
    src="{{ }}" 
    frameborder="0" allowfullscreen></iframe>
.embed-container {
  position: relative;
  padding-bottom: 56.25%;
  height: 0;
  overflow: hidden;
  max-width: 100%;
.embed-container iframe,
.embed-container object,
.embed-container embed {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;

Now you can embed any YouTube video in your markdown files using the following:

{% include youtube.html id="JLMbpiywVxQ" %}

With the ID being the YouTube ID.

You can see this in action and fork the youtube embed demo repository if you don’t want to do it by hand.