Video details

Chris Heilmann -JavaScript/Web tooling now and tomorrow


JSWORLD Conference 2021
Chris Heilmann -JavaScript/Web tooling now and tomorrow
We live in amazing times when it comes to browser tooling and open web tooling. Browsers aren't only a thing for end users, but also power our editors and can be automated to do a lot of work for us. In this session we'll take a look how the developer tools in browsers work, how to contribute and what's cooking to make developers more effective and prevent us from making mistakes before we make them.
Sign up for our newsletter: Stay up to date via LinkedIn:
Powered by
#unittests #webaudio #unittesting #hiphop #frontendlove or #vuejsamsterdam #javascript #reactacademy #react #microinteractions #designsystems #javascript #artificialintelligence #amsterdam #speaker #conference #frontendlove #frontenddeveloperlove #javascriptconference #frontendconference #vue #angular #react #cfp #theateramsterdam #meetup #conferences #events


Hello there. I'm Chris Heilman. I'm a principal program manager at Microsoft, and I want to talk today about Web Tooling for today and tomorrow. It says JavaScript. There's a few JavaScripts in there as well. But I always see Tooling is more holistic than just one language because we built things using several languages and several techniques coming together for our end users out there. So all the resources that I'm going to talk about will be available at this link, aka Ms JS Web Tooling, after this talk. So you don't need to scribble down things. You can just listen to me and see what's going on and if you like, what if we agree or if we disagree on things? So let's talk a bit about what Web Tooling was like and where it's going in the nearer future. The Web debugging journey has been quite rough. We started with alert and that was the only thing we had. And it was quite annoying because when you had, for example, a loop, you have to press Enter, like several times going in there. Sometimes you got stuck in an endless alert, which was back then rebooting the computer, which is nothing you should ever have to encounter as a developer. But that was the thing we had. We had Document right, which we also use to do messages in the screen or read out dimensions and things like that. And there was actually 997 or something like that. There was also a window script debugger and Microsoft Script editor. The only person I've seen use this and also tell people in trainings was Douglas Crockford when I worked with him at Yahoo. But it was around there, and that was already a very interesting approach to JavaScript to do like step by step debugging, which most people still haven't embraced. And I'm going to come back to that later on as well. The big breakthrough came when Firebug came around. Firebug was an extension for Firefox. It was not actually maintained by Mozilla. It was Chris Patrick, I think it was, and it was a runaway success. It was just gorgeous for the first time to be able to see the render Dom, see the changes in CSS, and do all the things to proper inspect what you're doing and see what the browser is doing for you. And that led to developer tools being embedded in browsers. And all of them come with developer tools nowadays. You've got Safari developer tools, you got the Firefox ones, and you've got the big chromium ones, which are in Chrome and in Microsoft Edge. So a lot of what I'm going to talk about today are the Microsoft Edge chromium ones, because that's the one I'm working on. But I don't mind which one you use. I love that people have different browsers and different ideas, and I also love that we have differentiation in that space, that different browser makers have different focus on what they want to do but the good thing is that all developer tools are in browsers nowadays. You can Press F Twelve or Command Shift I to open them. And for us as developers, this is amazing. For end users, it can be confusing. Like, often you see people accidentally opening them and then be confused about, oh my God, I got a terminal on my machine. What's going on here? But I think it's great that we have this opportunity. There's even an editor built in. You don't need actually to do anything else but having a browser to get started as a web developer. And generally we're in good shape. We got evergreen browsers that get updated every few weeks. There's daily builds of browsers, and I hope there won't be any coming up right now with my machine, which it always does when you give a presentation. There's good platform adoption. Like, a lot of things that you get excited about and you see, like, oh, did you know this new CSS feature in the past took us years to actually get. But nowadays you can say, like, after three or four months, most browsers will have embraced it and it will be able to you. Of course, there's always outliers like UC browser or people having to support old Internet Explorer, but I think we shouldn't keep back because of that. Most of these things can be used progressively and you can actually use them just to enhance things rather than just relying on them. We've got Open and Extensible Editors, so the editing space is written in TypeScript as well. Or you can embed Editors in the browser, things like code pen, things like the Monaco editor that we have in Microsoft or even back then, Brackets. This was great that I can use a full editor in the browser without having to install and maintain yet another app on my machine. We got hosting with version controlling and hooks like GitHub or also code pen, also Jspin and all these things out there. You don't need to actually maintain your own server any longer just to show a quick example to people. When you ask, for example, for issues like you call it something, you don't know why it's broken. It's very easy to set up a Jspin or to set up a code pen. Send that around to your friends and say, like, can you help me with that? And most of these even have live editing tools that you can work together, and that's great. We also got Frameworks a minute. There's a new thing to replace the old web, and we get super excited about that one. But we're not going to go into this one at this talk. What I'm more annoyed about is that you see these kinds of things every time you open the developer tools and you just surf around. Your console is full of stuff. It's full of things that you don't understand, that you probably as a developer, you're not quite sure if you can fix or if you're confused about and if it's really your job to do. But it's painful to see just how many simple things are being done wrong in lots of websites out there. Considering our space that we're in, considering the state of the debugging environments and the state of the web in general, this is actually just disheartening. It's kind of annoying that we are there. It's disappointing considering the state of tooling and documentation, because back in the day you had to buy books, you had to buy courses. But most of the time nowadays you just go to Mdn and you go to any other resource and you look things up and you get information by the truckload. You know why things are breaking. But still people don't do it. And that's actually to the charger of our end users. They have the problem with it. Then imagine being a new developer, open developer tools, and seeing all these issues come up. They are basically, first of all, you feel overwhelmed. You're like, oh my God, I will never be as clever to know what all these things mean. But you also see that, well, if the cool websites use it and don't care about it, why should I put more effort into it? Why should I be a quality developer when it's actually okay to do these kinds of things? So there's a lot of reasons, because for the state of the web as it is right now, forgiving browsers is one thing. As a browser, we cannot break anything. Everything has to be working. Like 25 year old websites have to render and the coolest newest thing has to render as well. So a lot of times browsers are super forgiving and try to fix things for you that they probably shouldn't, but we cannot just break the web. We said, like, the web is going to be open and allowed everybody to be in there and any code can run on it. What we can do is stop illegal things or stop dangerous things to be run, but that's about it. Authorforgiving languages, JavaScript and others like CSS is super forgiving like if a line of code doesn't work, it just jumps to the next line of code and that's totally fine. That's an inbuilt resilience of the language itself. And JavaScript and the convenience methods of JavaScript are quite bizarre as well. For example, the global ID thing I never liked, like you put an ID on an HTML element, it becomes a global JavaScript variable. So a lot of people don't actually get a hook to the ID element in the page, but they are already relying on that. The browser does it for them, which is not necessarily true for all the browsers out there. Another thing I call full stack overflow development, which is like I'm actually finding something that is working. I go, I go to Google, I find a stack overflow answer. I just copy and paste the answer the first one and hope that everything works. I might change some numbers around, but it's good enough, and it's good enough in most of the cases. But the problem is that I don't know what that code does. I don't learn anything from it. And of course, there could be all kinds of security issues or performance issues in that code. It's just a fast, quick answer. I had a lot of discussions with people about that. We shouldn't discourage new developers just by finding something and copying and pasting it. Like W three schools is another one of those that has that problem that explains the how to you but not the why. But it's also a question if every new developer is interested in the why or should be knowing about the why, so we're not there. But the stack overflow development is a thing that people just basically copy and paste things and don't know what's going on and add on top, on top, on top, on top of things. And that's why we have a lot of code on the web that doesn't necessarily do much. There's third party interference, there's a package and trackers and all these things. Often you write a really cool website and then the marketing Department puts all kind of like telemetry and stuff on top, and all of a sudden you have like a 20 megabyte JavaScript file that you don't know where it came from, and you're still being actually told us the developer to fix that's platform by committee. So every new year some new content management system will be used in your company, and you have to use that or a framework, and you have to use that. And let's focus on a high impact audience as well. Often we say, oh, we need to support iOS because this is where people spend the most money. We need to support this kind of environment because that's where our audience lies. And it's sometimes a very outdated environment, which means you have to put a lot of extra code in there that doesn't necessarily do much for the web, but for that audience, that brings in the money, and it's kind of okay. I mean, we have to get paid somehow. And developer tools are overwhelming. When I started as a product manager on developer tools, I didn't notice how deep it goes. Like, there's thousands of panels and sub panels and menus and little things to know about. And I'm spending a lot of time documenting that right now because I think we shouldn't overwhelm people. But at the same time, a lot of the stuff is in there because we thought it was a great opportunity at that time, and we never realized we take it out there. If you look at the usage numbers, a lot of people are using, like two or three bits of the developer tools, and the others just lay there in case we ever need them. And that's confusing for beginners. Like, if I get a tool that looks too complex to me, I get disheartened and I don't actually know what I'm doing. So I want to make sure that we're getting into a space where beginners are not overwhelmed by the tools that they're supposed to use to give them insights. Now, when it comes to development, we're working in three different environments. We're working an editor or an IDE. That's where most of the code is done. That's where we develop things. Then we jump to the browser where we test and tweak things, and we write some CSS. And then we go to developer tools and change the colors around and see that the pixels are perfect and these kind of things. That's what we use the browser developer tools a lot for. And then once we're happy with the changes, we go to the terminal and that's where we do our version, controlling our continuous integration, continuous development, and our build scripts to actually generate the final websites. And this is actually very common that we do these things. That's a very common workflow. It's also an opportunity to get bogged down in customization, like the amount of blog posts I see where people talk about which is the perfect terminal font or what is the best theme to make you a professional developer. And instead of concentrating on the final web product, we actually get bogged down on which browser to use, which idea to use, and which terminal to use, and which terminal version to use. And I find that it's interesting. Of course we're geeks, we love to do these kinds of things, but it can also be overwhelming for beginners. Like, I just want to get started with a web product and I don't want to tweak my editor to be perfect for the next half year. And it's an endless cycle of context switching. So we're jumping from the IDE to the browser to the terminal and then create the web product. Then we go back from the browser to the IDE. Once we did some changes in the developer tools and it doesn't seem much. But actually jumping from one app to another is a cognitive overhead that actually impacts our way of working. We are not as effective as we could be because our brain needs to get rewired every five minutes or something to jump from one environment to the other. And of course the big forgotten part about it. Once we get excited about tweaking our browsers and IDs, we actually don't learn things anymore. We don't actually read documentation, we don't find out about best practices. We just basically copy and paste things and get too excited about what's out there and what we can do instead of what the end user actually needs. I think there is an interesting concept of that. Developer tools shouldn't require expert knowledge. They should make you an expert over time. When you use them. You should learn things, what not to do and what to do and why something happens. I want to take that whole holistic learning and being effective as a developer together in the developer tool rather than just being an extra on the site. Like once you publish something, then you go look it up and read it, which we probably don't do. And best practices and documentation should be part of the tool and not something you find elsewhere. These are things that actually should be part of your development flow rather than something that you need to do once your development flow is over. So let's get on to that journey, to that utopia that I want. The first thing we did is noise reduction. As I said at the beginning, you open the developer tools and you see your console and all the messages that are not yours that you can't do anything about. You wonder what's going on. So that's why we have console filtering now in the developer tools. That's almost all of them in the browser. So you can just say only give us the user messages. These are also the things that you wrote with console log. Stop showing errors, stop showing warnings, only show the verbose ones, and so on and so forth. So this already helps you with a lot of like, okay, I don't see all the things that I cannot do anything about anyways, because that's my colleagues doing it. So this also makes you a happier developer by just filtering down to the needs. But one thing you see in there as well is something new or newish, which is called issues. So there's a message called some messages have been moved to the issues panel and it shows us 244 issues. And that's not uncommon that's most websites have a lot of these issues, and some of them are actually quite easy to fix and to change. Now these issues panel that I'm going to show in a second are powered by something called Webit. Webpage is an NPM package. It's also an online service that does testing off your code for accessibility issues, performance problems if it's ready to be an app, like if the manifest is there, and so on. Compatibility with standards and browser compatibility, common pitfalls to avoid and security issues. And this one, you can use a new CI CD, you can use an NPM package and run it against the Web server, or you can actually embed it somewhere else. And that's what we did with the developer tools. And also in the editor, which I'm going to show in a second. Webpage is open source. It's maintained by the Jas Foundation, so it's not a Microsoft product, and you can take a look at it if you want to. You can also tweak it. It's highly customizable. You can set up your own hints, and you can run it behind a firewall. If your code, for example, is not available on the web. Now, in the Issues panel, we sorted these issues by type so you can say like, I don't really care anything about security. So don't show me those. I only want to fix the accessibility ones. I only want to fix the performance once, and so on and so forth. You also have a tick box in there to include third party issues or to not show them. So if something comes from your ad package or from your tracking package, you can turn that off because it's not your job to fix it. And still it would be in the back of your head like, I need to fix this right now. Now, when you go deeper into this accessibility panel, for example, you get information why something is and learn more links. So it doesn't only say it's an error, but it says like that error means this. And this is why you should fix this. And here is how you can fix it. If you want to learn even more about it, here's another link to actually learn about it. You also might see if you look at the screen, there's this view in Elements link here as well. So that's another thing. You can click on that link and it opens up the Elements view of the developer tools. So you don't only need to know how to fix it, which you got explained, but it also gets sent to the place where you can fix it. And hopefully over time these things will show up less because it becomes second nature to you or muscle memory to actually learn what's going on there. Now, this is when something already happened. What about preventing you from making mistakes? How about helping you out to not write bad code, which is a good thing too. Now, Web page is also an extension for Visual Studio code. You can install it for that one as well. And then it comes down to the panel as the problem. So there you have a to do list of what to fix and that does the same thing. It explains to you why and explains to you where to go to fix it. You don't get sent to different parts of Escode because it doesn't have the same functionality as the developer tools, but this is already a really good way. And I found that all the Linting tools like Es Lint for JavaScript CSS Lint also show up in that problems paint. And it's really nice to actually clean up your code bit by bit so that your to do list of wrong things is going away. You also have life Linting in the code. So you got these little squiggly lines being shown under code when there's a problem with it and you can roll your mouse over it and then it shows you like in this case, for example, that a download is not supported by Internet Explorer or iOS Safari. So you shouldn't rely on it, but you should also find another way for those browsers to do it. And that's great because back in the day we had to go to NBN, we had to go to Can I use and learn about these things. But having it in context while you're writing your code prevents you from making stupid things, and that's a great thing to have. There's also little touches in Vs code that I think go a long way. This is code here, for example, called do from Stuff bad method name never used that just for the demo here right now, but you can see it's kind of grayed out, and the reason is that it's not being used yet. But as soon as I now add an event handler that calls to doform stuff, it gets this lighter yellow. So a lot of themes in Vs code show you unused things as grayed out, and that's a great opportunity to actually find out what you're not using. Or if you found old code that you put lots of things in that you wanted to build data, which we never get to, you can see what to delete. And that's a very simple and subtle little thing, but it made me much so much more effective realizing like this is not used while it's still in there and so on and so forth. We also thought about visual tools and workflows, because often there are things where the syntax of CSS especially is kind of overwhelming to people. So we thought, like, how can I make this easier for you to understand what you're doing? One big thing is CSS grids, one of the newer CSS things. So what we have in there is like this little loss in my American colleagues always call it. I always need to cough when I hear it, that little thing called grid. And if you actually Hover over that or click it, you get an overlay on the page showing you all the information about that grid. And when you click on it as well, the CSS on the bottom Scrolls to that part of the CSS grid where it is defined, so you can see the changes, but you can also tweak them immediately in the browser. And that helped a lot of people actually get their head around what's going on with CSS grid. Css Flexbox is similar, and you can see in the screencast right now what it does. You can click on that one, and then you get the overlay showing you what the flex settings mean and how they're actually changed. And you can go through the whole tree clicking them on and seeing which part is actually be done with each Flexbox setting. And again, the CSS on the bottom Scrolls to the part of the CSS that is responsible for that. So you don't have to go to the editor and Hunt for it any longer in the editor itself or the CSS editor. When you start typing. We put these little source indicators in there right now as well. So all the different alignments, you might not know what they mean. So it's already great that we have auto completion, so you don't need to type all these things and know the syntax. But now you also get a little information what that alignment means and what the effect of it will be without having to do it and reload the page and see what's going on. So that already shows you what a certain setting is good for. Another thing, we saw people stumbling over a lot is typography. So we have this little font editor now in the developer tool. So every time there is some font definition in the CSS selector, you get this little AA icon that you can click on, and that opens up a graphical font editor. So there you can choose the different font families. It automatically realizes which fonts are being used on the page or which generic fonts you want to choose from. And you can tweak the CSS properties, so you can use the sliders to change the font size and change the line height, and so on. You can even convert between different formats. So if you have, for example, pixels and you want to convert them to em, you can do that with that tool, right built into the browser as well. It generates the CSS code for you to copy and paste. Another big thing that I haven't put in the slide deck yet is that we now have new features in the CSS editor to copy and paste either the selector or the full selector or the full CSS. So it's much easier than you in the past you had to highlight it with your mouse and copy and paste, but now you can also context click it and just copy and paste that way. I think it's also important for people to make it easier to go deeper, because the go to debugging thing that we all do is console log. And that also leads to these massive logs in the developer tools and every live website out there. And not necessarily a good experience for your end users. And it's also a very inefficient way of developing if you think about it, because you're still putting information where you are in the code. We're still thinking in a level of like basic programming line by line. And it's not necessarily the case. And there's actually much more to debugging than just knowing at that time what that certain value is. So for me, Breakpoint debugging is the biggest step that made me more efficient as a developer, but it's a huge problem for beginners, and it seems like this overwhelming thing to start embracing. I mean, you can set Breakpoints in the editor or in the browser or other debugging environments. You can also set Breakpoints in the editor itself. And sometimes it's just like, okay, my generated code is somewhere else. So this Breakpoint is going somewhere else. The line numbers don't match, so you need source maps and so on and so forth. They are much more work upfront. But I think once you get your head around Breakpoints, it makes you so much more efficient. And actually it's so much easier to do things. And of course you have no problem anymore having a console log in there that shouldn't be in there. Because the big thing about Breakpoints is that it stops the code execution. You don't slip through and get lots of log files, and then you have to scroll up again and see what's going on. But you get an end to end picture of what's going on. You can see where the data came from, how it got converted, and what it's affecting. In the Dom, for example, you're not likely to litter the web with yet another console message as well. Another interesting one is Live expressions. If you haven't looked into that one as well, that's also a really good replacement for lots and lots of console logs. But the problem that I still see is that a Breakpoint environment is confused to somebody who's a visual thinker or somebody who comes from the front end development world. And that's why I think one underused item that we had for a long time is Dom Break points. If you haven't seen that one yet, you can actually go to your HTML interface. What you generate and you can right click it and say Inspect. That one will get you to the elements view. And in the Elements view you have this highlighted and you can see this overlay there giving you all kinds of information about what's going on there. But you also have that dot dot dot menu on the highlighted line. And I understand that people don't find it because it's really tough to realize. But when you click that one, you get things like Break on and it could be subtream modification, attribute modification, or node removal. So if you now say, for example, sub tree modification and you just start using the interface, all of a sudden you get into the Breakpoint environment, it already highlights the sources tab for you, and it sets a Breakpoint. Or it gives you a Breakpoint environment where you are without having to set a Breakpoint by hand. You can do that from the interface to the sources editor rather than having to do it in the sources editor in the first place. And you can see, for example, those Brown things here next to the out and the information that you get. This is what you would write a console log for. And this is why I think these environments are gorgeous, because they also already give you the information without having to write a console log. How often have you written a console lock to run it to go back and write another five console logs to give you more information and inspect other variables that are actually being affected by that one. And this environment shows you that. And I think a Dom Breakpoint is a great way to get into that without having to start at the Breakpoint environment. And you've got the chord stack, you got the scope, and you can go through it bit by bit. And again, you see the mouse events here and the buttons. So you find all the things that are going on without having to write yet another console log. Now another thing we talked about was context switching, jumping from browser to editor to terminal. And this seems to be like a cool thing. I know all three of them, but it makes us less effective than it should be. And I love that. For example, Visual Studio code leaps and bounds in this area and made it much easier for me to do things. So the first thing that I love about Visual Studio code is it has Git integration. Version controlling is a wonderful thing. If you ever encountered a repository with like 15 folders called final version, really final version this time we mean it kind of thing. Version controlling is great because it means you don't make mistakes that cannot be undone. You never lose any of your code that you would with like zip files or something like that. But it's tough. Gate is kind of hard to understand and there's lots of opportunity to get bogged down in the syntax of Git itself. So having an editor inside the browser that actually does all the good stuff for me and allows me to concentrate on the messages, on the commit messages means I use version controlling the way it was meant to be, not the way I actually thought it would be the right thing to do or going to the command line and learning all the Git commands first. So this makes you concentrate on the things that really make a difference for the next user that has to look at your code and get a commit message. And it also takes all the complexity of Git out of the workflow. You will have to learn it at one time or another. But I think as a beginner, it's great that you don't have to. It's also a built in terminal, so this one you can actually point to all kinds of contexts to actually debug. And that's another thing. You don't have to jump to the terminal to just run a build command or something. You just do command backtick, open the thing, start typing the command command back, tick, go back to your code. And that's wonderful. Now, browsers are changing or have changed in the last years a lot as well. They can be automated. So we have web drive, you got things like puppeteer, you got things like playwright. So a lot of times a browser is not something that the end user uses, but just a piece of code running in the background that you throw data at, you get data back. So creating screenshots, continuous integration, continuous testing, all of these were possible. Now that browsers can be automated rather than just being a thing that end users have, they can also be embedded, like the web views that we have can be embedded in other applications to give you, like a browsing experience for the web without having to write one yourself. And one of my biggest bugbears is Android apps that have their own outdated web view, which doesn't have, for example, my cookies, my information. It's super annoying that people ship with their own web view without using an evergreen one, because that is a lot of complexity for developers out there as well. Now, Visual Studio code allows for extensions. That's probably the biggest success. Factors like people were able to put their functionality into the editor that wasn't in there in the first place. So I was thinking, or we were thinking about a year ago, why do we merge the two? Why don't we take the great development experience of Visual Studio code with the terminal and the Kit integration and the developer tools? Where you go to Tweak anyways, where you go to change your CSS, where you change the color pictures and so on and so forth? Why don't we make one thing out of that? And we did that with the extension called Microsoft Edge Tools for Vs code. I had to put all the names in there, sadly enough. And that's great. It basically means that you don't have to switch context anymore. You stay within the context of Visual Studio code, and you still get the functionality that you expect from the browser. This is what it looks like in a screencast. So you actually connect to an instance of the browser, and it gives you a view of the browser, and you can then do the inspection, and you can click on the CSS link and do the editing in the Vs code. Browser itself. Editor itself, you know that in the browser, like, if you click on the CSS file name, it opens the Sources tab with that embedded editor. It's a great editor, but it's kind of old and you're already in an editor. So why don't we just send you back to the context that you came from? This is the full browser experience in Vs code. This is not a stream or a video or something. You can interact with it. You can change things, you can type things in, and it's excellent. When you put it on another screen or something like that, you still get the developer tools and the editing suite in one go. This is not quite like an IDE. I don't like ideas. They're too much. But this just gives you what you need at the time. For now, we didn't put everything in there, but we made it easy for you to actually launch a browser. You don't have to install a driver any longer. You don't have to install a debugger. It all comes with the extension itself. Right now you can inspect, edit and tweak the Dom structure like you would in the browser. You can inspect network requests. That's something that people also wanted to do. And you can interact with the browser directly. So you don't have to go to another browser window and type things in there. You can sync the changes with your code. If you set up source maps and you set up your product the right way, then you could tweak the CSS. It changes your SaaS, for example. And that's excellent. And you can choose your own browser window or an embedded one. If you're on a Mac, the embedded one, the headless version is the better one because the other one is a bit buggy. So that's a problem of macOS that we're still working on right now. So this already gives you most of what you want to have. But what about another context that I haven't talked about often? You see people working with APIs and having to change API calls on the fly. So this is the network pane and what we thought about like how about we extend that one to give you another context so you can right click now and edit and resend? This is something that Firefox had for a while as well. But we went all in and actually gave you a network console right now. So there you can tweak all the settings in there. You can import and export API environments. You can actually do something like tools like Postman or Insomnia or other API tools do directly in the browser. And this is something we are considering bringing into the environment, into the Vs code extension as well. Right now that's only in the browser as an experiment. But please tell us about what you think about that. Now, one thing that most people don't realize is that the developer tools are actually written in HTML, CSS and JavaScript. So it's a wonderful experience as a web developer to be completely free of dependencies. Like you can use all the cool new technology of the web because you're right inside the browser and right inside the engine. And the fun thing is that you can debug the developer tools using the developer tools. What does that look like? Well, you open Developer Tools Command Shift I on a Mac or F Twelve CTRL Shift I on Windows, and then you make sure that they're actually in full screen. So activate the menu and Select Undock into separate window. That way you get the developer tools as a full screen experience and not just like a left side or a bottom. And then when you press Command Shift, I again, you open another instance of the developer tools that now debug the other developer tools. This is actually how we build them, and this is also how we automated our tests. So you can find out how these developer tools were built just by using another instance of the developer tools on top of them. So you can see what we've done and how we could do it better and what we find out. This also works in other environments like Windows team, Microsoft Teams for example. Another discord is another thing that I found that as the developer tools already built in as well. So it's great to actually see how things are working and peeking under the hood. So what's next for this environment? I think it's important that you tell us all of this is well, the DBS code extension is actually on GitHub, so please file issues, tell us when you want something else, tell us when something is wrong. And we would love to hear about how you use these things and what else we could do to make it more effective for you to be a developer and not having to jump from one context to another. We also have detailed developer tools explainers on GitHub. So this is what's coming in the nearer future. Like tell us where you learn about new features and again, you can file issues. You can tell us that we're going totally in the wrong direction or that something else is already doing that for you. We would love to know about that one. And in general, it's all about making things for you. I showed you a lot of stuff that we learned and all of that came from user feedback. Nothing of that was like something we like, oh, we should probably do that and people will love it. This is all about people asking us, oh, I can't do that. Wouldn't it be good to have something to make that easier? And that's the feedback that we want. And please give us feedback. This is me and my team. Edge Dev tools on Twitter is where we are. Zohair is a colleague of mine, Rachel, Erica. We all do different parts of the developer tools. I'm cooking on Twitter and you can also reach us by clicking that. I can directly in the developer tools that does a screenshot of the current context that you're in so we know where you get stuck. So that's all I had. I think there is a lot of to be done in the developer space. I want to make it easier for end users and for beginners to get started with it. But at the same time, I don't want to let experts miss out things. So please communicate, please tell us what you need and we're going to build it. Thank you very much.