Hacker News Reader

Comment by skrebbel | Hacker News Reader

A question: If I'm not mistaken, PTVS is basically a whole bunch of Visual Studio plugins, presumably not written in JavaScript. Since VS Code is a while different program made in a different language and a different UI framework, does this simply mean there will be a new bunch of py/r/jupy plugins for VS Code, accidentally made by the same team?

Or does VS Code have more VS-compatible integration options than I knew of, which you're going to use to port PTVS over?

View on HN

Visual Studio Code has a very modular architecture. The tool itself is written in Node.JS and web technologies, on top of Electron, and most extensions have a Javascript component. But most of the language and debugging functionality is built as out-of-process components, which means that they can be built in any technology. For example, our Typescript and Node tools are built with Node; our .NET tools are built in .NET and native code; and most of the functionality of our Go extension is built (by the Go community) in Go.

PTVS is written in a combination of .NET and Python - but with CoreCLR available across all platforms, a lot of that code can be reused. The way they integrate into the tools may be different, but they can share a lot of common code.

Interesting. I have been looking for a good editor, I use Sublime now, but I want somethign a bit more modern.

> The tool itself is written in Node.JS and web technologies, on top of Electron

This is worrying. I think Atom is a really cool editor, and it seems to have come a long way, has a lot of great features and an awesome UI. However, it is buggy and slow as hell. It crashes and behaves unexpectedly, causing it to crash and either lose changes, or need to be restarted.

I try it once every few months, most recently this week. Does VS Code behave the same way? I copied a 1000 line JSON object into Atom yesterday, and it basically crashed, how do you find VS performance?

Code is definitely not Atom. You should give it a try. It's free.

Ya, Electron != Atom. Grab Code and paste that giant JSON into Code and let us know how it goes.

visual studio code seems way faster, pasting the object was nearly instantaneous and it looks like it has a nice set of features. also, i feel i should add, i realize electron is independent of atom, however it was developed by a github engineer previously working on nodewebkit for the github texteditor called atom. it used to be called "Atom Shell" and is in the atom/electron repo. So I was curious if this was related to electron generally, or choices made in atom.

Electron was indeed originally called Atom Shell, and part of Atom. But it's a general purpose shell for cross-platform apps - it basically provides a native application shell hosting Chromium. And lots of apps - including many that aren't developer tools - are built on it. While VS Code uses Electron, and we contribute to it, we've made a lot of design choices differently from Atom in building the editor and rest of the product.

My lay perspective is that it is apparently the other way around: It certainly appears that VS is increasingly "VS Code compatible". A lot of the extensions in the VS gallery have silently been working in more TS/JS code and even some of the "built-in" functionality relies on TS/JS code. (The Typescript compiler itself, of course, has always been self-hosted in VS. The DOM Explorer which can be used in webpage debugging and Cordova mobile remote debugging uses a bunch of Edge Dev Tools code much of which is also shared with VS Code as well. [Which is more reason the VS Code open source announcement is rather wild.])

It definitely would not surprise me if that's an intentional direction in VS and many more extensions and components will start to be built (or rewritten) for VS Code first as TS/JS and then "ported" to run in VS "proper". Of course, I certainly don't know anything of the matter for certain, this is just lay observation of trends I'm watching with interest in VS.

Reply on news.ycombinator.com