https://futureofcoding.org/ logo
Join Slack
Powered by
I published a piece yesterday suggesting Visual St...
# linking-together
r
I published a piece yesterday suggesting Visual Studio Code might be the most popular text editor for a long time, possibly for decades to come. Love to hear thoughts from anyone here. https://blog.robenkleene.com/2020/09/21/the-era-of-visual-studio-code/
đź‘Ź 5
g
reading now but ctrl f for “until most poll”— i think should read “until its most recent poll”
i
I saw this blow up on HN. Congrats!
🙏 2
r
@Garth Goldwater Thanks and fixed! (And in case anyone else sees any typos I really appreciate when people point them out)
🍰 2
a
Holy crap, I had no idea it had gotten so popular. Typo in footnote 3: "survery". :)
r
Thanks, fixed!
a
FoC-relevant question the HN thread doesn't seem to have directly addressed: how are you confident that VSCode has reached the optimal extension API? Without necessarily doing a deep dive in their docs, could you talk about what makes its API good?
đź‘Ť 2
r
I actually don't think the API matters, just which language it's written in. E.g., what's "right" about VS Code is simply that extensions are written in HTML, CSS, and JavaScript, the "proof" of that is simply all the extensions that have been written for it, especially relative to previous approaches. (And the point is doubly illustrated by Atom's initial explosion of extensions, with a completely different API.) I'd be happy to hear some evidence that the design of the API itself is important. I can think of examples that illustrate it's not important (VimScript as an example of successful poorly designed API, NeXTSTEP/AppKit as a well-designed API not being as successful as it should have been) but I can't think of any that illustrate that it is important. Generally my opinion is that what matters is platform momentum, and developers will support the platform regardless of the design of the API, as long as it can do what they need it to. (There's a bit of a contradiction here, in that the language choice could be considered part of the API, I have to think more about that, but I think the answer has something to do with the "special" nature of HTML/CSS/JS as the browser languages.) One random side note: I do actually think VS Code has a weakness right now, and that's that it can't run in integrated browser. Historically that's been a tough feature to capitalize on though.
One thing to clarify is that I think frameworks need a good API, e.g., Ruby on Rails needs a nice developer experiment, but platforms don’t, like Twitter doesn’t need a great API, or Windows, developers come to it for other reasons.
Come to think of it, I actually think VS Code is more evidence API doesn't matter. I honestly couldn't even say whether VS Code's API is well designed because I don't even know what it's design is. Atom has a beautiful API, communicated effectively through documentation (I appreciated their design and philosophy around lazy loading for example). I've now spent more time with VS Code than I ever had with Atom, but since documentation doesn't really communicate it, I don't feel like I even understand what philosophy or organizational principles of their extension system are. If I were to characterize VS Code's design approach it would be: Scale solves all problems (a play on "given enough eyeballs, all bugs are shallow"). E.g., just ship something and let people bicker it out in GitHub issues and eventually we'll arrive at a working design. And so far there been right! And I actually think the approach is brilliant, because it's future proof. Bad decisions now, get corrected over time, because correcting bad decisions literally is their process.
e
your article doesn't seem to address https://microsoft.github.io/language-server-protocol/ or https://microsoft.github.io/debug-adapter-protocol/ I suspect part of the reason the popularity of VS Code exploded is because both projects allow providing excellent IDE support at relatively low cost to language authors (at least when compared to the cost of creating a custom IDE or writing plugins for say, idea or visual studio)
a
Ah, I think I misinterpreted the "There just isn't anywhere else to go" paragraph as being about the API design. What exactly did you mean by that?
r
@Andrew F Regarding "There just isn't anywhere else to go": Installing extensions went from manual (TextMate/Emacs/Vim) -> to third-party, centralized, but CLI style UI (Sublime Text's Package Control) -> to integrated "App Store"-style extension installing experiences (Atom/VS Code) Extension capabilities went from almost no ways to customize UI (TextMate, and VIM/Emacs for anything non-textual) to customizing the UI through a custom API (Sublime Text) to customizing the UI in a standardized way with HTML/CSS/JS (Atom/VS Code). Those are the progressions I don't see anywhere else they can go, i.e., installing extensions can't get any easier, and customizing UI can't get any easier. I think you're primarily asking about other parts of the API? But I'm not sure these APIs have had major limitations in other ways besides in customizing UI and installing extensions. The most notable example I can think of is async process management being added to Vim/NeoVim. For the most part there just aren't other limitations, unless I'm missing them?
đź‘Ť 1
@Emmanuel Oga Debugging and LSP are tough to address... to answer I think I have to zoom out. The way I wrote the piece was to draw on my observations watching conversations around people switching from TextMate to Sublime Text to Atom to VS Code, and reading people describing in their own words why they switching. And the overwhelming answer for Atom to VS Code isn't LSP or debugging, but it's because Atom was slow. (Note I'm leaving out the role extensions here because Atom and VS Code both have first-class extension support, whereas LSP is definitely a VS Code vs. Atom distinction.) This isn't to say a lot of people don't also list debugging and LSP, but it was (and still is) dwarfed by performance discussions, and my goal was to have the article based as much as possible on what people are saying, not what I personally think is important.
đź‘Ť 1
Another point about LSP: Oddly enough, I think LSP benefits everyone except the incumbent more, because the incumbent can just get great support for these features through sheer inertia, whereas more resource-strapped outfits benefit more from the standardization by being able to work more efficiently.
And a quick bit on debugging: Personally the debugging integration is my all-time favorite feature of VS Code. But I can't imagine very many people are using it, outside of experts. As far as I can tell, you have to make an 
launch.json
file just to debug a default Node app? That's madness. That's a great example of an early-stage VS Code feature, where a completely nutty implementation is just dropped on users. But over time I'm sure setting up debugging will be amazing, because of the pace of development. That's the VS Code way.
(As a side note I had a section that got cut that had more personal opinions on VS Code's features, especially LSP/Debugging. But I decided to cut it and make it into a separate post because it was more based on what I personally think is important rather than what my pulse on the community at large thinks is important.)
g
I do actually think VS Code has a weakness right now, and that's that it can't run in integrated browser
what does this mean?
r
That you can’t run a browser inside VS Code. It’s always struck me as strange that web developers use consumer bowser that are sandboxed from the file system to test a program that’s of course made up of files on that file system. You can see the impacts of this model in action by looking at the hacky live browser plugin for VS Code that spins up a server just to get automatic refreshing for HTML files. But the bigger impact is the sophisticated dev tools bundled into browsers. It would make so much more sense for those tools to be bundle with the actual source files, so there’s more seamless interaction between the two. For example jumping to editing the source HTML or CSS, or clicking in the IDE to add debugger breakpoints. There are some hacks to get around this, but they’re just that, hacks.
g
very odd considering that it’s based on electron
r
Yeah agreed
g
I'm not really following what you're suggesting. There are plenty of plugins for VS code that show a live webpage in one pane. There are multiple reasons to use a simple webserver (which like 3 lines of code in node). If they used the files system then any 3rd party script loaded over the net would have access to their hard drive. Loading from the filesystem in a browser is just not something you should do. Further, many browser features are restricted to https only. And finally, often you want to run via some staging server because the simple case where everything can run from local files would be an exception for most actual usage. As for bundling debugging tools into your own code, how does that have anything to do with VSC? If you want debugging tools compiled into your code you add them to your code no? For example if you want [spector.js](https://spector.babylonjs.com/) added to your code then you add it to your code. (yes, it's presented as an extension on that page but if you read the docs you can just as easily use it as a library in your code without having an extension)
r
There are plenty of plugins for VS code that show a live webpage in one pane.
Not sure what you're talking about here? I'd love to see examples? I only know of one (https://marketplace.visualstudio.com/items?itemName=auchenberg.vscode-browser-preview), and it uses Chrome's video sharing API to stream PNG images and that's why it has the performance issues documented here (https://github.com/auchenberg/vscode-browser-preview/issues/21).
If they used the files system then any 3rd party script loaded over the net would have access to their hard drive. Loading from the filesystem in a browser is just not something you should do.
This is a restriction that's there because consumers are mainly accessing arbitrary (and potentially dangerous) websites over the internet, whereas the integrated browser would mainly be used to access local web development projects, which have a different risk profile. (Plus I'm not saying that the websites you access should have access to the file system, I'm saying that the developer tools should.)
As for bundling debugging tools into your own code, how does that have anything to do with VSC?
When I said bundled with the source code, what I meant was, right now the Chrome DevTools (https://developers.google.com/web/tools/chrome-devtools/) are in the browser, which doesn't have access to your source files. I'm saying these tools could be more useful if there were in the IDE instead.
(The easiest way to explain what I'm saying is that I think the browser developer tools should be an IDE feature, not a browser feature. The whole sandboxing question is a bit of red herring because integrated browsers are everywhere--just not in VS Code itself. The sandbox is only really relevant because since today the DevTools are a browser feature, the DevTools are subject to the browser's sandbox. Theoretically you could just not sandbox the dev tools, but that doesn't give enough value to be worth it alone.)
(I tend to talk about the browser sandbox because I think applying the risk profile of a consumer browser, used to browser arbitrary websites online, to a developer browser used to browse primarily local development projects is silly. But, strictly speaking, almost all of the most important browser developer tool features I'd like to see could be done without any sandbox changes, not even to the dev tools themselves.)
Finally, just to keep the conversation on track, there are a few points about loading local files and running dev servers that are confusing to me. Like this:
And finally, often you want to run via some staging server because the simple case where everything can run from local files would be an exception for most actual usage.
I'm not sure what that's responding to, but I think the answer is source maps (https://developers.google.com/web/tools/chrome-devtools/javascript/source-maps) and Workspaces (https://developers.google.com/web/tools/chrome-devtools/workspaces). I.e., accessing local files and running a dev server are not mutually exclusive? Really I'm not talking about anything that doesn't already exist today, about half of what I want already exists, just with a atrocious UX because dev tools are essentially trying to stuff a second IDE into the browser.
g
Maybe I'm mis-understanding what you're looking for. Here's HTML live preview in VSCode

https://www.youtube.com/watch?v=4-VhMGFe_1kâ–ľ

I agree with you the Chrome DevTools are better than the VSC Debugger. I don't know what if any features of the Chrome DevTools can't be written via chrome extensions (since there are extensions that add features to the devtools) AFAIK most of the DevTools are written in JavaScript using the extension API so it might be possible for VSCode to apply them to an HTML page, though I suspect rather than copy the tools they should just let the HTML plugin expose the existing devtools for its preview. You might also argue that trying to stuff too many things into one place might make it jack of all trades master of none. It might be better to talk to the Chrome team and see if they can come up with an API to tell you embed your editor of choice in the devtools? I don't know. At some point it feels like the 2 things are going to conflict with each other. VSC is a code editor, not a JavaScript editor, so I'd prefer it not hard code a JavaScript debugger and then in turn need a C++ debugger, C# debugger, a Swift debugger, a Rust debugger, etc... At the same time, of course I want better tools period.
A few maybe relevant links. You can run the devtools on the devtools (debug the debugger) https://docs.google.com/document/d/1WNF-KqRSzPLUUfZqQG5AFeU_Ll8TfWYcJasa_XGf7ro/edit# Only pointing that out just to show that the devtools are written in JavaScript so if you feel like contributing you can either copy them into an vscode plugin, or add/propose changes to chrome to help get the solution you're looking for.
r
I think the confusion was just because I mentioned live browser for previewing HTML, but that’s just one use case. The real goal is of course better dev tool integration when making entire web apps. I’m not sure the line between JavaScript editor and code editor matters much. VS Code is Chromium, the dev tools are already bundled in to it. And of course any special dev tools could (and probably should) be extensions, just like everything else. The VS Code app just doesn’t expose things like Chromium web views and the dev tools to extension developers, if they did, I’m guessing this work would already be well underway. The assumption I’m challenging is whether the dev tools should be part of the IDE or the browser (I don’t see the benefit of VS Code in Chrome, I want my dev tools next to the source code). I think they’d be more useful as part of the IDE (via extensions), because they’d have more seamless interaction with the source files. This is how Xcode (the other dev environment I know well) works, and I’d imagine most IDEs for non-web programming language. The whole browser dev tools concept seems to be a historical artifact of there not having been a better place to put these tools before, but with VS Code where it is today is argue that’s a better place now. (Running a web server process in the terminal is another similar historical artifact. VS Code has a decent solution to this with 
launch.json
files.)
Regarding “I don't know what if any features of the Chrome DevTools can't be written via chrome extensions (since there are extensions that add features to the devtools)”. The idea is to be able to jump to the relevant files in your editor from the dev tools, like easily edit the source HTML for a tag. You can do this today with Workspaces but it’s so many steps to setup because the dev tools are so far from the IDE that it’s not worth it to use. It’s UX problems being solved here, not what’s technically possible.
We’ll there goes VS Code's last weakness... https://blogs.windows.com/msedgedev/2020/10/01/microsoft-edge-tools-vscode/
2 Views
Open in Slack
PreviousNext
Powered by