Soy un hombre de tradiciones y toca continuar la que inicié el año pasado, a petición de Alfredo, repasando mis tecnologías del 2015. Es además una buena forma de resumir las herramientas que uso actualmente para los que puedan estar interesados en conocerlas.

Al igual que el año pasado, me ceñiré a tecnologías que uso profesionalmente porque son con las que más me he pegado y de las que puedo dar una opinión más formada. También quiero recordar que me dedico a desarrollar productos, no proyectos. Son además productos que llevan años en el mercado y (esperamos) durarán unos cuantos años más, y son instalados en miles de clientes por un montón de distribuidores, sobre un parque de equipos (hardware y software) de lo más heterogéneo. Todo esto hace que andar saltando de tecnología en tecnología sólo porque esté de moda o porque prometa maravillosas mejoras no es para nosotros una opción, así que no esperes grandes cambios ni plataformas ultramodernas de dudoso futuro.

.NET

Seguimos planteándonos la posibilidad de abandonar .NET a medio plazo, así que tratamos de minimizar los nuevos desarrollos sobre esta plataforma.

Eso no quiere decir que no la usemos, al contrario, todos nuestros sistemas de backend están desarrollados en C# y trabajamos con ellos todos los días, pero hemos hecho pocos cambios en esta parte.

Mantenemos nuestro stack de librerías por defecto: NHibernate como ORM, Castle Windsor como contenedor IoC, NUnit para tests y log4net para logging. No siempre las usamos, pero lo normal es que si queremos echar mano de alguna librería de ese tipo, recurramos a ellas.

Puede que haya librerías más actuales para todas esas cosas, pero cuando hemos jugado con ellas tampoco nos han aportado lo suficiente para cambiar. Supongo que si nos dedicásemos a hacer proyectos acotados en el tiempo tendríamos más variedad; en nuestro caso, reescribir partes grandes de una aplicación solo pasar a otra librería más moderna que realmente no te aporta mucho más, es una pérdida de tiempo y dinero.

Miramos de reojo .NET Core con ciertas esperanzas de que nos pueda ser útil algún día y que nuestra migración sea a .NET Core desde .NET Framework en lugar de saltar a plataformas más extrañas para nosotros, pero por el momento lo vemos lejos. Quizá esto se aclare dentro de un tiempo, cuando sea un poco más estable, las herramientas estén más consolidadas y se vea más claro dónde va a acabar todo.

Javascript

Si después de hablar de la inestabilidad de .NET Core te digo que HTML5 y Javascript es nuestra plataforma preferida para desarrollar aplicaciones cliente, seguramente te resulte extraño. La diferencia fundamental es la comparación con las alternativas. Mientras que .NET Core todavía lo consideramos una opción inferior (en nuestro escenario, insisto) a .NET Framework, HTML5 y Javascript nos aporta más que soluciones nativas o multiplataforma como Xamarin, lo que nos compensa en cierto modo la falta de estabilidad.

En la parte de Javascript hay menos uniformidad que en .NET y tenemos algún cadáver en el armario desarrollado con AngularJS que nos da un excelente rendimiento económico y unos cuantos quebraderos de cabeza a la hora de mantenerlo.

Todos los desarrollos nuevos los estamos haciendo desde hace un par de años con ReactJS, que cada vez nos gusta más por la flexibilidad que nos da a la hora de estructurar el código.

El año pasado mencionaba nuestras dudas con React Router, y eso ha acabado desembocando en un cambio hacia minimal-router, una microlibrería que surgió de un ejercicio de diseño en abierto y que estamos usando en producción en un par de aplicaciones.

Otra cosa que no nos acababa de gustar era Material-UI, y aunque la aplicación donde lo usamos sigue empleando ese interfaz de usuario (y no tenemos previsto cambiarla), hemos vuelto a diseños basados en Bootstrap o implementados desde cero por nosotros.

En cuanto a herramientas, las mismas que el año pasado: scripts npm (sin Grunt ni Gulp), mocha, chai, …, en fin, los sospechosos habituales. Como incorporación de este año hemos tenido enzyme para testear componentes de ReactJS que nos ha gustado bastante (aunque en general tratemos de evitar ese tipo de tests).

El año de TypeScript

Es la mayor novedad del 2016 para nosotros, y es algo de lo que todavía no estamos muy convencidos.

De momento tenemos alguna aplicación en producción y estamos desarrollando más con TypeScript, pero, sinceramente, aún no las tengo todas conmigo con respecto a esta tecnología.

Un lenguaje que saca versiones nuevas cada 2 meses, introduciendo cambios semánticos importantes, da un poco de miedo. Si a eso le unes que al usarlo te conviertes automáticamente en ciudadano de segunda dentro del ecosistema Javascript y tienes que pegarte más para poder usar determinadas herramientas y librerías que no están pensadas para TypeScript, es normal que surjan dudas.

Sin embargo, hay que reconocer que sus herramientas, uno de los puntos fuertes de TypeScript, facilitan mucho la vida en otros aspectos. Además son ampliamente soportadas por los editores de texto, lo que permite libertad a la hora de elegir el entorno de desarrollo, que es algo que valoro mucho.

Tal vez alguno os preguntéis por qué no hemos optado por otro tipo de lenguajes, como mi «amado» clojurescript. Estuvimos evaluando algunas alternativas, pero lo cierto es que para elegir un lenguaje de programación hay factores que pesan más que el propio lenguaje.

No hemos hecho grandes cambios en nuestra arquitectura o herramientas para integrar TypeScript y mantenemos las mismas herramientas y liberías que con Javascript, sólo que ahora hay que buscar las definiciones de tipos (algo que no siempre es fácil) y los plugins adecuados para preprocesar los ficheros TypeScript y convertirlos a Javascript, como tsify para browserify o ts-node para ejecutar los tests con mocha.

Aquí siempre echo de menos que el compilador de TypeScript no esté implementado como un plugin de Babel; no sé si es posible, pero simplificaría muchísimo todo.

La relación de amor/odio con webpack

Otra de las novedades de este año para nosotros es webpack. Después de haber pasado por grunt y gulp, y haber acabado con una solución muy ligera basada en scripts npm, utilizar una herramienta como webpack nos genera serias dudas.

Por una parte, es muy atractivo poder gestionar todos los recursos de tu aplicación de una forma homogénea, incluyendo TypeScript, less, imágenes, etc. Que sea posible versionarlos con un hash para gestionar la caché es muy útil, y hay partes que encajan especialmente bien con TypeScript, como el plugin file loader, que a la vez que nos permite aprovechar el pipeline de webpack para gestionar ficheros, nos ofrece un acceso «tipado» a las rutas de los ficheros.

Para gestionar los ficheros css, incluyendo la concatenación de ficheros desde distintas rutas y la consolidación de recursos (imágenes, fuentes, etc.) en una única carpeta, no hemos encontrado una solución mejor.

A cambio, introduce una complejidad excesiva. A esto hay que unirle que la documentación es bastante mala (aunque ya vamos estando acostumbrados a eso) y que vive a caballo entre la versión 1.x y la 2.x (aunque la 2.x parece que ya está más cerca), cada una con sus peculiaridades, lo que contribuye a hacerlo todo aún más confuso.

Pero el principal problema es que es lento. Lentísimo. Hay una parte que es culpa del compilador de TypeScript (que tampoco es lo más rápido del mundo), pero con webpack el problema se exacerba. Acostumbrado a tiempos de décimas de segundo para compilar con Babel y Browserify, pasar a varios segundos con webpack y TypeScript se me hace muy duro.

Al menos gracias a la inestimable ayuda de Dani de la Cruz hemos conseguido que la parte de gestión de css sea lo bastante rápida como para que resulte usable.

Pese a que hemos invertido unas cuantas horas en Webpack y tenemos aplicaciones funcionando con él, no tengo nada claro que se mantenga entre nosotros, o por lo menos que lo haga como solución única para compilar TypeScript. Ahora mismo me inclino más por una mezcla con browserify (u otro sistema rápido) durante el desarrollo y usar Webpack para empaquetar sólo de cara al despliegue… Ya veremos cómo acaba la historia.

Y poco más

En la parte de infraestructura no hemos hecho prácticamente ningún cambio con respecto al año pasado y seguimos usando las mismas herramientas (YouTrack, SVN, Cruise Control.NET, …). Estamos pendientes de novedades y, a título personal, usamos otro tipo de soluciones (Git, Trello, etc.), pero lo cierto es que hasta ahora no hemos encontrado motivación suficiente (dado nuestro escenario) para que nos compense la migración a nivel profesional con todo lo que ello implica.

En cuanto a editores, IDEs, y demás, seguimos utilizando Visual Studio 2013 (no hemos necesitado nada del 2015 y las quejas que hemos leído nos han echado un poco para atrás) y, aunque yo sigo fiel a emacs, VS Code ha entrado con fuerza para desbancar a los Atom y Sublime que usaban algunos.

Si alguno tiene curiosidad por alguna herramienta o tecnología en concreto, puede preguntar en los comentarios: no hacemos nada tan secreto que no se pueda contar ;-)