Bibliotecas de componentes de interfaz de usuario: compilación frente a compra

¿Para construir o para comprar una biblioteca de componentes? Esta es una pregunta que desarrolladores y responsables de desarrollo abordan con bastante frecuencia. Cuando la eficiencia y la consistencia lo son todo, la decisión no es solo cuestión de preferencia. Se trata de alinear la estrategia técnica con los objetivos empresariales a largo plazo.

Por eso, el objetivo de este artículo será ayudar a los ingenieros de software a tomar una decisión al elegir entre diferentes librerías de componentes de interfaz que no les cueste:

• Su tiempo, a menudo desperdiciado intentando entregar su acumulación de pendientes bajo plazos ajustados.
• Su presupuesto: muy limitado y normalmente no está bajo su control cuando se necesitan recursos adicionales para aportar valor.
• Su confianza en sus propias habilidades, cuando en realidad no pueden usar una biblioteca de interfaces de terceros para el propósito específico de una aplicación extremadamente específica. Tampoco pueden construir, por ejemplo, una Angular Pivot Grid desde cero, mientras otro desarrollador gestiona un componente selecto diferente al mismo tiempo, que debe soportar múltiples funcionalidades. Así que, al final, las dos cosas chocan en la interfaz y la experiencia de usuario inconsistentes.

¿Por dónde empezar y qué considerar al elegir bibliotecas de componentes de la UI?

Cuando se trata de abordar aspectos clave como necesidades, propósitos, habilidades, tipo de aplicación y más, las opciones para gestionar el desarrollo se reducen a:

• Creación de una biblioteca de interfaz de usuario interna 
• Comprar una biblioteca de componentes de terceros 
• Choosing an open-source software (OSS) 

Para decidir cuál es el mejor enfoque para usted, primero echemos un vistazo al panorama general y veamos el contexto más amplio en el que cada una de estas tres opciones se puede aplicar potencialmente antes de ajustar nuestra lente narrativa y acercarnos.

• Company size and teams 
• Know-how y experiencia 
• La aplicación, su propósito y el cliente 

1.Tamaño de la empresa y equipos 

Antes de decidir si construir o comprar una biblioteca de componentes, piensa en el tamaño de tu empresa, cómo está configurado tu equipo y qué quieres conseguir.  La mejor opción depende de cómo funcionen tus equipos, qué herramientas ya tengas y de la importancia de la escalabilidad y la coherencia.

Cosas importantes que preguntar:

• ¿Tenéis un sistema de diseño compartido entre diseño y desarrollo?
• ¿Qué librerías de frameworks de aplicaciones o componentes de UI usáis ya?
• ¿Qué importa para la entrega de tu app: velocidad/tiempo de comercialización, productividad de los desarrolladores, personalización o mantenimiento a largo plazo?
• ¿La coherencia entre equipos/aplicaciones hace que tu proceso de desarrollo sea más eficiente?

2. Conocimientos técnicos y experiencia 

A la hora de decidir si usar bibliotecas de componentes de interfaz preconfiguradas o crear una propia, ten en cuenta el historial del equipo de TI. Si los desarrolladores no tienen suficiente conocimiento para construir componentes integrales que sirvan a objetivos a corto o largo plazo (dependiendo de las necesidades específicas, por supuesto), entonces no merece la pena invertir tiempo ni esfuerzo en absoluto. Esto también requerirá recursos adicionales de desarrolladores más experimentados para documentar código y procesos.

Preguntas a hacer en este contexto: 

• ¿Han construido componentes complejos para uso en producción en el pasado?
• ¿Tienes un sistema de diseño existente que se corresponda con tu biblioteca de componentes de la interfaz?
• ¿Con qué frameworks y tecnologías trabajan?
• ¿Cuánto esfuerzo de mantenimiento se requiere hoy en día y cómo afectaría la creación de nuevos componentes?
• ¿Cómo aseguráis la integración de componentes con vuestra arquitectura actual?

3. La aplicación, su propósito y el cliente 

Por último, tu decisión debe estar impulsada por el proyecto en el que vas a trabajar, qué y cómo se va a utilizar y por quién.

Preguntas a hacer en este contexto: 

• ¿Los componentes reutilizables eliminarán tareas repetitivas y fomentarán la reutilización en otras áreas de tu base de código?
• ¿O es un caso de uso único, muy específico y especializado que nunca volverás a usar y, por tanto, no se aplicará en múltiples escenarios/apps/proyectos?
• ¿Estás construyendo para un cliente externo que requiere una personalización extensa y cumple con estrictos requisitos de diseño?
• ¿Las funciones de la red de datos listas para usar y otras se adaptarán a tus necesidades, o necesitas más flexibilidad y personalización, incluso a nivel de usuario?
• ¿Estás construyendo/manteniendo un sistema interno que requiera un desarrollo de aplicaciones más rápido y mejorar la colaboración entre equipos multifuncionales?
• ¿Tu objetivo es crear productos únicos e innovar, por lo que necesitas control total y escenarios/funcionalidades ilimitadas que puedas cambiar y actualizar cuando decidas?

Comprar vs construir: pros y contras de una biblioteca de componentes de terceros, una biblioteca de interfaz de usuario interna y OSS

Para los fines de esta sección, filtraré cada opción por  7 factores y resaltaré los compromisos de cada una.

Factor 1: Reutilización de componentes 

Esto sin duda permite estandarizar entre proyectos, especialmente si son continuos, y planeas usar el mismo código varias veces para ahorrarte trabajo manual y tareas repetitivas. Sin embargo, ciertos componentes, especialmente para frameworks relativamente nuevos como Blazor, son especialmente difíciles de construir desde cero. No me refiero a un botón aquí. Piensa en redes de datos que pueden ser lo suficientemente rápidas y completas como para ofrecer cumplimiento de accesibilidad, todo tipo de columnas, celdas y filas, manipulación de datos, visualización personalizada, etc.

Reutilizabilidad de componentes	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Atender a una amplia variedad de desarrolladores y proyectos; solución rápida de problemas; estilo consistente; acelera la estandarización.	Puede requerir formación inicial; Las características de nicho pueden tardar más en implementarse.
Bibliotecas internas	Creado a medida para necesidades del proyecto; priorización de características enfocada; Conocimiento interno adquirido.	Reutilización limitada; carece de documentación; ignora la accesibilidad; altos costes de mantenimiento a largo plazo.
Software de Código Abierto (OSS)	Mejoras impulsadas por la comunidad; flexibilidad para ampliar las funcionalidades.	A menudo abandonada; funcionalidades faltantes; Depuración intensa y actualizaciones inconsistentes.

Factor 2: Dependencias externas 

Cuantas más dependencias tenga que agregar en el futuro, más complejo se vuelve lo que inicialmente quería simplificar. Es importante, entonces, considerar todas las opciones en este sentido.

Dependencias externas	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Dependencias mínimas; gestionado y probado por el proveedor; Baja complejidad.	Dependencia del soporte de proveedores externos; Las soluciones externas pueden llevar tiempo.
Bibliotecas internas	Control total sobre las dependencias.	Las dependencias obsoletas aumentan la complejidad; Los riesgos de seguridad interna deben gestionarse.
Software de Código Abierto (OSS)	Gran ecosistema con código reutilizable.	Cadenas de dependencias poco claras; Potencial para vulnerabilidades y conflictos de seguridad.

Factor 3: Actualizaciones 

¿Cuántas actualizaciones podéis gestionar tú o tu equipo de desarrollo a diario, al mes, al año...? Cada una de las tres opciones tiene sus pros y sus contras, y es fundamental evaluarlas en cuanto a actualizaciones antes de decidir.

Actualizaciones de software	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Actualizaciones regulares alineadas con los marcos de trabajo; gestionado por equipos dedicados; Probado para comprobar la estabilidad.	Las actualizaciones frecuentes pueden requerir ajustes; Las versiones beta pueden causar inestabilidad temporal.
Bibliotecas internas	Mantenimiento inconsistente; los proyectos pequeños suelen estar obsoletos o abandonados.	Rara actualización; rápidamente obsoleto; Los equipos internos deben encargarse de todo el mantenimiento.
Software de Código Abierto (OSS)	Los proyectos bien mantenidos pueden contar con actualizaciones activas y apoyo comunitario.	Mantenimiento inconsistente; los proyectos pequeños suelen estar obsoletos o abandonados.

Factor 4: Documentación y recursos de aprendizaje de la biblioteca de UI 

Una documentación bien redactada y completa, que incluya demostraciones, ejemplos de componentes implementados, secciones adicionales de recursos y una base de conocimiento, es clave. No documentar tu código o no tener uno listo puede dificultar construir incluso una lista desplegable o un paginador. Y mucho menos con componentes más complejos como Blazor DockManager, o visualizaciones compuestas como Angular gráfico financiero/bursátil.

Documentación y recursos de aprendizaje	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Documentación completa, muestras en vivo y tutoriales; Grandes comunidades online.	Documentación pobre o incompleta; Las actualizaciones irregulares aumentan la curva de aprendizaje.
Bibliotecas internas	El conocimiento personalizado se adapta a los flujos de trabajo de la empresa.	La documentación a menudo se descuidaba debido a recursos limitados; Difícil incorporación para nuevos desarrolladores.
Software de Código Abierto (OSS)	Colaboración abierta; guías aportadas por la comunidad.	Documentación pobre o incompleta; Las actualizaciones irregulares aumentan la curva de aprendizaje.

Factor 5: Personalización 

Conseguir y entregar todo en una app requiere actualizaciones y cambios. Entonces, ¿qué tan flexible necesitas que sea tu biblioteca de UI y qué tan flexible puedes hacerla? No pases por alto este factor cuando optes por una solución u otra, pero ten en cuenta que a veces componentes o funcionalidades altamente configurables que permiten a todos hacer cambios pueden resultar en código difícil de mantener y romper muchas otras "cosas" que nadie conoce o que son muy específicas. Por eso tenemos componentes de Angular personalizados que son más sencillos que el componente de Combo Box, por ejemplo.

Personalización	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Altamente configurable; soporta sistemas de accesibilidad, tematización y diseño; Se integra con herramientas low-code.	Limitado por el alcance de diseño del proveedor; La personalización excesiva puede complicar el mantenimiento.
Bibliotecas internas	Personalización ilimitada; Control total sobre las funciones y actualizaciones.	desarrollo intensivo en tiempo; requiere pruebas y validación exhaustivas.
Software de Código Abierto (OSS)	Flexible y modificable; Extensiones de la comunidad posibles.	Calidad fragmentada; extensibilidad inconsistente sin un fuerte apoyo comunitario.

Factor 6: Soporte técnico 

Además de beneficiarse de documentos de ayuda detallados y explicativos y otros recursos de aprendizaje, obtener soporte técnico calificado también es algo que importa.

Apoyo técnico	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Equipo de apoyo dedicado; Respuestas profesionales puntuales.	Depende de los SLA del proveedor; Flexibilidad limitada en asuntos fuera de horario.
Bibliotecas internas	Acceso directo a los creadores para una depuración rápida.	Sin apoyo dedicado; La carga interna de trabajo aumenta con el tiempo.
Software de Código Abierto (OSS)	Colaboración comunitaria y debates abiertos.	No hay apoyo garantizado; Depende de la popularidad del proyecto y del tiempo de voluntariado.

Factor 7: Coste, licencias y retorno de inversión 

Por último, todo depende de cuánto cueste todo y si el precio se compensa en el futuro.

Coste, licencias y ROI	Advantages	Disadvantages
Bibliotecas de interfaz de usuario comerciales	Planes de licencia flexibles; actualizaciones frecuentes; Rentable para un uso a largo plazo.	Los costes iniciales o anuales pueden ser elevados; Las versiones de prueba pueden limitar el acceso completo a las funciones.
Bibliotecas internas	Ahorro inicial en tasas de licencia.	Costes ocultos a largo plazo en mantenimiento, actualizaciones y documentación; 10 veces más coste total que ROI.
Software de Código Abierto (OSS)	Acceso libre; modelos de licencias adaptables.	riesgos de propiedad intelectual y licencias; ROI incierto; Mucho tiempo de personalización y mantenimiento.

El coste oculto de construir desde cero

Los desarrolladores suelen subestimar lo que realmente significa "construir". No se trata solo de componentes de programación. Eso los mantiene durante años. Los equipos que pasan por alto esta realidad a menudo ven cómo su biblioteca interna queda obsoleta antes incluso de que se envíe. Cuando eso ocurre, la coherencia se desmorona: los desarrolladores empiezan a importar componentes de fuentes externas solo para cumplir con los plazos, lo que lleva a una interfaz fragmentada, esfuerzos duplicados y deuda técnica a largo plazo difícil de deshacer.

Muchos equipos se sienten atraídos por la idea de construir bibliotecas internas de componentes de la interfaz, pero a menudo malinterpretan el alcance y la complejidad que conlleva. También hay una sutil falacia del coste hundido en juego. Una vez que se ha invertido tiempo y esfuerzo en componentes personalizados, los desarrolladores dudan en reemplazarlos por soluciones de terceros, incluso cuando estas son más robustas y rentables.

El verdadero valor no reside en reinventar los componentes básicos, sino en crear bibliotecas de patrones que se alineen con los objetivos empresariales, garanticen la coherencia y permitan a los equipos innovar más rápido. Sin embargo, demasiadas veces, los desarrolladores se centran en reconstruir cuadrículas, menús desplegables o botones en lugar de perfeccionar patrones compartidos de diseño y experiencia de usuario.

Construir internamente significa asumir toda la responsabilidad de:

• Mantenimiento continuo para accesibilidad, actualizaciones del navegador y cambios en el framework.
• Redactar documentación, incorporar nuevos desarrolladores y hacer cumplir la gobernanza.
• Pérdida de productividad cuando los ingenieros mantienen infraestructuras en lugar de construir características.

Las bibliotecas de componentes de interfaz DIY suelen pasar por alto el rendimiento, la mantenibilidad, las pruebas y la accesibilidad, convirtiendo lo que se pretendía ser una ventaja estratégica en una carga operativa a largo plazo. ¿El resultado? Un sistema lento, caro de mantener y frágil de desarrollar.

Mi opinión personal y por qué elegir Ignite UI

Por último, ¿qué es Ignite UI y por qué es una buena solución para tu negocio?

Los días en que los equipos de TI dependían de procesos de desarrollo de software torpes y tenían que construir todo desde cero quedaron atrás.

No importa si hablamos de desarrollo de aplicaciones para clientes externos o soluciones internas, o de librerías y conjuntos de herramientas de componentes de la interfaz. Siempre es lo mismo. Si las herramientas pueden acelerar y facilitar el desarrollo de aplicaciones y lograr una mejor experiencia de usuario cumpliendo con los principios más modernos relacionados con la tematización, la capacidad de respuesta, el a11y y el desarrollo rápido de aplicaciones, casi no tienes más remedio que usarlas.

Te costará encontrar un responsable o ejecutivo de desarrollo que apruebe un proyecto de desarrollo de software que podría costar millones de dólares, llevar meses o años completarse, que no forme parte del negocio principal o de la experiencia de tu empresa. Y peor aún, está completamente desactualizado cuando se pone en producción, ya que las decisiones se tomaban meses o años antes, mientras que los frameworks modernos de interfaz se lanzan varias veces al año con nuevas funciones, actualizaciones de seguridad y correcciones de errores.

En cuanto a las bibliotecas de componentes, las completas realmente cubren la mayoría de los requisitos de diseño y aplicaciones, con la extensibilidad incorporada que uno podría esperar. Igual que nuestro Ignite UI que ofrece una caja de herramientas para Angular, Blazor, React, Web Components y otros frameworks populares.

Cada biblioteca recibe mejoras continuas y funciones adecuadas para cualquier negocio, y sobre todo proporciona coherencia entre frameworks. Yo puedo elegir y tú puedes elegir entre decenas y decenas de componentes disponibles, como cuadrículas, gráficos, entradas de datos e incluso exportaciones de archivos. Tienes la oportunidad de formar parte de una comunidad fuerte que no solo te ayudará a lograr cualquier cosa con el marco que elijas, sino que también crecerá como desarrollador/diseñador, aportando además un ahorro significativo a tu empresa.

Para más detalles sobre el ROI de las bibliotecas de componentes de interfaz reutilizables y el coste de compilar frente a comprar, lee nuestro whitepaper.