Ladybird ultrapassa o limite de 90% da Apple no web-platform-tests

• O Ladybird alcançou o limite de 90% de aprovação da Apple no teste automatizado de padrões da web chamado web-platform-tests
• Esse teste mede de forma abrangente a compatibilidade com padrões da web do navegador, como HTML, CSS e JavaScript
• Ao registrar uma alta taxa de aprovação nos testes em nível semelhante ao navegador da Apple (principalmente o Safari), o Ladybird garantiu que seus algoritmos centrais e sua implementação dos padrões da web tenham confiabilidade semelhante à de navegadores líderes do setor
• Este é um marco importante que mostra que um novo navegador de código aberto pode competir de forma concreta com os líderes estabelecidos do mercado

[shakespeares]

Espero que consiga ficar lado a lado com o Blink e o WebKit.

[GN⁺]

Comentários do Hacker News

• Como alguém que já se envolveu profundamente com o web-platform-tests, acho que é preciso ter cautela ao usar taxa de aprovação de testes como métrica. Isso não é para diminuir a conquista do Ladybird; o rápido progresso do Ladybird é realmente impressionante, e se o web-platform-tests ajuda essa equipe, isso por si só já é ótimo. É muito bom ver novas implementações de plataforma web como Ladybird, Servo e Flow surgindo. Dito isso, o web-platform-tests foi otimizado originalmente como uma ferramenta de engenharia, não foi projetado como uma métrica objetiva. Por exemplo, a proporção de testes relacionados a decodificação dentro do total é excessivamente alta. O motivo não é que isso seja especialmente difícil no desenvolvimento de navegadores, mas sim que esses testes são fáceis de gerar. Além disso, tentamos reduzir as barreiras técnicas e sociais para que qualquer um possa contribuir livremente com testes úteis. Isso não combina com a criação de uma boa métrica, mas combina muito bem com um bom recurso de engenharia. O Interop Project resolve parcialmente esse problema com outros trade-offs e subconjuntos seletivos de testes, mas o sistema atual já foi desenhado para ter como alvo apenas implementações de motores de navegador quase completas
  • No tweet é mencionado que essa métrica é um critério arbitrário imposto pela Apple à equipe do Ladybird. Nas atualizações mensais do Ladybird, eles também divulgam a contagem de testes aprovados excluindo os testes de encoding, que inflacionam demais a taxa de aprovação
  • Fico me perguntando se seria impossível usar como métrica um subconjunto selecionado de testes
  • Nesse caso, é preciso falar diretamente com a Apple. Foi a Apple que criou esse critério
  • Não entendo por que levantar esse ponto aqui. Essa não é uma métrica do Ladybird, é uma exigência da Apple para o iOS
• É muito legal que o navegador Ladybird pareça estar chegando a um estágio utilizável em breve. Eu achei que ainda levaria mais alguns anos, não imaginava que ele ficaria competitivo tão rápido
  • Não usei pessoalmente, mas vi alguns vídeos de resumo mensal. Passar em testes e ter velocidade suficiente para uso diário rápido são questões totalmente diferentes. O Ladybird não parece ser tão rápido assim no momento. Ainda assim, o resultado de desenvolvimento da equipe como um todo é extraordinário
  • Fico curioso se aquele ditado “90% da conclusão leva 90% do tempo, e os 10% restantes também levam outros 90%” se aplica ao Ladybird. Mesmo que seja verdade, ainda parece um prazo de desenvolvimento bem razoável no geral
  • Recomendo não criar expectativa demais. Pelo relatório de desenvolvimento de setembro, ainda há muita coisa para corrigir. Sem dúvida foi um avanço enorme, mas parece que o Ladybird ainda vai levar mais alguns anos para ficar pronto
  • Há 3 anos eu era cético em relação ao Ladybird. Mas, primeiro, agora eles têm 8 engenheiros em tempo integral, o que eu não esperava, e, segundo, de fato já se passaram 3 anos. Então hoje estou bem mais otimista. Claro, ainda falta muito para competir com o Chrome, e continuo me perguntando qual é o valor de construir isso do zero em vez de fazer um fork de um motor existente
  • Antes eu achava que criar um motor de navegador totalmente novo levaria várias décadas, mas é surpreendente ver pessoas tão dedicadas como a equipe do Ladybird realmente conseguindo fazer isso acontecer
• Em um tweet relacionado, foi mencionado que isso é um marco importante para o Ladybird ser considerado como motor de navegador alternativo no iOS
  • Agora entendo por que a Apple aparece no título da matéria
  • Mas isso vale, no mínimo, só dentro da UE; fora dela, a Apple não vai permitir, por melhor que o motor seja
• É realmente impressionante como o Ladybird, um projeto independente e não corporativo, cresceu tão rápido
  • Entendo a expressão “non-corpo”, mas na prática a própria organização Ladybird é uma entidade legal. Veja os documentos relacionados
  • Quando se pensa na quantidade de coisas que um navegador faz, um projeto desse porte é realmente gigantesco. Só fazer um excelente renderizador de HTML/CSS e um motor de JS já seria impressionante, mas, depois que se entra no ecossistema, ainda é preciso continuar acompanhando as mudanças futuras. O Chrome consegue até resistir a novas propostas, enquanto navegadores menores parecem quase sempre só correr atrás
  • Tenho dúvidas se o Ladybird é mesmo tão não corporativo assim. Se bem me lembro, houve algum patrocínio corporativo. Nesse sentido, não dá para dizer que ele seja melhor do que o Gecko sem fins lucrativos do Firefox
  • Se o Ladybird conseguir manter esse ritmo, espero que até o fim de 2027 ele se torne um concorrente de verdade. Mas, pessoalmente, acho que o Servo, o motor com mais funcionalidades depois dele, também precisa de um esforço concentrado assim. FF/Mozilla não parece muito interessada, então um projeto de navegador separado é realmente necessário
  • Fazer os testes passarem com segurança é uma questão completamente diferente. Isso são testes de conformidade, não testes de segurança. Ainda assim, é extremamente impressionante
• Fico pensando em quão difícil será esse último 10%. Em projetos de software em geral, alcançar os 10% finais costuma exigir mais de 90% de esforço adicional
  • E o último 1% vai continuar mudando e nunca realmente acabar. Os 90% são segundo o critério da Apple. Mas fico curioso sobre qual seria o nível exigido pelos usuários comuns
  • Navegadores têm sido historicamente alguns dos maiores e mais difíceis projetos que existem. Não vejo por que esperar que isso fique fácil. Se oferecerem uma recompensa de 20 mil dólares por encontrar um segfault, talvez aí dê para dizer que está realmente pronto
• Eu compilei e executei o Ladybird. Surpreendentemente, um bom número de sites já abre bem. O YouTube ainda não funciona, e há crashes no Vimeo e no campo de comentários do Reddit. Mesmo assim, o resultado é muito animador. A compilação exige cerca de 6 GB de espaço em HDD
• Dá para ver um grande salto no gráfico! Fico curioso sobre o que causou essa melhora
  • Na thread do Twitter, alguém perguntou isso diretamente ao Andreas, e a causa foi a fusão da especificação da CSS Typed Object Model API
  • Esse Pull Request fez cerca de 6400 testes relacionados a CSS passarem a mais. Mesmo assim, talvez isso não explique todo o pico visto no gráfico, mas certamente ajudou. Detalhes do PR
  • O gráfico não tem eixos, então não dá para saber se foi mesmo um grande salto. Por exemplo, pode ter ido de 89% para 90,2%. Talvez essa mudança não seja um caso especialmente maior do que os aumentos anteriores que não aparecem no lado esquerdo do gráfico
• Fico curioso sobre como está o desenvolvimento do Ladybird para GTK
• Fico curioso sobre qual motor de JS o Ladybird usa
  • Usa o próprio motor, o LibJS GitHub do LibJS
  • Todo o código-fonte é original
• Do ponto de vista de engenharia, é surpreendente que uma grande empresa defina padrões de qualidade e restrinja o acesso de softwares de terceiros às APIs. Do ponto de vista do cliente, é bom saber que há verificação de segurança graças a padrões rígidos de qualidade e restrições de API no nível do sistema operacional
  • Do ponto de vista do consumidor, as atualizações do navegador ficam mais lentas, inclusive correções de bugs e de segurança, porque o navegador precisa passar pela revisão da Apple. No Mac e em outras plataformas, isso não é necessário. A Apple faz com que navegadores que não usam o Safari nem funcionem direito, e não existe esse tipo de ambiente no Mac ou em outros sistemas operacionais. E, embora finja permitir motores alternativos na UE, na prática isso só aumentou a conformidade maliciosa, então motores alternativos continuam sendo algo quase só teórico. No fim, isso também prejudica o consumidor
  • Do ponto de vista do consumidor, até usar serviços como GitHub ou Threads no navegador oficial do sistema operacional traz problemas
  • Do ponto de vista de engenharia, o que eu gostaria de saber é se o navegador da Apple também cumpre seus próprios critérios. Só o Safari apresenta certos bugs com uma frequência absurda. Há muitos bugs comuns, do tipo que qualquer pessoa que já tenha feito uma página web provavelmente encontrou ao menos uma vez
  • Fico me perguntando se existe mesmo a opção de simplesmente não usar um navegador quebrado
  • Isso não é surpreendente; acho que é uma tentativa de manter o controle de forma anticompetitiva e injusta