¿Por qué las bases de códigos para navegadores web modernos son tan grandes?

Question

Las bases de códigos para navegadores web modernos como Chrome, Firefox y Safari (WebKit) son bastante grandes. Tengo curiosidad sobre qué hace específicamente que sus implementaciones sean tan triviales que requieran grandes cantidades de código.

Como una pregunta complementaria, si un navegador hipotético solo admite HTML y JavaScript estrictos, para evitar ataques de compatibilidad, ¿la base de código sería significativamente más pequeña?

Answer 1

Para su primera pregunta, tenga en cuenta las cosas que un navegador moderno tiene que aplicar (algunos navegadores empujan parte de este trabajo a los servicios del sistema operativo):

1. Varios programas de análisis: XML, HTML, JavaScript, CSS, al menos.
2. Al menos cuatro sistemas de disposición separados (modelo de caja CSS, flexbox, SVG, MathML).
3. Al menos una biblioteca de gráficos; para los navegadores multiplataforma esto necesita backends por plataforma (IE9 + solo usa la biblioteca del sistema Direct2D, Safari en Mac solo usa Quartz hasta donde yo sé).
4. Una máquina virtual de alto rendimiento con un JIT, un recolector de basura, una biblioteca estándar (crece todo el tiempo, ve las matrices tipadas y varias otras características de JavaScript recientes).
5. Implementación de DOM, que incluye varias cosas como las interfaces DOM específicas de SVG y específicas de SVG, entre otras.
6. Instalaciones de procesamiento de audio y video (nuevamente Safari en Mac e IE descarguen estas al sistema operativo).
7. Instalaciones de procesamiento de imágenes, con soporte para al menos JPG/GIF/PNG. Nuevamente, algunos navegadores pueden descargar partes de esto al sistema operativo.
8. Una biblioteca para convertir secuencias de bytes a caracteres Unicode. Nuevamente, a veces esto puede descargarse al sistema operativo y otras no.
9. Para navegadores multiplataforma, algún tipo de capa de portabilidad que abstrae los bits específicos de la plataforma.
10. Un editor HTML con transacciones y una API programable; piensa contento.
11. Un editor de texto plano para textareas. Parte de esto se puede compartir con el editor de HTML, tal vez.
12. Un corrector ortográfico, que puede descargarse o no en el sistema operativo.
13. Una biblioteca de red compatible con HTTP, tal vez SPDY, probablemente FTP, y tal vez algunos otros protocolos. De nuevo, esto puede o no descargarse en el sistema operativo.
14. Una biblioteca criptográfica para manejar SSL y varias otras necesidades de criptografía. De nuevo, esto puede o no descargarse en el sistema operativo.
15. Al menos una implementación de base de datos (sqlite parece ser popular).
16. Varios códigos para la interfaz de usuario real y otras cosas.
17. Código de pegamento para manejar las interacciones entre todos estos: código que gestiona las llamadas entre JavaScript y DOM, código que gestiona el estilo de recomposición y la información de diseño cuando cambia el DOM, código que maneja cosas como document.write inyectando cadenas de JavaScript en el flujo de entrada del analizador, y demás. Tenga en cuenta que la cantidad de código de pegamento generalmente es cuadrática en el número de módulos que interactúan.

Probablemente me estén perdiendo algunas cosas, pero eso es algo fuera de lo común.

Además de esto, al menos Gecko y WebKit tienen bibliotecas de plantillas para cosas como cadenas y matrices (debido a que las bibliotecas estándar de C++ tienen varios inconvenientes).

Para el resto ... en este punto, muchos de los "hacks de compatibilidad" son en realidad parte de los estándares web. Entonces no puedes evitarlos exactamente. Su escenario habla sobre JavaScript y HTML pero no SVG o MathML o CSS. Si realmente solo quiere decir HTML y JavaScript, pero no CSS o el resto, entonces, obviamente, podría recortar un montón de código. Si incluye todos esos, más las capacidades de audio y video de HTML5 y desea que su navegador funcione bien, entonces dudo que pueda hacerlo mucho más pequeño.

Answer 2

Creo que los navegadores web modernos son aplicaciones complicadas. Principalmente, tienen motores de renderizado que tienen que manejar diferentes tipos de HTML, capacidad para manejar formatos no HTML (como XML, RSS, etc.), manejadores CSS, motores Javascript a veces con un JIT.

Aparte de eso, tienen arquitecturas de plugins y API, partes para abstraer las diferencias entre plataformas y generalmente se construyen usando componentes que otras aplicaciones usan.

Esto los hace absolutamente no triviales. En cuanto a su collorary, creo que sí. Lynx es bastante pequeño y no es compatible con Javascript o HTML de lujo.