Em resposta a [ Dúvida ] Criar do Zero ou Agilizar com Libs?

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

kht

10 meses atrás

Pra mim, qualquer um que defenda ou leve a sério esses pacotes tipo is-odd já é desqualificado na hora.

E pra completar o show de horrores, o is-even tem como dependência o is-odd, inclusive seu código fonte é:

module.exports = function isEven(i) {
    return !isOdd(i);
};

E o is-odd, por sua vez, tem outra dependência, o is-number.

Por fim, vale lembrar que quanto mais dependências, mais chances de dar problema caso alguma delas fique desatualizada ou deixe de existir. Quem não se lembra do infame caso do left-pad?

Claro que reinventar a roda toda hora não é produtivo, então o ideal é tentar encontrar um equilíbrio entre usar algo pronto e fazer vc mesmo. Não tem regra exata pra isso, sempre é uma análise caso a caso.

rafael

10 meses atrás

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

Eu uso o ExpressJS e não tenho problemas com ele, mas ele tem poucas atualizações (e pouca manutenção no código), pode ver pelas últimas versões no NPM. Não acompanho o desenvolvimento, mas a versão 5 já me parece quase uma lenda 😅

Para você, o que diferencia o ExpressJS do silex, já que parece ter mencionado ele positivamente no texto? Uma falta de manutenção por mais alguns anos não poderia torná-lo um silex?

Me parece fácil migrar do ExpressJS para outra solução, mas nunca precisei fazer isso. E também nunca usei o silex, por isso estou perguntando.

Algo não relacionado à esta sequência de comentários, mas relevante ao tópico discutido, é o caso do protestware do node-ipc (mais sobre a história no BleepingComputer).

user1

Autor

10 meses atrás

Citei o Silex pois vi um tutorial desse ano recomendando ele para gerenciar rotas, a pessoa deve usá-lo repetidamente a anos e nem sequer deve acompanhar como está o projeto. É para essa situação que eu quis chamar a atenção.

Quanto ao Express, por mais que o desenvolvimento dele esteja lento, ele não está morto ou abandonado, há commits no projeto toda a semana. E os outros projetos em torno dele (como middlewares), o tornam extensível e talvez por esse motivo o pessoal prefere esse caminho do que alterar o core.

E nesse caso em particular, as coisas começaram a andar mais devagar quando a Node Foundation se envolveu diretamente no projeto. Caso ele fique abandonado realmente, seria imprudente iniciar um novo projeto com Express.