Em algum momento, resolvi que queria ter um blog. Um lugar para expor as coisas que eu faço, desenvolver pensamentos e organizar ideias de um jeito mais coerente do que simplesmente deixá-las flutuando na cabeça. Mas, sejamos honestos, eu já poderia ter escrito muito mais até agora.

Isso acabou revelando um problema que, de tão recorrente, chega a ser preocupante: eu costumo gastar mais tempo ajeitando as ferramentas do que realmente fazendo o que precisa ser feito. Mesmo que eu tenha demorado um pouco para montar o blog, poderia ter levado ainda mais tempo, se não tivesse tomado cuidado.

O vasto mar

Vamos pegar o desenvolvimento web como exemplo. A tecnologia web é um terreno extremamente vivo. A web está por toda parte e, tirando a parte dos servidores, ainda é sustentada por aqueles velhos conhecidos: HTML, CSS e JavaScript. Claro, existem novas stacks que cresceram bastante, como os frameworks multiplataforma, mas sejamos realistas: a maioria dos desenvolvedores ainda gosta mesmo é do trio HTML, CSS e JS. Basta olhar para os frameworks mais usados para desenvolvimento mobile (aliás, são tantos que até assusta).

Se você quer lançar seu app tanto no Android quanto no iOS — o que hoje é praticamente o padrão —, vale muito a pena usar um desses frameworks multiplataforma. Tem React Native, Cordova, Ionic, NativeScript, PhoneGap... todos eles, juntos, carregam boa parte do mercado nas costas. Mesmo com o Flutter ganhando espaço, o velho stack da web ainda comanda o espetáculo.

E não para por aí: o JavaScript também conquistou território nas aplicações de desktop. O Electron, por exemplo, usa o motor V8 do Chrome para rodar aplicações como se fossem páginas web com poderes de sistema operacional. É uma ideia que divide opiniões, sem dúvida, mas que mostrou ser muito eficaz.

No final das contas, estamos falando do maior ecossistema de desenvolvimento para o usuário final. E, como era de se esperar, isso significa uma quantidade quase infinita de frameworks, bibliotecas e plataformas à sua disposição. Parece incrível, não?

Dependency hell (mas não como você imagina)

Nesse oceano de opções, é muito fácil se perder. Todo dia surge uma nova ferramenta prometendo ser “a salvação” — resolver todos os seus problemas e ainda proporcionar a melhor experiência para o usuário. E assim, cada novo framework vira “o futuro do desenvolvimento”.

Quando um desenvolvedor sente que uma solução não é boa o bastante, a reação natural é criar outra solução. E é aí que essa famosa tirinha do xkcd faz todo sentido.

É ótimo que existam pessoas corajosas querendo melhorar o mundo do software — afinal, é isso que move a tecnologia pra frente. Mas, num cenário tão caótico, é preciso cautela.

Tirando as ideias do papel

Eu queria criar um blog. E a primeira coisa que me veio à cabeça foi usar um gerador de site estático (o famoso SSG). Comecei então a pesquisar os melhores frameworks. Não queria nada com editor WYSIWYG ou gerenciamento de banco de dados — queria controle total, do código ao conteúdo.

Foi aí que encontrei opções como Next.js, Nuxt, VuePress, Jekyll, Gatsby, VitePress... e a lista só cresce (sério, é interminável). Minhas exigências eram simples: bom suporte a TypeScript, suporte a pré-processadores de CSS e uma estrutura de projeto organizada. Além disso, queria aproveitar para aprender mais sobre Vue, que está em alta. Escolhi o Nuxt: ótimo para geração de conteúdo e com controle total do layout usando Vue.

Só que logo na largada já veio o primeiro dilema: usar o Nuxt 2 (estável, mas baseado em JS) ou apostar no Nuxt 3 (que ainda estava em fase de release candidate). Como sou teimoso, escolhi o 3. Resultado: documentação incompleta, problemas de configuração... enfim, aquela diversão toda. Depois de muito suar, consegui, finalmente, começar a desenhar o blog. Mas aí veio a exaustão. Comecei a questionar se eu realmente teria algo pra escrever. E então, deixei tudo de lado por uns dias.

Um tempo depois, surgiram umas ideias vagas sobre arte, e pensei: "Sabe, daria um ótimo post de blog!" Só que... não havia blog.

Dessa vez, eu sabia que precisava ser rápido. Busquei a solução mais simples e rápida possível. Parti pro Next.js, que já conhecia, procurei um CMS leve — gostei do Sanity — e fui costurando tudo. Em poucas horas, estava com o blog pronto e já escrevendo.

Foque nos seus objetivos

O desenvolvimento, no geral, tem uma comunidade gigantesca — e, com isso, milhares de ferramentas à sua disposição. Mas é essencial ter um objetivo claro e se manter firme nele. Caso contrário, a produtividade despenca.

Se o seu objetivo for aprender uma nova tecnologia, ótimo — mas que seja com esse propósito específico em mente. Se a missão é fazer algo funcionar, foque nas ferramentas que você já domina.

Finalizando o trabalho

Dependendo do que você quer construir, vários fatores entram em jogo para escolher a melhor ferramenta. E o primeiro é:

• Quanto tempo você realmente tem (ou deveria gastar) para encontrar a melhor solução?

Não perca de vista seus objetivos. Às vezes, o simples e o conhecido já resolvem. Mas se for um projeto grande, ou que envolva uma equipe, aí sim vale a pena gastar mais tempo planejando.

Pegando sempre a próxima onda

Existem frameworks novos e empolgantes surgindo, como Solid.js e Svelte — ambos trazem avanços impressionantes em performance. Pessoalmente, estou animado para ver essas tecnologias crescendo e sendo mais adotadas.

Mas usar algo novo na prática é outra história. Essas ferramentas ainda são muito jovens e, inevitavelmente, você vai esbarrar em problemas. Nunca se esqueça: aquele software “legado” que muita gente torce o nariz costuma ser, justamente, o mais sólido.

No fim das contas, talvez sua escolha não seja a mais rápida, nem a mais bonita — mas se ela fizer o trabalho bem feito, será, sem dúvida, a escolha certa.