![Guia do CISO para segurança 5G: riscos, resiliência e fortificações](https://optimuscloud.com.br/wp-content/uploads/2024/05/1717094644_Guia-do-CISO-para-seguranca-5G-riscos-resiliencia-e-fortificacoes-150x150.jpg)
Guia do CISO para segurança 5G: riscos, resiliência e fortificações
30 de maio de 2024Como os LLMs podem unir promoção de eventos analógicos e calendários digitais
30 de maio de 2024Há vinte anos, os aplicativos baseados em navegador — aplicativos da web — deram um salto gigantesco em termos de funcionalidade. Em abril de 2004, o Google lançou um dos primeiros aplicativos web que funcionava como um aplicativo nativo: o Gmail. A tecnologia por trás disso, uma técnica JavaScript que mais tarde seria chamada de “Ajax” (Asynchronous JavaScript and XML), permitiu que aplicativos da web enviassem e recuperassem dados de um servidor de forma assíncrona – ou seja, sem que o usuário precisasse recarregar a página da web.
De repente, a internet de 2004 ficou muito mais interativa. Uso do Gmail de carregamento instantâneo de e-mails habilitado para Ajax e pesquisa em tempo real. Outros aplicativos da web rapidamente seguiram o exemplo – Flickr, Bloglines e Basecamp entre eles. Mais tarde, o Facebook usou Ajax para enviar e recuperar comentários e curtidas de forma assíncrona, permitindo que essas ações fossem atualizadas imediatamente na página sem recarregar completamente. Foi mágico e permitiu que a “web como plataforma” (também conhecida como Web 2.0) florescesse nos dez anos seguintes.
O que acontece quando você dobra o JavaScript
Mas então aconteceu uma coisa curiosa. De aproximadamente 2014 até agora, os desenvolvedores dobraram a aposta no JavaScript – você não pode ter muita coisa boa, certo? Assim, os aplicativos web tornaram-se mais complexos, especialmente após a introdução de novas bibliotecas JavaScript como React (que estreou em 2013) e estruturas associadas como Next.js (2016). Embora isso sem dúvida tenha ajudado os aplicativos da web a escalar e fazer coisas ainda mais mágicas com a interface do usuário, também aumentou a quantidade de JavaScript processado nos dispositivos do usuário. O que também aumentou a carga de manutenção para os desenvolvedores.
O ecossistema JavaScript ficou grande demais e membros proeminentes da comunidade web começaram a pedir um retorno aos fundamentos da plataforma web. Tenho relatado esse fenômeno nos últimos anos, mas até agora não tinha visto um aplicativo da web (em grande escala, pelo menos) que sintetizasse o impulso de “voltar ao básico”.
Mas talvez eu tenha encontrado agora, com a atualização mais recente do navegador da Microsoft, o Edge baseado em Chromium. Isso chamou minha atenção esta semana por alguns motivos. Primeiro, reduziu sua dependência do React; e dois, aumentou o uso de Web Components, uma abordagem HTML para desenvolvimento web.
“… mudar do React para uma arquitetura moderna de Web Components + HTML trouxe um *enorme* benefício para os usuários.”
– Alex Russell, gerente de produto parceiro da Edge
Como o Edge reduziu seu código de reação?
A postagem no blog da Microsoft sobre o novo Edge (versão 122) na verdade não menciona o React. Em vez disso, concentra-se no que o usuário experimentará: velocidades mais rápidas. A empresa colocou desta forma:
“A partir do Edge 122, a IU do Browser Essentials agora é muito mais responsiva. A IU agora é 42% mais rápida para usuários do Edge e 76% mais rápida para aqueles que usam um dispositivo sem SSD ou com menos de 8 GB de RAM!”
Mas Alex Russell da Microsoft, gerente de produto parceiro do Edge (e antes disso, um dos criadores dos Web Components), confirmou os detalhes do desenvolvimento do Mastodon:
“Nós construímos *muito* navegadores a partir de “coisas” da web hoje em dia (pense em favoritos, histórico, downloads, configurações, página de nova guia, etc.), e nos afastando do React para um moderno Web Components + HTML A primeira arquitetura teve um benefício *enorme* para os usuários, especialmente aqueles que usam hardware de baixo custo.”
Na verdade, isso significa que menos interface do usuário no Edge está sendo renderizada com código JavaScript. Menos JavaScript significa um espaço menor, o que se traduz em experiências web mais rápidas para os usuários. A Microsoft fez um pequeno vídeo para demonstrar as diferenças de velocidade:
“WebUI 2.0” é o novo mecanismo de UI para Edge e foi visivelmente mais rápido nesta demonstração.
Observe que, neste estágio, apenas alguns aspectos da UI do Edge sofreram essa alteração. Em resposta a um usuário do Mastodon que perguntou sobre isso, Russell confirmou que é “um esforço contínuo” e que a equipe Edge está “convertendo superfície por superfície, com cerca de 15% totalmente concluído até agora”.
Você também pode estar se perguntando por que um navegador estava usando React em primeiro lugar. Isso ocorre porque grande parte da interface do usuário nos navegadores é basicamente páginas da web. E parece que todos os principais navegadores caíram na toca do coelho React durante os últimos dez anos, assim como todos os outros. Portanto, recursos como a tela “Fundamentos do navegador” (mostrada no vídeo) ou os Favoritos do navegador – eles são renderizados como páginas da web. A Microsoft afirma que outros recursos do Edge, como “histórico, downloads, carteira e muito mais”, também serão convertidos para “WebUI 2.0” nos próximos meses.
As origens da WebUI 2.0
Em sua postagem no blog, a equipe do Microsoft Edge reconhece que as estruturas JavaScript modernas são boas em alguns aspectos – a produtividade do desenvolvedor é mencionada especificamente. Mas quando olharam mais de perto, descobriram que o custo dessa experiência de desenvolvimento era a velocidade relativamente lenta do navegador para os usuários finais. O dedo foi apontado para as tendências recentes dos desenvolvedores web:
“Muito do nosso código usava uma estrutura que dependia de JavaScript para renderizar a UI. Isso é conhecido como renderização do lado do cliente, que tem sido uma tendência popular entre os desenvolvedores da Web na última década porque ajudou os desenvolvedores da Web a serem mais produtivos e possibilitou experiências de UI mais dinâmicas.
Então eles se perguntaram: “Quão rápido poderíamos fazer as coisas se retirássemos essa estrutura e construíssemos nossa UI apenas usando a plataforma web?”
“Esperamos que mais sites comecem a se mover nessa direção de marcação, pequenos pacotes e menos código JavaScript de renderização de interface do usuário.”
— Equipe Microsoft Edge
Isso resultou no WebUI 2.0, “uma arquitetura inteiramente nova de marcação que minimiza o tamanho de nossos pacotes de código e a quantidade de código JavaScript executado durante o caminho de inicialização da IU”.
Isso resultou em uma arquitetura mais modular que depende de “um repositório de componentes da web ajustados para desempenho em mecanismos da web modernos”.
A equipe acrescenta: “Esperamos que mais sites comecem a se mover nessa direção de marcação, pequenos pacotes e menos código JavaScript de renderização de interface do usuário”.
Um momento do Gmail para 2024?
Admito que comparar a versão mais recente do Edge com o que o Gmail fez em 2004 pode ser um exagero. Mas é potencialmente muito significativo, dada a grande base de usuários em potencial do Edge – todos os PCs com Windows incentivam você a usar o Edge (embora, é claro, dados os julgamentos legais anteriores, ele não possa ser o navegador padrão).
Se a nova abordagem HTML-first do Edge encorajar projetos semelhantes de outras empresas e startups, então poderemos ter o início de um novo movimento de desenvolvimento web em nossas mãos. Para muitos na comunidade de desenvolvedores web, uma mudança para marcação primeiro/segundo JavaScript seria bem-vinda.
A postagem Do React ao HTML-First: Microsoft Edge estreia ‘WebUI 2.0’ apareceu pela primeira vez em The New Stack.