Ingeniería de navegadores web (2021)

 (browser.engineering)
2 puntos por GN⁺ 2024-10-16 | 1 comentarios | Compartir por WhatsApp
  • Web Browser Engineering cubre desde redes hasta JavaScript y propone crear tú mismo un navegador web básico pero completo con varios miles de líneas en Python
  • El recorrido de aprendizaje va desde la carga de páginas hasta la visualización de documentos, la ejecución de aplicaciones y funciones de navegadores modernos, conectando en orden HTTP, HTML, CSS, DOM, seguridad y el pipeline de renderizado
  • La parte inicial se enfoca en la implementación de fundamentos del navegador, como URL y solicitudes HTTP, creación de ventanas y dibujo en canvas, además de ajuste de línea y espaciado entre líneas de texto
  • La parte media y avanzada incluye construcción del árbol HTML, layout, aplicación de estilos, envío de formularios, respuesta a eventos, cookies e inicio de sesión, además de XSS y CSRF
  • La parte final abarca composición, event loop, animaciones con GPU, árbol de accesibilidad, iframe, invalidación y precisión en la edición, ofreciendo una mirada amplia a los elementos de implementación de los navegadores modernos

Aprender la estructura del navegador implementándolo directamente

  • Web Browser Engineering está organizado para entender cómo funciona un navegador web mediante la implementación directa de un navegador básico pero completo
  • El lenguaje de implementación es Python y el tamaño total de la implementación es de varios miles de líneas
  • El alcance va desde redes hasta JavaScript
  • El libro impreso se puede comprar en Bookshop, B&N y Amazon
  • Hay ediciones traducidas en Hanbit para coreano y O’Reilly para japonés
  • Las actualizaciones se pueden seguir en el blog, Mastodon y Twitter, y también hay un foro de discusión en GitHub

Flujo del índice

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-16
Opiniones de Hacker News

  • Algo bueno de este libro es que dedica una parte aparte a “lo que no hizo”.
    El layout es realmente difícil, e incluso manejar solo tablas sin CSS ya es complicado. Si además entra CSS, el layout se vuelve tan complejo que es casi imposible.
    Me pregunto si hay alguien capaz de tener en la cabeza toda la especificación de CSS y sus comportamientos relacionados. El CSS+HTML+JavaScript actual se ha acercado más a un lenguaje de tecnología de páginas dinámicas (PDL), y probablemente sea uno de los softwares más complejos de hoy.
    Además, la decodificación de video se descarga al hardware, así que ya no consume tanta batería como antes.

    • Implementar layout CSS con calidad de producción requiere una cantidad enorme de código, y el código fuente de Servo lo muestra bien.
      Por ejemplo, este archivo solo implementa contextos de bloque/inline; tiene algo de boilerplate de Rust, pero la mayor parte es lógica real que aborda varias partes de la especificación. Hay una carpeta llena de archivos así: https://github.com/servo/servo/blob/main/components/layout/f...
      Aun así, implementar un motor de layout es posible. CSS no es magia: hay una especificación que puede trasladarse cuidadosamente a código. Mostrar este tipo de código a quienes se frustran porque CSS parece arbitrario ayuda a entender que también hay lógica en el entorno de ejecución.
      Claro, no es algo en lo que uno vaya a hacer clic seguido como cuando revisa la implementación de una biblioteca, pero en ese sentido no creo que sea muy distinto de algo como React.
    • Sí, el layout es difícil, y creo que sobre todo por dos razones.
      Primero, las partes más centrales del layout, como CSS 2, fueron diseñadas de forma bastante desprolija, y funciones raras interactúan entre sí de maneras raras. Cosas como float y clearance, o el colapso de márgenes. Parte de este núcleo se pensó para usarse de forma universal en todos los modos de layout, pero no encaja bien con otros modos. Por ejemplo, margin y padding no tienen un propósito claro en elementos grid.
      Segundo, no está bien modularizado como las API de JavaScript. Las API de JavaScript suelen implementarse de forma independiente, pero los módulos de layout pueden anidarse de muchas maneras, así que todos se afectan entre sí. Las especificaciones más nuevas, como grid, intentan ser más estrictas, pero existe el problema fundamental de que varios modos de layout tienen que compartir un recurso común: una pantalla 2D real.
    • El layout era tan difícil que dejé un proyecto personal que estaba haciendo con Common Lisp y ncurses, y terminé convirtiéndome en aquello que juré destruir: un desarrollador React.
      No puedo ser el único que quiere un lenguaje de layout más simple que CSS, pero que incorpore las lecciones de los últimos 20 años para maximizar el producto entre simplicidad y expresividad. Me pregunto si hay algún proyecto que esté diseñando algo así en serio, o si todos aceptaron CSS3 y están esperando un backend LLVM, o simplemente volvieron al texto plano.
    • En React Native, los ingenieros de Facebook básicamente se rindieron y dijeron: “lo único que les damos es layout flexbox”, y a la gente le pareció bastante bien. Claro, también hay quienes se quejan de que no hay display grid.
      https://github.com/facebook/yoga
    • Esta torre de Babel algún día se va a derrumbar.
      El layout no tiene por qué ser tan complejo. Hay decenas de frameworks GUI con sistemas de layout más simples, y para las aplicaciones que usa la gente son suficientes.

  • Se ve genial. Hace unos 15 años empecé a crear un navegador headless y lo mantuve durante varios años.
    Usaba SpiderMonkey como intérprete de JavaScript e implementé el DOM por mi cuenta. Ejecutaba todo el JavaScript moderno de la época, AJAX y demás, y más tarde incluso agregué un runtime Flash personalizado. Era un proyecto que hacía casi todo excepto dibujar en pantalla, así que fue muy divertido.
    Tengo muchas ganas de leer este libro.

    • Me da curiosidad qué biblioteca pensabas usar para dibujar en pantalla.

  • Me alegra que la ingeniería de navegadores parezca estar volviéndose una tendencia
    El ecosistema está, en la práctica, en un estado bastante pobre, definido solo por Google, Apple y Mozilla. Me gustaría ver un futuro con más motores de navegador independientes

    • No creo que reescribir un motor de renderizado para HTML sea algo que valga la pena intentar. Nunca se termina. HTML ya es, en la práctica, una especificación completamente controlada por Google y Apple, y es demasiado compleja para implementarla desde cero
      El área interesante son las tecnologías de UI/documentos no basadas en HTML. Typst, en otro hilo, es como un LaTeX mejorado, y Markdown también tuvo un gran impacto. Hay mucho espacio para crear “HTML, pero mejor”. Ni siquiera tiene que ser necesariamente un formato de marcado. Typst y React HTML difuminan la frontera entre código y datos, y Jetpack Compose muestra cómo las capacidades de DSL de Kotlin permiten crear algo que parece una descripción de UI, pero que en realidad es código
      Claro que para eso habría que distribuir un ‘navegador’ para ese formato, o encontrar una forma de mostrarlo en los navegadores existentes. Aun así, compilar a JavaScript/HTML/WASM es posible. También se puede usar un toolkit de GUI portable como JavaFX, y obtener accesibilidad. Incluso se pueden hacer ambas cosas
      Si defines tu propio lenguaje de UI, puedes intentar muchas cosas que HTML no hace bien. Un ejemplo claro es la separación entre contenido y estilo. HTML lo intentó, pero nunca terminó de lograrlo bien, y XSL:T lo intentó con más empeño, pero era un lenguaje funcional puro extraño que usaba sintaxis XML. React es bastante bueno para convertir JSON en cajas, pero el protocolo subyacente siempre termina siendo algo añadido de forma improvisada, por lo que es difícil construir herramientas útiles encima
      Otra idea posible sería un formato que, por defecto, sea inmune a XSS
    • Me gustaría que hubiera un navegador que use menos memoria. Fuera de eso, salvo por el spyware de Google Chrome con G mayúscula y Mozilla Firefox con M mayúscula, no creo que el bajo número de motores sea un gran problema en sí mismo. Son millones de horas de trabajo acumuladas sin duplicación
      Dicho eso, sí quiero una alternativa a HTML. Si yo hiciera un navegador, creo que me enfocaría en reemplazar HTML porque no lo soporto, y también querría cambiar JavaScript porque su runtime es pesado
      Por ejemplo, sería bastante gracioso un navegador que casi no tenga runtime de JavaScript y solo ejecute WASM
    • Quizás haga falta una plataforma o un protocolo completamente nuevo. Lo actual está totalmente saturado de complejidad
    • Me da curiosidad si alguien ha revisado motores de navegador alternativos como Servo, Ladybird, Goanna, NetSurf, Sciter o Flow

  • Soy uno de los autores de este libro. Gracias por los comentarios positivos; si tienen preguntas, puedo responderlas

    • Gracias por crear un libro excelente. Como desarrollador web, o ingeniero web como lo expresa el libro, siempre quise aprender más sobre la base técnica de la que dependo
      Me da curiosidad cómo llegaron a elegir Python como lenguaje de implementación del navegador. Me parece que JavaScript vía Node quizá habría ofrecido una experiencia de programación más relacionada

  • Un texto donde el autor explica por qué eligieron Python: https://browserbook.substack.com/p/why-python
    Parece que parte de eso compila Python a JavaScript, de modo que ahora también se ejecuta dentro del navegador, es decir, “dentro del propio libro”
    https://browserbook.substack.com/p/compiling-python-to-js

    • El hecho de que esté escrito en Python hizo que realmente me dieran ganas de leer este libro. Si hubiera sido Rust o Go, probablemente lo habría saltado, y C++ es demasiado difícil de leer para un proyecto de diversión
      Espero poder volver después de leerlo y decir algo más significativo

  • Me emociona mucho ver que se creen materiales como este
    Los navegadores parecen cajas negras misteriosas e indescifrables, y probablemente a Google le convenga que se los perciba así. Pero al ver el esfuerzo y los resultados de proyectos como Ladybird, esa pared se está resquebrajando
    Algún día me gustaría meterme de lleno y contribuir a romper ese foso defensivo, y este libro parece un excelente punto de partida

    • Ese foso no existe por falta de motores de navegador que no sean Chrome, sino porque muy poca gente usa motores que no sean Chrome
      Firefox ya existe. Pero casi nadie lo usa, y cuando los usuarios encuentran un sitio web que no funciona en Firefox, simplemente aprendieron a abrir Chrome
      Puede ser divertido contribuir a motores de navegador como Ladybird con la esperanza de romper el foso, pero es difícil decir que eso por sí solo contribuya a romperlo. Me gustaría saber qué ayudaría de verdad
    • Chris, uno de los autores del libro, es quien lidera el equipo de renderizado de Blink en Google
    • Soy uno de los dos autores del libro, y el otro es el responsable de Blink Rendering. Hablé varias veces con gente del equipo de Chrome, y nunca me parecieron personas interesadas en mantener los navegadores como algo misterioso
      Al contrario, la gente que trabaja en Chrome, Firefox, Safari y Ladybird parece muy entusiasmada por hablar de los navegadores y de cómo funcionan. El mundo del desarrollo de navegadores es más pequeño de lo que parece, y los ingenieros también se mueven con frecuencia entre empresas, así que creo que sería difícil sostener cualquier “conspiración”
      Dicho eso, sí es cierto que faltan materiales educativos. Por eso escribimos este libro, y también falta un vocabulario común para hablar de las partes internas del navegador en etapas clave como layout y rasterización. Chris y yo queríamos que este libro ayudara a crear esa base

  • Estaba buscando un proyecto interesante para empezar, y ya estoy disfrutando muchísimo este libro. Me gusta especialmente lo interesante que está escrito
    Este cómic que explica cómo funciona Chrome también es un buen material para empezar: https://www.google.com/googlebooks/chrome/med_00.html

  • Estoy aprendiendo la arquitectura interna de los navegadores, y este libro es excelente
    Ayuda a construir una intuición sobre cómo funciona un navegador sin tener que meterse en los millones de líneas de código de Chrome

  • Me pregunto si hay algún código promocional para HN.
    Hace tiempo usé HTMLUnit [1] junto con Jython [2] con buenos resultados, y me interesa mucho un futuro en el que se puedan generar automáticamente partes del código del navegador mediante generación de código y técnicas de verificación. Respeto herramientas como Playwright/Cypress/Selenium, pero nunca me resultaron tan cómodas como HTMLUnit.
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • El libro todavía no se publicó, así que no hay código promocional, pero está disponible completo en línea de forma gratuita.

  • Es un buen libro. Recomiendo dividir el capítulo 9 en dos capítulos.
    Sería bueno dejar la parte de ejecutar JavaScript con Duktape como un capítulo, y la parte de interacción con el DOM y los eventos como otro capítulo separado más adelante.

    • Quizá lo mejor sea leerlo en dos partes.
      Hacia el final, los capítulos se vuelven más largos y tratan temas más avanzados, y recomiendo ir siguiendo también el código mientras se lee el libro.