30 anos da web vistos pela tag `<br>`

• Um texto que organiza como o desenvolvimento web evoluiu, acompanhando as mudanças da web estática dos anos 1990, passando pela web centrada em JavaScript dos anos 2010, até a web da era da IA nos anos 2020
• A web, que começou com a tag <br> e FTP, expandiu-se rapidamente como uma plataforma que qualquer pessoa podia criar, passando por PHP e MySQL
• Nos anos 2000, com Rails, Git e Heroku como marcos, o desenvolvimento web foi reorganizado como uma indústria estruturada, automatizada e centrada em colaboração, lançando as bases da era da nuvem e dos dispositivos móveis
• Nos anos 2010, o surgimento de React, das build chains, do Docker e do ecossistema Node consolidou a web não como um conjunto de documentos, mas como uma verdadeira plataforma de aplicações
• Nos anos 2020, ChatGPT e Copilot mudaram a forma de escrever código, tornando-se um novo ponto de virada em que a IA amplia a produtividade no desenvolvimento
• Todas essas mudanças, ao custo de mais complexidade, levaram a um processo de popularização da web que permite que mais pessoas criem coisas maiores

---

The Static Web - a era da web estática

"View Source was how you learned"

• No fim dos anos 1990 (late 90s), a web era uma fronteira em que ninguém sabia ao certo no que ela se tornaria, e essa própria incerteza fazia parte do seu fascínio
• Sites pessoais começavam não em empresas ou organizações, mas em servidores pessoais e diretórios individuais
  • Com um diretório pessoal em um servidor Unix, arquivos HTML e um cliente FTP, já era possível ter um espaço na internet
  • Dava para escrever em um editor de texto simples como o Notepad e publicar imediatamente
• A web dessa época era um espaço criativo sem censores nem processos de aprovação
  • Publicações livres centradas em interesses como culinária, dinossauros e música
  • Uma estrutura em que era possível postar imediatamente “o que te interessava naquela semana”
• A forma de aprender era totalmente baseada em ver e imitar diretamente
  • Não existiam tutoriais no YouTube nem Stack Overflow
  • Se você queria entender outro site, o caminho padrão era clicar com o botão direito → View Source
  • Para conteúdos mais profundos, aprendia-se com livros físicos de verdade
• Era comum estudar com livros técnicos de centenas de páginas, como Core Java, alternando entre o código e o livro
  • Era mais lento, mas o conhecimento tendia a permanecer por mais tempo
• O HTML era uma mistura de estrutura e estilo
  • As tags <table>, <font> e <center> cuidavam ao mesmo tempo do layout e da aparência
  • O espaçamento era ajustado com GIFs transparentes 1x1 (spacer GIF)
  • Era grosseiro e ineficiente, mas funcionava
• CSS existia, mas na prática ainda não era dominante
  • A maior parte do estilo era feita com atributos inline ou com as próprias tags HTML
  • O layout era resolvido com tabelas aninhadas
• Recursos dinâmicos tinham uma barreira de entrada extremamente alta
  • Até funções básicas como livro de visitas e contador de acessos exigiam scripts CGI
  • Era preciso escrever em Perl ou C, e até processar um único parâmetro de URL demandava muito código
  • Essa complexidade limitava fortemente a disseminação da web dinâmica
• Quase não havia solução para o problema de layout compartilhado
  • Cabeçalho, navegação e rodapé eram copiados e colados em todos os arquivos HTML
  • Qualquer alteração exigia editar todos os arquivos
  • Também havia a prática de inserir elementos comuns com <iframe>, mas com muitos efeitos colaterais
• A compatibilidade entre navegadores já era um problema sério
  • Netscape Navigator (1994) e Internet Explorer (1995) exibiam resultados de renderização diferentes
  • Avisos especificando navegador e resolução recomendados eram realmente necessários
• Mesmo assim, a web dessa era tinha um poder de atração enorme
  • Era possível publicar para o mundo inteiro sem precisar de equipamentos de impressão ou transmissão
  • A web foi a primeira a concretizar a democratização dos meios de expressão
• Serviços de hospedagem gratuita como GeoCities (1994) e Angelfire (1996) ofereceram espaço de criação para milhões de pessoas
  • Fan sites e comunidades se conectavam por meio de web rings
  • Formou-se um ecossistema caótico, mas vivo
• Nas empresas, o conceito de “equipe web” ainda praticamente não existia
  • Quando havia um site, na maioria dos casos ele era feito por “a pessoa que entendia de computador”
  • Era a fase imediatamente anterior a o desenvolvedor web se consolidar como profissão
• As ferramentas eram primitivas e os sites, toscos, mas
  • foi nessa época que a ideia central de um espaço onde qualquer pessoa pode criar e compartilhar criou raízes
• Essa era, sustentada pela tag <br> e pela paixão, tornou-se o ponto de partida para toda a evolução posterior da web

A stack LAMP e a Web 2.0

"Everything was PHP and MySQL"

• Mesmo após o estouro da bolha das pontocom em 2000, a web continuou crescendo, e esse período se tornou um ponto de virada em que a barreira de entrada caiu drasticamente para quem queria criar alguma coisa
• O maior avanço da era da web estática foi o PHP (1995)
  • Na época em que era preciso escrever centenas de linhas em C ou Perl para CGI, a experiência de ler parâmetros de URL com uma única linha, $_GET['name'], foi uma mudança decisiva
  • Funcionava só com salvar e recarregar, sem compilação, gerenciamento de memória ou mensagens de erro crípticas
  • O XAMPP (2002) revolucionou a simplicidade de montar um ambiente de desenvolvimento local ao permitir instalar Apache, MySQL e PHP de uma vez
  • O PHP foi o primeiro a resolver de fato o problema de reutilização de layout da era da web estática
    • Com uma linha, include 'header.php', era possível gerenciar cabeçalhos e rodapés comuns
    • A sensação de mudar o site inteiro com uma única alteração era empolgante
  • Apesar das falhas da linguagem, a força do PHP era a acessibilidade
    • HTML e lógica ficavam misturados, os nomes de funções não eram consistentes e as APIs de segurança eram precárias, mas
    • dava para aprender no fim de semana e colocar um serviço real no ar
    • Com hospedagem compartilhada (US$ 5/mês), cPanel (1996) e phpMyAdmin (1998) já incluídos por padrão, a barreira de entrada para publicar online caiu ao nível mais baixo da história
• O banco de dados que na prática vinha junto com o PHP era o MySQL (1995)
  • Quase todos os tutoriais, hospedagens e CMS eram estruturados com MySQL como pressuposto
  • Em termos de funcionalidade, era suficiente, mas o tratamento de texto internacionalizado era uma dor sem fim
  • A codificação padrão era latin1, e para usar UTF-8 direito era preciso
    • alinhar a configuração do banco de dados, a codificação da conexão e a declaração de charset no HTML
  • O problema do “ä em vez de ä” ficou como um trauma simbólico dessa era
• O WordPress (2003) mudou a própria natureza da web
  • Mesmo sem saber programar, era possível instalar em 5 minutos e começar a publicar na hora
  • Dava para operar um site só escolhendo um tema e escrevendo posts
  • Na prática, concretizou a popularização da criação de sites
  • Para usuários não técnicos, o WordPress foi uma libertação
    • Bloggers, pequenos comerciantes, artistas e até restaurantes passaram a poder ter um site
    • Surgiu uma nova identidade: "blogueiro"
    • O painel administrativo do WordPress se disseminou a ponto de ser percebido como o próprio “editor de sites”
  • Para desenvolvedores, o WordPress virou uma ferramenta quase universal
    • Blog, portfólio, site corporativo, comunidade, comércio eletrônico: tudo era WordPress
    • Com o WooCommerce (2011), absorveu também o e-commerce
    • Em troca da implementação rápida, acumulou-se dívida técnica baseada em excesso de plugins e customização de temas
• O acontecimento que redefiniu de forma fundamental as possibilidades da web foi o lançamento do Gmail (2004)
  • Numa época em que Hotmail e Yahoo Mail ofereciam alguns MB de armazenamento
  • 1 GB de armazenamento gratuito foi um número chocante
  • A mensagem “não apague, pesquise” propôs uma nova forma de usar e-mail
  • A verdadeira inovação do Gmail não era o armazenamento, mas a experiência
    • Uma interface que permitia ler, escrever e alternar entre e-mails sem recarregar a página
    • Uso total de comunicação assíncrona baseada em AJAX (XMLHttpRequest)
    • Provou que a web podia ser não apenas um documento, mas um aplicativo
• O Google Maps (2005) levou essa possibilidade um passo além
  • Mover o mapa com clique e arrasto
  • Interação natural com carregamento de tiles em segundo plano
  • Foi nesse momento que o termo Web 2.0 realmente se consolidou
  • Interface sem recarregamento, cantos arredondados, gradientes e sombras viraram a linguagem básica da web
• Mudanças decisivas também continuaram nas áreas de mídia e social
  • No vídeo, o YouTube (2005) mudou o jogo
    • Fim do inferno de plugins como RealPlayer, QuickTime e Windows Media Player
    • Era baseado em Flash, mas oferecia a experiência de “clicar e reproduzir na hora”
    • Vídeo deixou de ser um problema técnico para se tornar um meio de expressão
  • O Twitter (2006) apresentou uma nova forma de comunicação com o microblog de 140 caracteres
  • O Facebook (2006) foi aberto ao público geral, levando as redes sociais ao mainstream
  • A web passou de mídia de consumo para plataforma participativa
    • Formou-se uma estrutura em que qualquer pessoa podia ser publicadora e criadora
• Apesar de todas essas mudanças, o JavaScript ainda era doloroso
  • Debugging interminável por causa das diferenças de implementação de DOM, eventos e AJAX entre navegadores, além dos problemas de compatibilidade com IE6
  • O jQuery (2006) praticamente encerrou esse caos
    • $('#el').hide() funcionava igual em todos os navegadores
    • $.ajax() simplificava a comunicação assíncrona
    • Para muitos desenvolvedores, jQuery era o próprio JavaScript
      • Ao mesmo tempo, também servia como amortecedor que evitava compreender diretamente como o navegador funcionava
  • Os problemas dessa era só foram reconhecidos como problemas mais tarde
    • SQL Injection e XSS eram disseminados até no nível de tutoriais
    • Era comum código que concatenava diretamente a entrada do usuário em queries
• O controle de versão era dominado pelo Subversion (2000)
  • Commits eram pesados e branches eram evitadas
  • Nomes de pasta como final_final_REAL eram coisa do dia a dia
• Não havia padronização do ambiente de execução
  • Local: Windows + XAMPP
  • Servidor: Linux + outra versão de PHP
  • “works on my machine” se repetia sem parar
• Também não existia o conceito de gerenciador de pacotes
  • Em JS, fazia-se download de ZIP e o gerenciamento era manual na pasta /js
  • Bibliotecas PHP eram copiadas na base do arquivo por arquivo
• A estrutura de equipe e o processo de desenvolvimento eram muito informais
  • Quase não existiam papéis de PM ou EM
  • Não havia code review
  • Fazia-se upload por FTP e a mudança já entrava em produção
  • Quando havia incidente, corrigia-se direto no servidor de produção, no improviso
• Ainda assim, a energia dessa era era intensa
  • Com PHP e hospedagem barata, qualquer um podia fazer deploy
  • Espalhou-se a sensação de que com AJAX dava para criar “apps de verdade”
  • Com as plataformas sociais, qualquer um podia ter audiência
• Era o momento em que a profissionalização e a estruturação do desenvolvimento web estavam apenas começando
  • O Ruby on Rails (2004), com “Convention over Configuration”, anunciava a próxima era, mais estruturada
• Os desenvolvedores dessa época construíam a web com a stack LAMP, plugins de jQuery e,
  • sob a expectativa de “criar o próximo grande serviço”

A guerra dos frameworks

"Rails changed everything, then everyone copied it"

• Final dos anos 2000 (late 2000s): conforme as aplicações web cresceram em escala, os scripts PHP tradicionais e as estruturas centradas em trabalho manual chegaram ao limite

• Como resposta para esse momento, o desenvolvimento centrado em frameworks ganhou força, e quem definiu esse movimento foi o Ruby on Rails (2004)

  • A influência real do RoR passou a se intensificar de fato por volta de 2007–2008
  • Com a filosofia de "Convention over Configuration", o framework passava a decidir a estrutura de arquivos, convenções de nomenclatura e formas de conexão
  • Bastava ao desenvolvedor seguir as regras, e isso foi visto não como restrição, mas como uma libertação que trazia velocidade

• O Rails reuniu de uma vez conceitos que depois se tornariam a gramática básica do desenvolvimento web

  • Migrações para gerenciar alterações no banco de dados por código
  • ORM para reduzir drasticamente a dependência de SQL
  • Um fluxo de desenvolvimento com testes incluídos por padrão
  • A padronização prática da arquitetura MVC (Model–View–Controller)
  • MVC era um conceito originado no Smalltalk dos anos 1970, mas foi com o Rails que se consolidou como forma básica do desenvolvimento web
  • Depois do sucesso do Rails, quase todo ecossistema de linguagem passou a adotar essa fórmula
    • Django (2005) no Python e Laravel (2011) no PHP consolidaram a estrutura ao estilo Rails
    • CakePHP (2005) e CodeIgniter (2006) também evoluíram dentro da mesma corrente
  • O aumento de produtividade não era exagero
    • O que um desenvolvedor individual conseguia criar em um fim de semana antes equivalia a trabalho de equipe
    • Em ambientes de startup, isso funcionava como a ferramenta ideal para experimentar rápido e iterar
  • Na prática, vários serviços emblemáticos cresceram sobre Rails
    • Basecamp (2004), Twitter (2006), GitHub (2008), Shopify (2006), Airbnb (2008)
    • O Rails logo passou a ser visto como um símbolo da velocidade das startups

• Os frameworks elevaram a produtividade, mas a implantação continuava sendo um gargalo

  • Na era do PHP, fazer deploy por FTP era o normal, e um único erro podia derrubar o serviço
  • Mesmo nos casos melhores, tarefas como SSH + SVN pull + reiniciar o Apache eram feitas manualmente
  • Separar diretórios de release e trocar links simbólicos, entre outras práticas, fazia com que todo o processo fosse customizado e frágil

• Quem mudou esse problema de forma fundamental foi o Heroku (2007), que começou a se espalhar de fato por volta de 2009–2010

  • Entregou a experiência de concluir um deploy com uma única linha: git push heroku main
  • A plataforma passou a cuidar da configuração do servidor, reinício do servidor web e escalabilidade
  • O Heroku acabou consolidando na prática o conceito que depois seria chamado de PaaS (Platform as a Service)
    • O papel do desenvolvedor mudou para focar apenas no código, e não na infraestrutura
    • Ao popularizar os princípios do Twelve-Factor App (2011), difundiu uma mentalidade voltada à nuvem, com processos stateless, configuração via variáveis de ambiente e logs em fluxo contínuo

• No mesmo período, também ocorreu uma grande transformação na forma de colaborar

  • O Git (2005) introduziu um modelo distribuído de controle de versão que permitia commits, branches e merges livres no ambiente local, e como o custo de criar branches era quase zero, experimentar e voltar atrás virou algo cotidiano
  • O antigo Subversion (2000) tinha uma estrutura centralizada, branches pesados e merge era motivo de medo, então muitas equipes dependiam de desenvolvimento centrado no trunk
  • O Git foi uma inovação no nível da ferramenta, mas foi o GitHub (2008) que transformou isso em cultura ao combinar exploração de repositórios públicos, desenvolvimento baseado em fork e colaboração centrada em Pull Requests
  • O GitHub padronizou a cultura de code review
    • Antes de fazer merge de um PR, alguém necessariamente precisava revisar o código
    • Esse fluxo também se espalhou para o desenvolvimento interno das empresas
    • Era o fim da época em que o código ia direto para produção
  • A forma de contribuir com open source deixou de ser enviar patches por mailing lists e passou a ser submeter PRs com um clique, reduzindo muito a barreira de entrada

• No fim desse período, também surgiram mudanças que abalaram a identidade da web

  • Com o lançamento do iPhone (2007) e da App Store (2008), os apps nativos dispararam
  • A web móvel naquela época era muito precária. A experiência era basicamente tentar ver sites de desktop encolhidos, com rolagem horizontal e repetidas ações de zoom in e zoom out
    • Alguns criaram sites móveis separados, como m.example.com, mas as limitações eram claras
  • Os apps nativos eram rápidos, funcionavam offline, ofereciam notificações push e, com o slogan "There’s an app for that", pareciam o futuro
  • Os desenvolvedores web começaram a viver uma crise de identidade: ainda valia a pena continuar na web? Era preciso aprender Objective-C? A web iria desaparecer?

• Como resposta a essa confusão, surgiu o Responsive Web Design (2010)

  • Ethan Marcotte (2010) propôs usar media queries de CSS para ajustar o layout ao tamanho da tela, apontando para uma direção em que mobile e desktop seriam unificados em uma única base de código
  • No começo, a adoção foi lenta por causa da imaturidade das ferramentas e do trabalho extra, mas a direção que a web precisava seguir ficou clara

• O Bootstrap (2011) foi o gatilho que levou o design responsivo ao uso real no dia a dia

  • Começando como uma ferramenta interna do Twitter, ele oferecia de uma vez sistema de grid, tipografia básica e estilos de formulário, permitindo que até desenvolvedores sem designer tivessem uma UI utilizável imediatamente
  • Como resultado, a web começou a parecer cada vez mais igual, mas para muitos desenvolvedores o Bootstrap foi a primeira experiência com biblioteca de componentes e sistema de design
  • Esse movimento depois levaria à difusão de sistemas de design mais estruturados, como o Material Design (2014)

• A infraestrutura também mudou rapidamente nesse mesmo período

  • Em vez de comprar ou alugar servidores físicos antecipadamente, o modelo passou a girar em torno de servidores virtuais (VPS), tornando possível criar recursos de servidor conforme a necessidade
  • A AWS (2006) surgiu primeiro, mas sua complexidade e perfil voltado ao mercado corporativo pesavam para desenvolvedores individuais
  • A DigitalOcean (2011), com droplets de US$ 5, interface intuitiva e experiência rápida de criação de servidores, reduziu muito a barreira de acesso à infraestrutura e deu a desenvolvedores independentes uma flexibilidade parecida com a das grandes empresas

• O problema de armazenamento de arquivos foi praticamente resolvido pelo Amazon S3 (2006)

  • Ele oferecia um modelo simples: armazenamento escalável independentemente da quantidade de servidores e retorno imediato de URL após o upload
  • Problemas com uploads de usuários, backups e gerenciamento de arquivos em ambientes com múltiplos servidores puderam ser resolvidos de uma vez

• O Node.js (2009) trouxe outro choque para os desenvolvedores web

  • Com base no motor V8 do Chrome, tornou possível executar JavaScript no servidor, o que pareceu uma opção atraente para desenvolvedores de frontend e provocou reações céticas em desenvolvedores de backend
  • Seu modelo de I/O não bloqueante mostrou força em aplicações em tempo real, e a maioria dos tutoriais acabava em exemplos de aplicativos de chat
  • Nessa época, o Node ainda era mais objeto de curiosidade do que mainstream em produção; os serviços reais continuavam centrados em Rails, Django e PHP, e o ecossistema do npm ainda estava em estágio inicial
  • Ainda assim, o impacto real do Node apareceria primeiro não no servidor, mas como base de execução para ferramentas de build e ambientes de desenvolvimento

• Na área de bancos de dados, a onda NoSQL ganhou força

  • O MongoDB (2009) chamou atenção com seu modelo de dados baseado em documentos, flexibilidade de schema e estrutura amigável a JSON
  • Ele tinha vantagens em prototipagem rápida, escalabilidade e compatibilidade com a stack JavaScript, mas não era adequado para todos os serviços
  • Também eram comuns os casos em que ele era escolhido pelo motivo de "talvez um dia precise escalar", mas os limites de transação já apareciam quando o serviço chegava a alguns milhares de usuários

• O ecossistema de startups entrou, nesse período, em uma fase de crescimento de verdade

  • Com a declaração de Marc Andreessen (2011), "Software is eating the world", e a difusão da metodologia Lean Startup (2011), consolidou-se o ciclo MVP → medir → iterar

• Com o amadurecimento das ferramentas, a competitividade de equipes pequenas começou de fato a funcionar

• O processo de desenvolvimento também mudou

  • Agile Manifesto (2001) e Scrum se popularizaram, e práticas como stand-up, sprint e retrospectiva passaram a ser adotadas quase como padrão
  • Também surgiram muitas equipes em que restou apenas a forma, e não os princípios
  • Revisão de código e testes automatizados passaram de recomendação a expectativa básica, e sistemas de CI executando testes a cada commit aceleraram a profissionalização e a especialização do desenvolvimento de software

• Ainda assim, funções hoje consideradas óbvias ainda não estavam estabelecidas

  • Em 2012, era comum haver equipes sem engineering manager, product manager ou uma gestão sistemática de backlog e tickets
  • Equipes pequenas e estruturas organizacionais horizontais eram comuns, e não era raro que um “desenvolvedor sênior” tivesse apenas 3 anos de experiência

• Por volta de 2013, a web já tinha uma cara completamente diferente

  • Frameworks poderosos, deploy fácil, colaboração social em código, suporte a mobile, infraestrutura barata e a expansão total do JavaScript aconteceram ao mesmo tempo
  • A web, após superar a crise do mobile, ficou ainda mais forte e concluiu sua preparação para a próxima fase: a era em que o JavaScript dominaria tudo

Renascença do JavaScript

"Everything is a SPA now"

• Por volta de 2013, a web já havia provado, com casos como Gmail e Google Maps, que era capaz de suportar “aplicações de verdade”, mas a abordagem tradicional de jQuery + renderização no servidor começou a esbarrar cada vez mais em seus limites :contentReference[oaicite:0]{index=0}
• O problema central era o gerenciamento de estado (state)
  • Em uma estrutura em que o servidor gerava HTML e o jQuery acrescentava interatividade, tornou-se rapidamente difícil manter dados e UI de forma consistente em vários pontos
  • À medida que o mesmo estado precisava ser refletido em várias partes da interface, como comentários, contadores e badges de notificação, o código se enroscava e virava uma estrutura espaguete
• A conclusão comum para isso foi: vamos mover toda a renderização para o cliente
  • O servidor passou a ser reduzido ao papel de API que retorna JSON
  • Ganhou força a arquitetura de SPA (Single Page Application), em que o JavaScript no navegador gerencia toda a UI
• Os primeiros frameworks de SPA surgiram nesse período
  • Backbone.js (2010) oferecia uma estrutura mínima com os conceitos de modelo e view
  • Angular (2010) tentou uma abordagem mais corporativa ao introduzir data binding bidirecional e injeção de dependência
  • Ember.js (2011) propôs regras fortes com o objetivo de ser o “Rails do JavaScript”, incluindo roteamento, dados e templates
  • Esses frameworks representaram um avanço, mas em comum não resolveram completamente a complexidade de sincronizar DOM e dados
    • Em especial, o binding bidirecional dificultava rastrear o fluxo de atualizações e aumentava o custo de depuração
• O ponto de virada foi a chegada do React (2013)
  • Quando o Facebook o lançou como open source, a sintaxe JSX causou rejeição por parecer inverter a separação de responsabilidades
  • Mas o React apresentou uma nova forma de pensar: em vez de manipular o DOM diretamente, descrever declarativamente o resultado da UI com base no estado
  • O núcleo do React é o modelo declarativo e o Virtual DOM
    • Quando o estado muda, o React calcula e aplica apenas as alterações mínimas no DOM
    • O desenvolvedor pode focar no gerenciamento de estado sem se preocupar com manipulação direta do DOM
  • O conceito de componentes também foi decisivo
    • A UI passou a ser composta pela combinação de pequenas unidades como Button, UserAvatar e CommentList
    • Cada componente pode ser pensado de forma independente e reutilizado
  • O React se espalhou gradualmente e por volta de 2015 se consolidou como mainstream
    • Vue.js (2014) surgiu como alternativa, oferecendo conceitos semelhantes com uma sintaxe mais familiar
    • A guerra dos frameworks entrou em uma nova fase
• A disseminação das SPAs significou um aumento explosivo na quantidade de JavaScript
  • O problema era que o JavaScript que os desenvolvedores queriam escrever era diferente do JavaScript que os navegadores entendiam
• ES6 / ES2015 (2015) introduziu grandes melhorias na linguagem, como arrow functions, classes, módulos e promises
  • O inferno dos callbacks e o padrão var self = this desapareceram, e o JavaScript finalmente começou a parecer uma linguagem moderna
• No entanto, o suporte dos navegadores ficou para trás, e fazer deploy disso como estava era impossível
• Babel (2014) resolveu esse problema como um transpiler que converte JavaScript moderno em ES5
  • Em troca, a etapa de build se tornou parte obrigatória do desenvolvimento em JavaScript
  • Era o fim da era em que bastava editar um arquivo e recarregar a página
• Nesse processo, o Node.js (2009) passou a dominar todas as máquinas de desenvolvedores não como servidor, mas como ambiente de execução de ferramentas de desenvolvimento
  • Mesmo sem usar Node no backend, instalar Node se tornou obrigatório por causa das ferramentas de build
• A cadeia de ferramentas de build também evoluiu rapidamente
  • Grunt (2012) gerenciava etapas complexas de build por meio de arquivos de configuração como task runner
  • Gulp (2013) tentou simplificar isso com pipelines baseados em código, mas ainda era complexo
• A mudança decisiva veio com o Webpack (2014)
  • Não era apenas um task runner, mas um module bundler capaz de entender o grafo de dependências
  • JavaScript, CSS, imagens e fontes passaram a ser tratados como módulos
  • Introduziu conceitos como code splitting e hot module replacement
  • O preço do poder foi uma configuração de fama terrível
    • A configuração do Webpack virou meme, e em cada equipe havia “uma pessoa que entendia isso”
    • Quando essa pessoa saía, a configuração virava uma relíquia da qual todos tinham medo de mexer
• Ao mesmo tempo, o ecossistema npm cresceu de forma explosiva
  • Saiu de cena o modelo de baixar bibliotecas manualmente, e entrou o fluxo centrado em npm install
  • moment, lodash e até utilitários minúsculos como left-pad viraram pacotes
  • O incidente do left-pad (2016) expôs a fragilidade do ecossistema
    • A exclusão de um pacote com apenas 11 linhas fez o build de milhares de projetos falhar ao mesmo tempo
    • Até React e Babel ficaram impossíveis de instalar
    • O npm conteve a situação restaurando o pacote à força, algo sem precedentes
  • A conveniência permaneceu, mas todos passaram a reconhecer a realidade do inferno das dependências
• Em 2016, a complexidade chegou ao auge
  • O texto satírico “How it feels to learn JavaScript in 2016” se espalhou
  • Também cresceu o cansaço com a ideia de que era preciso uma infinidade de ferramentas, como React, Webpack, Babel e Redux, para criar uma simples página web
  • A velocidade das mudanças no ecossistema era tão alta que o conhecimento aprendido ficava obsoleto rapidamente
  • Ainda assim, os resultados eram claros
    • Tornou-se possível criar aplicações web interativas em um nível que antes era inviável
    • A complexidade passou a ser aceita como o custo da ambição
• Enquanto isso, o Docker (2013) começou a resolver um problema completamente diferente
  • Resolveu com contêineres o problema do “works on my machine”
  • Com Dockerfile, tornou-se possível definir o ambiente de execução e rodar da mesma forma em qualquer lugar
  • No começo, a adoção não foi fácil por causa de problemas de desempenho no Mac e da confusão com rede
    • Docker Compose, Docker Swarm e depois o Kubernetes (2014) surgiram, dando início à guerra da orquestração
    • Por volta de 2017, ao menos uma coisa já estava clara: os contêineres eram o futuro
• Junto com isso, a tendência de microsserviços se espalhou
  • Trouxe vantagens como separação de serviços e deploy independente
  • Em troca, gerou novas complexidades, como service discovery, load balancing e rastreamento distribuído
  • Muitas equipes só depois perceberam que haviam trocado a complexidade do monólito pela complexidade dos sistemas distribuídos
• Nesse período, a qualidade das aplicações web subiu visivelmente
  • O Slack (2013) substituiu o e-mail como ferramenta de colaboração rápida e pesquisável
  • O Figma (2016) invadiu o território dos aplicativos desktop com uma ferramenta de design colaborativo baseada no navegador
  • Junto com o Notion (2016) e outros, provou que a web podia implementar software de nível desktop
  • Esses casos serviram de justificativa para a complexidade de React, Webpack e da cadeia de build
• A estrutura organizacional também entrou em uma fase de maturidade
  • Por volta de 2016, product manager e engineering manager se consolidaram como papéis padrão
  • A antiga estrutura horizontal das equipes foi gradualmente dando lugar a organizações mais orientadas a processos
  • Scrum e os rituais ágeis se difundiram amplamente e, dependendo da equipe, viraram ferramenta ou mera formalidade
• Em 2017, o ecossistema começou a entrar lentamente em uma fase de estabilização
  • O React se tornou, de fato, o vencedor
  • ES6 virou a sintaxe padrão
  • Webpack e Docker passaram a ser aceitos como padrão, ainda que dolorosos
• A próxima etapa já estava anunciada
  • A ascensão do TypeScript
  • Meta-frameworks como Next.js
  • Uma experiência de deploy mais simples
• Mas havia uma condição
  • Só os desenvolvedores que atravessaram o caos dessa Renascença do JavaScript puderam avançar para a etapa seguinte

Era TypeScript

"Types are good, actually"

• Depois do renascimento do JavaScript, a proliferação descontrolada de ferramentas diminuiu, e o TypeScript se consolidou como ponto de virada para a entrada do ecossistema em uma fase de maturidade
• TypeScript (2012) introduziu tipagem estática no JavaScript, mas no começo foi ignorado por muito tempo por causa da filosofia das linguagens dinâmicas e do custo adicional de uma etapa de build
  • À medida que as aplicações cresciam, os limites da tipagem dinâmica ficavam cada vez mais claros
    • aumento do custo para rastrear pontos de chamada após mudanças na assinatura de funções
    • problemas de legibilidade em códigos nos quais era difícil entender a forma dos objetos
    • casos recorrentes em que erros simples de digitação causavam falhas em produção
  • A partir de 2017–2018, a adoção do TypeScript se espalhou rapidamente
    • maior segurança em refatorações com autocompletar e análise estática
    • as interfaces passaram a atuar como documentação obrigatória sincronizada com o código
  • A adoção pelos principais frameworks funcionou como ponto de inflexão
    • Angular adotou uma estratégia focada em TypeScript
    • com o amadurecimento das definições de tipos do React e a reescrita do Vue 3 com base em TypeScript, ele passou a ser visto como padrão de fato
    • por volta de 2020, quase não se escolhia mais JavaScript puro para novos projetos
  • O TypeScript melhorou bastante a acessibilidade do codebase
    • novos integrantes conseguiam entender o modelo de domínio apenas lendo as definições de tipos
    • a menor dependência de conhecimento implícito reduziu o custo de escalar equipes
• A combinação com o VS Code (2015) mudou de forma decisiva a experiência de desenvolvimento
  • oferecia autocompletar inteligente, exibição inline de erros e refatorações confiáveis
  • Sublime Text e Atom foram perdendo influência gradualmente
• Formou-se outra camada de abstração sobre o React
  • como biblioteca de UI, o React não tinha uma solução padrão para roteamento, data fetching e SSR
• Next.js preencheu essa lacuna como um meta-framework que oferecia por padrão roteamento baseado em arquivos, server-side rendering, rotas de API e code splitting automático
  • surgiram diversos frameworks em resposta, como Nuxt, Remix, SvelteKit e Gatsby
  • no ecossistema React, o Next.js se estabeleceu como a escolha padrão de fato
• Com a disseminação dos meta-frameworks, a fadiga da fragmentação de tooling da era anterior foi bastante reduzida
  • o processo de montar manualmente configurações de webpack e Babel foi absorvido pelos padrões padrão
• O ambiente de deploy também ficou muito mais simples
  • Vercel e Netlify passaram a oferecer deploy automático e ambientes de preview apenas conectando ao GitHub
  • designers, PMs e QA puderam verificar mudanças em ambiente real antes do merge
• A influência do Heroku enfraqueceu, enquanto PaaS de nova geração como Railway e Render ganharam força
• O conceito de Serverless se espalhou em torno do AWS Lambda (2014)
  • oferecia cobrança por uso e escalabilidade automática
  • não era uma solução universal por causa de cold start, gerenciamento de estado e limitações de debugging
  • Cloudflare Workers expandiu isso com um modelo de execução na edge
• Também houve uma transição silenciosa na área de CSS
  • depois de Sass e Less, e passando por CSS-in-JS, o Tailwind CSS (2017) foi adotado em massa
  • a abordagem baseada em classes utilitárias
    • eliminou o peso de nomear classes
    • reduziu problemas de cascade e specificity
    • e, como resultado, ajudou a manter stylesheets menores
• GraphQL (2015) chamou atenção como solução poderosa em aplicações que lidavam com estruturas de dados complexas
  • oferecia vantagens como consultas exatas de dados, schema baseado em tipos e um bom ecossistema de ferramentas
  • por causa da complexidade da camada de servidor e da dificuldade de cache, acabou sendo uma escolha excessiva para CRUD simples
  • algumas equipes mantiveram REST ou escolheram alternativas mais simples, como tRPC
• A disputa em orquestração de contêineres terminou, por volta de 2018, com a vitória do Kubernetes
  • era poderoso, mas vinha com alto custo de aprendizado e complexidade operacional
  • para muitas equipes era uma solução exagerada, o que ajudou a explicar a volta do PaaS
• A COVID (2020) ampliou rapidamente a demanda por desenvolvimento web
  • trabalho remoto, e-commerce e ferramentas de colaboração se tornaram essenciais
  • isso levou a uma explosão na demanda por desenvolvedores e ao crescimento acelerado de empresas de ferramentas para desenvolvimento
• Em ambientes remotos, a importância da colaboração assíncrona e da documentação aumentou
  • code review, descrições de PR e qualidade da documentação interna passaram a ser fatores centrais
• Também houve amadurecimento no nível organizacional
  • consolidação de estruturas de níveis de engenharia
  • legitimação da trilha de IC
  • diferenciação dos papéis de PM, EM e tech lead
• Developer Experience (DX) passou a ser vista como alvo de investimento próprio
  • times de plataforma interna, CI rápido e melhoria de onboarding se tornaram elementos centrais de produtividade
• Por volta de 2022, o desenvolvimento web chegou a um estado complexo, mas administrável
  • TypeScript como padrão
  • ecossistema centrado em Next.js
  • automação de deploy e tooling maduro
• E então tudo mudou: uma empresa chamada OpenAI lançou algo chamado ChatGPT

O momento da IA

"Wait, I can just ask it to write the code?"

• Com o lançamento do ChatGPT (2022), surgiu a experiência de simplesmente digitar uma pergunta e receber explicações, código e resultados de debugging, mudando as regras do desenvolvimento
  • ele conseguia ir de explicações sobre física quântica até debugging em Python, e o choque veio do fato de que, embora não fosse perfeito, era bom o suficiente para uso real
  • desenvolvedores começaram a experimentar imediatamente, e escrever componentes React, analisar causas de erros e converter código entre linguagens passou a ser possível em segundos, sem buscar documentação nem vasculhar fóruns
• O GitHub Copilot (2022) levou a geração de código para dentro do editor no formato de autocompletar, espalhando uma experiência de autocompletar extremamente poderosa que sugeria implementações apenas com comentários
  • a nova meta-habilidade de avaliar, aceitar, ajustar e rejeitar rapidamente sugestões de IA surgiu como competência central para desenvolvedores
• Tarefas como boilerplate repetitivo, escrita de testes e tratamento de edge cases ficaram muito mais rápidas, permitindo um desenvolvimento sem quebrar o fluxo
• O Cursor (2023) tornou isso possível em um IDE que integra IA não como recurso, mas como pressuposto, permitindo selecionar código para pedir refatorações, modificar vários arquivos com base em descrições em linguagem natural e conversar com o codebase
• Essa mudança abalou o significado de senioridade, mas na prática aumentou ainda mais a importância da capacidade de decidir o que construir e de avaliar requisitos, restrições e efeitos colaterais
  • a IA consegue escrever código, mas não consegue definir o problema nem escolher a direção correta
• Em versões extremas, houve reações que iam de “o fim da programação” a “uma moda inútil”, mas o resultado real apareceu como amplificação da produtividade de desenvolvedores que usam IA
• A barreira de entrada para projetos pessoais e paralelos caiu drasticamente, e áreas que antes não eram tentadas com facilidade (ML, games, novos frameworks) passaram a ser acessíveis por aprendizado baseado em conversa
• Esse movimento funciona como uma etapa que acelera a antiga direção da web: a democratização da criação
  • o foco se desloca de saber programar para saber o que se quer construir
• Não desenvolvedores também passaram a participar da criação de protótipos, e PMs, designers e especialistas de domínio passaram a criar ferramentas diretamente, fazendo a fronteira entre técnico e não técnico ficar mais difusa
• Com o aumento de indie hackers e solo builders, virou realidade um ambiente em que uma pessoa sozinha também consegue criar produtos de verdade
• Ao mesmo tempo, ferramentas como React Server Components, htmx, padrões aprimorados de CSS e JavaScript e Bun reforçaram a corrente de “vamos usar a própria plataforma”
• Depois do grande boom de contratações em 2022–2023, somado a ondas de reestruturação, o mercado balançou, mas a IA não substituiu desenvolvedores, e a capacidade de usar IA virou expectativa básica
• Em 2025, o desenvolvimento web está no estado mais rápido da história do ponto de vista da ideia ao deploy, e
  • em um ambiente que combina nuvem, frameworks e IA, o indivíduo se tornou um criador mais poderoso do que nunca
• A promessa da web que começou com a tag <br>, de que “qualquer pessoa pode criar e compartilhar”, continua na era da IA de forma ainda mais forte
• Agora é um momento realmente excelente para fazer desenvolvimento web

[ethanhur]

Li como se fosse um livro de história, e foi bem divertido.

[zihado]

Naquela época, eu assinava uma hospedagem de servidor na Cafe24, instalava o Zeroboard e brincava de montar o que eu considerava uma comunidade, rs

[lethee]

Li com prazer. Deu uma sensação de retrospectiva da vida passando num lampejo antes de morrer, rsrs.

[edunga1]

Gostei muito da leitura.
Se formos para o ambiente de desenvolvimento, dá para conectar ao surgimento do VS Code e do LSP. E também às ferramentas anteriores à era da IA da Tabnine.

[aer0700]

JavaScript의 간략한 역사
Acho que vale a pena ver junto com este artigo também

[GN⁺]

Comentários do Hacker News

• Dizer que toda página precisava do mesmo cabeçalho, navegação e rodapé, mas não havia como compartilhá-los, não está totalmente correto
  Os servidores web tinham o recurso de Server Side Includes (SSI), e, se você não quisesse usá-lo, também dava para resolver simplesmente com o comando cat header body > file
  Documento relacionado: Tutorial de SSI da NCSA (1997)

  • Como o HTML foi originalmente criado como um vocabulário baseado em SGML, SGML e XML tinham recursos de entidades/macros de texto para referenciar fragmentos de documento, como cabeçalhos ou rodapés comuns
  • Provavelmente o comentário original estava falando com base em HTML puro

• Fiquei pensando que teria sido bom se o texto terminasse com algo como "...e, em meio a todo esse processo, a humilde tag <br> continua fazendo seu trabalho"

• Na empresa em que trabalhei antigamente, usávamos um sistema em que, a cada deploy, era criada uma nova pasta e o link simbólico era apontado para a versão mais recente
  Era manual, mas eu achava uma abordagem realmente elegante, porque permitia uma troca atômica em cada servidor e facilitava o rollback
  Antes disso, era preciso copiar arquivos manualmente para dezenas de servidores e executar na mão de 10 a 20 comandos; comparado a isso, era muito mais seguro e simples
  Mais tarde usei ferramentas de automação, mas, como a configuração era complexa e opaca, o processo acabou sendo até mais frágil para deploy

• Há quem diga que “para usar scripts CGI era preciso aprender Perl ou C”, mas fiquei em dúvida se realmente seriam necessárias centenas de linhas
  Na prática, dá para ler parâmetros de URL até com uma função simples em C
  Recentemente criei um site de enquetes em C puro, e foi relativamente tranquilo graças a uma biblioteca de geração de HTML que eu havia feito antes
  Refatorei e reutilizei a biblioteca CGI do sistema operacional e fiz link estático com SQLite para distribuir tudo como um único binário
  Também dava para testar via stdin/stdout, sem servidor web
  Em resumo, um site CRUD é perfeitamente viável em C, e, como HTML é uma estrutura em árvore, acho que interpolação de strings (string interpolation) é a abordagem errada

  • Como o código faz correspondência do primeiro parâmetro que termina com <param>, talvez não haja correspondência exata, e ele também não trata percent-encoding
  • Concordo com a ideia de que interpolação de strings é inadequada, já que HTML representa uma estrutura em árvore
    Mas, mesmo depois de 30 anos, ainda parece que interpolação de strings continua sendo a ferramenta mais comum

• Foi um texto realmente abrangente e bem escrito
  O autor é otimista, mas eu vejo o desenvolvimento web como uma torre instável feita de gambiarras acumuladas
  Acho que, à medida que a padronização da web foi dominada por um pequeno número de fabricantes de navegadores, o resultado foi apenas remendar por cima, sem resolver os problemas fundamentais
  As ferramentas recentes de IA generativa também não passam de soluções temporárias para contornar essa complexidade
  No fim, acredito que essa torre vai desabar algum dia

• Este texto provavelmente vai virar um artigo clássico
  Ele resume de forma concisa a história das tecnologias web que os desenvolvedores de hoje deixaram passar

• Ao ler a parte “Virtual private servers changed this…”, lembrei de algo
  Na verdade, o primeiro provedor de VPS foi a JohnCompanies, por volta de 2001, com base em FreeBSD jail
  Os clientes queriam backups remotos e preferiam rsync
  Então, quatro anos depois, registrei o domínio rsync.net (com permissão dos autores de rsync/samba)

• Trabalhei com desenvolvimento web de 1998 a 2012, e ler este texto foi como fazer uma viagem no tempo
  Também serve como um resumo que permite ver de uma vez só as mudanças que vieram depois

• O conteúdo do texto bate quase perfeitamente com o fluxo das tecnologias web de que eu me lembro
  Antes do PHP, CGI era trabalhoso, mas mod_perl e FastCGI o tornavam usável
  Escrever CGI em linguagem compilada era quase uma forma de masoquismo, e o PHP, nesse sentido, era leve e divertido
  Eu saí do desenvolvimento frontend logo antes de o jQuery explodir

• Foi um texto realmente impressionante
  Não se limita a listar uma cronologia técnica; ele transmite com vivacidade o espírito da época (zeitgeist) de cada era
  Foi marcante ver o contexto humano, que normalmente só é passado oralmente, registrado por escrito
  Em vez de simplesmente criticar “como o mundo da nuvem ficou tão complexo”, o texto ajuda a entender isso como um resultado histórico do acúmulo de escolhas racionais em cada momento
  Deu para sentir a ironia da história humana dentro da história da tecnologia