Impressões de uso do navegador Servo em Rust
(spacebar.news)- Com o crescimento da participação de navegadores baseados em Chromium globalmente, aumenta a preocupação com a diversidade dos padrões da web e com o futuro da web aberta
- O motor Servo desenvolvido em Rust tem como pontos fortes desempenho multi-thread e segurança de memória, sendo reconhecido como uma nova alternativa no campo de motores de renderização web
- Como ainda está em estágios iniciais, há bugs de renderização na maioria dos sites, mas em algumas páginas de demonstração ou em sites simples como a Wikipedia seu funcionamento é normal
- O projeto Servo, que começou originalmente sob a liderança da Mozilla, hoje é gerenciado pela Linux Foundation Europe e possui estrutura de decisão técnica com foco na comunidade e autonomia tecnológica
- No contexto da concentração dos motores de navegador, há uma indicação de que o desenvolvimento contínuo de motores alternativos como Gecko e Servo é importante para proteger a diversidade do ecossistema web
A concentração dos motores da web e seus riscos
- Nos anos 1990 e início dos anos 2000, havia convivendo motores de navegador diversos como Trident do Internet Explorer, Presto do Opera, Gecko do Netscape e KHTML do Konqueror
- Com o tempo, o KHTML foi integrado/substituído pelo WebKit, e o Presto e Trident (além do Tasman) foram integrados/substituídos pelo Blink (motor do Chromium)
- Como os principais navegadores modernos (Chrome, Edge, Opera etc.) tornaram-se praticamente todos baseados em Chromium/Blink, ocorre o fenômeno de que a implementação passa a se tornar o próprio padrão
- Problemas como vulnerabilidades de segurança e limitações de extensibilidade se tornaram mais evidentes, em que, ao depender de um único motor, todo o ecossistema da web é afetado ao mesmo tempo
O surgimento do motor Servo
- O Servo é um motor de renderização de navegador desenvolvido do zero em Rust
- Ele busca reduzir estruturalmente as vulnerabilidades de motores baseados em C/C++ (por exemplo, bugs de memória), aproveitando as vantagens de Rust de processamento multi-thread e segurança de memória
- O principal objetivo do Servo é ser um motor de renderização web embarcado, podendo ser usado também como alternativa a Electron e Android WebView, além de navegadores autônomos
- Sob a Linux Foundation Europe, a tomada de decisão técnica é operada com foco em comitê técnico, em vez de grandes empresas
- Por ter surgido como o primeiro motor de navegador totalmente novo em cerca de 10 anos, ele incorpora experiências de motores mainstream para melhorar sua maturidade
Experiência de uso e status atual do Servo
- É possível testar o Servo por meio de Nightly builds publicados no site oficial (para Windows, macOS, Android e Linux)
- Recursos básicos de navegador, como favoritos, extensões e sincronização de dados, ainda não são suportados
- Bugs de renderização aparecem na maioria dos websites, e em buscas do Google ou em alguns sites ocorre quebra de layout ou crash
- Páginas de estrutura simples, como Wikipedia e CNN Lite, funcionam normalmente
- Nas páginas de demonstração do Servo, é possível demonstrar desempenho gráfico, e em benchmarks como Particle Physics foram observados resultados de 55~60 FPS em um MacBook Pro recente (emulação x86)
- No teste Acid3, a pontuação foi de 83/100, inferior à dos navegadores principais (em torno de 95 pontos)
- O roadmap inclui, para o futuro, suporte a padrões web importantes como Shadow DOM e CSS Grid, com foco em melhorar a compatibilidade web
História do Servo e principais marcos
- O Servo começou na Mozilla em 2012, com a Samsung entrando no desenvolvimento em 2013
- O objetivo inicial previa também substituir o motor Gecko após sua estabilização, mas houve uma mudança para uma estratégia de substituir gradualmente partes do Gecko com código Servo
- Na atualização do Firefox 57 (Quantum), o motor CSS (Quantum CSS, Stylo) foi substituído por código Servo, observando-se melhorias significativas em desempenho e eficiência de memória
- Após os grandes cortes estruturais da Mozilla em 2020 (incluindo desenvolvedores do Servo), o Servo foi transferido para a Linux Foundation, recuperando financiamento e sendo mantido atualmente com desenvolvimento centrado na comunidade com apoio de empresas de código aberto como Igalia
Possibilidades futuras para o ecossistema de navegadores
- Com a vitória do Departamento de Justiça dos EUA em um processo sobre a posição monopolista do Google (Chrome e Android), estão em discussão medidas para proibir a venda do Chrome e contratos de busca com navegadores de terceiros
- A Mozilla declarou oposição a essas medidas, pois depende fortemente da receita de colocação de busca padrão do Firefox (necessária para manter o desenvolvimento do Gecko)
- Se a Mozilla perder os ganhos do Google, existe a possibilidade de o Firefox migrar para WebKit ou Chromium/Blink para reduzir custos de desenvolvimento
- Nessa situação, prevêm-se cenários como fork do código Gecko e operação comunitária, ou uma possível erosão gradual do Gecko
- A existência de motores alternativos como Servo e Gecko volta a emergir como elemento importante para manter a diversidade e o equilíbrio da plataforma web
Conclusão e implicações
- Mesmo em meio à unificação dos motores dos principais navegadores, o surgimento de alternativas inovadoras como o Servo desempenha papel importante em preservar a diversidade e a saúde do ecossistema da web
- Embora dificilmente se torne um navegador de uso diário em curto prazo, a exploração e evolução técnicas continuam sendo realizadas continuamente
- Há grande expectativa sobre a direção futura do Servo e seus efeitos de repercussão no setor
4 comentários
Estão mandando a gente baixar e usar algo que mal funciona? De onde vem essa arrogância, afinal?
Ouvi dizer que Rust é uma linguagem criada para desenvolver o Servo... tomara que o Servo dê certo.
O projeto Hurd continua vindo à minha cabeça… deve ser só impressão minha, né?
Comentários do Hacker News
No roadmap atual, Shadow DOM e CSS Grid estão como prioridades. Eu estou trabalhando no suporte a CSS Grid, e em breve deve ser adicionado suporte a "named grid lines and areas". Espero que isso faça com que mais layouts de sites funcionem corretamente. Posso estar sendo parcial porque é meu projeto, mas acho bem legal a forma como o Servo implementa CSS Grid. A implementação principal foi separada em uma biblioteca externa, o Taffy (link do GitHub), e essa biblioteca é amplamente usada no ecossistema de UI em Rust. Por exemplo, ela é usada em vários papéis, como Flexbox e Block layout, no motor web Blitz (link), no editor de texto Zed (link) e no engine de jogos Bevy (link). Espero que a abordagem do Servo, de dividir o motor web em módulos independentes e APIs públicas com base na experiência de desenvolvimento de bibliotecas modulares como Stylo e html5ever, ajude a reduzir a barreira de entrada para desenvolvedores de motores web e seja de grande ajuda para novos desenvolvedores de web engine no futuro
É a primeira vez que ouço falar do Blitz. Parece um projeto bem interessante e ambicioso, quase como um verdadeiro motor web "escondido". O Servo é amplamente conhecido desde que Rust apareceu pela primeira vez, mas o Blitz é igualmente impressionante
Fico curioso se a experiência de implementar diretamente recursos de um engine de navegador influencia a forma como você escreve HTML ou CSS. Também queria perguntar se você ainda pesquisa "css grid cheatsheet" três vezes por semana
Fico preocupado que essa abordagem de dividir funcionalidades em módulos possa acabar levando a excesso de funcionalidades ou fragmentação. Para enfrentar o Google, uma estratégia focada parece importante, e isso me preocupa
Estou usando o taffy para montar o layout do meu pequeno calendário e-ink baseado em Rust. Acho esse tipo de notícia muito interessante
Eu realmente gosto dessa abordagem de dividir o motor web em módulos de API pública que possam ser usados de forma independente. Quando olhei para WebRTC no passado, fiquei pensando por que fazer uma imitação meia-boca do Skype tinha que ser ou 50 linhas de JavaScript ou um pesadelo de uma semana compilando C++ do Chromium. Ainda bem que agora também existem crates Rust de WebRTC, então não são só os apps web que se beneficiam desse tipo de investimento
Tenho a sensação de que a Mozilla vai entrar para o hall da fama das empresas que "criaram a tecnologia do futuro e depois a deixaram escapar para os concorrentes", como a Xerox. Ela chegou a passar o Google no desenvolvimento de navegadores com Rust e Servo, mas ainda não consigo entender por que não continuou levando isso adiante
A Mozilla é diferente da Xerox. Se alguém for a nova Xerox, é mais o Google. O Google investe enormes quantias em departamentos de P&D sem plano de negócios. Um exemplo representativo são os modelos Transformer — na prática, o Google criou os LLMs primeiro, mas acabou ficando para trás em relação à OpenAI. O sucesso da Mozilla sempre esteve concentrado em navegadores web, como Netscape e Firefox. O próprio Rust, em essência, foi criado para navegadores. O fato de ele ser útil em outros lugares é apenas um bom efeito colateral
O Google é a principal fonte de receita da Mozilla desde 2006. Para a Mozilla continuar existindo, basta manter o Google satisfeito. Isso gera potencial para conflitos, mas do ponto de vista da Mozilla é um acordo bastante bom
Acho que a Mozilla já era. Ela dependeu demais do Google e agora pode perder até isso. Servo e Ladybird serão o futuro, e é realmente impressionante ver o Ladybird avançando tão rápido com uma equipe pequena
Se a Mozilla abandonar o Gecko, esse será o momento de fazer um hard fork e sair da Mozilla. E, para constar, abandonar o Gecko significa migrar para Chromium, não para Servo
Tenho a impressão de que é difícil fazer as pessoas pagarem por um navegador. Elas gastam sem problema 10 euros em cerveja, mas vi muita gente ao meu redor tentando evitar a licença vitalícia de 0,99 euro do WhatsApp
Ainda não consigo entender por que a Mozilla desistiu do futuro técnico do Firefox. Mas, quando se olha para a Mozilla no fim das contas, acompanhar o fluxo de dinheiro faz muita coisa fazer sentido
O encerramento do Pocket também é um caso triste. Às vezes imagino uma pegadinha de 1º de abril em que a Mozilla anunciasse o fim do Firefox para se concentrar no negócio principal. É uma piada amarga, sugerindo que a verdadeira atividade principal parece ser encerrar lindamente produtos populares
Pelas várias saídas e pelo estilo de comunicação, a Mozilla parecia ser uma empresa extremamente política naquela época. O Servo tinha comunicação muito ativa e o Rust também tinha um clima bom, então às vezes penso que isso pode até ter incomodado a chefia. A Mozilla ainda é tocada principalmente por gente antiga, e considero que a culpa foi em grande parte dos erros da alta gestão
Ainda acredito fortemente que o Servo pode ser uma alternativa real ao monopólio do Chrome/Chromium. Não entendo por que a Mozilla desistiu disso nem por que a Linux Foundation quase não dá apoio
Se você olhar a estratégia da Mozilla no longo prazo como uma busca por independência do dinheiro do Google, ela faz sentido. A receita não vinda do Google realmente aumentou de 80 milhões de dólares em 2022 para 150 milhões em 2023. Os ativos totais também cresceram 100 milhões de dólares por ano, chegando a 1 bilhão de dólares em 2023. A participação do dinheiro do Google caiu de 90% em 2020 para 75% em 2023. Ainda não é independência total, mas existe uma direção. Ao contrário do que as pessoas costumam dizer, se você olhar apenas o fluxo de dinheiro, pode chegar a outra conclusão. Muita gente critica dizendo que o Servo deveria ter sido mantido, mas acho que, na prática, o Servo não teve um papel tão grande no Firefox depois do Quantum
Você está perguntando se é verdade que a maior parte da receita da Mozilla vem do Firefox?
Também existe o Ladybird (site oficial) para desafiar o monopólio do Blink. Ainda não está claro como isso vai evoluir, mas estou na expectativa
Não entendo bem qual é o objetivo do Ladybird. Está claro que não é só um projeto de hobby, já que há engenheiros em tempo integral e também arrecadação de doações. Mesmo assim, é difícil imaginar que ele consiga competir com Blink, WebKit e Gecko em funcionalidade, segurança e desempenho. Como não são equipes enormes, acho que sem adoção em massa não há muito efeito em fazer apenas o engine. Isso também vale para o Servo, mas o Servo tem objetivos técnicos um pouco mais convincentes. No Ladybird, não vejo esse tipo de informação com tanta clareza
Tecnicamente, não vejo muito apelo no Ladybird. Ele é basicamente escrito em C++, então não parece ter uma diferenciação em relação a Gecko e Blink. O Servo tem diferenciais claros de projeto técnico, como segurança e paralelismo, e isso o torna atraente
Espero que o Ladybird tenha sucesso. Agora que também é possível apoiá-lo diretamente, acho isso significativo. Ao contrário da Mozilla, tenho confiança de que as doações arrecadadas serão usadas integralmente no desenvolvimento do navegador
Fico curioso se o Ladybird está tentando migrar para Swift. Se um engine de navegador for desenvolvido em C++, isso não me agrada muito, mas parece uma escolha prática e focada no resultado. Se fosse em Rust, eu reconheceria esse aspecto mais voltado para o futuro. Mas fazer um engine em outra linguagem, como Swift, me parece mais uma decisão política interna de empresa. Acho questionável escolher deliberadamente uma linguagem que ainda tem pouco ecossistema de suporte (tweet de referência)
O teste Dogemania roda suavemente a 60 FPS até 400 imagens em um MacBook Pro M4 Pro. No Chrome, porém, os 60 FPS se mantiveram até 1400 imagens, e acima disso fiquei com preguiça de continuar e fechei
Eu também fiz o mesmo experimento, e a diferença entre Firefox e Chromium foi decepcionantemente grande. No Chromium, mesmo passando de 1000 imagens, ele continuou em 100 FPS, enquanto no Firefox, ao passar de 500 imagens, já caía imediatamente abaixo de 60 FPS. Talvez não tenha sido um teste totalmente justo — no Chromium eu não tinha extensões e quase não uso esse navegador —, mas isso me mostrou muita coisa sobre o desempenho comparativo
Se no dogemania as imagens ficam paradas depois da animação, fico pensando se esse não seria um caso realmente fácil de otimizar. Dá até a impressão de que computadores antigos como o Amiga conseguiriam lidar com isso indefinidamente
Chamar o Servo de engine "novo" é um pouco forçado
Eu sabia que o Rust tinha sido criado para o navegador web Servo
Sobre a opinião de que “se restar apenas uma implementação de um padrão, ela própria vira o padrão”, não entendo bem por que isso seria um problema. Se a implementação for open source e a especificação for decidida por um comitê administrado por várias partes, me parece aceitável. A situação atual, de despejar recursos para criar vários engines, parece mais desperdício. Acho que seria mais eficiente ter apenas um motor de navegador, como o kernel Linux, e distribuições diferentes por cima
Por melhores que sejam as intenções, implementações sempre deixam bugs e pequenas falhas. Sem uma segunda implementação independente, no fim o bug em si vira padrão porque "funciona em todo lugar". Se páginas web passarem a depender desses bugs, então elas acabam funcionando com base em falhas específicas de uma implementação, e não na especificação. Foi isso que fez do suporte a compatibilidade do MS Windows um pesadelo, com várias camadas de UI antiga empilhadas. Com várias implementações independentes, o padrão realmente pode ser mantido e evoluir, e a otimização também fica mais fácil
Em teoria isso parece aceitável, mas na prática acho indesejável porque um desenvolvedor único nem sempre tem os mesmos interesses dos usuários e do benefício geral. Especialmente recentemente, a descontinuação do manifest v2 no Blink desagradou os usuários
Quanto mais engines de navegador existirem, menor o risco de vulnerabilidades de segurança se concentrarem em um só. Mesmo com linguagens memory-safe, erros lógicos ainda podem causar danos, então a diversidade é importante
Você falou em uma estratégia de “um engine com várias distribuições”, mas, para quem está acostumado com ambientes BSD ou com ZFS, a sensação de estabilidade e acabamento fica bem evidente justamente quando se sai desse modelo antigo
As opiniões do Google e de pessoas próximas a ele já influenciam fortemente a padronização. Se tudo passar a girar em torno do Chromium, a situação vai piorar ainda mais. Talvez só um desastre completo faça todo mundo reconhecer os limites de lugares como o W3C e o WHATWG
Sobre a observação de que “a maioria dos sites tem pequenos bugs de renderização e alguns simplesmente não funcionam; há muitos elementos sobrepostos nos resultados de busca do Google e a home do MacRumors trava depois de rolar, mas Wikipedia, CNN Lite, sites pessoais e o texto da NPR funcionam perfeitamente” — ao ver isso, quase nunca vejo alguém dizer que o Google ou o MacRumors deveriam corrigir seus sites para funcionar no Servo. Em vez disso, a conclusão costuma ser apenas que o Servo precisa se comportar como o Chrome/Chromium, e isso me decepciona bastante. Se for assim, então (a) empresas de publicidade acabam definindo o padrão e (b) quem faz páginas web passa a ter incentivos errados. Ajustar as coisas para o caminho mais simples, como Wikipedia ou CNN Lite, na verdade parece mais fácil. Eu acho que um navegador “padrão” deveria buscar o padrão de verdade, e não o mais popular. O verdadeiro padrão é fazer funcionar tanto em navegadores pouco populares quanto nos populares. No fim, argumento que a resposta está em corrigir as páginas web, não os navegadores. Eu ainda faço experimentos com a biblioteca original libwww do w3c e suas ferramentas. Com pequenas modificações, ela ainda funciona muito bem, mais de 30 anos depois, para otimização de páginas web baseadas em texto. A internet é um bem público, mas os navegadores e páginas de hoje estão inclinados demais para otimização de anúncios e coleta de dados. Só faz sentido priorizar páginas e navegadores que realmente sirvam aos usuários da www. Abaixo está um script simples para compilar um binário estático com libwww
É realmente triste ver a Mozilla deixando de ser uma empresa competitiva de navegadores e se transformando cada vez mais em uma organização com perfil de ativismo. Isso dá a sensação amarga de que o produto principal foi enfraquecendo cada vez mais