Bringing the browser developer tools to Visual Studio Code | Hacker News Reader

Bringing the browser developer tools to Visual Studio Code

blogs.windows.com

160 pointsPretzelFisch43 comments

When I was part of F12 team, we had proposed this to head is developer tools but he was a bit dismissive at the time. Edge was the future. Chrome was the enemy.

Oh how times have turned. IIUC, this is chrome devtools packaged as a vscode extension using chrome remote protocol to talk with the browser.

I’m glad this finally landed.

Looks like this requires Edge to be installed on whatever machine you have VS Code installed on. I was kinda hoping that this was a browser properly embedded into VS Code so I could use it in github's Codespaces. No such luck, I'm afraid - trying to install the extension throws an error.

Interesting, thanks for pointing this out. This contradicts my comment here (https://news.ycombinator.com/item?id=24657613) a bit, but I’d be shocked if they didn’t get it working with Codespaces.

I do think it’s always going to require Edge though, I don’t see how Microsoft could resist getting tons of developers to install Edge for these features. I’m probably going to today. So a real VS Code strategy starts to emerge...

>So a real VS Code strategy starts to emerge...

Sounds more like premature drama/conspiracy theory atm...

I don't think they need to embed a browser into VSCode considering it's already running in one (Electron). However I wouldn't be surprised to see a browser embedded into a browser these days either.

I'm pretty sure the electron browser engine moves slower than Blink.

If so, it would be extremely unhelpful for development and debugging since you would rarely have the latest engine on your machine, which would be the engine the majority of your customers would be on.

Using an external browser makes a lot of sense in that regards, and also, it separates the testing engine from the application itself, which allows for (although I doubt it's been implemented yet) testing in different browsers, or different versions of browsers, etc.

It makes logical sense that MS would start with Edge, but I can see (for standards compliance) them expanding to work with other browsers too; it would be too great a selling point not to use.

> I'm pretty sure the electron browser engine moves slower than Blink.

> If so, it would be extremely unhelpful for development and debugging since you would rarely have the latest engine on your machine, which would be the engine the majority of your customers would be on.

I would think that it would make sense to A) test in a slower browser anyways -- if your code runs well in a slow environment it'll run in a fast one as well, and B) Test in multiple browser engines anyways. Why would you only test one engine?

I wrote a piece that got some discussion here on VS Code (https://blog.robenkleene.com/2020/09/21/the-era-of-visual-st...). After writing that piece and reflecting, I decided that VS Code did in fact have one weakness: It doesn't have an embedded browser. I even tried to start a conversation about it on the VS Code Dev Slack here's what I said:

> Any thoughts in integrating a browser into VS Code? Panic's just released text editor for macOS, Nova, has this feature. The obvious thing it gets you is a live updating preview of HTML files, but taking it further: With VS Code's development community, this seems like it could be the path forward for features like being able to instantly jump to editing the source file for a CSS rule or an HTML element from the DevTools, or jumping to a component's source file from the React DevTools. I'm aware there a couple of projects that have tried to do integrate a browser into VS Code, but nothing has really come to fruition yet, any thoughts?

(Didn’t get much of a response, but obviously no one would talk about this if they knew.)

The above summarizes my thoughts, but here’s another one: This is a key component of GitHub Codespaces. One of the weaknesses in remote development is the round trip between the developer server process and the browser is less seamless than when doing local development. The IDE-style debugger integration doesn’t work without running Chrome on the same machine for example.

Anyway, VS Code now doesn’t have any weaknesses that I’m aware of anymore.

Isn't VS Code literally written in Electron? It would be the easiest thing to implement.

The vscode dev slack is just normally quiet, I wouldn't chalk it up to some implicit secrecy about a project with a pretty open team.

VSCode extensions can render arbitrary html in web view tabs already. However they're sandboxed from the rest of vscode and communication between the browser page and rest of the ide is tricky. This is actually a bit painful if you want to debug something that uses a webview, since vscode's debugger won't step into the embedded window's runtime.

The other obvious win is browsing documentation.

It does have another big architectural weakness: no detachable windows (see issue #10121). Not impossible to fix but quite hard.

And while the embedded dev tools is very cool, especially for the headless browser, it only brings in even more windows in the main VS Code window. Notice how dev tools typically take the largest part of the screen. In many workflows it is beneficial to have the dev tools on a second or third monitor so it doesn't obscure the code.

I’d like to see some innovation on this front from VSCode or any of the major editors. The developer ui experience can easily be overlooked since we’re used to dealing with all kinds of hoops to do most of our work.

JetBrains Rider has tool panes that you can dock like "traditional" IDE tool panes, or break out into separate windows. Presumably other IntelliJ-based IDEs have the same capability.

I really like this feature when working with multiple monitors - I can keep the primary monitor "clean", with just the editor and solution explorer, and have the test explorer and test runner split vertically in a secondary portrait monitor monitor, and debug/console output in my laptop screen.

You still cannot use it for native GUI design, Forms, WPF, WinUI/UWP,... and thus no match for Blend/VS in this regard.

Well, people doing native GUI design and not doing it for mobile (where there is already XCode and the Idea-based Android IDE) are probably 1/100 of people doing web work, and of them most do it for Windows, so already have VS proper.

Well I was replying to

> Anyway, VS Code now doesn’t have any weaknesses that I’m aware of anymore.

For me no support for native GUI designers is a weakness.

Yeah, I'm just saying for the target group it's not a major one :-)

Same way it's not a good COBOL environment either

If Microsoft on their dungeons plans to ever replace VS with VSCode, given the JS/Electron influence going on across the company, then this is surely part of the target group.

If they reach that point they could trivially slap in a form designer. It's not like those are hard...

No background images without ugly hacks.

Good development. Debugging in FireFox and Chrome suck, compared to real IDEs.

This looks great. The lack of the network and inspect element is the main reason I end up not using the built-in debugger with VS Code.

I've come close to setting up https://github.com/skeeto/skewer-mode several times. Things like this always demo better than they actually improve my productivity, though. Especially with modern frameworks that don't let you redefine everything. (Odd that common lisp is still head and shoulders above most languages with how much you can redefine at runtime.)

FYI you have to enable the network tab in the extension settings for it to show up, it is not enabled by default.

They kind of mention this in the article but it wasn't super clear.

I wonder how this would help with WebView. I develop an extension that loads the page inside the WebView, but having to use the WebView's inspector sucks. If this new tool can let other extension use it's panels, it would be awesome.

True! This is why I try to design my webview apps in a way that they also run in a standalone chrome tab and connect through web sockets to vscode!

I heard you like Browsers ... So we put a browser into your browser...

If this feature boosts productivity to a large extent perhaps it would finally be a reasonable trade-off for having an Electron-based editor?

Next thing would be to bring library specific dev tools to vscode. Like for mobx, react, rxjs and so on.

I'd love to explore that area!

Why are Microsoft websites so slow?

Wonder how hard it would be to highlight elements on mouseover of tags in the normal editor.

This appears to be only for Edge?

Edge (Chromium), so shouldn't be a problem in practice given every website has to be Chromium-compatible anyway.

I'm guessing the real objection is needing to run Windows to use this. Unless Edge runs on other OSes?

The new version of Microsoft Edge can be downloaded for macOS and Windows, but I'm not sure about Linux.

Preview coming later this month.

You could have spent the 2 minutes to google this https://www.microsoft.com/en-us/edge

(it works on macOS)

And Linux Beta is supposed to arrive this month.

https://www.theverge.com/2020/9/22/21449062/microsoft-edge-l...

But why? What’s wrong with having it on a different window?

The second paragraph is titled "Why embed developer tools in an editor?". Answer: "reduce cognitive load"

The 20 second demo vid literally shows them switching between two tabs in VS (Edge Tools for browser and styles.css for changes).

Not sure how that reduces cognitive load vs Alt-tab?

As best as I can tell they saved maybe a click or two. At the cost of no longer looking at a full screen stock browser.

Interesting but not a clear win in my books

Yeah, that's true. If you have a wide screen monitor, the browser and VS Code fit happily next one another.

Reply on news.ycombinator.com