Visual Studio Code: nacimiento, auge y su futuro en MuleSoft

Desde MuleSoft proveemos software de integración flexible y robusto que permite conectar aplicaciones, datos y dispositivos. La mayor parte de las aplicaciones MuleSoft se construyen desde nuestra IDE: Anypoint Studio, la cual está basada en Eclipse.

Si bien Studio nos ha rendido sus buenos frutos y lo continuará haciendo, siempre estamos en la mira para evaluar nuevas tendencias en el mundo de las IDEs. Uno de los acontecimientos más importantes en este espacio ha sido el surgimiento de Visual Studio Code. En este breve artículo repasamos su historia, los desafíos que enfrentan los desarrolladores de sus extensiones y cómo estamos atacando los mismos en el contexto de las herramientas que estamos construyendo en MuleSoft.

En 2011 un tal Erich Gamma se unió a una tal empresa conocida como Microsoft. Erich quizás te suene como uno de los co-autores de EL libro de design patterns: el “Gang of Four”. A la empresa quizás la tengas por creaciones como Windows, Office y Clippo.

Al mando de Erich, el equipo de Microsoft en Zurich se puso a repensar las herramientas de desarrollo para la programación del futuro (?). Por esos tiempos estaban surgiendo nuevos paradigmas de trabajo como los µServices y nuevas tecnologías como por ejemplo Go y Node.js. Con tanto cambio alrededor, ¿servirían aún las herramientas del siglo XX?

Al mismo tiempo, en GitHub estaban desarrollando un editor de texto portable 100% basado en tecnologías web: Node.js para el back-end y Chromium como UI. Este editor fue bautizado como Atom, y su tecnología subyacente como Atom Shell, luego renombrada Electron.

A Erich y su equipo les encantó esta idea de tener un editor portable. Al fin y al cabo, si prácticamente todo lo que hacemos en la computadora ya está en la nube, ¿por qué no mover nuestros entornos de desarrollo a la nube también?

Pero una IDE (Integrated Development Environment) es mucho más que un editor de texto. Hay que proveer coloreo de sintaxis, autocompletar (¡darle al ctrl-space como un campeón!), información de contexto al mover el mouse sobre un elemento, compilación, debugging, … La lista es prácticamente infinita.

Rápidamente, este equipo llegó a la conclusión de que sería prácticamente imposible resolver todos estos problemas para todos los lenguajes de programación sólo con tecnologías web. En otras palabras, implementar un sistema que ofrece opciones para autocompletar un programa Python es algo que es más fácil de implementar directamente en Python. Y hacerlo para un programa Java es más fácil de implementar en Java mismo.

La forma de resolver esto fue haciendo que cada uno de los “subsistemas” que manejan cada lenguaje sea implementado como un proceso aparte. Al quedar aislados en un proceso separado, cada uno de esos subsistemas puede estar implementado en la tecnología que mejor se adapte a la necesidad de cada lenguaje. Así, el subsistema que provee opciones para autocompletar Python estará hecho en Python, el de Java en Java, etc.

¿Y cómo se comunicaría el proceso principal de la IDE con cada uno de estos subsistemas? Para eso, Gamma y compañía diseñaron un protocolo llamado LSP: Language Server Protocol. Este protocolo permite a un cliente (la IDE) y a un servidor (el subsistema que entiende de un lenguaje) interactuar para resolver pedidos puntuales. Por ejemplo: abro un programa en mi IDE, y esta le avisa al Language Server correspondiente para activarlo y que esté listo para resolver pedidos como por ejemplo navegar a la definición de un símbolo.

Algo muy interesante es que, al definir un protocolo estándar entre la IDE y el Language Server, esto permite que cada lado se enfoque en resolver UN problema sin tener que conocer al otro. En otras palabras, quien diseña la IDE se puede enfocar en tener la mejor solución posible para navegar hacia la definición de un símbolo, sin importar en qué lenguaje sea el programa ni cómo identificar cómo se resuelve eso para tal lenguaje. Por otro lado, quien diseña un Language Server para un lenguaje de programación específico puede concentrarse en armar una solución para identificar la definición de un símbolo, sin preocuparse por dónde o cómo se usará tal información.

Una consecuencia de esta separación es que los Language Servers no sólo sirven para la IDE diseñada por Gamma y su equipo, sino para cualquier otra IDE que tenga implementado un cliente de LSP. Al momento en que escribo estas palabras, LSP está soportado por Visual Studio, Atom, vim y Eclipse, entre otros. Efectivamente, el LSP convierte un problema de M x N en un problema M + N.

Armados con el concepto de LSP y otro protocolo similar para abstraerse del debugger (DAP), Microsoft lanzó en 2015 su IDE basada en Electron: nace Visual Studio Code. Visual Studio Code es un producto realmente muy versátil. Su portabilidad y su extensibilidad hicieron que hacia 2019 se convierta en la IDE más usada del mundo según la encuesta de StackOverflow.

Pero no todo es tan sencillo como parece. Para quienes tenemos experiencia desarrollando extensiones para otras IDEs, hay elementos que aún están ausentes. Por ejemplo, en IntelliJ hay un índice central al que todas las extensiones pueden contribuir con símbolos y metainformación, así como consultar. En el caso de Visual Studio Code, cada Language Server es responsable de implementar su propio índice, algo que es ineficiente y complejo.

Otra limitación es la falta de extensibilidad en las propias extensiones. En Eclipse, por ejemplo, existe el concepto de extension point. El mismo declara la intención, por parte de una extensión, de que cierto aspecto de la misma sea modificado o extendido a su vez por otras extensiones. Este concepto es clave para tener un “árbol” de extensiones rico en donde se favorezca el reuso. Visual Studio Code carece de este concepto y las extensiones tienen que arreglárselas para definir sus puntos de extensión. Esto fomenta que haya mucho copy-pasta entre las extensiones.

Finalmente, hay conceptos que están simplemente ausentes en LSP: compilar, testear, manejar dependencias. Para esto se creó otro protocolo llamado Build Server Protocol, pero aún no tiene tanta adopción como para saber si prenderá en la comunidad.

En MuleSoft estamos resolviendo estos desafíos, trabajando para desarrollar herramientas livianas, fáciles de usar y potentes basadas en LSP y Visual Studio Code (¡ya habrá más novedades! ;). Si te interesan estos temas te invito a que visites nuestros sitios sobre ingeniería en MuleSoft y Salesforce.