Visual Studio Code

1

So Visual Studio Code is a lightweight text editor which is free and works on Windows, OSX and Linux it has some pretty cool/decent features (nodejs, intellisense, gulp, bower, git)

I can’t help but notice this is very similar to Sublime Text or Atom who knows it might be a fork of Atom, anyways just wanted to see what you guys think about this if you even heard about it.

2

I think it is a fork of Atom… lemme see if I can verify…

[edit]
Yeep

3

It’s interesting. Funny to see that most of the size of the app is the Chromium shell. (It’s less funny that the same is true for Atom, since Microsoft isn’t the one shipping it.)

Funny to see TypeScript syntax when you hover over identifiers to see type info. Not so funny to see a bunch of squiggly underlines in an HTML file that loads D3 and some other stuff over HTTP in script tags. I mean, I get that the editor’s not going to want to download those files, but it’s complaining about something that’s a super common pattern, especially if I’m just opening up Code to test it out quickly and don’t want to invest in figuring out its project structure.

4

I’ve heard about its development for some time now, but I am still too much in love with either plain Atom with Live Preview (and a bunch of other packages) or Brackets with Live Preview.

:smile:

5

Facebook has released their Atom-based editor (Nuclide) too:

6

Haha yeah, saw this. So much Atom these days! And it’s always seemingly using 1GB+ RAM… which is fine I guess but why does a text editor with ~10 open text files use 1/16 of the memory on the entire computer?

Avik works on related stuff now. I mean, projects sort of bundled into Nuclide.

7

And not to be outdone by the recent release of Atom 1.0:

And I’m guessing the text editor does very little with all that memory, but just happens to rely on a convoluted tech stack that does.

1 Like
8

Thought about using TypeScript and VS Code for a recent project I had latitude on. Didn’t work out because it seemed like everything was relying on this one person’s 3rd-party type definition repo, and getting any type info required marking every import with something like:

/// <reference path="types/node.d.ts" />

It just seems like… if I’ve hit the point where I’m writing significant XML comments in JavaScript to enforce some type semantics, I’ve gone terribly off the rails.

1 Like