Introdução
O desenvolvimento web percorreu um longo caminho desde o início da internet. Da criação da primeira página da web, no início dos anos 90, até as aplicações web dinâmicas e interativas de hoje, a evolução do desenvolvimento web tem sido impulsionada por um esforço constante para solucionar problemas e melhorar a experiência do usuário. No entanto, o caminho para o desenvolvimento web moderno não foi isento de desafios. Neste primeiro post, começaremos dando uma olhada nos primeiros dias do desenvolvimento web e examinaremos os problemas enfrentados pelos desenvolvedores. Ao entender esses desafios, podemos compreender as decisões tomadas pelas soluções de desenvolvimento web moderno e comparar com confiança as mais recentes ofertas na segunda parte desta série.
A Primeira Era
Alguém tentou dividir por zero e causou o Big Bang, alguns peixes decidiram andar em terra firme, uma vaca lambeu gelo, esse cara estranho fez um anel que te deixa invisível, sei lá, não tô nem aí. Na real, vale a pena lembrar das coisas de uma época sem computadores?
A Idade Pré-web-ica
Em 1989, Sir Tim Berners-Lee e sua equipe no CERN tinham um problema: eles precisavam criar e compartilhar coisas científicas, mas os pesquisadores da época usavam vários programas proprietários que não eram simples, nem baratos. Mas o pior de tudo: essas ferramentas não se comunicavam corretamente entre si. Isso tornava difícil a colaboração em projetos de outros pesquisadores, além de complicar o acesso a informações. Para resolver isso, eles criaram o HTML.
O HTML foi projetado para ser uma linguagem de marcação que poderia ser usada para criar documentos que fossem facilmente compartilhados e acessados de forma tecnologicamente neutra pela rede – algo grandioso na época. O projeto fornecia uma maneira de estruturar o texto e adicionar links entre documentos, o que facilitava a navegação e exploração de informações em diferentes documentos.
A Idade do Estático-como-pedra
A primeira página da web já criada foi feita por Sir Tim Berners-Lee em 1991. Era uma página simples que fornecia informações sobre o projeto da World Wide Web, que ainda estava em seus estágios iniciais na época. A página tinha o clássico fundo branco com texto preto e links azuis, que ainda conhecemos do HTML básico sem CSS.
A razão pela qual a primeira página da web foi criada era fornecer uma plataforma para compartilhar informações e recursos na World Wide Web. Sir Tim Berners-Lee imaginou a web como uma forma para cientistas e pesquisadores compartilharem informações e colaborarem em projetos de maneira mais fácil. Seu objetivo era criar uma rede descentralizada de informações que pudesse ser acessada de qualquer lugar do mundo.
Naquela época, o HTML foi projetado para exibir apenas conteúdo estático. Isso significa que os primeiros sites eram essencialmente versões digitais de documentos impressos – não havia maneira de incorporar elementos dinâmicos como animações, vídeos ou formulários interativos. Você só podia ler o que estava escrito ou navegar para outro documento.
Como resultado, as primeiras páginas da web dependiam muito de hiperlinks para conectar diferentes páginas e fornecer aos usuários uma maneira de navegar pelos sites. Embora essa abordagem fosse funcional, também poderia ser frustrante para os usuários, que tinham que clicar constantemente de um lado para o outro entre as páginas para encontrar as informações que estavam procurando. Especialmente porque os navegadores não tinham abas naquela época.
As coisas são ainda piores (pelos padrões modernos), pois cada página HTML era estática. Se você quisesse ter a mesma barra lateral em várias páginas, precisaria codificá-la manualmente em cada uma delas. E se você quisesse adicionar mais um link nessa barra lateral, boa sorte atualizando manualmente todas as páginas que a utilizavam. Não existia a possibilidade de reutilizar modelos ou componentes. Era um trabalho verdadeiramente artesanal, feito pelos antigos mestres anciãos do HTML.
E tudo estava bem como estava, até que alguém decidiu ir um pouco mais longe.
A Idade dos Servidores de Ferro
A pior parte do HTML estático é que, uma vez carregada a página, não havia maneira de atualizar o conteúdo sem atualizar a página inteira. Além disso, se você quisesse incluir conteúdo dinâmico, como dados digitados pelo usuário, era necessário usar soluções complicadas e limitadas.
Entra em cena a renderização no servidor (Server side rendering – SSR). Ao invés de escrever HTML manualmente, os desenvolvedores tiveram a genial ideia de escrever código que geraria o HTML dinamicamente no momento que usuário requisitar o documento. Desta forma, seria possível alterar o HTML (com certos limites) de forma dinâmica entre as atualizações.
Isso marcou o início das linguagens e frameworks focadas em gerar HTML no servidor, por exemplo o PHP.
Com a renderização no servidor, você poderia incluir conteúdo dinâmico, como entrada de dados ou consultas a bancos de dados, sem precisar depender de soluções complicadas (atualizando o HTML o tempo todo, inserindo outras páginas por meio de iframes, bibliotecas semelhantes ao Flash, etc.). Você até poderia ter diferentes páginas renderizadas para diferentes usuários, talvez até adicionando os nomes dos usuários na barra de navegação. Incrível, não é?
Lembra daquela barra lateral que os anciãos do HTML inseriram manualmente em cada página? Isso é passado, sem mais erros de digitação, sem retrabalho, apenas chame a mesma função e você sempre terá a mesma barra lateral, verdadeiramente glorioso. Essas soluções estavam anos-luz à frente dos simples arquivos HTML. Todas as pessoas descoladas estavam usando servidores nessa época.
Embora essa ideia de servidores não seja mais a única opção disponível, é importante tê-la em mente, pois ainda é uma parte importante do conjunto de ferramentas de desenvolvimento web.
A Idade do Javascript Clássico
Ah, meados dos anos 90. Alguns consideram a era de ouro do desenvolvimento web. Enquanto SSR revolucionou a forma como os incas e maias construíram suas aplicações web, outra tecnologia estava começando a surgir: o JavaScript.
JavaScript, como você já sabe, é uma linguagem de script que (normalmente) roda no navegador cliente. Javascript (JS para os íntimos) permite aos desenvolvedores criar aplicações web dinâmicas e interativas. Mas, nos meados dos anos 90, o JavaScript ainda estava em seus primeiros dias. Na verdade, a primeira versão só ficou disponível 1995.
E isso mudou o jogo de uma maneira significativa. Foi como a peça do quebra-cabeça que faltava para desbloquear o potencial da web, e os usuários experimentaram uma série de benefícios como resultado.
Uma das maiores mudanças introduzidas pelo JavaScript foi a interatividade. Antes as páginas da web eram (em sua maioria) estáticas, com interatividade limitada e sem capacidade de responder às ações do usuário – a não ser que a página inteira fosse recarregada. Mas, com a introdução do JavaScript, os desenvolvedores web de repente tiveram a capacidade de adicionar recursos interativos como animações, validação de formulários e atualizações de conteúdo dinâmico, tudo isso sem precisar recarregar nada.
O resultado foi uma experiência web mais envolvente e dinâmica para os usuários. Em vez de ler passivamente por uma página web estática, os usuários agora conseguiam interagir com elementos na página, acionar animações e receber feedback em tempo real. Por exemplo, imagine preencher um formulário em uma página web e ver um feedback instantâneo informando se sua entrada é válida ou não? Absolutamente incrível e avançado para a época.
Mas com grandes poderes, vêm grandes complexidades. O JavaScript abriu um mundo inteiramente novo de possibilidades (e problemas que não existiam antes – ataques XSS por exemplo) para o software baseado na web. Não é exagero dizer que o JavaScript transformou a forma como pensamos sobre o desenvolvimento web.
A Idade Média do Javascript
Ah, a era medieval, quando o JavaScript se tornou sinônimo de jQuery e Ajax – duas ferramentas clássicas no mundo do desenvolvimento web que tornaram nossas vidas muito diferentes. Vamos dar uma olhada mais de perto no que são e por que foram tão populares.
jQuery é uma biblioteca JavaScript que foi criada em 2006 por John Resig. Foi projetada para simplificar tarefas comuns de desenvolvimento web, como manipulação do DOM, manipulação de eventos e requisições AJAX. E o que é AJAX, você pergunta? Significa Asynchronous JavaScript and XML, e é uma técnica para fazer requisições HTTP a um servidor web sem exigir uma recarga completa da página.
Por que o jQuery foi tão popular? Para começar, ele tornou o desenvolvimento web muito mais fácil e eficiente. Com o jQuery, os desenvolvedores podem escrever menos código para fazer mais coisas, e conseguiam fazer isso mais rapidamente. Isso era ainda mais forte para tarefas comuns, como manipulação de eventos e manipulação do DOM, que podiam ser feitas com apenas algumas linhas de código jQuery.
Lembre-se de que, nessa época, a maioria das manipulações e seletores DOM nativos que temos hoje não estavam disponíveis. Sua criação e necessidade foram fortemente inspiradas na forma como os desenvolvedores maias e incas dessa época interagiam com o próprio jQuery. Pode-se dizer que o jQuery ajudou a moldar o JavaScript (e HTML) nativos como conhecemos hoje.
Outro motivo para a popularidade do jQuery foi sua compatibilidade com vários navegadores. Nos começo da web, diferentes navegadores tinham implementações diferentes de JavaScript e DOM, o que poderia tornar o desenvolvimento web um pouco complicado. No entanto, o jQuery abstraiu essas diferenças, facilitando a escrita de código que funcionasse em todos os principais navegadores.
Agora, vamos falar sobre o AJAX. Como mencionei antes, o AJAX é uma técnica para fazer requisições HTTP a um servidor web sem exigir que a página seja recarregada. Isso significa que dados podem ser carregados e exibidos em uma página web sem que o usuário precise esperar por uma atualização. Isso foi uma grande novidade, pois permitiu uma experiência web mais fluida e responsiva.
No entanto, o AJAX também tinha seus desafios. Escrever código AJAX manualmente podia ser um pouco complicado, especialmente quando se tratava de lidar com erros e gerenciar chamadas assíncronas. Foi aí que entrou em cena a funcionalidade AJAX do jQuery. Com o jQuery, fazer requisições AJAX era tão simples quanto chamar algumas funções, e a biblioteca lidava com todos os detalhes complicados, como tratamento de erros e chamadas de retorno.
No geral, essas foram duas ferramentas revolucionárias no mundo do desenvolvimento web. Elas simplificaram tarefas comuns, abstraíram as diferenças entre navegadores e abriram o caminho para uma web mais dinâmica e responsiva.
A Idade da Aplicação Web Moderna
Ah, as Single Page Applications – ou SPAs – outra criação fascinante no mundo do desenvolvimento web. Então, o que são elas e por que são tão populares? Vamos descobrir!
Uma SPA é uma aplicação web que funciona dentro de uma única página. Alguém brilhante teve o seguinte monólogo interno:
“Agora que temos todo esse JavaScript, por que precisamos mesmo de páginas? Por que não podemos carregar uma página inicial em branco e apenas atualizar continuamente as coisas na mesma página?”
“E por que faríamos isso? Porque podemos! Só precisamos de um framework para facilitar esse processo.”
Para os usuários, as SPAs oferecem uma experiência mais fluida e responsiva, com tempos de carregamento mais rápidos, menos carregamentos de páginas e melhor desempenho geral. Para os desenvolvedores, as SPAs oferecem uma experiência de desenvolvimento mais modular e flexível, com manutenção de código mais fácil, melhores capacidades de teste e a capacidade de reutilizar código em várias aplicações. As SPAs permitiram que as aplicações web se tornassem mais complexas e mais integradas.
Os primeiros frameworks de SPA começaram a surgir no início dos anos 2010, sendo o Backbone.js e o Ember.js dois dos primeiros exemplos. Esses frameworks forneceram aos desenvolvedores as ferramentas necessárias para construir SPAs complexas, com recursos como two-way data binding, roteamento e manipulação de eventos. No entanto, foi o AngularJS (agora conhecido apenas como Angular), lançado pelo Google em 2010, que realmente popularizou as SPAs.
O AngularJS foi um divisor de águas no desenvolvimento web, permitindo que os desenvolvedores construíssem SPAs complexas com relativa facilidade.
Depois do lançamento do AngularJS, uma série de outras ferramentas legais apareceram no cenário, como React e Vue.js. Elas pegaram o que o AngularJS fez e melhoraram ainda mais. Por exemplo, o React, criado pelo Facebook em 2013, é mais leve e flexível que seu antecessor. Além disso, ele introduziu o conceito de virtual DOM, que permite atualizar a interface do usuário em um tempo ainda menor. E é baseado em componentes, o que significa que você pode construir aplicativos complexos dividindo-os em componentes menores e reutilizáveis. Legal, né?
O Vue.js, lançado em 2014, é semelhante ao React, mas com seu próprio estilo. Ele é frequentemente chamado de framework “progressivo” porque pode ser usado tanto em aplicações pequenas quanto em grandes aplicações. Além disso, é mais fácil de aprender do que o React ou o AngularJS, o que é uma grande vantagem para quem não quer passar semanas estudando. Com o Vue.js, você obtém uma sintaxe mais simples e uma curva de aprendizado menor.
Primeira Revolução Servidorial
Então…
Lembra daquela antiga abordagem de renderizar tudo no servidor em vez de usar SPAs?
As SPAs executam o JS no navegador do usuário, então elas são muito mais baratas e muito mais rápidas depois que o JS inicial é carregado. Então, não precisávamos mais daqueles servidores.
Mas os servidores são tão legais que os trouxemos de volta. Vida longa ao SSR!
Se você está acompanhando as tendências do desenvolvimento web, já deve ter se perguntado: por que o SSR se tornou tão popular de repente? Existem algumas razões para isso.
Em primeiro lugar, o SSR oferece melhor desempenho e SEO (Search Engine Optimization). Com CSR (Client Side Rendering – categoria dos SPAs), toda a aplicação é carregada no navegador do cliente, o que pode resultar em tempos de carregamento inicial lentos, especialmente em dispositivos móveis ou conexões de internet mais lentas – embora a página seja super rápida após esse início. Com o SSR, o servidor envia de volta uma página HTML totalmente renderizada para o cliente, o que significa que o tempo de carregamento inicial é mais rápido. Em um mundo onde a atenção tende a ter a duração de um Tik-Tok, isso é uma grande vantagem.
Além disso, como as SPAs começam inicialmente com uma página vazia e a modificam ao longo do tempo, os mecanismos de busca podem ter dificuldade em interpretá-las. Isso não acontece com o SSR, onde os rastreadores podem analisar e indexar facilmente o conteúdo da página, que é HTML em sua maior parte. Isso resulta em melhor SEO, pois os provedores de busca podem entender o conteúdo da página com mais facilidade, o que pode levar a uma classificação mais alta nos resultados de busca.
Por último, o SSR é mais seguro. Como o servidor é responsável por renderizar a página, ele pode realizar verificações de segurança e sanitização antes de enviar o conteúdo para o navegador do cliente. Isso pode ajudar a prevenir vulnerabilidades de segurança, como ataques de cross-site scripting (XSS).
Mas por que agora é o momento em que o SSR volta dos mortos? Bem, isso se resume à infraestrutura de suporte. Além dos provedores de nuvem modernos, como AWS, GCP, Azure, Oracle, ainda temos os revendedores de nuvem, como Vercel, Netlify, Firebase e outros, tornando cada vez mais fácil implantar e gerenciar servidores. Isso tudo aliado a várias melhorias em CDNs, serverless functions, edge functions e melhorias gerais nos padrões da Internet, podemos ver que a maioria dos problemas e desvantagens causados pela posse e manutenção de servidores é fortemente mitigada.
A cereja do bolo é que Angular (não mais AngularJS), React e Vue.js não são apenas para SPAs. Eles também suportam SSR por meio de seus metaframeworks – como por exemplo o Angular Universal, Next.JS e NuxtJS.
Tudo isso combinado criou a situação perfeita para o renascimento do SSR.
Primeira Guerra dos Frameworks
Com tudo isso acontecendo, foi um momento marcante para os desenvolvedores web, mas também um momento confuso. Como vimos, após o Angular, surgiram vários outros frameworks, cada um com seus pontos fortes e fracos.
Isso criou a “guerra” entre os frameworks JavaScript.
Frameworks menores, como Ember, Backbone, Knockout, CanJS, Aurelia e Durandal, que ganharam popularidade nos anos do AngularJS, rapidamente sucumbiram à pressão dos grandes jogadores. Eles acabaram perdendo terreno para o React e o Vue, que surgiram como os dois frameworks JavaScript mais populares, enquanto o AngularJS se tornou o Angular (vamos fingir que o Angular 2.x não existiu…).
O React, desenvolvido pelo Facebook, foi um dos primeiros frameworks a desafiar a dominância do Angular. Adotando uma abordagem diferente para a construção de aplicações web, usando um virtual DOM para melhorar o desempenho e facilitar a construção de interfaces de usuário complexas. O React rapidamente ganhou popularidade e hoje é um dos frameworks JavaScript mais amplamente utilizados.
O Vue adotou uma abordagem mais leve para a construção de aplicações web, facilitando a integração com projetos e bases de código existentes. O Vue também ganhou muita popularidade, especialmente na Ásia, e hoje é uma escolha popular para a construção de aplicações web modernas.
Esses três surgiram como os principais jogadores na “guerra” entre os frameworks JavaScript. Mas, no final, a escolha entre eles se resume à preferência pessoal e às necessidades específicas do seu projeto.
No final das contas, a “guerra” entre os frameworks JavaScript foi um testemunho da inovação e criatividade da comunidade de desenvolvimento web. Algumas pessoas dizem que, até hoje, um novo framework JavaScript é lançado a cada duas semanas. Embora alguns frameworks tenham surgido como vencedores e outros tenham ficado para trás, a competição ajudou a impulsionar os limites do que era possível com o JavaScript e ajudou a tornar a web um lugar mais dinâmico e interativo.
A Grande Depressão
Após a “guerra” inicial, os sobreviventes foram principalmente Angular, React e Vue.
Durante alguns anos, esses três frameworks dominaram o espaço, com os desenvolvedores contando com eles para construir uma ampla gama de aplicações web. Mas algo inesperado aconteceu: por um tempo, não vimos muitos novos frameworks surgirem. Era como se todos estivessem satisfeitos em continuar usando os vencedores da guerra. A “guerra” se tornou mais fria e a competição passou a ser sobre qual dos três era o melhor.
Talvez os desenvolvedores estivessem simplesmente satisfeitos com o que tinham e não quisessem complicar as coisas. Ou talvez eles estivessem hesitantes em adotar novas tecnologias até que elas fossem comprovadas como confiáveis e eficazes.
Mas, como em qualquer campo em constante evolução, as coisas eventualmente começaram a mudar. Nas sombras, reunindo forças para desafiar o status quo, alguns projetos inovadores começaram a ganhar força. Afinal, aqueles três favoritos começaram a mostrar sua idade. Eles ficaram confortáveis por tempo demais, tornaram-se complacentes, são lentos para se movimentar e dois deles são comandados por gigantes da tecnologia.
A paz nunca foi uma opção, foi apenas um prelúdio para uma tempestade maior.
Estamos começando a ver as coisas mudando. As ferramentas básicas de desenvolvimento web já começaram a mudar.
- Webpack perdeu terreno para o Vite.
- Sass é desafiado pelo PostCSS.
- Bootstrap está em declínio e o Tailwind está em ascensão.
- NPM está sendo quase completamente substituído pelo PNPM.
- Node tem concorrência no Deno e no Bun.
As estruturas básicas da velha guarda estão mudando, o próprio alicerce onde o desenvolvimento web se apoiava está se movendo.
A competição está começando a sair das sombras, lentamente, mas com certeza, o Monção está se dissipando.
Estamos nos dirigindo para a…
Segunda Guerra dos Frameworks (atual)
Por que alguns anos foram necessários alguns anos para surgirem novos frameworks depois que Angular, React e Vue dominaram o mundo?
Quais são os frameworks que estão surgindo? No que eles melhoram?
Vamos explorar essas perguntas e comparar esses frameworks na Parte II (e final) desta série.
Crédito
Escrito por Lucas Ferreira
