Quando a equipe do navegador Edge da Microsoft lançou o WebUI 2.0 em maio, um projeto que visava substituir componentes React por componentes web nativos , seu objetivo principal era tornar o Edge mais rápido para usuários finais. A ideia central era que adotar uma "arquitetura markup-first" reduziria a dependência de JavaScript em seu produto, o que significaria menos código para processar no lado do cliente — portanto, uma melhor experiência para o usuário.
Para descobrir como está o projeto WebUI 2.0 — incluindo o que o inspirou e seus objetivos finais — conversei com Andrew Ritz , que lidera a equipe Edge Fundamentals na Microsoft.
O que são Componentes Web?
Antes de entrarmos nos detalhes, vamos esclarecer rapidamente o que são componentes web. O site da comunidade WebComponents.org os descreve como "um conjunto de APIs de plataforma web que permitem que você crie novas tags HTML personalizadas, reutilizáveis e encapsuladas para usar em páginas web e aplicativos web". Ritz coloca desta forma, ao aconselhar sua própria equipe sobre como abordar esse paradigma de desenvolvimento web: "Sempre que você quiser fazer um novo controle [e] se encontrar escrevendo qualquer JavaScript, pause — pare — converse com um engenheiro sênior e pergunte, como você resolve isso com HTML e CSS?"
Por que a Microsoft abandonou o React?
Ritz diz que o objetivo de sua equipe é converter cerca de 50% das interfaces de usuário da Web baseadas em React existentes no Edge em componentes da Web até o final deste ano. Mas qual foi o ímpeto para o projeto — por que eles decidiram que precisavam se afastar do React em suas interfaces web?
Ritz explicou que começou observando as solicitações de trabalho que sua equipe de "web desk" na Edge estava recebendo — "tanto externas, para ajudar a melhorar o projeto Chromium, quanto solicitações internas". Um exemplo do último foi o aplicativo web Excel, que usa o elemento Canvas. Então, uma das perguntas que eles tiveram que considerar foi: "Como podemos tornar o Canvas mais performático?" O elemento HTML é usado para desenhar gráficos dinamicamente por meio de scripts — e isso geralmente é feito com JavaScript.
Para ajudar a equipe do web desk a lidar com solicitações como essa, Ritz queria adotar uma "abordagem mais opinativa" que também abordasse questões como lentidão em aplicativos da web.
"E então o que fizemos foi começar a olhar internamente para todos os lugares onde estávamos usando tecnologia web — todas as nossas interfaces de usuário web internas — e percebemos que elas eram realmente inaceitavelmente lentas."
A resposta para essa lentidão? React.
"Percebemos que nosso desempenho, especialmente em máquinas de baixo custo, era realmente terrível — e isso porque adotamos essa estrutura React e usamos o React provavelmente de uma das piores maneiras possíveis."
O uso do React dentro da Microsoft continuou se agravando ao longo do tempo, à medida que mais equipes o usavam para suas UIs. Então a empresa acabou com "um pacote gigantesco do qual todos dependiam", disse Ritz. Era uma bagunça de dependências de pacotes entre aplicativos da web.
"Foi uma experiência terrível, especialmente nas máquinas de menor custo e de menor qualidade", disse Ritz. "Estávamos vendo tempos de inicialização de vários segundos para algo que é ostensivamente local. Foi simplesmente, você sabe, chocante."
Interfaces de Usuário da Web no Edge
Dentro do próprio Edge, há entre 50 e 100 UIs da web, disse Ritz, acrescentando que "cada uma delas é como seu próprio pequeno aplicativo da web". Cerca de dois terços dessas UIs da web do Edge foram construídas no React, antes do início do projeto Web UI 2.0. Curiosamente, a equipe do Edge usou originalmente o React para se diferenciar do Chrome.
"A equipe, enquanto fazia a portabilidade para o Chromium, decidiu, bem, precisávamos adicionar algum tipo de diferenciação de IU — diferente do que o Chrome tinha — e então, no processo, eles fizeram esse tipo de conversão pesada para React."
Então, o atual projeto Web UI 2.0 está, de certa forma, revendo grande parte do trabalho de desenvolvimento original feito no Edge.
A equipe de engenharia de Ritz possuía uma dessas UIs da Web React: "browser essentials". Quando você usa o Edge, ele é ativado clicando em um ícone de coração na barra do navegador, que abre uma barra lateral. Isso se tornou o ambiente de teste para ver quais melhorias de desempenho poderiam ser feitas usando componentes da web para essa UI, para substituir os componentes do React.
Quão Difíceis São os Componentes da Web?
Recentemente, outro debate surgiu nas mídias sociais sobre componentes da web versus componentes de framework. Ryan Carniato , criador do framework SolidJS JavaScript, escreveu uma postagem de blog com o título provocativo, " Web Components Are Not the Future ". Essencialmente, seu argumento é que um framework como o SolidJS é capaz de fazer mais do que componentes da web em certos cenários e é mais fácil de implementar. Ele descarta os componentes da web como "um compromisso completo".
Em resposta a Carniato, o criador do Shoelace, Cory LaViska, argumentou que os componentes da web oferecem estabilidade e interoperabilidade.
"As pessoas que realmente entregam software estão cansadas da rotatividade de frameworks", escreveu LaViska. "Eles estão cansados de merdas que escreveram no mês passado já estarem desatualizadas. Eles querem estabilidade. Eles querem saber que as coisas que eles constroem hoje funcionarão amanhã."
LaViska também destacou que os componentes da web não fazem todas as coisas que os componentes do framework fazem "porque eles são uma implementação de nível inferior de um elemento interoperável".
Perguntei a Andrew Ritz como sua equipe de engenharia se adaptou aos componentes da web e se eles são tão difíceis de implementar quanto alguns críticos alegam.
"Nossa abordagem tem sido realmente dizer, vamos usar o máximo possível de construções internas", ele respondeu. "Então, o máximo de elementos internos que existem dentro do navegador, e não tem sido tão ruim fazer isso."
No entanto, Ritz admite que "o esforço para fazer com que os componentes da web tenham um bom desempenho definitivamente tem sido um problema."
Ele observou que os desenvolvedores do Edge têm a vantagem de usar o próprio framework Fluent UI da Microsoft , que inclui componentes React e componentes web (entre outros tipos de componentes — como os centrados em dispositivos móveis para iOS e Android). Mas mesmo usar um framework de toda a empresa para implementar componentes web não tem sido fácil.
"Houve casos em que um controle integrado precisa de muito trabalho — você sabe, é bem pesado com polyfills, ou coisas assim — que nunca, nunca iremos precisar. Então, o esforço para fazê-los funcionar bem definitivamente tem sido um problema."
Em termos do que Ritz chama de "agilidade de desenvolvimento" em torno de componentes da web (outros podem chamar de "experiência do desenvolvedor"), ele diz que "nós realmente vimos algumas melhorias muito boas". Por exemplo, ser capaz de focar em HTML e CSS significou que os desenvolvedores e designers estão mais alinhados — porque eles estão falando a mesma língua.
"Ao nos concentrarmos [os desenvolvedores] em usar HTML e CSS, meio que removemos toda essa camada de tradução, onde alguém [na equipe de desenvolvimento] pode ter que pegar, tipo, um wireframe e convertê-lo para alguma outra coisa. […] E então isso [era] um grande impedimento para a produtividade do desenvolvedor para nós, e eliminamos todo esse loop."
Adoção Generalizada de Componentes da Web
É justo dizer que é mais fácil para a equipe de navegadores da Microsoft implementar componentes da web do que a equipe média de desenvolvimento da web. Além de ter a estrutura Fluent UI da Microsoft para recorrer, a equipe do Edge também está construindo um produto de software que só precisa atender a um navegador: o seu próprio. Enquanto quase todas as outras equipes de desenvolvimento da web precisam garantir que seu produto seja utilizável em uma variedade de navegadores diferentes: do Chrome ao Edge, Safari, Firefox e outros.
"Talvez tenhamos mais facilidade porque podemos dizer que dependemos apenas do Edge para nossas coisas locais", é como Ritz coloca. "Isso pode ser como essa verdadeira expressão da [web] moderna e mais recente. Enquanto um proprietário de site — nossa, eles podem ser forçados a dar suporte ao Safari, ou algo assim, que não dá suporte a metade das construções que gostaríamos… e isso traz complexidade."
Dito isso, a intenção da Microsoft é lançar alguns de seus pacotes WebUI 2.0 como código aberto — assim como um conjunto de "padrões de plataforma web". No entanto, Ritz observa que muitos desenvolvedores externos podem não querer fazer as coisas exatamente da mesma maneira — por exemplo, muitos desenvolvedores gostariam de escolher uma estrutura de estilo diferente do Fluent UI. Mas, no mínimo, a equipe de Ritz será capaz de fornecer "padrões de aprendizado" para outros.
Uma etapa intermediária provavelmente será tentar convencer outros produtos web da Microsoft a migrarem para componentes web.
"Não sei exatamente o que o resto da Microsoft fará", disse Ritz. "Nós [a equipe do Edge] meio que queremos limpar nossa casa com […] uma biblioteca comum e tudo mais. Mas acho que seria uma boa prova se pudéssemos fazer com que alguns dos maiores sites não componentes da web dentro da Microsoft migrassem."
Mas ele acrescentou que eles estão abertos a parceiros externos para ajudar a liderar o caminho para um mundo pós-React.
"Se pudéssemos encontrar alguém externo que fosse significativo, que quisesse fazer parceria nisso — certamente ficaríamos encantados."
