Cuenta la historia de la primera vez que me defraudó profundamente el manejo de un proyecto open source. O mi intuición a la hora de elegir libs.

El año pasado (2016), arranqué una aplicación web de uso interno en un nuevo trabajo. Sería mi primer proyecto ahí, siendo el único desarrollador, con la posibilidad de elegir tecnologías a piacere.
Había usado previamente React/Redux sólo en mínimas pruebas hogareñas mientras alt-tabeaba y leía docs y posts sobre tooling, estilo y otras yerbas [sic]. Había trabajado previamente con angularjs, conocía sus desventajas, y sabía que estaba siendo reemplazado por angular (al día de hoy, angular 4.2.0 ).

Elegí angularjs como framework front-end de todas maneras.
Siempre consciente de los trade-offs que estaba haciendo. Iba a ser bastante rápido para prototipar. Y así fué. Escupiendo two-way data binding para todos lados, agregando controllers a más no poder, sin testear. Quedó una aplicación bastante sólida, con una interminable lista de TODOs, pero funcional, estable y mantenible! (o mucho más de lo que suena).

Tal vez la “fatiga js” influyó un poco en esa decisión; pero haciendo retrospectiva, no es que lo haya hecho negativamente.

En cierto punto, comencé a usar Angularjs Material para un nuevo módulo de la app. Aproveché para rediseñar el proceso de build client-side. El setup de build client-side que tenía previamente era bastante desastrozo (connect-assets). Opté por usar webpack. Después de sufrir la configuración, quedó bastante bien. La experiencia de desarrollo era mucho mejor, y todo era alegría, pero eso es otra historia. TODO: post sobre la migración a webpack

A medida que iba descubriendo angular material, me iba topando con algunos problemas. Lo esperable. Nada que un poco de stackoverflow, o naufragar en issues de github pueda solucionar. Así como fuí armando pantallas más complejas, me fuí topando con temas menos triviales de resolver. Hasta llegar al punto de la total desilusión. Desde el equipo de angular material habían empezado a cerrar issues a mansalva - sin resolver!!. Con el comentario “Surge Focus on Material 2”, fue suficiente para cerrar montones de issues. Un poco de google y no me sentí solo (oh que ironía). Por no hablar de los issues “deprecated” de la nada.

Una gran cantidad de issues sepultados bajo el mismo patrón de:

issue o request
+1
+1
+1
Closed as surge BS
-1
-1
-1

Cada vez que llegaba a uno de esos, me volvía un sabor amargo, cerraba el tab inmediatamente, y resolvía el problema atándolo con alambre por mi cuenta. Claro estaba en el issue tracker que intentar contribuir con algo a ese proyecto sólo iba a traer dolores de cabeza.

Siempre esperé que angular-material sea un proyecto mucho más maduro.

Proyecto grande de una empresa grande, muchos stars, gente utilizándolo, actividad. Prácticamente abandonado de una manera absolutamente desprolija e irresponsable. ¿Un proyecto con demasiada tracción al que no le supieron bajar la persiana prolijamente? ¿Por qué no un traspaso del ownership a la comunidad?

Actualmente sigo utilizando angularjs material a modo “legacy”. Al parecer siguen sacando actualizaciones menores.

Hoy en día no hay una advertencia clara en la homepage o el readme del proyecto. Aunque hay varias centenas de issues abiertos, y ¿quién sabe cuán dibujado está ese número!?

Existe bastante deuda técnica en mi código y sus dependencias. Administrarla y ser honesto con ella es gran parte de nuestro trabajo.
Es una deuda, tarde o temprano, alguien tiene que pagarla. Al esconderla debajo de la alfombra, no hacemos más que fallar a la honestidad.

NOTA: Si, quejarse de algo a lo que no aportaste nada es gratis. Si, ngMaterial es MIT licensed, without warranty blabla. Tampoco es un desastre. Mi punto es el mal management del proyecto, que desalienta a los usuarios a contribuir, y te deja garpando cuando funcionalidades básicas no funcionan del todo bien.
Si pudiera volver en el tiempo no elegiría ngMaterial, aunque si angularjs.
Todavía no entiendo como no hay más gente puteando por lo mismo.