Microsofts Open-Source-IDE Vistual Studio Code im Fokus

„Wir möchten, dass VS Code zum beliebtesten Code-Editor wird.“
Kommentare

Die von Microsoft entwickelte IDE Visual Studio Code erfreut sich bei Entwicklern aus allen Lagern großer Beliebtheit. Wir sprachen mit einem der Köpfe hinter dem Projekt – Erich Gamma – über VS Code und das neue Language-Server-Protokoll, das Entwicklern noch mehr Möglichkeiten bietet.

Hallo Erich. Du arbeitest momentan bei Microsoft an der IDE VS Code. Worum geht es dabei im Kern? Handelt es sich um eine Browser-Variante von Visual Studio?

Erich Gamma: Visual Studio Code ist keine eigentliche Browser-IDE. VS Code wurde zwar mit HTML5 und TypeScript/JavaScript entwickelt, aber VS Code läuft nicht im Browser, sondern auf dem Desktop. Der Benutzer soll nicht merken, dass hinter VS Code Web-Technologien stecken. VS Code soll sich wie eine „gewöhnliche“ Desktop-Applikation verhalten. Auf dem Weg zu Visual Studio Code haben wir unter anderem auch eine Browser IDE gebaut. Als wichtigste Komponente entstand dabei der Monaco Editor, der als universeller Code-Editor im Browser eingesetzt werden kann. Übrigens, seit einer Woche ist dieser Monaco-Editor auch separat verfügbar und verschiedene Web Sites verwenden den Editor bereits.

Als Teil des Architektur-Konzepts kommt bei VS Code das Language-Server-Protokoll zum Einsatz. Welches Ziel verfolgt ihr mit dem Protokoll?

Microsoft möchte  Entwicklern die freie Werkzeugwahl ermöglichen.

Erich Gamma: Eine erste wichtige Erkenntnis ist, dass man die Unterstützung für eine bestimmte Programmiersprache am besten in dieser Programmiersprache selbst implementiert. Dies ist nicht unbedingt die Sprache, in der die IDE oder der Editor geschrieben wurde. Im Fall von VS Code ist der Editor in TypeScript/JavaScript realisiert. Die Implementierung der C#-Unterstützung erfolgte aber durch das Microsoft C#-Team im Rahmen des Open-Source-Projekts Roslyn natürlicherweise in C# und nicht in JavaScript.

Außerdem ist die intelligente Unterstützung einer Programmiersprache typischerweise komplex und speicherintensiv, da ein Programm als abstrakter Syntax-Baum repräsentiert wird. Darauf aufbauend können dann mächtige Funktionen wie zum Beispiel Intellisense angeboten werden. Um VS Code von solchen potentiell Ressourcen-hungrigen Programmiersprachen-Services zu entkoppeln, ist es aber sinnvoll, sie als separate Prozesse zu betreiben. So wird der Programmiersprachen-Service zu einem Programmiersprachen-Server, der auf dem lokalen Rechner läuft.

Wir nennen das auch einen Tool-Server. Hat man erst einmal einen separaten Prozess, dann öffnet das die Tür, diesen Prozess von verschiedenen Editor/Werkzeugen zu nutzen. Dies kann man noch weiter vereinfachen, wenn man das Protokoll, mit dem die IDE mit dem Programmiersprachen-Server kommuniziert, standardisiert. Eine IDE muss so nur eine Integration mit dem Protokoll implementieren und kann dann alle Programmiersprachen-Server „gratis“ nutzen, die das gleiche Protokoll verwenden.

Für den Anbieter einer Programmiersprache heißt das, dass die Sprachunterstützung nur einmal als Programmiersprachen-Server angeboten werden muss und dann von verschiedenen IDEs konsumiert werden kann. Es ist also eine Win-win-Situation. Wir als Microsoft möchten so den Entwicklern die freie Werkzeugwahl ermöglichen. Wenn jemand gerne C# oder TypeScript auf dem Mac mit Sublime oder Emacs entwickeln will, so soll das möglich sein.

Du bist einer der Architekten der Eclipse Platform – somit drängt sich hier ein Vergleich auf: Schon bei Eclipse ging es ja darum, verschiedene Tools via Plug-ins in eine Tooling-Platform zu integrieren. War diese Erweiterbarkeit bzw. Verallgemeinerbarkeit auch ein Leitgedanke für VS Code?

Wir sind im Vergleich zu Eclipse einen Schritt weitergegangen.

Erich Gamma: Eclipse hat bezüglich Erweiterbarkeit vieles richtig gemacht und VS Code muss natürlich auch erweiterbar sein. Wir verwenden zum Beispiel auch das Prinzip von „Lazy Loading“ von Erweiterungen. Wir sind aber im Vergleich zu Eclipse einen Schritt weitergegangen, wenn es darum geht, eine Erweiterung so zu isolieren, dass sie der IDE nicht „schaden“ kann. Sei dies beim Starten der IDE oder auch, wenn eine Erweiterung „Amok“ läuft.

Es ist ein Ziel von VS Code, schnell zu starten, unabhängig von den installierten Erweiterungen. Ebenfalls soll es immer möglich sein, seine Änderungen zu speichern, auch wenn eine Erweiterung sich gerade in einer endlosen Schleife „aufgehängt“ hat. Aus diesem Grund führt VS Code Erweiterungen in einem separaten Prozess aus und kommuniziert mit diesem sogenannten „extension host“ via RPC. Auf diese Art und Weise werden Erweiterungen isoliert ausgeführt und der Kern der IDE ist geschützt.

Ein anderer Unterschied zu Eclipse ist, dass wir von Anfang an einen Marktplatz für Erweiterungen anbieten wollten. Im Marktplatz können Erweiterungen einfach gefunden und von da aus installiert werden. Seit letztem November wurden schon über 1000 Erweiterungen für VS Code entwickelt und auf dem Marktplatz verfügbar gemacht.

Aktuell gibt es jetzt die Ankündigung, dass Red Hat, Codenvy und Microsoft gemeinsam das Language-Server-Protokoll voranbringen möchten. Wie wird das Ergebnis dieser Zusammenarbeit aussehen?

Erich Gamma: Wir haben das Protokoll definiert, nachdem wir schon zwei Programmiersprachen-Server in VS Code integriert hatten, nämlich OmniSharp für C# und den TypeScript Server. Dann haben wir nach Partnern gesucht, die auch Interesse hatten, Programmiersprachen-Services über IDEs und Editoren hinweg zu verwenden. Wir sind dabei auf Codenvy und Red Hat gestoßen. Red Hat hat kürzlich an der DevNations-Konferenz angekündigt, einen Programmiersprachen-Server für Java anzubieten und diesen in VS Code zu integrieren. Codenvy möchte für Eclipse Che auch Programmiersprachen wie C# unterstützen. Daraus ist eine weitere Win-win-Situation entstanden. Das Protokoll wird jetzt erstmals gemeinsam in einem öffentlichen Repository auf Github weiterentwickelt. Anwender des Protokolls diskutieren bereits via ‘Issues’ über mögliche Erweiterungen.

Wie soll es nun weiter gehen mit VS Code? Was sind die nächsten Ziele?

Wir möchten, dass VS Code zum beliebtesten Code Editor wird.

Erich Gamma: Wie es sich für ein Open-Source-Projekt gehört, planen wir sehr transparent, nach dem Motto, je mehr die Community weiß, woran wir arbeiten, desto mehr gutes Feedback erhalten wir. Wir werden weiterhin jeden Monat ein neues Release publizieren und so kontinuierlich Feedback sammeln und berücksichtigen.

Der monatliche Iterationsplan ist jeweils auf Github verfügbar. Hier ist zum Beispiel der Juni-Plan. Woran wir in den nächsten sechs Monaten arbeiten, steht in der Roadmap. Dazu gehören unter anderem die Eliminierung sogenannter „adoption blockers“. Unser Ziel ist ganz einfach: Wir möchten, dass VS Code zum beliebtesten Code Editor wird.

Vielen Dank für dieses Interview!

eg2_400x400Erich Gamma wurde als Co-Autor des IT-Klassikers „Design Patterns – Elements of Reusable Object-Oriented Software“ und Mitglied der sogenannten Gang Of Four bekannt. Bei IBM leitete er die Entwicklung der Eclipse Java Development Tools und arbeitete am Projekt Jazz, Rational Team Concert. Gemeinsam mit Kent Beck schuf Gamma das populäre Java-Testwerkzeug JUnit. Seit 2011 ist er für Microsoft als Distinguished Engineer tätig, wo er für die Entwicklung der IDE Visual Studio Code verantwortlich zeichnet.

Aufmacherbild: Retro old typewriter with paper von Shutterstock / Urheberrecht: BrAt82

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -