“Não é o que você não sabe que lhe causa problemas. É o que você tem certeza que não é assim.” Mark Twain estava pensando em desenvolvimento de software quando escreveu essas palavras? ly:Arial;<br> mso-font-kerning:0pt;<br> ligaduras mso:none;<br> idioma mso-ansi:EN;}.MsoPapDefault<br> {mso-style-type:export-only;<br> line-height:115%;}div.WordSection1<br> {página:Wor
O software progride de várias maneiras. Principalmente, fazemos um esforço deliberado para melhorar as coisas e aproveitar as oportunidades quando elas se apresentam. Às vezes, enfrentamos um desafio por si só, como escalar uma montanha “porque ele está lá”. Ou seja, às vezes ficamos cativados pela possibilidade inerente a um projeto e simplesmente vamos atrás dela.
E fora desta mistura caótica, muitas vezes retrabalhámos, redescobrimos ou reaproveitamos ideias de formas surpreendentes. O mais surpreendente de tudo é que às vezes esses caminhos voltam contra si mesmos – uma ideia antiga surge novamente para superar uma ideia mais nova. Aqui estão nove exemplos desse tipo, desdobrando-se agora.
JS simples supera TypeScript
Justamente quando você pensa que algo é um acordo, uma certeza absoluta, o universo irá contradizê-lo rudemente. Parecia óbvio que o TypeScript iria absorver toda a base de código da Internet. A simples ideia de adicionar tipos ao JavaScript tornou-o uma opção radicalmente popular tanto para programadores quanto para empresas.
Mas agora parece que estamos caminhando em direção a um futuro onde o JavaScript absorverá o TypeScript. Não apenas há esforços para tornar a digitação inspirada no TypeScript um recurso do JS (“tipos como comentários”), mas também há um grande esforço para transformar o TypeScript em algo como uma etapa de linting no IDE. Esta é a nova abordagem de “remoção de tipo”, com tempos de execução como Node.js substituindo o tipo por espaço em branco em tempo de execução, deixando o JS antigo como executável e eliminando totalmente a complicada etapa de compilação.
Resumindo, o TypeScript está se tornando um linter sofisticado para JavaScript.
SQL supera ORMs
SQL, inventado na década de 1970, foi um avanço monumental no gerenciamento de dados. Juntamente com algumas outras tecnologias fundamentais, ajudou a alimentar o crescimento expansivo da Internet. Mas, ao contrário de outras tecnologias fundamentais como o COBOL, o SQL tem uma característica especial que muitas vezes ignoramos: é uma forma fundamental e irredutível de manipular informações.
É claro que SQL não é o apenas maneira de lidar com dados. Mas as estruturas de dados relacionais nos proporcionam uma abordagem rigorosa e universal. Portanto, é compreensível, embora surpreendente, que o SQL esteja ressurgindo depois que o pêndulo oscilou em direção aos bancos de dados NoSQL e às camadas de mapeamento objeto-relacional (ORMs).
A própria característica que alguns consideram questionável, o rigor esquemático, torna o SQL uma plataforma estável. O SQL agora está chegando ao navegador, via WebAssembly (Wasm), oferecendo um único idioma de dados em toda a rede. O SQL também está retornando à base de código do lado do servidor, com wrappers mais simples como o JOOQ oferecendo acesso mais direto ao SQL do que ORMs como o Hibernate.
Por que? Simplesmente porque as abstrações inevitavelmente acrescentam atrito. É um cálculo arriscado trocar o imediatismo do SQL pelo amplo poder de um ORM.
IDE local supera ambientes de desenvolvimento em nuvem
O IDE em nuvem é o herdeiro óbvio do ambiente de desenvolvimento local. Então, por que ainda estamos grudados em nossos IDEs locais?
Não é inércia. Não é só porque é a isso que estamos acostumados. Parte disso é a mesma mentalidade de “comprar versus alugar” que funciona contra as implantações na nuvem. Parte disso é a sensação altamente pessoal do IDE local.
Mas também é o fato de que os laptops modernos são feras absolutas. Mesmo um laptop empresarial modesto proporcionará ao desenvolvedor iterações IDE extremamente rápidas. Embora os desenvolvedores ainda tendam a confiar em um back-end remoto de IA para suprir a necessidade onipresente de poder de IA, o resto do sistema se ajusta confortavelmente aos recursos locais, onde RAM e SSD fornecem resultados quase instantâneos.
Monolith supera microsserviços
Os microsserviços têm seu lugar. Eles são extremamente poderosos quando a situação os exige. Mas — e é um grande “mas” — eles são um poço de engenharia excessiva e complexidade quando usados quer queira quer não.
Se a frase “depurar Kubernetes” não for suficiente para fazer você estremecer, considere que os microsserviços implicam inerentemente latência de rede em cada borda do serviço. O modelo de servidor monolítico elimina essas duas desvantagens desde o início.
É claro que ainda é necessário arquitetar adequadamente um servidor monolítico, ou a complexidade também sobrecarregará sua implementação. Além disso, temos que reconhecer que abordar a alta disponibilidade e outras questões de QoS aumenta o número de peças móveis. Mas as camadas em camadas da pilha monolítica (dados/serviço/IU) equivalem a um modelo mental muito mais simples.
E não é realmente uma situação “ou/ou”. A maioria dos aplicativos hoje em dia incorporará alguns serviços remotos (sejam aplicativos internos ou aplicativos de terceiros), mesmo quando usar uma pilha central do lado do servidor. Mas a maré mudou e houve uma mudança distinta no ímpeto dos microsserviços em direção ao monólito.
Na prática, é apenas uma questão de identificar o caminho de menor resistência – a complexidade mínima que resolverá o problema – em vez de honrar o que é considerado “o caminho”. O desejo pela simplicidade orienta naturalmente os arquitetos em direção a projetos monolíticos sempre que apropriado.
O caminho feliz supera a integração
Integrar ferramentas bem testadas em um todo coeso é muito mais inteligente do que construir uma solução abrangente e personalizada… não é?
Nos últimos anos, o “Jamstack” (JavaScript, APIs e marcação) e a “pilha de dados moderna” (combinando as melhores ferramentas de gerenciamento de dados baseadas em nuvem) exemplificaram esta filosofia: nunca construa o que você pode alugar. Disseram-nos para misturar e combinar uma dúzia de plataformas SaaS especializadas – uma para autenticação, uma para banco de dados, uma para pesquisa, uma para hospedagem, etc. – e colá-las todas com APIs.
Mas a realidade desta abordagem é um fardo opressivo de integração. Em vez de escrever lógica de negócios, os desenvolvedores seniores passam seus dias escrevendo código cola para manter APIs de terceiros conversando entre si. Quando um serviço atualiza seu SDK, o castelo de cartas distribuído fica instável.
A indústria está agora recorrendo a estruturas de “baterias incluídas”. A filosofia iniciada por Rails e Django, e modernizada por frameworks como Next.js e Spring Boot, está se reafirmando. Isto significa que contamos com um ecossistema altamente opinativo – um “caminho de ouro”. Embora uma metaestrutura como Next.js ou Spring Boot possa não ter seu próprio banco de dados proprietário, ela fornece uma estrutura profundamente integrada (como NextAuth ou Spring Security). Ele oferece aos desenvolvedores um ambiente coeso e pré-conectado. Você ainda traz seu próprio banco de dados ou provedor de autenticação, mas a estrutura elimina totalmente o código de cola frágil.
Após anos de cansaço dos fornecedores, os desenvolvedores estão percebendo que submeter-se a um ecossistema unificado e opinativo é o caminho definitivo para a velocidade.
Metal local vence nuvem
Quando Larry Ellison ridicularizou a “revolução” da nuvem como uma moda passageira… será possível que ele estivesse certo?
Provavelmente não. Mas o entusiasmo com que a indústria pressionou em direção à infraestrutura em nuvem parecia excessivamente extremo. Às vezes parecia quase um culto, como se houvesse algo inerentemente errado em executar processos no ferro que você possui.
É claro que há muitos benefícios na nuvem. Mas a indústria despertou gradualmente para aquela questão eterna e fundamental: “Qual é a ferramenta certa para o trabalho?”
É simplesmente um fato que às vezes é melhor que uma organização execute a computação, o armazenamento e/ou a rede internamente. Há muitas vantagens em executar sistemas no local, como conhecimento interno, controles de custos, faturamento previsível e soberania de dados, que podem fazer pender a balança em relação à necessidade de provisionar e gerenciar seus recursos.
Engenharia especializada vence desenvolvedor full-stack
Isso não é novidade. Não é possível dominar todos os aspectos da hidra multifacetada conhecida como desenvolvimento web. A descrição típica do trabalho de um desenvolvedor full stack parece um departamento de TI inteiro. Isso simplesmente não é humanamente possível. Se você entender o layout da grade CSS como a palma da sua mão, isso tirará o conhecimento do design do banco de dados da memória ativa.
Naturalmente, existem sábios por aí que tocam bateria, violão e trompete e cantam lindamente. Mas para a maioria de nós, isso simplesmente não é possível. Precisamos contar com outros para preencher as lacunas. Quer essa ponte seja um agente de IA, outra pessoa ou uma biblioteca, podemos compor de forma inteligente uma pilha completa usando esses recursos.
Quando alguém se tornar um engenheiro sênior, ele terá em mãos muitas partes diferentes do cenário de ferramentas de tecnologia de software. Isso é obviamente altamente valioso. Nesse sentido, você poderia chamá-los de engenheiros “full-stack”. Mas o que realmente queremos dizer é que eles têm uma boa compreensão de como todas as partes se articulam e são capazes de combinar as várias partes de forma eficaz.
É também por isso que os verdadeiros desenvolvedores full-stack geralmente não se aposentam. Eles se tornam gerentes.
Wasm vence Docker
Docker foi uma ideia excelente e influente. Faça uma unidade de processamento portátil que você possa colocar em qualquer lugar. Mas, na prática, o Docker pode se tornar bastante complicado e seus arquivos de configuração podem ser complicados. Na verdade, há momentos em que acho todo o modelo mental um pouco desajeitado. Você tem seu software real e suas diversas necessidades ambientais, e há o Docker entre eles como uma camada extra de abstração.
Mas Wasm. Wasm pega seu código e o resume em um binário portátil (análogo a um executável nativo). Bam! É isso. É o mesmo nível de franqueza de executar um .exe no DOS na década de 1990. Simples.
E, é rápido. Enquanto o Docker precisa inicializar um espaço de usuário Linux e um sistema de arquivos virtualizado, os tempos de execução do Wasm são projetados para sobrecarga mínima. Alguns deles até compilam em código de máquina.
É claro que o Docker é uma parte bem compreendida da empresa, com diversas ferramentas ao seu redor. Continuará a ser uma ferramenta importante. Mas o Wasm ganhou impulso após a fase experimental e agora está se tornando uma inovação verdadeiramente disruptiva.
Java vence Node, Go, Rust, et al.
Java, de trinta anos, ganhou a reputação de ser uma espécie de relíquia. Era um gigante pesado, prolixo e pesado, diziam as pessoas. Quem precisa do “Java antigo” ou do “Java vovô” quando temos ecossistemas modernos como Node.js para E/S assíncrona, Go para simultaneidade leve e Rust para velocidade pura, pensaram as pessoas.
Mas acontece que o vovô sabe o que está fazendo.
Claro, reclamações como a necessidade de public static void main apenas para executar um pequeno programa são perfeitamente legítimos. Mas olhe mais de perto e você encontrará recursos de última geração. Em particular, o que torna o Java um rolo compressor do lado do servidor são os threads virtuais (junto com atualizações relacionadas, como simultaneidade estruturada). Threads virtuais empurram o threading para a JVM, onde a plataforma os manipula para você. Isso torna a simultaneidade um serviço semelhante ao gerenciamento de memória.
Threads virtuais permitem que os servidores Java sejam dimensionados para potencialmente milhões de solicitações paralelas com uma única alteração de importação. Além disso, os threads virtuais são totalmente compatíveis com as APIs de threads mais antigas.
Estranhamente, a linguagem obrigatória de 2026 pode ser aquela inventada na década de 1990.
Tenha a mente aberta
Meu conselho, como um velho velhinho balançando na cadeira de balanço da varanda, é manter a mente aberta. Quando comecei a programar aplicativos da web, parecia que CGI e Perl continuariam sendo os reis da colina.
Fiquem ágeis aí, pessoal. E não deixe de experimentar o HTML. Você encontrará um guia prático para começar aqui.
