Visual Studio Code now has a TikTok channel and they asked me if I wanted to contribute, so here you are:

@vscode

A look under the hood ##vscode ##techtok ##codetok ##programming ##edutok

♬ original sound – Visual Studio Code

A 20 second video of me explaining that I like VS Code a lot as it comes with DevTools built in where you can see how the interface was done with HTML/CSS and JS.

Here’s how I did it:

• Filmed me saying all the things on my balcony with my phone
• Recorded my screen using Screenflow doing the things that I talked about
• Created a 1080×1920 new project in Screenflow
• Added my video as the background (weirdly enough I had to rotate it 90 degrees)
• Resized the screen recordings accordingly and added a zoom action to the second one.

I had a longer meeting with the VS Code team on the merits of TikTok and how you reach a different audience that way. And I learned that edutok is a thing.
I don’t like the portrait format for showing off full code editors or browser functionality where the app by default is landscape, but I can see doing more of these in the future for the VS Code team. As to me joining TikTok, not sure. It already annoyed the hell out of me that the video keeps looping while I am answering comments.

This weekend I released a video on the YouTube Channel of Visual Studio Code that shows end-to-end web project debugging.

In five minutes I walk through debugging a web project bit by bit:

• I open a project inside VS Code by opening its folder. The demo used is a simple, plain Vanilla JS/CSS/HTML ToDo app you can download/fork on GitHub.
• I open a Terminal inside VS Code and start a local server. I use the server that comes with PHP as it already on my computer (for now – MacOS will soon deprecate this option)
• Instead of opening the project in the browser, I use the run and debug workflow of VS Code to open a dedicated browser instance to debug this project with. If I have a Chromium based browser on my device and have it set as my default browser, this will be the one VS Code uses. In my case, this opens a new window of Microsoft Edge, as this is my main browser on this MacOS computer (yes, it runs on Mac for over 1.5 years now). I use Edge to show extra functionality later that is only supported in this Chromium based browser.
• Having a dedicated browser instance also means that I get the Browser Developer Tools Console functionality now inside the Debug Console of Visual Studio Code. The Debug Console shows any console.log messages from my JavaScript and I can also interact with the document in the browser using the Console convenience methods like $ for querySelector(). I have full access to the window object and can change the DOM and the styles of the document in a programatic way.
• In addition to console.log() debugging I also have the opportunity to use breakpoint debugging instead, which gives me a lot more insight and also has the benefit of halting the execution of my script until I found out what’s going on.
• As I am using Microsoft Edge as the debugging browser I also get an inspect button on the debugger toolbar. This one gives me access to the Edge Developer Tools right inside Visual Studio Code. This functionality is powered by the Edge Tools for VS Code extension which gets installed for me the first time I select the inspect button
• Once the extension runs, I can access and change the DOM and the CSS of the current project right inside Visual Studio Code using the same tools I normally use in the browser.
• I also have access to the Network tool to inspect any Network requests and see if there are any issues of content not being loaded.
• In order to automate the process of starting the browser and opening the localhost address next time, I can also get the debugger extension to generate a launch.json file for me. Once I have that, next time all of the above happens automatically.

If you want to learn more about the JavaScript debugger in VS Code, you can check the documentation here or talk to Connor Peet on Twitter. For the Edge DevTools for VS Code integration you can read the extension documentation and check the code on GitHub. We’re also welcoming filing any issues on GitHub and you can talk to me, codepo8 on Twitter or the team at EdgeDevTools

A special thank you to the team involved in all this work, James Lissiak, Michael Liao, Vidal Guillermo Diazleal Ortega, Brandon Goddard, Olivia Flynn, Tony Ross, Rob Paveza, Jason Stephen, Connor Peet and of course the VS Code team.

Today the World Wide Web is 30 years old. I’ve worked on it since 1997 or so and I saw a lot of technologies and design trends come and go. I’ve also seen a lot of “this is much better and will replace the web” solutions come and go. What remained is the web with its “dumb” technologies HTTP, HTML and CSS. Each of them are forgiving in their nature. They allow developers to make mistakes without punishing the end user. Many people sing the praise of this approach and architecture, so I’m not going to repeat it.

Enter JavaScript. When I started with JavaScript, it was a fun thing to do as it prevented you from having to reload a document. You could validate a a form and tell people they forgot something. A much better experience than finding out after a few seconds of loading the document. And of course hoping people in the other room don’t pick up the phone and interrupt your modem connection.

JavaScript is fun to work with as a developer. You can generate HTML and CSS with it and you have full control over what you create. You can detect things like window size and if certain technologies are supported and create content accordingly. You can load things on demand and only when the user needs them. It feels great to be in control.

CSS and HTML, on the other hand, feel like you give away control and hope for the best that it will work. There is no feedback channel, you can’t set up an error trap. That’s on purpose and the main thing to learn as a web developer is that you aren’t in control, but your users are. The more flexible your solution is to cater to the needs of your user, the more successful it will be. “Survival of the fittest” isn’t about strength, but about adaptability.

JavaScript isn’t a web technology. It isn’t governed by the W3C but by ECMA. What works and doesn’t work in JavaScript is dependent on browser makers. What you can use in JavaScript is also dependent on the end user having a “modern” browser. “Modern” means nothing, by the way, and I wished we stopped using that term as it is fleeting.

Other things that affect your JavaScript happiness are proxies and blocker add-ons. Or bad connectivity and a file not loading. The issue is that JavaScript isn’t as forgiving as HTML and CSS is – when you do something wrong, things break. Used wrongly, JavaScript can seriously affect the performance and even the security of the web product you create. To a degree this also applies to CSS and HTML, but you have a lot more power with JavaScript.

However, if you work with a new-ish computer on a fast connection, you are most likely not savvy to any of these issues. Instead, you’re prone to pile up more and more dependencies and code to increase your developer convenience.

When it comes to used technologies of the web, it shouldn’t be a surprise that a lot of it depends on JavaScript. And on not well-thought-out, hacky and unmaintained JavaScript to boot. Libraries don’t get updated regularly despite blatant security issues in them. Stop-gap solutions built to work around an issue of a browser in a certain version never get removed.

The web is a landfill of accumulated, unmaintained and often bafflingly bad code. And yet it works. This isn’t only the result of sturdy technologies driving it. It is – to a large part – browsers doing anything they can not to break the web.

The first browser I used as a daily driver was Netscape 3. Netscape had no chill. If you didn’t close your tables in your HTML, it didn’t show anything. That taught me to value HTML validators as part of my workflow. But these days browsers can’t ever break the web. Whatever you throw at them, something will render. And that takes a lot of work and we should thank browser makers more as that is something that kept the web alive.

Working on browsers taught me a lot of things and made me a lot more humble than I was when I was a web developer. As a web developer I thought browser makers keep the web from evolving as it doesn’t affect their bottom line. As a developer working for browsers I learned that a huge part of the engine is dedicated to backwards compatibility. JavaScript engines make sure that code that performs badly because of the way it was written still runs smoothly. And new features of the platform only get into production after making sure that they aren’t a security, accessiblity or performance issue.

So, when we celebrate the web today, I also think we should celebrate the people who built the technology that enabled it. Browser makers, framework creators, server-software creators and all the people working on the infrastructure of it.

Of course it is damn cool that the first web site ever (and yes, the Space Jam one – enough already) still renders in browsers now. The reason is though that these web sites don’t do anything hard and are quite clean code. That the web in between, with the crimes of DHTML, the library and browser wars and all the hacks people put in there to achieve a certain effect still renders is because of browsers allowing for this.

I would love to be able to make browsers a lot leaner. But the web we have now is a mess. A wonderful, exciting mess that allows anyone to take part in it as a creator. And that’s thanks to its base technologies and to a lot of people in browser companies making sure it keeps working.

Today I finished moving the Edge Tools for VS Code extension documentation to its official space in the Microsoft docs. That meant I needed to redirect the documentation I hosted with GitHub pages in a docs folder/branch of the repository.

There are plugins available for that, but I didn’t want to install any extra features on the repository, so I chose a simpler approach.

You can define HTML templates for your GitHub pages in a folder called _layouts and connect them using the Markdown frontmatter. So if you create a file called test.md you can define a template called forward. You can also add a target to redirect to, in this case https://example.com

test.md:

---
layout: forward
target: https://example.com
---
... rest of your markdown ...

Your forward.html template in the _layouts folder can use a meta redirect to the target. In its most basic form this can be:

forward.html:

<html lang="en">
<head>
    <meta charset="utf-8"/>
    <meta http-equiv="refresh" content="0;url={{ page.target }}"/>
    <link rel="canonical" href="{{ page.target }}"/>
    <title>Redirecting</title>
</head>
<body>
    <p>Document has moved, if you aren't automatically redirected 
    <a href="{{ page.target }}">go here</a>.</p>
</body>
</html>

That means that if someone goes to the test document in your GitHub pages, they will get redirected to example.com

You can see this in action in this GitHub demo repo I quickly put together. I’ve added quite a few more options to redirect, such as definition of the time and displaying different titles and text. You can read it all and try out the demos in the README.

Using the new in-built JavaScript debugger in Visual Studio code you can use the browser developer tools Console right inside the editor.

I just published a “TikTok” style video on the official Visual Studio Code channel explaining this and – after lots of criticism for the quality of the video (lads, this is on purpose!) – people had more questions, so here goes.

In the video I use a project I have open with a launch.json file already defined, which means it opens the correct URL for you when you start debugging. You can, however, also do that by hand. And it even works without a local server. So, let’s do this.

Step 1: Create a folder and call it consoledebug
Step 2: Start Visual Studio Code, choose “open” – select that folder

Step 3: Select New File, call it index.html
Step 4: Add some HTML/JS and save it

Step 5: Select the “Run and Debug” icon and press the “Run and Debug” button

Visual Studio Code now opens a browser window for you and you can see the console.log message from the demo code in the Debug Console.

You can use the Debug Console to do anything you normally do in the Console of the browser tools. You also have access to all the convenience methods, like $ for document.querySelector. Try it out by using $(‘body’) in the Debug Console. You get all the information about the body element of the current document.

This is a full REPL console, and you can just type in any JavaScript to try out, for example 2+3 or ‘log’.repeat(20)

You also have full access to the Window object and the DOM of the current page, for example, to change the background colour of the document, you can use $(‘h1’).style.background = ‘peachpuff’ (and not what I did first in the screenshot).

For all the features of Console, check the documentation.

If you use Edge as your debugging browser, you also get something extra. Hitting the Inspect button on the debug bar will open the Developer Tools Elements and Network right inside your editor.

But more on that later.