Por qué no utilizar librerías de terceros

El mundo Open Source es fantástico, pero al final nada es perfecto. A lo mejor el título de esta entrada puede malinterpretarse, quiero aclararlo, me refiero exclusivamente a las librerías de terceros, es decir, aquellas que un usuario particular o grupo de usuarios mantiene desinteresadamente. Tampoco debe tomarse como una orden, pero si espero que sirva a modo de reflexión e información al momento de comenzar un proyecto.

Vino de Autor o Librería de Autor

Desde que existe internet que existen librerías para lenguajes muy interesantes, desarrolladas por desarrolladores independientes que simplemente quieren tener una librería con X característica y la misma no existe. Por lo tanto suelen suplir un poco la problemática. Pero el verdadero problema de todo esto es que esos autores rara vez quieren hacer una librería, se trata solo de un conjunto de código que utilizan en su día a día para hacer una práctica más sencilla y lo mismo deciden compartirlo y gana popularidad. En poco tiempo esa persona decide organizar mejor el código ya que hay gente que le interesa, y crea la librería. Pero el destino final del proyecto suele ser que dichas librerías se dejan de mantener. Si es cierto que gracias a GitHub muchas veces otros usuarios hacen un fork de la librería y empiezan a mantenerla por su cuenta, lo cual es de destacar. Eso puede ayudar, pero al principio generará problemas; y si la librería no es tan popular entonces es posible que nunca consiga un fork.

Librerías Oficiales vs Librerías de Terceros

Vamos a un caso real, Angular y sus librerías para UI. Angular en si tiene su propio sistema de UI llamado Angular Material. Este sub-framework es mantenido por el equipo de desarrollo de Angular, es decir, que ni bien se actualiza Angular se actualizan todos sus derivados, entre ellos Angular Material. Pero hay muchos desarrolladores que pensarán que hay algunos sistemas de UI para Angular mucho mejores, como Onsen. El problema es que Onsen está mantenido por una empresa y no hay una certeza de su verdadero tiempo de vida. Si Angular Material deja de existir mañana es porque Angular tendrá ya listo un nuevo UI o porque Angular será el que deje de existir. Pero si sistemas como Onsen dejan de existir, entonces al momento de actualizar nos tocará pasar todo el código de terceros a una nueva plataforma (oficial o de terceros) y eso puede llevar mucho tiempo.

Tengo la experiencia con ngx-bootstrap que al principio se llamaba ng2-bootstrap y que muchos usamos para implementar bootstrap en Angular ni bien salió; lo cual fue equivocado porque lo que se debía hacer era implementar Bootstrap desde la propia implementación oficial de Bootstrap y no dejar que una línea de comando nos "solucione el problema". La librería cambió de nombre, llevando a varios problemas en un inicio, y actualmente aunque existe no tiene sentido usarla. Además, se hicieron tantos Forks que la página de NPM se ha llenado de versiones de ngx-bootstrap, ¿cuál usar?. Y realmente la instalación de Bootstrap de forma oficial en Angular es sumamente simple de por sí, no hace falta agregar capas de complejidad extras.

¿Nunca usar librerías de Terceros?

Tampoco hay que ser tan estricto. Pero una pequeña investigación antes de usar una librería tan solo porque la recomiendan en todos los foros es algo recomendable. Principalmente porque puede que exista una forma nativa de hacer lo mismo, o incluso de no existir es posible que sea muy sencillo implementar algo similar sin recurrir a librerías que solo suman peso y problemas al actualizar.