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.
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...
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.
> 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?
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 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.
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.
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.
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.
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.
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.)
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.
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.