Yo diría que la culpa es de node.js, y especialmente de todas las herramientas basadas en node.js que se usan para desarrollo frontend, pero lo cierto es que para desarrollar cada vez se usan más aplicaciones de línea de comandos y cada vez hay más plataformas (como .NET Core) que van en esa línea.
No es que usar herramientas de línea de comandos sea algo inventado por la comunidad Javascript (nada más lejos de la realidad), pero la ubicuidad de Javascript como lenguaje y el tirón que han tenido node.js y el desarrollo frontend han contribuido a popularizar formas de trabajar que antes resultaban más exóticas para el gran público.
Los que llevan toda su vida trabajando en entornos *nix, o con lenguajes como ruby o go, están muy acostumbrados a este tipo de herramientas, pero para los desarrolladores de .NET o Java, acostumbrados a depender (quizá demasiado) de sus potentes IDEs, es más novedoso.
Personalmente, le tengo cariño a las herramientas de línea de comandos desde mi época de linuxero pesado y llevo mucho tiempo usándolas para desarrollar también en .NET, pero comprendo las reticencias de algunos que las consideran un paso atrás y una vuelta al pasado.
En realidad, se trata de una cuestión de aprendizaje.
Las herramientas de líneas de comandos pueden tener una curva de aprendizaje más dura, sobre todo si no estás acostumbrado a utilizar este tipo de herramientas, y es normal que te dé pereza pensar que tienes que recordar muchos parámetros y que tienes que andar teclando una y otra vez largos comandos en una consola.
Afortunadamente, cuando ya conoces unas cuantas herramientas es más fácil encontrar sus similitudes, comprender las formas en las que suelen manejarse, y aprender a utilizar nuevas herramientas no se hace tan cuesta arriba.
Aun así, la cuestión no es tanto si son fáciles o difíciles de usar, sino si merece la pena usarlas.
¿Por qué querría invertir tiempo en manejar este tipo de herramientas cuando puedo tener un IDE en el que pulso un botón, sale un wizard que me va guiando, y consigo el mismo resultado?
La respuesta es sencilla: eficiencia.
Ólvidate por un momento de esas herramientas de línea de comandos tan antediluvianas que aborreces, y piensa en tu precioso IDE, que te conoces al dedillo y manejas con soltura.
Dentro del IDE hay ciertas tareas que requiren utilizar un asistente. Normalmente, estas tareas suelen ser más infrecuentes, requieren más pasos y es más fácil olvidar cómo se realizan, por lo que tener un wizard que te va guiando, aunque implique pasar por más pantallas y hacer más clicks, merece la pena.
También hay otras tareas que realizas con mayor frecuencia, y tener que pasar por 7 pantallas de un wizard en las que te van pidiendo un par de campos cada vez es muy tedioso. Por suerte suele ser posible saltarse el wizard, llegar a una pantalla llena de opciones, y conseguir el mismo resultado. Es menos guiado, pero resulta más rápido.
Aun así, hay tareas que haces tantas veces que tener que ir a pulsar un botón resulta un engorro, y te acabas aprendiendo un atajo de teclado. Hasta mi madre conoce Ctrl-C y Ctrl-V, y seguro que tú te sabes unos cuantos atajos de teclado del IDE que sueles usar. Memorizar un atajo de teclado es más complicado que explorar una barra de botones o un menú hasta encontrar la opción que estás buscando, pero a cambio te permite ser más rápido.
Las herramientas de línea de comandos son el paso siguiente. Quizá resulten más complicadas de aprender que algunos atajos de teclado (excepto si usas emacs y has memorizado cosas como C-c C-t t), pero no sólo te permiten ejecutar un comando con parámetros rápidamente, también te permiten automizar la ejecución de comandos.
Sí, la principal ventaja de las herramientas de líneas de comandos es que son “programables”, y se supone que a nosotros nos gusta programar cosas.
Se supone que se nos da bien resolver problemas de otros escribiendo código, pero muchas veces nos cuesta usar nuestra capacidad de desarrollar aplicaciones para resolver nuestros propios problemas. Nos parece razonable que un cliente nos pague para diseñarle una aplicación que haga que sus empleados puedan hacer las cosas en menos tiempo y con menos esfuerzo, pero aplicar esa misma idea a nuestro propio trabajo ya es otro tema.
Cuando puedes lanzar una herramienta por línea de comandos es fácil integrarla dentro de un proceso mayor, por ejemplo dentro de un servidor de integración continua, en un lanzador de tareas como grunt o gulp o en las opciones de tu editor de texto.
Esto no implica que olvidemos los interfaces gráficos. Igual que tener un atajo de teclado no impide tener también la opción disponible en un menú, tener un interfaz de línea de comandos es perfectamente compatible con tener también una interfaz gráfica.
En el mundo linux es muy habitual ese escenario, con herramientas gráficas que actúan como frontend de una herramienta de línea de comandos, y tampoco es raro encontrar librerías que son utilizadas tanto por herramientas de línea de comandos como por aplicaciones con interfaz gráfica.
En mi opinión, las herramientas de desarrollo deberían contar siempre con algún mecanismo para invocarlas por línea de comandos, y de hecho he tenido que descartar herramientas bastante interesantes por no tenerlo.
Me aburre mucho tener que hacer tareas repetitivas, y pese a que los lenguajes de scripting son una de mis asignaturas pendientes, intento siempre automatizar todo lo que puedo mis flujos de desarrollo. Además de para ganar en eficiencia, tener las tareas automatizadas me permite aumentar la confianza en el proceso, porque sé que no se me olvidará darle a un botón y el resultado de lo que estoy haciendo será más predecible.
En definitiva, puede que las herramientas de línea de comandos sean algo del siglo pasado, pero a día de hoy todavía son la mejor opción para muchas tareas y, como decía Rubén (que tan amablemente me ha dejado usar su frase como título de este post), la consola mola.
Posts relacionados: