Essas bibliotecas servem para você conseguir gerenciar rotas, de forma geral. Receber uma requisição HTTP e respondê-la. Infelizmente, em JavaScript temos muitas bibliotecas que fazem as mesmas coisas porque alguém queria algo "um pouco diferente" ou blazingly fast.

O Express talvez seja o mais antigo (não pesquisei), e quase não tem atualizações. É uma biblioteca bem madura e simples. Já foi muito usada, e isso significa que muito sofware em produção hoje usa o Express por causa de uma decisão de cinco anos atrás. Eu já usei (e ainda uso), e ele cumpre bem seu propósito.

Existem outros que vieram para tentar "destronar" o Express, como o Koa, mas se você for ver no NPM, é uma diferença de 32 milhões de downloads semanais do Express contra 2 milhões do Koa. Claramente o Koa não é pequeno, mas veja o tamanho do Express.

O NestJS é opinado. É inspirado no Angular, e já ouvi falar que por causa disso o pessoal que vem de outras linguagens (como Java) tende a se dar melhor com ele. É um framework que encapsula o Express. Eu não cheguei a usar o NestJS porque me pareceu trazer mais complicações do que o necessário (vi o NestJS em alguns vídeos da Rocketseat).

Hono é mais um concorrente, bem mais novo. Não conheço direito para comentar sobre.

Se for trabalhar num projeto simples, acredito que o NestJS seja coisa demais. Acho interessante usar algo simples de substituir, mesmo que você nunca precise. Isso por si só já signfica que o desenvolvedor não precisa aprender "a biblioteca" para trabalhar no projeto.

Se for trabalhar num projeto grande, me parece arriscado usar algo novo como o Hono.

Recentemente experimentei o Bun para um projeto simples, e não precisei nem mesmo do Express, só usei o Bun.serve e ifs para gerenciamento das rotas. Mas, quando fiz uma versão compatível desse projeto com o Node.js, precisei adicionar o Express.

Se você estiver com tempo, recomendo experimentar criar uma API simples e usar algumas bibliotecas diferentes que chamaram a sua atenção. Conseguirá entender o quanto cada uma tem de "boilerplate", se a velocidade delas influencia na quantidade de requisições que você precisa atender, se a "experiência de desenvolvimento" é boa ou não etc.

Programmer404há 2 meses

As vezes esqueço que o JavaScript é um ecossistema cheio do mesmo. Agora que você mencionou este fato, nem me surprendeu mais ter 4 frameworks com as mesmas propostas.

Achei muito interessante seu comentário, e fico profundamente agradecido por ele! Talvez, num futuro próximo, nem precise mais de frameworks de gerenciamente de rotas. Seu exemplo com o bun é um exemplo disto.

Mas por agora parece que temos mais projetos legados ou relativamente velhos do que novos, então talvez eu dê uma atenção maior para o express enquanto estudo aos poucos os mais recenetes.

Mais uma vez, muito obrigado!

vincenthá 2 meses
Importante apontar que essas bibliotecas sobre as quais você perguntou não são exatamente _frameworks_, são apenas bibliotecas. Nesse caso, são bibliotecas que facilitam o gerenciamento de rotas pra servidores HTTP. Quanto a "não precisar mais dessas bibliotecas": tenta implementar seu próprio Express usando o [módulo de http](https://nodejs.org/api/http.html) do próprio Node. Não é tão difícil e você vai aprender muito! Mas pra projetos em produção, eu aconselharia usar, sim, Express ou Hono.
Programmer404há 2 meses
Citei "framework" pois estava taxado em todos os lugares em que eu vi, apesar de serem pacotes bem simples. Como sou novato no mundo do Backend, nem pensei muito sobre. Nem passou pela a minha mente criar meu próprio "express", mas já veio uma enxurrada de ideias quando você falou. Acredito que ao ter um certo domínio do HTTP e o Node.js, e claro, ter uma boa estruturação, nem deve ser tão difícil quanto parece ser!