Finalmente chegamos à ultima parte desta sequência de post sobre a história da internet, a gente vai falar hoje da parte de front-end, do início dos anos 2000 até os dias atuais. Para quem não leu os outros posts, onde eu falo sobre o início da internet, os primeiros protocolos, navegadores, e sobre back-end, eu recomendo a leitura, é uma história bacana, até para você saber de onde vieram as coisas, quais foram as evoluções mais importantes e como a gente chegou onde está hoje. Eu vou deixar os posts linkados aqui:
Para começar esse post, eu preciso falar de alguns conceitos que já estavam em discussão desde o inicio dos anos 2000.
O primeiro deles é o SPA [Single-Page Application] que, para quem não sabe, é o conceito de não precisar recriar todas as páginas de um site individualmente, utilizando uma comunicação que traz sob demanda as informações necessárias para o preenchimento dinâmico dessas páginas. Isso se tornou possível através do XMLHttpRequest, que permitia que o site carregasse um template padrão através da requisição HTTP e, conforme necessário, fossem criadas sub-rotas internamente via JavaScript, que carregavam o content, o “meio” daquela página. Dessa forma você não tem mais a necessidade de fazer um site grande e pesado ficar recarregando, desmembrando essas páginas em vários pedacinhos e carregando à medida do necessário. Principalmente para softwares web applications que têm uma série de telas e comportamentos é super interessante esse conceito de SPA porque reduz a necessidade de ficar re-processando o site inteiro, você só processa o “miolinho”. Esse conceito começou a tomar força e foi culminar nos frameworks de front-end mais pra frente.
Vou fazer algumas breves “menções honrosas” de coisas que aconteceram nesse período também. Em 2005 foi criado o framework Prototype para JavaScript. Eu utilizei o Prototype antes do jQuery, ele ajudava bastante a abstrair alguns problemas que o JavaScript tinha nessa época. Logo em seguida, em 2006, a gente teve as primeiras versões do jQuery, que se popularizou, se tornando o framework JavaScript mais utilizado durante muitos anos, principalmente a casadinha entre WordPress e jQuery, que permitia a criação de plug-ins complementares, então era muito escalável. O jQuery cresceu muito e ficou praticamente hegemônico no mercado de frameworks para JavaScript até a popularização do Angular 1 em 2010.
Outra coisa importante foi o lançamento da primeira versão do Android em 2008. Nessa época já tinha o iPhone e a gente estava começando a ter a onda dos Smartphones. Essa data é super importante porque a partir daí os aplicativos começaram a ter muita influência no desenvolvimento web, porque conta da popularização absurda de Smartphones. Nesse primeiro momento existia uma barreira de entrada porque era preciso saber Java para programar apps para Android ou Objective C para apps iOS. Eis que, em 2009, é lançado o PhoneGap, que depois foi relançado como open-source e rebatizado de Apache Cordova. A ideia do PhoneGap e do Cordova era possibilitar, através de JavaScript, HTML e CSS, a criação de aplicações WebView para Android e iOS. Eles criam um aplicativo que consiste de um browser que carrega um site em SPA. O SPA começou a se popularizar muito por causa disso, principalmente com o surgimento de frameworks que facilitavam o desenvolvimento para múltiplas plataformas de Smartphone. Como o PhoneGap era JavaScript “por de baixo dos panos”, você podia inclusive usar jQuery na hora de programar. Mas como todas as aplicações do PhoneGap rodavam em cima de um browser embutido, elas eram extremamente lentas, o que levou, mais a frente, à substituição dessas aplicações PhoneGap por apps nativos, via React Native ou Flutter.
Em 2009 a gente tem a criação do MongoDB, um banco de dados com um conceito totalmente diferente do que a gente tinha até então. O mercado era dominado totalmente por bancos de dados relacionais, principalmente Oracle e SQL Server no mundo enterprise e, no mundo de open source, o MySQL e o PostgreSQL. O MongoDB tinha uma característica muito diferente dos outros porque era classificado como um banco de dados de documento, utilizando o padrão JSON tanto para armazenamento quanto para consultas. Era uma casadinha perfeita, porque você podia plugar o MongoDB no NodeJS e utilizar a leitura dessas APIs no JavaScript, fazendo a comunicação de ponta a ponta usando JSON, sem um SQL no meio dando problema. Isso foi responsável pela enorme popularização do MongoDB, principalmente na comunidade do NodeJS, se tornando praticamente o banco de dados padrão para qualquer aplicação Node. Depois, obviamente, foram criados derivados do Mongoose [biblioteca do MongoDB], para serem utilizados em qualquer banco de dados no mesmo “modelo” que o MongoDB, só que, em questões de performance, ele ainda é absurdamente mais rápido do que praticamente todos os outros bancos de dados que eu conheço.
O JavaScript e o NodeJS ganharam um aliado fortíssimo em 2010, chamado Express.js, um framework para criação de servidores HTTP. Já que o Node faz todo o funcionamento de ponta a ponta do servidor web, nativamente ele já vem com bibliotecas para gerenciar HTTP e HTTPS, mas o Express cria uma camada de abstração em cima desses protocolos e facilita muito a criação de servidores web. O Express foi extremamente importante para a popularização do Node porque, através dele, ficou muito fácil criar rotas e controladores e, até hoje, é o servidor web mais utilizado para NodeJS. Isso mostra pra gente que está tendo uma movimentação do NodeJS para implementação de melhorias.
Finalmente estamos chegando ao foco principal desta última parte, que é o desenvolvimento do front-end, agora sim eu vou parar para falar um pouco mais a fundo.
No mesmo ano de 2010, a gente tem o surgimento do AngularJS, ou Angular 1. Ele nasceu dentro do Google, quando um dos engenheiros recebeu a tarefa de migrar um sistema chamado Google Inbox. Com tinha poucas semanas para fazer isso, ele pediu para utilizar uma ferramenta criada por ele mesmo, o Angular, e assim ele conseguiu fazer essa tarefa de recriar o Inbox em pouquíssimo tempo. O pessoal do Google ficou impressionado com a rapidez e decidiu apadrinhar esse framework, o Angular 1. O Angular tinha uma dinâmica muito diferente do que a gente estava acostumado porque ele trazia conceitos de controladores, de intervenção direta dentro do JavaScript por meio de marcadores que não existiam naturalmente no HTML. Através desses marcadores, o Angular conseguia fazer a leitura e criar escopos e, pela primeira vez, a gente teve o conceito de two-way data binding, super importante pro front-end. Data binding nada mais é do que sincronizar uma variável JavaScript com uma exibição posteriori dentro do HTML, até o surgimento do Angular a gente precisava que os frameworks fizessem essa comunicação com o HTML via DOOM e, aí sim, fazer a alteração dos valores on demand. Esse conceito do data binding foi extremamente disruptivo e facilitou absurdamente a forma como a gente lidava com esse comunicação entre JavaScript e HTML. Por esse motivo, no meu ponto de vista, é que a popularização dele aconteceu de uma forma absurda, num nível tão grande e tão rápido que conseguiu desbancar o jQuery, que vinha mantendo sua hegemonia há muito tempo.
Nesse momento começou uma febre no mercado de front-end, com a criação de milhões paginas SPA utilizando Angular, mas a gente tinha outro problema que veio junto com essa popularização, porque páginas SPA não indexavam bem no Google. O mecanismo de busca do Google foi criado para o modelo de MVC, que já carrega o HTML com tudo que precisa, então, a partir do momento que se criam conteúdos dinâmicos via APIs utilizando XMLHttpRequest e framework, não se tem mais disponíveis todos os dados que precisam ser indexados no Google, então a indexação ficava extremamente prejudicada. Só que, obviamente, pelo Angular ser uma ferramenta que estava dentro do Google, ele começou a se adaptar também a essas atualizações de frameworks SPA para conseguir indexar melhor.
Em 2011 a gente começou a ter a disseminação do conceito de Web Components, que pegava elementos que já existiam dentro JavaScript e do HTML e criava esse conceito de componentes reutilizáveis, com a criação de templates renderizados on demand. A primeira aplicação desse conceito de Web Components aconteceu em 2013 com um framework, também do Google, chamo Polymer. Eu cheguei a testar o Polymer, mas era um pouco difícil lidar porque ele utilizava prioritariamente HTML para criar os componentes. A gente vai ver que esse conceito fica muito mais bem aplicado nos frameworks mais modernos de front-end. E, de novo, esse conceito de componentização não é novo, nos anos 2000 já existiam ferramentas que utilizavam componentes, como o Delphi, o próprio .NET e as últimas versões do Dreamweaver também, então não é um conceito novo, ele só teve o formato adaptado para a internet. A vantagem do Web Components é que a gente podia criar um componente e reutilizá-lo quando necessário, renderizando esse componente on demand. Apesar de extremamente interessantes, de novo, a gente está falando de um sistema de SPA interagindo com JavaScript, e isso prejudicava a indexação.
Na parte de mobile, em 2013 a gente teve uma evolução no mercado de sistemas de criação de apps com o surgimento do Ionic, que também se tornou muito popular tão logo foi lançado. Ele ficou conhecido como “PhoneGap killer” porque todo mundo começou a migrar as aplicações para Ionic, e ele tinha o visual mais bonito também.
Em 2013 a gente tem, ainda, a criação pelo Facebook do famoso React, que trazia o conceito mais avançado desde o Angular. Ele misturava Web Components com as premissas do Angular1, num formato de framework, já prevendo a componentização com escopos independentes, utilizando Shadow DOM. Logo o React também começou a se popularizar e meio que a brigar com o Angular 1.
Também em 2013 a gente teve a criação do Electron, um projeto super interessante porque ele deu um “poder” a mais pro JavaScript porque: da mesma forma que o PhoneGap e o Ionic permitiam a criação de apps múltiplataformas, o Electron possibilitava desenvolver softwares desktop para múltiplas plataformas, Windows, Linux e Mac, utilizando JavaScript como base. Para isso, embutido dentro do Ionic tinha um Chrome, e isso possibilitou a criação de aplicações diversas, o próprio VS Code [que a gente está utilizando no curso de lógica computacional – se você ainda não viu, eu vou deixar o link no final] foi feito em Electron. Softwares feitos em Electron rodam nesse navegador interno e são codificados em JavaScript, HTML e CSS, e se comportam como um software nativo do sistema operacional, tendo acesso a arquivos e tudo mais. Então hoje a gente não consegue muito diferenciar o que é software nativo de fato e o que está rodando dentro do Electron e é JavaScript ou TypeScript, que também pode se utilizado.
No ano seguinte o Google criou o Material Design como um padrão de UX para softwares Android. Antes disso os aplicativos desenvolvidos para Android não seguiam um padrão muito bem definido, ao contrário dos aplicativos para a Apple, então o Material Design se tornou um “manual de regrar e boas práticas” para desenvolvimento de aplicações para Android. O Material Design se popularizou tanto que hoje praticamente todos os frameworks que eu conheço utilizam o Material Design como padrão de SCC, substituindo o, até então super famoso, Bootstrap, do Twitter, principalmente quando a gente fala de aplicações que tem “cara de sistema”, mas que, ainda assim, são muito bonitas. Tanto o React quanto o Angular e o Vue aceitam o Material Design, embora ele seja opcional. O Flutter também utiliza Material Design. Eu sempre falo pra quem é designer e gosta de CSS que, por mais que você seja muito bom em design, o Material Design foi criado pelos melhores engenheiros gráficos de UX em CSS do Google, e é um projeto digno de respeito, que merece ser olhado e entendido por que foi feito dessa forma. Por mais que tenha quem diga que tudo fica com a mesma cara, você pode personalizar o Material Design, desde que respeita as regras de boas práticas dele.
Continuando a história, 2014 a gente também tem a criação do Vue. Quando o React começou a ter certa expressão, o Google percebeu que para voltar a ser competitivo, precisaria unir o Polymer ao Angular. Por mais que o Polymer não tivesse emplacado, ele trazia o conceito de componentização, então eles fizeram a proposta de lançamento de um novo Angular, com essa mudança de escopo. Em paralelo, o criador do Angular, que ainda estava no Google,recebeu uma proposta para ir para a Microsoft, que também não queria ficar de fora dessa brincadeira. Olha que maluco, o Angular 1 é do Google, mas, a partir do Angular 2, é da Microsoft. Para “diferenciar”, o Angular 1 ficou como AngularJS e, do 2 em diante, só Angular. O Angular 2 era totalmente diferente do AngularJS, inclusive não utilizando mais o conceito de two-way data binding, mas de reatividade, a fim de melhorar a performance. Nessa divisão, uma parte da comunidade do Angular 1 saiu e criou o VueJS, que traz a essência do Angular 1, mas melhora uma série de coisas que eram deficientes, principalmente de termos de performance. Por mais que eu tenha mexido nos três frameworks, hoje eu prefiro o Vue, principalmente por causa da sintaxe, mas, no final, quando a gente vai peneirar, meio que dá tudo na mesma coisa.
Em 2015, o Facebook dá um passo importante e cria o React Native. O framework é muito semelhante à proposta do PhoneGap e do Ionic, mas agora utilizando React para criar apps. O grande diferencial do React Native, a priori, é que, em vez de criar aplicações Web View, ele gera códigos nativos para cada um dos sistemas operacionais. Com ele você pode criar a sua aplicação em JavaScript usando React como base e o Material Design como forma gráfica, e exportar essas aplicações para Kotlin, Java ou Objective C, já nos padrões para exportar no Google Play ou na Apple Store. Essa é a primeira vez que a gente tem um framework que de fato gera apps nativos, embora tenha alguns pequenos problemas de performance e não seja tão fluido quando um app em Flutter, por exemplo. Eu já utilizei o React Native e achei muito bom, principalmente se a aplicação não tem necessidade de performance extrema e não é uma coisa muito pesada, ele é um excelente start.
Em 2016 saiu a versão 2 do Angular, agora pela Microsoft, segregando ainda mais o mercado numa divisão clara, com React tomando a dianteira. O Angular 2 recebeu uma migração em massa da galera do AngularJS, mas teve uma galera que ainda se manteve no Angular 1 por muito tempo. Eu mesmo fiquei bastante tempo e depois fiz a migração para o Vue, porque eu não gosto da sintaxe do React, mas também não queria fazer a migração para o Angular 2.
Demorou algum tempo para a galera começar a entender que fazer site em SPA e frameworks front-end tinha uma série de problemas, principalmente de indexação. Eu lembro que nessa época, de 2016 para 2017, eu estava começando o Vigia de Preço e eu utilizava Angular, mas para um comparador de preço a indexação é super importante. Até hoje muitos sites que precisam de boa indexação no Google que utilizam o MVC, o próprio site da Amazon, por exemplo, que tem pouquíssimas coisas dinâmicas, porque o que é mais importante é a indexação; eles abriram mão de utilizar um framework dinâmico porque se eles perderem tempo com carregamento da página, eles perdem venda. Inclusive, existe um estudo da própria Amazon que fala que, a cada 100ms de latência no carregamento da Amazon.com, eles perdem 1% das vendas.
Também em 2016, surgiram os frameworks SSR [Server Side Rendering], o Next.JS para React e o Nuxt.JS para Vue [para o Angular, o que mais se assemelha é o Angular Universal, mas o projeto não partiu do Google e sim da comunidade]. Esses frameworks funcionam como uma camada de server para pré-renderizar componentes, onde você consegue pré-processar informações importantes em back-end antes de enviar o HTML e, através desses sistemas de SSR, corrigir os problemas dos frameworks front-end para indexação no Google. Na maioria dos meus projetos eu utilizo o Nuxt.JS junto com o Vue, e já estou migrando pro Vue 3 e Nuxt 3. Eles foram lançados há pouco tempo então obviamente é esperada uma série de bugs, além da dificuldade normal para fazer uma migração, já que muitas coisas que funcionavam muito bem no Vue 2 pararam de funcionar. Eu recomendo a todos que estão na área de front-end, e até mesmo que mexe com back-end, olhar o NextJS e/ou o NuxtJS.
Eu quero mencionar uma ferramenta que eu usei recentemente, que também é do Google, chamado Flutter, que utiliza uma linguagem muito parecida com TypeScript chamada Dart. O Flutter tem uma questão interessante que, para mim, é uma evolução no entendimento desses apps que não são 100% nativos, que é a utilização do componente canvas para renderização do app. O canvar é um elemento de draw que normalmente é utilizado para desenhar jogos, e tem por objetivo justamente ser um renderizador bom e eficiente, diferente do HTML, que é uma imensa gambiarra. Só que no canvas você tem a necessidade de codificar o desenho como um todo, e o Flutter faz justamente esse meio de campo, de criar esses componentes utilizando em sua linguagem conceitos do HTML/CSS, e ele “desenha” esses componentes utilizando Material Design como framework gráfico. Ele consegue gerar aplicativos extremamente fluídos e rápidos, usando um paradigma bem diferente. Outra coisa que o Flutter faz com excelência é gerar apps nativos, assim como o React Native, mas sem utilizar um interpretador de JavaScript, já que o Flutter é compilado. Para quem estiver estudando sobre aplicações para Smartphones, eu recomendo estudar o Flutter, quem já usa JavaScript/TypeScript não vai ter grandes dificuldades. Inclusive eu vou recomendar aqui o canal Flutterando, do meu amigo Jacob Moura, que foi consultor lá no Vigia de Preço, o conteúdo é muito bacana para estudo ou mesmo para utilizar em produção.
Então, percebam, desde o começo da internet a gente teve uma evolução enorme em relativamente pouco tempo. De mais ou menos 1993 até 2022 a gente teve melhorias consideráveis no JavaScript, no CSS, no HTML, no HTTP. A gente teve algumas “mortes” ao longo do caminho, ActiveX, Flash, ASP clássico, Orkut, Prototype, Cordova, Angular 1, e por aí vai. A evolução é contínua e eu acho super bacana ter participado dela. Eu utilizei profissionalmente praticamente tudo que eu citei nesses três posts em algum momento , ou pelo menos eu estudei bastante sobre, então eu conheço cada parte por experiência própria. Já fiz apps nativos, já fiz apps em PhoneGap, em Flutter, já utilizei React, Vue, Angular1, um pouco do Angular 2, e tudo mais. Algumas tecnologias eu não utilizo mais, outras, por incrível que pareça, eu uso até hoje ou, por exemplo, o caso do C#, que eu tive contato em 2009, e voltei a ter contato agora em 2021, quando eu comecei a mexer com Unity para desenvolvimento de jogos, e gostei bastante da evolução da linguagem e até tirei um pouco da resistência que eu tinha por não ter tido uma boa experiência na época.
O ponto em que eu quero chegar com toda essa história é que a gente teve uma divisão clara na evolução da internet, que acabou fazendo com que o back-end virasse basicamente micro-serviços e API e o front-end começasse a tomar conta da lógica do desenvolvimento, só que os programadores de front-end derivaram principalmente do design e não eram acostumados a usar lógica computacional para programar, enquanto a galera do back-end não estava muito a fim de ficar mexendo com front-end. A gente colocou a lógica do negócio na mão de uma galera que não sabe programar direito, obviamente existem exceções, mas na maioria das vezes os front-end estão focados em fazer o CSS, o HTML, deixar o negócio bonito. E aí criou esse cargo bizarro, chamado full stack, que é o cara que mexe com os dois e que, na minha época, chamava Web designer, programador, não existia essa diferença entre front-end e back-end. Particularmente, eu acho ruim essa divisão, estruturalmente ela até faz sentido, mas em questões de cargos não faz sentido.
Essa, inclusive, é uma mensagem que eu quero deixar quem está contratando: procurem programadores ou designers, não procurem “o cara que sabe React” ou qualquer framework específico porque tudo isso o cara que tem uma boa base de HTML, CSS e JavaScript aprende fácil. Procurem profissionais que queiram trabalhar de fato, que estão interessados, que, independente do conhecimento que têm hoje, estão procurando aprender mais. E consigam diferenciar se o cara tem maior probabilidade de ir para o lado do design ou pro lado da programação: se o cara é mais programador, é muito mais fácil você alocar ele entre back-end e operacionalização do front-end, principalmente mexendo com React, Vue e Angular; já o designer vai estar muito mais focado em resolver problemas de CSS, de criação do HTML, mas ele vai ter que aprender a mexer um pouco com esses frameworks. Outra saída é voltar para o modelo de MVC, o que muita gente faz, utiliza o WordPress e não utiliza esses frameworks mais modernos para desenvolvimento. Sempre vai ter prós e contras. Optar pela utilização de um framework de front-end você vai trazer facilidade de implementações, mas, ao mesmo tempo, vai ter problema para conseguir um profissional de front-end que seja bom programador, e aí vai acabar tendo que recorrer a um full stack que goste de design para poder fazer as aplicações, ou até mesmo um designer fazendo o layout e passando para o full stack implementar.
Embora a gente venha de uma evolução muito grande nesses últimos trinta anos, eu quero que vocês percebam uma coisa: a gente ainda escreve código do zero, na mão. A gente escreve o código inteiro, o CSS, o HTML, o componente, tudo. Por mais que a gente pegue coisas semi-pontas, utilize NPN para fazer gestão de dependência e tal, a gente ainda cria tudo via código. Existem algumas aplicações que facilitam a criação de páginas para internet, recentemente eu utilizei uma chamada Wix, por exemplo, em que você cria visualmente o site, bem bacana. No meu ponto de vista, eu acho que a internet ainda vai passar por outra mudança, porque a gente já tem componentização, frameworks front-end, tem boas tecnologias de back-end, já tem implementado dentro dos browsers tecnologia suficiente para canvas, web socket, web sound, e tudo mais, mas a gente não tem nenhuma ferramenta que utiliza com satisfação todas essas tecnologias que foram implementadas. Nós temos vários frameworks de front-end e de back-end, e tudo mais, mas a gente ainda escreve para a internet como a gente escrevia nos anos 90 para desktop.
Eu vou deixar uma reflexão, que inclusive é uma coisa que eu já penso há muito tempo: eu tive experiências nos anos 2000 com o Delphi, uma excelente ferramenta de desenvolvimento que misturava a possibilidade de escrever códigos, com uma parte gráfica simples de criação de telas, para implementar softwares complexos sem precisar necessariamente botar a mão em código. O Delphi possibilitou que pessoas sem tanto conhecimento de programação criassem softwares específicos para resolver problemas, pequenos ou grandes, aplicando a lógica dos seus próprios negócios, fazendo uma gestão de estoque, uma gestão de padaria, um sistema de escritório de advocacia… Você tinha softwares de vários portes desenvolvidos em Delphi nos anos 2000. Eu acredito que o futuro da internet passa por um grande software disruptivo, que vai mudar a forma como a gente cria para a web.
Diferente do que muita gente vem falando, que a inteligência artificial vai tornar obsoleto escrever código, eu acho que a programação pode ser abstraída, mas a regra de negócios ainda continua existindo. Por regra de negócios eu estou falando do comércio, do serviço, do mundo, das especificidades de cada setor. Se você está vendendo um produto, a forma como você gerencia o estoque, como você controla os pagamentos dos funcionários, o financeiro, o RH e tal, isso tudo tem premissas, tem processos que diferem de uma empresa para outra, e quando você vai criar softwares para fazer o gerenciamento desses negócios, dessas empresas, essa lógica muda. Abstraindo a parte de código, pessoas que não têm tanto conhecimento assim vão poder desenvolver suas aplicações sem a necessidade latente de um programador, até porque existe muito ruído de comunicação entre quem está passando a lógica do negócio para quem está escrevendo o código. Então eu acho que a gente está caminhando para essa próxima etapa, essa revira-volta da internet, que são os softwares no code. Isso está cada vez mais em alta, com os sistemas de inteligência artificial ajudando, como o Copilot, para melhorar os códigos.
Mas ainda vai ter um ponto de virada que vai ser algo equivalente ao Delphi para desenvolvimento de softwares para internet, browser e aplicativos. E esse entendimento eu não é de agora, tem mais de 10 anos que eu penso nisso, que em algum momento vai ter essa virada, e eu acho que agora nós estamos próximos porque a tecnologia já evoluiu para isso. Hoje o TypeScript e o JavaScript estão muito mais robusto, os browsers são muito mais ágeis, a internet está a cada dia rápida, e tudo isso possibilita a criação de um software assim, por isso que eu acho que esse é o próximo passo evolucionário para o desenvolvimento da internet.
Espero que vocês tenham gostado dessa série! Eu vou ficando por aqui, até a próxima!
O curso de lógica computacional pode ser encontrado aqui:
O conteúdo deste post é baseado no vídeo “A Internet – Frontend (2002 a 2022)”:
