Engenharia de Navegadores Web (2021)

 (browser.engineering)
2 pontos por GN⁺ 2024-10-16 | 1 comentários | Compartilhar no WhatsApp
  • Web Browser Engineering aborda desde redes até JavaScript e propõe a tarefa de construir você mesmo um navegador web básico, mas completo, com alguns milhares de linhas em Python
  • O fluxo de aprendizado vai do carregamento de páginas à exibição de documentos, execução de aplicações e recursos de navegadores modernos, conectando em sequência HTTP, HTML, CSS, DOM, segurança e pipeline de renderização
  • A parte inicial se concentra na implementação dos fundamentos do navegador, como URLs e requisições HTTP, criação de janelas e desenho em canvas, quebra de linha de texto e espaçamento entre linhas
  • A parte intermediária e final inclui construção da árvore HTML, layout, aplicação de estilos, envio de formulários, resposta a eventos, cookies e login, além de XSS e CSRF
  • A parte final avança para composição, loop de eventos, animações com GPU, árvore de acessibilidade, iframe, invalidação e correção de edição, permitindo uma visão ampla dos elementos de implementação dos navegadores modernos

Aprenda a estrutura do navegador implementando você mesmo

  • Web Browser Engineering foi estruturado para explicar como um navegador web funciona por meio da implementação direta de um navegador básico, mas completo
  • A linguagem de implementação é Python, e a escala total da implementação é de alguns milhares de linhas
  • O escopo vai de redes até JavaScript
  • O livro impresso pode ser comprado na Bookshop, B&N e Amazon
  • Há traduções publicadas em Hanbit para coreano e O’Reilly para japonês
  • As atualizações podem ser acompanhadas no blog, Mastodon e Twitter, e também há um fórum de discussões no GitHub

Fluxo do sumário

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-16
Opiniões no Hacker News

  • Um ponto positivo deste livro é que ele trata separadamente das “coisas que não foram feitas”
    Layout é realmente difícil, e mesmo lidar só com tabelas, sem CSS, já é difícil. Quando o CSS entra na jogada, o layout fica complexo a ponto de ser quase impossível
    Fico em dúvida se existe alguém capaz de manter na cabeça toda a especificação de CSS e os comportamentos relacionados. O CSS+HTML+JavaScript de hoje se aproximou de uma linguagem de tecnologia de páginas dinâmicas (PDL) e possivelmente é um dos softwares mais complexos da atualidade
    Além disso, decodificação de vídeo não consome tanta bateria quanto antes, porque é descarregada para o hardware

    • Para implementar layout CSS em nível de produção, é necessária uma quantidade enorme de código, e o código-fonte do Servo mostra isso bem
      Por exemplo, este arquivo implementa apenas contextos block/inline; há um pouco de boilerplate em Rust, mas a maior parte é lógica real que lida com várias partes da especificação. Há uma pasta inteira cheia de arquivos assim: https://github.com/servo/servo/blob/main/components/layout/f...
      Ainda assim, implementar um motor de layout é possível. CSS não é magia; há uma especificação que pode ser transposta cuidadosamente para código. Mostrar esse tipo de código a pessoas frustradas por acharem que CSS parece arbitrário ajuda a entender que também há lógica no ambiente de execução
      Claro, não é algo em que você vá clicar com frequência como ao examinar a implementação de uma biblioteca, mas, nesse aspecto, acho que não é muito diferente de algo como React
    • Sim, layout é difícil, e acho que especialmente por dois motivos
      Primeiro, as partes mais centrais do layout, como CSS 2, foram projetadas de forma bastante desleixada, e recursos estranhos interagem entre si de maneiras estranhas. Coisas como float e clearance, colapso de margens. Parte desse núcleo foi pensada para ser usada de forma universal em todos os modos de layout, mas não se encaixa bem em outros modos. Por exemplo, margin e padding não têm um propósito claro em elementos grid
      Segundo, não é bem modularizado como as APIs de JavaScript. APIs de JavaScript muitas vezes são implementadas de forma independente, mas módulos de layout podem ser aninhados de várias maneiras, então todos afetam uns aos outros. Especificações mais modernas, como grid, tentam ser mais rigorosas, mas existe o problema fundamental de que vários modos de layout precisam compartilhar o mesmo recurso comum: a tela 2D real
    • Layout era tão difícil que acabei desistindo de um projeto pessoal feito com Common Lisp e ncurses, e me tornei aquilo que eu havia jurado eliminar: um desenvolvedor React
      Não devo ser o único que quer uma linguagem de layout mais simples que CSS, mas que incorpore as lições dos últimos 20 anos e maximize o produto entre simplicidade e expressividade. Fico curioso se existe algum projeto levando a sério o design de algo assim, ou se todo mundo aceitou o CSS3 e está esperando um backend LLVM, ou simplesmente voltou para texto puro
    • No React Native, foi como se os engenheiros do Facebook tivessem simplesmente desistido e dito: “o que damos a vocês é apenas layout flexbox”, e as pessoas acharam bem aceitável. Claro, há quem reclame da falta de display grid
      https://github.com/facebook/yoga
    • Esta Torre de Babel vai ruir algum dia
      Layout não precisa ser tão complexo assim. Existem dezenas de frameworks GUI com sistemas de layout mais simples, e eles são suficientes para os aplicativos que as pessoas usam

  • Parece interessante. Cerca de 15 anos atrás, comecei a criar um navegador headless e o mantive por alguns anos
    Usei SpiderMonkey como interpretador JavaScript e implementei o DOM por conta própria. Ele executava todo o JavaScript moderno da época, AJAX etc., e depois também adicionei um runtime Flash customizado. Era um projeto que fazia quase tudo, exceto desenhar na tela, então foi muito divertido
    Quero muito ler este livro

    • Fico curioso sobre qual biblioteca você pretende usar para desenhar na tela

  • Fico feliz que engenharia de navegadores pareça estar virando tendência agora
    O ecossistema está, na prática, em um estado bem frágil, definido apenas por Google, Apple e Mozilla. No futuro, gostaria de ver um mundo com mais engines de navegador independentes

    • Não acho que reescrever uma engine de renderização para HTML seja algo viável. Você nunca terminaria. HTML hoje é, na prática, uma especificação totalmente possuída por Google e Apple, e é complexa demais para implementar do zero
      A área interessante são as tecnologias de UI/documentos pós-HTML. O Typst mencionado em outra thread é algo como um LaTeX melhor, e Markdown também teve um grande impacto. Há muito espaço para criar “HTML, mas melhor”. Nem precisa necessariamente ser um formato de marcação. Typst e React HTML borram a fronteira entre código e dados, e Jetpack Compose mostra uma forma de usar os recursos de DSL do Kotlin para criar algo que parece uma descrição de UI, mas na verdade é código
      Claro que, para isso, seria preciso distribuir um “navegador” para esse formato ou encontrar uma forma de exibi-lo nos navegadores existentes. Ainda assim, é possível compilar para JavaScript/HTML/WASM. Também daria para usar um toolkit de GUI portável como JavaFX e ganhar acessibilidade. Dá para fazer as duas coisas
      Ao definir sua própria linguagem de UI, você pode tentar muita coisa que o HTML não faz bem. O exemplo clássico é a separação entre conteúdo e estilo. O HTML tentou, mas nunca conseguiu de fato; o XSL:T tentou com mais afinco, mas era uma linguagem puramente funcional estranha que usava sintaxe XML. O React é razoavelmente bom em transformar JSON em caixas, mas o protocolo subjacente é sempre uma gambiarra acrescentada depois, o que dificulta criar ferramentas úteis por cima dele
      Outra ideia seria um formato que, por padrão, fosse imune a XSS
    • Eu gostaria de ver um navegador que usasse menos memória. Fora isso, tirando o spyware do Capital-G Google Chrome e do Capital-M Mozilla Firefox, não acho que o pequeno número de engines seja um grande problema. São milhões de horas de trabalho acumuladas sem duplicação
      Mas eu gostaria de uma alternativa ao HTML. Se eu fosse criar um navegador, acho que focaria em substituir o HTML porque não o suporto, e também gostaria de trocar o JavaScript porque o runtime é pesado
      Por exemplo, seria bem engraçado um navegador que quase não tivesse runtime JavaScript e executasse apenas WASM
    • Talvez seja preciso uma plataforma ou um protocolo totalmente novo. O que temos hoje está completamente saturado de complexidade
    • Fico curioso se você já deu uma olhada em engines de navegador alternativas como Servo, Ladybird, Goanna, NetSurf, Sciter e Flow

  • Sou um dos autores deste livro. Obrigado pelas palavras gentis; se tiverem perguntas, posso responder

    • Obrigado por fazerem um livro excelente. Como desenvolvedor web, ou engenheiro web, como o livro coloca, eu sempre quis aprender mais sobre a base técnica da qual dependo
      Fico curioso sobre o processo que levou à escolha de Python como linguagem de implementação do navegador. JavaScript via Node talvez tivesse oferecido uma experiência de programação mais relacionada

  • Um texto em que o autor explica por que escolheu Python: https://browserbook.substack.com/p/why-python
    Parece que parte dele foi compilada de Python para JavaScript e agora roda dentro do navegador, ou seja, “dentro do próprio livro”
    https://browserbook.substack.com/p/compiling-python-to-js

    • O fato de ter sido escrito em Python realmente me deu vontade de ler este livro. Se fosse Rust ou Go, provavelmente eu teria pulado; C++ é difícil demais de encarar para um projeto visto por diversão
      Espero poder voltar depois de ler e ter uma conversa mais significativa

  • Ver esse tipo de material sendo criado me deixa muito empolgado
    Navegadores parecem caixas-pretas misteriosas e indecifráveis, e provavelmente há uma boa chance de que o Google queira que eles sejam percebidos assim. Mas, ao ver os esforços e os resultados de projetos como o Ladybird, essa muralha está começando a rachar
    Um dia quero me envolver diretamente e ajudar a romper esse fosso defensivo, e este livro parece um excelente ponto de partida

    • Esse fosso não existe por falta de engines de navegador que não sejam o Chrome, mas porque poucas pessoas demais usam engines que não sejam o Chrome
      O Firefox já existe. Só que quase ninguém o usa, e, quando os usuários encontram um site que não funciona no Firefox, eles aprenderam simplesmente a abrir o Chrome
      Contribuir com engines de navegador como o Ladybird na esperança de romper o fosso pode ser divertido, mas é difícil dizer que isso, por si só, contribui para rompê-lo. Gostaria de saber o que realmente ajudaria
    • Chris, um dos autores do livro, é a pessoa que lidera a equipe de renderização do Blink no Google
    • Sou um dos dois autores do livro, e o outro é o responsável pelo Blink Rendering. Já conversei várias vezes com pessoas da equipe do Chrome, e elas nunca me pareceram pessoas que quisessem manter os navegadores como algo misterioso
      Pelo contrário, as pessoas que trabalham no Chrome, Firefox, Safari e Ladybird parecem todas muito animadas para falar sobre navegadores e sobre como eles funcionam. O mundo do desenvolvimento de navegadores é menor do que se imagina, e os engenheiros também circulam bastante entre empresas, então acho que seria difícil manter qualquer “conspiração”
      Dito isso, é verdade que falta material educacional. Foi por isso que escrevemos este livro, e também falta um vocabulário comum para discutir o funcionamento interno dos navegadores em etapas centrais como layout e rasterização. Chris e eu queríamos criar essa base com este livro

  • Eu estava procurando um projeto interessante para começar, e já estou gostando muito de ler este livro. Gosto especialmente de como a escrita é interessante
    Esta história em quadrinhos que explica como o Chrome funciona também é um bom material para começar: https://www.google.com/googlebooks/chrome/med_00.html

  • Estou aprendendo a estrutura interna dos navegadores, e este livro é excelente
    Ajuda a construir uma intuição sobre como um navegador funciona sem precisar mergulhar nos milhões de linhas de código do Chrome

  • Fico me perguntando se há um código promocional para o HN
    Há algum tempo usei o HTMLUnit [1] com Jython [2] de forma satisfatória, e tenho muito interesse em um futuro em que partes do código do navegador possam ser geradas automaticamente com técnicas de geração e verificação de código. Respeito ferramentas como Playwright/Cypress/Selenium, mas nunca me senti tão à vontade com elas quanto com o HTMLUnit
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • O livro ainda não foi publicado, então não há código promocional, mas ele está disponível integralmente online de graça

  • É um bom livro. Recomendo dividir o capítulo 9 em dois capítulos
    Seria bom deixar a parte de executar JavaScript com Duktape em um capítulo, e a parte de interagir com o DOM e eventos em um capítulo separado mais adiante

    • Talvez seja melhor ler em duas partes
      À medida que avança, os capítulos ficam mais longos e abordam temas mais avançados; recomendo acompanhar também o código enquanto lê o livro