Bibliotecas de componentes da interface do usuário – Build vs Buy

"Nunca mais quero construir outro componente de calendário pelo resto da minha vida. Eu também gosto de reagir-select." Eu me deparei com isso no reddit enquanto navegava pelas discussões.

Mas então eu também li: "Quando você escreve sua própria (biblioteca), você aprenderá muito mais coisas como acessibilidade, índice de movimentação, gerenciamento de foco, identificação automática, etc. Tudo isso faz você apreciar a complexidade de um pacote de interface do usuário bom e estável."

E aqui estou tentando responder à pergunta "Construindo vs comprando bibliotecas de componentes: o que escolher?" e ajudar os desenvolvedores a tomar uma decisão que não lhes custará:

• Seu tempo em vão, quando na verdade eles são pressionados pelo próprio tempo para construir soluções de TI de qualidade rápida.
• Seu dinheiro é em vão, quando na verdade eles trabalham com orçamento rigoroso e a empresa não pode alocar mais para um projeto que é estimado em uma quantia X de dinheiro e uma quantia X de salário por hora.
• Sua confiança em suas próprias habilidades de programação, quando na verdade eles não podem usar uma biblioteca de interface do usuário de terceiros para o propósito específico de um aplicativo extremamente específico. Eles também não podem construir, por exemplo, um Angular Pivot Grid do zero, enquanto outro desenvolvedor lida com um componente select diferente ao mesmo tempo, que deve suportar vários recursos. Portanto, as duas coisas se chocam em UI e UX inconsistentes no final.

De qualquer forma, todos esses são cenários estressantes que podem rapidamente fazer com que um único projeto passe de missão crítica a missão impossível. O que fazer, então? Qual é a melhor maneira de criar seu aplicativo Web? Você deve usar componentes de interface do usuário pré-criados ou é melhor criar os seus próprios? E por que usar uma biblioteca de componentes em primeiro lugar?

O que é uma biblioteca de componentes?

Em termos mais simples, uma biblioteca de componentes de interface do usuário é um kit de ferramentas abrangente que combina componentes/controles ricos em recursos pré-criados, API, diretrizes, aplicativos de amostra, cenários de integração, exemplos de código e ferramentas extras que simplificam o desenvolvimento de aplicativos, ajudando os desenvolvedores a criar uma ótima interface mais rapidamente. Os componentes também podem ser personalizados, reutilizados e estendidos para obter opções de marca e mais flexibilidade.

Mas quando se trata de abordar aspectos-chave como necessidades, propósitos, habilidades, tipo de aplicativo e muito mais, as opções para lidar com o desenvolvimento se resumem a:

• Criando uma biblioteca de interface do usuário interna
• Comprar uma biblioteca de componentes de terceiros
• Choosing an open-source software (OSS)

Para decidir qual é a melhor abordagem para você, vamos primeiro olhar para o quadro geral e ver o contexto mais amplo em que cada uma dessas três opções pode ser potencialmente aplicada antes de ajustarmos nossa lente narrativa e ampliarmos.

• Company size and teams
• Know-how e experiência
• O aplicativo, sua finalidade e cliente

1.      Company size and teams

Uma das primeiras coisas a considerar ao tentar descobrir se deve comprar ou construir uma caixa de ferramentas com componentes é o tamanho da sua empresa e quantos programadores estão envolvidos na criação do aplicativo.

Perguntas a serem feitas neste contexto:

• A empresa opera em um campo altamente regulamentado?
• É uma empresa de pequeno, médio ou grande porte?
• Funciona com equipes de fusão? Existem desenvolvedores remotos ou cidadãos na imagem?
• Se for uma organização grande, as equipes já usam algum tipo de biblioteca de interface do usuário?
• O que a empresa e a equipe desejam alcançar ao implementar uma dessas caixas de ferramentas – Padronização? Reutilização contínua a longo prazo? Conformidade com a acessibilidade? Controle total sobre como eles criam software? Gastar mais tempo com a lógica de negócios do aplicativo e não ter que criar tudo do zero?

2. Know-how técnico e experiência

Quando se trata de decidir se deve ou não usar bibliotecas de interface do usuário pré-criadas ou criar uma própria, avalie o histórico da equipe de TI. Se os desenvolvedores não tiverem conhecimento suficiente na construção de componentes abrangentes que atenderão a metas de longo / curto prazo (dependendo das necessidades específicas, é claro), não vale a pena investir tempo e esforços. Isso também exigirá recursos adicionais de desenvolvedores mais experientes para documentar códigos e processos.

Perguntas a serem feitas neste contexto:

• Que know-how prático e técnico os desenvolvedores e designers da equipe possuem?
• Eles já usaram alguma biblioteca de interface do usuário antes e em que medida?
• Os designers e as pessoas por trás do UX na empresa têm experiência suficiente para projetar componentes profissionalmente?
• Eles aprendem rápido e estão prontos para se adaptar às novas práticas recomendadas e automação?
• Ou eles tentaram construir componentes do zero e quão reutilizáveis eles eram?
• Com quais estruturas e tecnologias eles trabalham?
• Você ou sua equipe estão prontos para lidar com dependências e acompanhar as versões do navegador ou as atualizações da estrutura? Você terá tempo para manter sua biblioteca interna atualizada?
• Quanto trabalho de front-end deve ser feito?

3. O aplicativo, sua finalidade e o cliente

Finalmente, sua decisão deve ser orientada pelo projeto em que você vai trabalhar, o que e como ele será usado e por quem.

Perguntas a serem feitas neste contexto:

• Você precisa de componentes reutilizáveis para um projeto de longo prazo que exigirá a eliminação de tarefas repetitivas e o uso dos mesmos módulos e código?
• Ou é um caso de uso único, muito específico e especializado que você nunca mais usará e, portanto, não será aplicado em vários cenários/aplicativos/projetos?
• Você está construindo para um cliente externo em um nicho restrito que não aceita uma solução única para todos e, em vez disso, exige personalização pesada, envolve especificações de design específicas e, portanto, impõe tarefas que exigirão de você lidar e solucionar problemas que são menos comuns?
• Os recursos e funcionalidades prontos para uso farão o trabalho para você e você/a equipe concorda com os recursos disponíveis para todos os usuários por padrão?
• Você é um sistema interno para sua organização e precisa acelerar o desenvolvimento de aplicativos e melhorar a colaboração entre equipes multifuncionais?
• Seu objetivo é construir produtos exclusivos e inovar, então você precisa de controle total e cenários/funcionalidades ilimitados que podem ser alterados e atualizados sempre que você decidir?

Compre vs construa: prós e contras de uma biblioteca de componentes de terceiros, biblioteca interna de interface do usuário e OSS

Para os fins desta seção, filtrarei cada opção por meio de 7 fatores e destacarei as compensações de cada opção.

Factor 1: Component reusability

Isso certamente alcança a padronização entre os projetos, especialmente se eles forem contínuos e você planeja usar o mesmo código em tempos diferentes para economizar alguns esforços manuais e tarefas repetitivas. No entanto, existem certos componentes, especialmente para estruturas relativamente novas, como Blazor, que são particularmente difíceis de construir do zero. Não me refiro a um botão aqui. Pense em grades de dados que podem ser rápidas e abrangentes o suficiente para fornecer conformidade de acessibilidade, todos os tipos de colunas, ações de células e linhas, manipulação de dados, visualização personalizada e assim por diante.

COMPONENT REUSABILITY
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Criados para atender e cumprir o maior número possível de desenvolvedores, equipes e projetos, eles podem ser aplicados a diferentes aplicativos.   Pode solucionar rapidamente desafios comuns.   Estilo consistente para vários componentes.   Obtenha padronização mais rapidamente e resulte em uma consistência instantânea de UI/UX.	Pode exigir algum treinamento e orientação antes de atingir o nível desejado de compartilhamento de conhecimento e desenvolvimento acelerado de aplicativos.   A priorização de recursos e funcionalidades de nicho pode levar mais tempo.
Bibliotecas internas	Obtenha know-how que pode ser usado para outros fins e projetos que requerem desenvolvimento modular.   Projete e desenvolva apenas os componentes necessários com o nível de reutilização desejado.   Priorização mais rápida de recursos/funcionalidades importantes.	O componente foi desenvolvido especificamente para o caso de uso atual, sem consideração na reutilização em outras equipes/projetos.   A manutenção e o custo de longo prazo não são considerados antecipadamente.   Nenhuma consideração para acessibilidade, a11y, conformidade com a Seção 508 e outros itens obrigatórios para componentes.   Sem documentação, portanto, as APIs são conhecidas apenas pelo desenvolvedor que criou o componente, dificultando o uso por outras pessoas.
OSS	Muitos projetos OSS reproduzem esforço e usam o mesmo código. É fácil propor novos recursos/funcionalidades dos quais a comunidade pode se beneficiar.	A maioria dos projetos OSS é abandonada em 12 meses, e ainda mais ganham zero apoio da comunidade.   Ainda não pode fornecer todas as vantagens da reutilização de componentes.   Você gastará tempo suficiente depurando, descobrindo quais funcionalidades estão faltando e adicionando-as posteriormente.

Factor 2: External dependencies

Quanto mais dependências você tiver que adicionar no futuro, mais complexo se tornará o que você inicialmente queria simplificar. É importante, então, considerar todas as opções a esse respeito.

EXTERNAL DEPENDENCIES
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Eles são reduzidos ao mínimo e, se você tiver que adicionar algum, é principalmente apenas um. O nível de complexidade é próximo de zero. Você não lidará com conflitos entre bibliotecas. Mas, caso haja algum, a equipe por trás da biblioteca paga lida com isso e geralmente eles detectam esse tipo de problema desde o início. É limitado apenas à própria biblioteca de terceiros.	Resolver esse pacote de dependência pode levar mais tempo porque você depende de suporte externo.
Bibliotecas internas		Eles multiplicam as complexidades do projeto porque você precisa lidar com dependências desatualizadas por conta própria.   Você é responsável pelos riscos de segurança em dependências OSS de terceiros.
OSS		Eles multiplicam as complexidades do projeto porque você precisa lidar com dependências desatualizadas por conta própria.   Você não sabe se é uma dependência de terceiros ou de terceiros.

Factor 3: Updates

Quantas atualizações você ou sua equipe de desenvolvimento podem lidar diariamente, por mês, por ano...? Cada uma das três opções certamente tem prós e contras diferentes e é crucial avaliá-las em relação às atualizações antes de se decidir.

SOFTWARE UPDATES
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Tudo é atualizado para a estrutura ou versão mais recente do navegador. As atualizações são feitas pela equipe externa por trás da biblioteca comercial. Você não precisa realocar pessoas ou lidar com isso sozinho.   Com processos de teste tranquilos em vigor, o que ajuda as equipes a lidar com atualizações e garantir estabilidade.   Projetos contínuos geralmente têm um roteiro com o futuro em mente e obtêm lançamentos regulares de acordo.	Pode acontecer de ter muitas atualizações.   As versões Alpha, Beta, RC podem ser lançadas diariamente para abordar itens de alta prioridade.
Bibliotecas internas	Você obtém informações em primeira mão sobre os últimos lançamentos porque é você quem precisa acompanhar as atualizações.	Você lida com tudo.   As bibliotecas domésticas geralmente nunca são atualizadas e estão desatualizadas mesmo no momento em que são colocadas no produto.
OSS	Você pode acessar um projeto de código aberto bem mantido que é atualizado todas as vezes. Projetos contínuos geralmente têm um roteiro com o futuro em mente e recebem lançamentos regulares.	Pode acontecer de ter muitas atualizações.   Apenas os maiores e mais bem financiados projetos OSS são mantidos atualizados regularmente.

Fator 4: documentação da biblioteca de interface do usuário e recursos de aprendizagem

Uma documentação abrangente e bem escrita, contendo demonstrações, exemplos de componentes implementados, bem como seções de recursos adicionais e base de conhecimento é fundamental. Não documentando sua codificação ou sem ter uma pronta, espere tempos difíceis para construir até mesmo uma única lista suspensa ou um paginador. Muito menos componentes mais complexos, como Blazor DockManager, ou visualizações compostas, como Angular gráfico Financeiro/Ações.

DOCUMENTAÇÃO E RECURSOS DE APRENDIZAGEM
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Sempre venha com documentação detalhada, fácil de ler e atualizada e não "faça uma vez e esqueça". Pode incluir exemplos de edição ao vivo que ajudam os desenvolvedores a entender melhor e sentir os componentes de código/interface do usuário com os quais eles estarão lidando. Forneça recursos de aprendizagem adicionais, blogs, perguntas frequentes, vídeos de instruções, tutoriais, aplicativos de amostra. Geralmente tem grandes comunidades no Stack Overflow, Discord, Medium, Reddit, GitHub.	Exigir compromisso com a documentação e o aprendizado. Pode levar algum tempo para se acostumar com isso.
Bibliotecas internas		Exigir horas de trabalho adicionais e tempo de desenvolvimento alocado para escrevê-lo e atualizá-lo.   A maioria das organizações não tem recursos para escrever documentação sobre os aplicativos que estão lançando no mercado, muito menos os componentes de interface do usuário desenvolvidos internamente usados no aplicativo.
OSS		É difícil encontrar projetos OSS com documentação, a menos que sejam muito grandes e bem financiados.   Pode levar muito tempo para se acostumar e aprender todas as coisas que são adicionadas e continuam sendo adicionadas regularmente ou irregularmente.

Factor 5: Customization

Obter e entregar tudo em um aplicativo requer atualizações e alterações. Então, quão flexível você precisa que sua biblioteca de interface do usuário seja e quão flexível você pode torná-la? Não negligencie esse fator ao optar por uma solução ou outra, mas lembre-se de que, às vezes, componentes/funcionalidades altamente configuráveis e permitem que todos façam alterações neles podem resultar em um código difícil de manter e podem quebrar muitas outras "coisas" com as quais ninguém está familiarizado ou são muito específicas. É por isso que temos componentes de Angular personalizados que são mais simples do que o componente Combobox, por exemplo.

Personalização
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Bibliotecas abrangentes como Ignite UI garantem que deixe espaço para personalização, acessibilidade e internalização. Professional components are super configurable. Inclua parâmetros interativos que os usuários podem alterar facilmente. Trabalhe igualmente bem com sistemas de design e criadores de aplicativos low-code/no-code.	Alguns recursos vêm prontos para uso.   Construído para se adequar a cenários comuns/todos (o que também pode ser uma vantagem).
Bibliotecas internas	Você tem opções e maneiras ilimitadas de criar recursos especiais e alterar componentes quando e como quiser.   Você pode decidir sobre os componentes e funcionalidades exatos.	As bibliotecas domésticas são criadas especificamente para uma necessidade específica, a personalização/extensibilidade de longo prazo não é considerada antecipadamente.   Requer mais tempo para construir, testar, validar, codificar, documentar.
OSS	Normalmente, super configurável.	Criado especificamente com recursos e extensibilidade adicionados assim que a tração da comunidade é obtida ou o financiamento é alcançado.

Fator 6: Suporte técnico

Além de se beneficiar de documentos de ajuda detalhados e explicativos e outros recursos de aprendizagem, obter suporte técnico qualificado também é algo importante.

SUPORTE TÉCNICO
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Há uma equipe de suporte técnico dedicada para lidar com todas as solicitações e dúvidas e fornecer soluções. Ajuda oportuna e qualificada.
Bibliotecas internas		Você lida com todos os problemas por conta própria ou solicita ajuda de alguém com mais conhecimento técnico.   Você ou sua equipe terão que responder a todas as demandas e solicitações em algum momento, comprometendo tarefas vitais e codificação de qualidade.
OSS	Caso a biblioteca OSS de sua escolha tenha um grande esforço da comunidade por trás dela, você terá grandes chances de encontrar uma solução.   Pode colaborar.   Aumenta suas habilidades de resolução de problemas apoiadas por uma comunidade de colegas desenvolvedores.	Caso contrário, você deve solicitar ajuda adicional ou tentar lidar com isso ou com o seu próprio.   Sem suporte técnico dedicado Ou o suporte técnico é baseado na popularidade e na comunidade da biblioteca OSS". Se a biblioteca é nova e desconhecida, não há comunidade por trás dela, para apoiá-la.

Fator 7: Custo, Licenciamento e ROI

Por fim, tudo se resume a quanto tudo vai custar e se o preço compensa no futuro.

CUSTO, LICENCIAMENTO E ROI
	ADVANTAGES	DISADVANTAGES
Bibliotecas de interface do usuário comerciais	Bibliotecas como Ignite UI oferecem diferentes pacotes e opções de licença para atender ao orçamento e às necessidades. Com versões de teste disponíveis para explorar e ver como os produtos funcionam antes de se comprometer com 100%.   Todos os pacotes são atualizados imediatamente após lançamentos importantes de frameworks como Angular, Blazor, React, Web Components e muito mais. Offer per-developer subscriptions.	Pode não incluir teste de todo o produto e todos os componentes ou recursos.   Dependendo do produto, pode ser caro e os planos completos não podem ser tão acessíveis.   Às vezes, não há assinatura mensal e apenas anual.
Bibliotecas internas	Pode ser a solução mais rápida, especialmente quando você atualmente não tem recursos para uma biblioteca de componentes de interface do usuário de terceiros cara.	Normalmente, o custo se multiplica pelo tempo de desenvolvimento necessário para construir a biblioteca, mantê-la e atualizá-la, escrever documentação, lidar com problemas, tarefas adicionais e assim por diante.   A pesquisa mostra que o custo é de 10 a 50 vezes maior do que o ROI em uma solução interna.
OSS	Funciona bem se você encontrar uma solução que corresponda exatamente ao que você precisa, caso contrário, você está gastando tempo personalizando uma base de código para a qual não possui o IP.	É necessária uma compreensão completa do licenciamento OSS, colocando seu IP em risco.   O custo se multiplica pelo tempo de desenvolvimento necessário para construir a biblioteca, mantê-la e atualizá-la, escrever documentação, lidar com problemas, tarefas adicionais e assim por diante.   Quase impossível estimar o custo e o ROI.

Minha opinião pessoal e Ignite UI

Em uma nota final, o que é Ignite UI e por que é uma boa solução para o seu negócio?

Os dias em que as equipes de TI dependiam de processos de desenvolvimento de software desajeitados e tinham que construir tudo do zero acabaram há muito tempo.

Não importa se nos referimos à criação de aplicativos para clientes externos ou soluções internas, ou se discutimos coisas como bibliotecas de interface do usuário e conjuntos de ferramentas. É sempre a mesma coisa. Se as ferramentas puderem acelerar e facilitar o desenvolvimento de aplicativos e obter um melhor UX, cumprindo os princípios mais modernos relacionados a temas, capacidade de resposta, a11y e desenvolvimento rápido de aplicativos, você quase não terá escolha a não ser usá-las.  Você terá dificuldade em encontrar um gerente ou executivo de desenvolvimento que aprove um projeto de desenvolvimento de software que pode custar milhões de dólares, levar meses ou anos para ser concluído, que não faz parte do negócio principal ou da experiência de domínio de sua empresa.  E pior ainda, está completamente desatualizado no momento em que é colocado em produção, pois as decisões foram tomadas meses ou anos antes, enquanto as estruturas de interface do usuário modernas são enviadas várias vezes por ano com novos recursos, atualizações de segurança e correções de bugs.

Quando se trata de bibliotecas de componentes, as abrangentes realmente cobrem a maioria dos requisitos de design e aplicativo com extensibilidade integrada que se possa imaginar. Assim como nosso Ignite UI que oferece uma caixa de ferramentas para Angular, Blazor, React, Web Components e outras estruturas populares.

Cada biblioteca recebe aprimoramentos contínuos e recursos adequados para qualquer negócio e, acima de tudo, fornece consistência entre as estruturas. Eu posso escolher e você pode escolher entre dezenas e dezenas de componentes disponíveis, como grades, gráficos, entradas de dados e até exportações de arquivos. Você tem a chance de fazer parte de uma comunidade forte que não apenas o ajudará a alcançar qualquer coisa com a estrutura de sua escolha, mas também a crescer como desenvolvedor/designer, ao mesmo tempo em que traz economias significativas de custos para sua empresa.

Para obter detalhes adicionais sobre o ROI de bibliotecas de componentes reutilizáveis e o custo de construção versus compra, leia nosso whitepaper.