This editor is built on Atom.

From their docs: https://code.visualstudio.com/Docs

Architecturally, Visual Studio Code combines the best of web, native, and language-specific technologies. Using the GitHub Electron Shell, Code combines web technologies such as JavaScript and Node.js with the speed and flexibility of native apps. Code uses a newer, faster version of the same industrial-strength HTML-based editor that has powered the “Monaco” cloud editor, Internet Explorer's F12 Tools, and other projects. And Code uses a tools service architecture that enables it to use many of the same technologies that power Visual Studio, including Roslyn for .NET, TypeScript, the Visual Studio debugging engine, and more. In future previews, as we continue to evolve and refine this architecture, Visual Studio Code will include a public extensibility model that lets developers build and use plug-ins, and richly customize their edit-build-debug experience.

The Electron Shell was previously known as the Atom Shell. So part of it is Atom work.

Fair point. I wanted to clarify the difference since "built on Atom" has a different meaning to me than "using the GitHub Electron shell". The first sounds like an extension to Atom and the second sounds like a whole new app.

They started work on this before the Atom Shell was "Electron" and speaking to the team in Zurich before this was unveiled (about 3 months ago) they mentioned this was built on top of Atoms foundations. There is an Atom binary inside the package app and this is where my comment came from (:

embraced and extended? [ducks]

I don't think they've extended it yet:

$ /Applications/Visual\ Studio\ Code.app/Contents/MacOS/Atom .

Can't be entirely Atom since so far it actually seems pretty responsive.

Oh, snap!

It seems this is the predecessor: Visual Studio Online (2013): http://weblogs.asp.net/jongalloway/a-quick-look-at-the-new-v... (scroll down half way to see the screenshots and videos) So the idea and technology behind it predates Satya Nadella CEO appointment by at least 3 months.

MS has always had great ideas and technology waiting in the wings. The problem was always they could never ship it.

Nadella's contribution is to make it possible to ship this sort of thing. Shipping this under Ballmer would have been a miracle.

> ... always ... waiting in the wings ... ship

This sounds like you're speaking from inside experience. I would _love_ to hear more of this back story. Seriously, to anyone, write it up.

You just have to look at the amount of money they sunk into R&D in the last 15 years, which is public data. Nobody spends that sort of cash to simply develop simple iterative versions of established products (which Windows and Office have been ever since XP, really) or one random new gizmo (Kinect).

R&D gets favorable tax treatment. Maintaining an OS, whatever it costs, is R&D.

Have a look at the list of projects here http://research.microsoft.com/en-us/ and see how many are probably going to be profitable in the next couple of decades. It's actually pretty amazing how much research Microsoft fund that seems unrelated to any of their current product lines.

I think MS Research would be a pretty amazing place to work.

MSR really is an incredible place to work, but also impossibly hard to get in. It's akin to getting a fully tenured professorship at a top-tier computer science program. Back when I was in graduate school, MSR dominated every other computer science research department in the number of SIGGRAPH papers they published each year. And that's just in graphics.

If i remember correctly, Haskell is being developed in MS RD. At least they have hired the main Haskell dev, and I think he was involved in the F# dev work, including ideas from Haskell. IThis was commented on in a talk with the Erlang and Haskell devs.

ghc, the Haskell compiler everyone uses, is developed mainly at MSR in Cambridge, UK.

I've never worked there but I know people who did. And anyone who follows MS Research can read between the lines. No direct experience here though so I'm the wrong person to write it up.

You could google for that minimsft blog and the `we forgot how to ship´ trend of a few years back (from Sinofsky(i?) I believe).

100% true on all counts.

Visual Studio Online is basically TFS online. Think github + CI + Kanban board + Issue tracking online.

It's more than that. Scroll half way down on my link above, check out the screenshots and video.

Visual Studio Code is more like an offline version of Visual Studio Online (the editor part), 2 years later.

The editor is a tiny tiny tiny tiny part of VS Online.

And exactly that "not so tiny" editor is the big part of Visual Studio Code. And it is not trivial at all - it's a very complex component to get right. The editor component comes from Switzerland and is called "monaco" and one of the main reasons why the "TypeScript" language exists and why ES6 looks as it looks today.

So it's crappy HTML and JS underneath? I was hoping for cross-platform WPF :(.

Agreed on the crappiness of the web stack for this application. But WPF isn't necessarily better. Case in point: a Bible study program where one's choice of video card actually mattered, at least in 2009 (see http://community.logos.com/forums/t/6200.aspx). BTW, I only know about that specific example because my brother is a preacher.

I think a better foundation for a cross-platform editor/IDE would be SWT, the Standard Widget Toolkit from Eclipse, perhaps ported to .NET.

And this is why it's web stack: there are no better alternatives.

For decades of trying, this is the best we've managed to do for cross-platform UIs. It ain't great, but it soundly beats the alternatives.

I think that SWT proves that for some criteria, particularly nativeness and accessibility, it is possible to do better than the web stack while covering all major desktop platforms.

Or even IntelliJs skin and components for Swing.

Do the IntelliJ skin and components have any advantages over Eclipse's SWT in your opinion? My understanding is that Swing is much heavier. In fact, SWT was originally designed for Java 2 Micro Edition [1].

[1]: http://flylib.com/books/en/2.120.1.42/1/

Swing was crap at the time, but it got significantly better.

Cross-platform WPF did exist. It was originally called "WPF/Everywhere" but eventually branded as Silverlight.

WPF?! You cannot be serious.

WPF is, by far, the most pleasant and flexible thick client, windowing system out there. XAML is a bit verbose, but the binding capabilities combined with an open source MVVM framework like Caliburn allow you to build extremely flexible UIs.

WPF also abstracts control behavior away from presentation and allows you to easily and quickly extend the base set of controls to do whatever you want to.

After building multiple thick client applications using VB6, MFC, Swign, Winforms and WPF, WPF exceeds all of these, by far, in flexibility and maintainability.

Also <grid> (as a sane alternative to <div class="table">) where you can actually align stuff exactly the way you want.

You know about flex box right?

Microsoft should have bought Qt when they acquired Nokia. So they have an alternative for cross platform desktop development.

This makes sense , Microsoft does not support C for user space development , and Qt/C++ is good way to push C out from user space development in all platform's .

It wasn't there anymore, Nokia sold it's Qt business to Digia quite soon after the 2011 announcement of Windows Phone strategy.

I find the binding part and MVVM stuff rubbish.

For me, the real value is composition flexibility.

Ahhh we can dream... sigh

Neato -- lots of JS code in: Visual Studio Code.app/Contents/Resources/app

Try using it to view its own source code inside the app!

Looks like it just uses Electron.

So is there any reason to use it instead of Atom? (assuming you're not developing with .net or C#)

If it supports any form of semantic completion (i.e. Intellisense) , that would be a reason. I'm still not sure from reading the article if that's the case, though.