Existe alguns pontos que eu acho problemáticos ao se adotar uma dependência (lib, framework,...)

Pelo hype

Como diriam os titãs: a melhor banda de todos os tempos da última semana
Todo dia surgem ferramentas milagrosas, resolvedoras de todos os males. Porém ninguém realmente testou essas ferramentas em produção por muito tempo, e já tem gente colocando em projetos reais.

Fazer isso é anti-profissional

Sem entender se o projeto/problema realmente precisa de uma solução desse tipo

Usando React como exemplo, tem muito site por aí que não precisava de React. Normalmente o programador adotou React por ser a única coisa que ele se propôs a estudar, e pulou os estudos de conceitos.

Já vi alguns projetos usando React apenas para validar formulários, gente... A validação nativa de formulários do HTML que está disponível há anos, já dá conta de boa parte do recado.

Sem entender como a dependência funciona

A pessoa nunca nem viu a dependência funcionando, não leu a documentação, não fez uma PoC. Apenas dá um npm install ... (composer, cargo, pip, etc), e reza para funcionar.

Sem se preocupar se o projeto é bem mantido pela empresa ou comunidade por trás dessa dependência

Além de projetos, já vi até tutoriais apresentando o uso de libs que já não são mais mantidas há muito tempo. Como o silex sem manutenção há 6 anos.

O silex era muito usado para criar rotas no PHP, esse tipo de projeto causa uma forte dependência do seu projeto com a lib, imagina o quão frágil é um projeto usando silex hoje em dia. Além desse forte acoplamento, não deixar seu projeto ser atualizado para novas versões do PHP nesse caso.

Sem dominar a linguagem por trás dessa dependência

Isso é o principal ponto de falha na minha opinião, se você não tem o mínimo de domínio na linguagem base, como você saberia dizer que um erro no projeto é por conta da lib ou por conta do seu código?

Já peguei um bug de um projeto em que a lib utilizada não realizava o clearInterval quando necessário. Perguntei ao programador original do projeto se ele não tinha visto, e por incrível que pareça ele não sabia o que era clearInterval. Típico programador frontend, mas desde que o frontend seja restrito ao framework X.

Quando é uma boa ideia usar dependências externas

Uma vez superado os pontos descritos acima, dependências externas são realmente uma boa ideia para agilizar a entrega.

Não há motivo para se recriar o ExpressJS se ele atende muito bem a necessidade do projeto.

Mas cuidado com a preguiça, dois exemplos clássicos são:

• is-odd com mais de 460k instalações nessa semana
• is-even com quase 300k instalações nessa semana

A primeira retorna se um número é ímpar, a segunda retorna se o número é par. 🤡🤡🤡

Ou seja, fazem o mesmo que (n % 2) === 0 e (n % 2) !== 0. Precisa mesmo dessa dependência no projeto?
Pela quantidade de instalações na semana, tem gente que pensa que sim, são UMA VERGONHA PARA A PROFISSION

Cada caso é um caso. Eu sou o tipo de programador que pensa um milhão de vezes antes de instalar uma lib. Meu critérios são:

1 - eu realmente preciso? Vou instalar essa lib pra não "reinventar a roda" ou por pura preguiça(Left Pad por exemplo)?

No seu caso, acho mais inteligente instalar um lib para o carrossel. Não é algo tão simples quanto parece, logo também não é algo crítico que vá quebrar o software, ao meu ver. Agora, se você for instalar uma lib para descobrir se um número é par ou impar, dai é preguiça pura.

2 - se eu preciso de uma lib, então vou procurar uma que seja estável, bem implementanda, conhecida, segura, que tenha manutenções frequentes e que tenha um licença adequada para seu uso.

O que tem de libs por ai nessa selva JS cheias de malwares é coisa de doido. Entre no repositório da lib e veja se tem uma alma viva que cuide dele e que não seja um projeto abandonado, com commits de 2 anos atrás.

3 - se quiser, seja curioso! Entenda como a lib funciona e tente implementar a sua própria! Isso separa os bons programadores dos medíocres.

Como disse, não gosto de ir instalando um monte de pacotes sem motivo. Tento deixar meus projetos o mais simples possível. Quanto mais libs, mais chances de quebrar. Pode ser ágil agora, mas lá pra frente vai ser o triplo de dor de cabeça!

Penso que se você precisa só de um carrossel, sem muito recurso, tudo bem fazer do zero.

Mas supondo que esse carrossel precise de um comportamento x na imagem 1, y na imagem 2, precise se comportar de tal forma no celular e de uma forma diferente no pc, aí já vale a pena você usar uma lib que implemente isso.

Por exemplo, ninguém se atreve a criar sua própria versão do chartjs. O tempo gasto não compensa.

Sobre algumas dependencias especificas que foram levantas nas outras já execlentes respotas:

Express

No desenvolvimento web com Node.js, o Express.js se destaca como uma extensão quase natural, semelhante à relação entre C++ e Boost. A questão não é a necessidade reinventar o Express, mas como proceder quando enfrentamos limitações ou problemas com ele.

A inclinação natural pode ser buscar soluções prontas, construídas sobre o próprio Express. No entanto, antes de adicionar outra dependência ao seu projeto, considere explorar as abstrações de rede nativas do Node.js. A solução mais eficaz e segura pode ser alcançada com o que já está disponível na plataforma, sem a necessidade de introduzir mais uma biblioteca externa.

is-odd

Se o Node oferecesse tal função nativamente, usá-la não apresentaria problemas. O real perigo está em adicionar ao projeto pacotes aleatórios do npm que, apesar de populares, podem carregar vulnerabilidades severas. O simples ato de instalar uma biblioteca com alertas de segurança deveria ser um sinal vermelho, mas muitas vezes é ignorado.

Na teoria, a melhor prática seria inspecionar e entender cada linha de código de terceiros que você inclui no seu projeto. Embora isso possa ser impraticável esse princípio não deve ser descartado. Esforçar-se para compreender o funcionamento e as implicações de segurança dos pacotes de terceiros não pode ser negligênciado.

A gestão prudente das dependências externas é um pilar fundamental para a segurança e manutenção de qualquer software no longo prazo. Esse cuidado não apenas protege seu projeto contra vulnerabilidades e erros desconhecidos, mas facilita o processo de atualização e manutenção, tornando-o mais gerenciável a longo prazo.

Carrossel

Se uma biblioteca de UI que você já utiliza em seu projeto oferece um carrossel que atende às suas necessidades, aproveite essa funcionalidade. Por outro lado se o objetivo é criar uma solução personalizada, recorrer a uma "colcha de retalhos" de bibliotecas aleatórias não é uma abordagem razoável. Nesses casos, desenvolver sua própria solução, torna-se uma escolha mais acertada.

Se o seu projeto já está utilizando um framework, como React, faz sentido aproveitar as capacidades para desenvolver componentes adicionais, como o carrossel. Agora introduzir uma lib como o react apenas para implementar esta funcionalidade também não é razoável. A solução para um novo requisito deve ser construída a partir do que você já tem, combinado com implementação própria que atenda especificamente às suas necessidades.

---

Software de terceiros, mesmo que aberto e gratuito, traz consigo um custo implícito. Antes de adotar, é essencial considerar se o esforço de criar algo não superam estes custos implícito no longo prazo.

O "molho" do seu projeto, especialmente aqueles aspectos que definem sua proposta de valor e diferencial competitivo, deve permanecer sob seu controle direto. Dependender excessivamente de terceiros para funções centrais vai colocar seu projeto em risco catastrófico se essas dependências falharem.

O mal entendio do não reinventar a roda

Se não existem rodas para seu carro disponíveis no mercado, a solução é fabricar a sua própria. Isso não significa reinventar a roda: você enfrenta o mesmo problema – a necessidade de movimento – e reconhece que uma roda é a solução adequada. Agora, o passo seguinte é construir essa roda, uma que se ajuste perfeitamente ao seu fusquinha mequetrefe e não tentar colocar uma roda de Ferrari nele.

Compreenda (estudando as soluções testadas e provadas) a solução geral do problema: a "roda": e então construa uma versão que se adeque exatamente ao seu contexto.