Reseña del navegador web Servo hecho en Rust
(spacebar.news)- A nivel global, con el aumento de la cuota de navegadores basados en Chromium, crecen las preocupaciones sobre la diversidad de los estándares web y el futuro de la web abierta.
- El motor Servo, desarrollado en Rust, destaca por su rendimiento multihilo y su seguridad de memoria, y llama la atención como una alternativa nueva en el ámbito de los motores de renderizado web.
- Como aún está en una etapa inicial, hay errores de renderizado en la mayoría de los sitios web, pero en algunas páginas de demostración o sitios simples como Wikipedia funciona de manera correcta.
- El proyecto Servo, que comenzó inicialmente bajo el liderazgo de Mozilla, hoy está administrado por la Linux Foundation Europe y cuenta con una estructura de decisiones técnicas independiente y centrada en la comunidad.
- En la tendencia de concentración de motores de navegador, se destaca que el desarrollo continuo de motores alternativos como Gecko y Servo es importante para proteger la diversidad del ecosistema web.
La concentración de motores web y su riesgo
- En los años noventa y principios de los 2000 coexistían múltiples motores web como Trident de Internet Explorer, Presto de Opera, Gecko de Netscape y KHTML de Konqueror.
- Con el tiempo, KHTML se transformó en WebKit, mientras que Presto y Trident (junto con Tasman) fueron integrados o sustituidos por Blink (el motor de Chromium).
- Al quedar casi todos los navegadores modernos (Chrome, Edge, Opera, etc.) basados en Chromium/Blink, ocurre el fenómeno de que la implementación pasa a convertirse en el estándar.
- Se hace evidente el problema de que, al depender de un solo motor, una vulnerabilidad de seguridad o una limitación de extensibilidad impacta a todo el ecosistema web.
La aparición del motor Servo
- Servo es un motor de renderizado web desarrollado desde cero en Rust.
- Aprovechando las ventajas de Rust, como el procesamiento multihilo y la seguridad de memoria, busca reducir de forma estructural las debilidades de los motores tradicionales basados en C/C++, como los bugs de memoria.
- El objetivo principal de Servo es ser un motor de renderizado web embebible, por lo que podría usarse como alternativa no solo para navegadores autónomos, sino también para Electron o Android WebView.
- En la Linux Foundation Europe, las decisiones técnicas se gestionan con un comité técnico, no por grandes corporaciones.
- Como el primer motor web completamente nuevo en casi 10 años, está incorporando la experiencia de los motores principales para mejorar su nivel de madurez.
Experiencia de uso y estado actual de Servo
- Se puede probar Servo mediante las versiones nightly públicas del sitio oficial (para Windows, macOS, Android y Linux).
- Se encuentran sin soporte funciones básicas del navegador como marcadores, extensiones y sincronización de datos.
- En la mayoría de los sitios web aparecen errores de renderizado; en Google Search y algunos sitios se rompe el diseño o se produce un cierre inesperado.
- Páginas de estructura simple como Wikipedia o CNN Lite funcionan de manera normal.
- En la página de demostración de Servo se puede mostrar el rendimiento gráfico, y en benchmarks como Particle Physics se verificaron resultados de 55–60 FPS en un MacBook Pro moderno (con emulación x86).
- En la prueba Acid3 se obtuvo 83/100 puntos, una puntuación inferior a la de los navegadores principales (alrededor de 95).
- En el roadmap se incluye soporte para estándares web clave como Shadow DOM y CSS Grid, enfocándose en mejorar la compatibilidad web.
Historia y principales hitos de Servo
- Servo comenzó en 2012 en Mozilla, y en 2013 Samsung se sumó al desarrollo.
- El objetivo original consideraba reemplazar Gecko después de su estabilización, pero terminó cambiando a una estrategia de sustituir gradualmente partes de Gecko con código de Servo.
- Con la actualización Firefox 57 (Quantum) se sustituyó el motor CSS (Quantum CSS, Stylo) por código de Servo, observándose mejoras notables en rendimiento y eficiencia de memoria.
- Tras la reestructuración masiva de Mozilla en 2020 (incluyendo a los desarrolladores de Servo), luego Servo fue transferido a la Linux Foundation, recuperó financiamiento y continúa actualmente su desarrollo comunitario con patrocinio de empresas de código abierto como Igalia.
Posibilidades futuras del ecosistema de navegadores
- Tras el triunfo de la Fiscalía de EE. UU. en la demanda por la posición dominante de Google (Chrome, Android), se discuten medidas como la posible venta de Chrome y la prohibición de acuerdos de búsqueda con navegadores de terceros.
- Mozilla, cuya dependencia de ingresos por la configuración predeterminada de búsqueda de Firefox es alta (esencial para mantener Gecko), se ha opuesto a estas medidas.
- Si Mozilla pierde los ingresos de Google, existe la posibilidad de que Firefox migre a WebKit o Chromium/Blink para reducir costos de desarrollo.
- En ese caso, podrían darse varios escenarios, como el fork y la gestión comunitaria del código de Gecko, o la posible decadencia gradual de Gecko.
- La existencia de motores alternativos como Servo y Gecko vuelve a cobrar relevancia como elemento clave para mantener la diversidad y el equilibrio de la plataforma web.
Conclusión y puntos clave
- Aun en un escenario de estandarización de motores de navegador dominantes, la aparición de alternativas innovadoras como Servo desempeña un papel importante para preservar la diversidad y salud del ecosistema web.
- Aunque es difícil que se consolide como navegador de uso diario en el corto plazo, la experimentación y el avance técnico continúan de forma sostenida.
- Hay una creciente expectativa sobre la dirección futura de Servo y su impacto en la industria.
4 comentarios
¿Se supone que hay que descargar y usar algo que ni siquiera funciona bien? ¿De dónde sale semejante arrogancia?
Había escuchado que Rust se hizo para desarrollar Servo... ojalá que a Servo le vaya bien.
Que me recuerde tanto al proyecto Hurd… supongo que solo es idea mía, ¿no?
Comentarios en Hacker News
En la hoja de ruta actual, Shadow DOM y CSS Grid están marcados como prioridades; yo estoy trabajando en el soporte de CSS Grid, y pronto se agregará soporte para "named grid lines and areas". Espero que con esto más layouts de sitios web funcionen correctamente. Puede que esté sesgado porque es mi proyecto, pero creo que la forma en que Servo implementa CSS Grid es bastante genial. La implementación central está separada en una biblioteca externa (Taffy, enlace de GitHub), y esta biblioteca se usa ampliamente en el ecosistema de UI en Rust. Por ejemplo, se usa en el motor web Blitz(enlace), el editor de texto Zed(enlace) y el motor de juegos Bevy(enlace) para distintos roles como Flexbox, Block layout y otros. Espero que el enfoque de Servo, basado en su experiencia desarrollando bibliotecas modulares como Stylo y html5ever, de dividir el motor web en módulos independientes y APIs públicas ayude a reducir la barrera de entrada para quienes desarrollan motores web en el futuro y sea de gran ayuda para nuevos desarrolladores de motores web.
Es la primera vez que oigo hablar de Blitz; parece un proyecto bastante interesante y ambicioso, casi como un verdadero motor web "oculto". Servo ha sido bastante conocido desde que Rust apareció por primera vez, pero Blitz es igual de impresionante.
Me pregunto si haber implementado directamente funciones de un motor de navegador web influye en la forma en que escribes HTML o CSS. También quisiera preguntar si todavía buscas "css grid cheatsheet" tres veces por semana.
Me preocupa que este enfoque de dividir funciones y modularizarlas termine provocando exceso de funciones o fragmentación. Para plantarle cara a Google hace falta una estrategia enfocada, y eso me preocupa.
Estoy usando taffy para manejar el layout de mi pequeño calendario e-ink basado en Rust, así que este tipo de noticias me parece muy entretenido.
Me encanta esta idea de dividir el motor web en módulos con API pública que puedan usarse de manera independiente. Hace tiempo, viendo WebRTC, pensaba: ¿por qué hacer una imitación chafa de Skype tiene que ser o 50 líneas de JavaScript o una pesadilla de una semana compilando Chromium en C++? Ahora que también hay crates de WebRTC en Rust, da gusto que no solo las web apps se beneficien de este tipo de inversión.
Mozilla me da la impresión de que va camino a entrar al salón de la fama de empresas tipo Xerox, de esas que "crearon tecnología del futuro y luego dejaron que la competencia se la llevara". En algún momento le llevaba ventaja a Google en desarrollo de navegadores con Rust y Servo, pero al final no siguió empujándolo, y de verdad no lo entiendo.
Mozilla no es como Xerox. Si alguien fuera el nuevo Xerox, más bien sería Google. Google invierte cantidades enormes de dinero en áreas de I+D sin un plan de negocio claro; un ejemplo representativo son los modelos transformer: básicamente, Google creó primero lo que terminaron siendo los LLM, y aun así OpenAI terminó adelantándose. El éxito de Mozilla siempre estuvo centrado en navegadores web como Netscape y Firefox. Incluso Rust, en esencia, fue creado para el navegador; que también sea útil en otros lados no deja de ser un efecto secundario positivo.
Google ha sido la principal fuente de ingresos de Mozilla desde 2006. Para que Mozilla sobreviva, basta con mantener contento a Google. Eso puede generar conflictos, pero desde la perspectiva de Mozilla ha sido un trato bastante bueno.
Yo creo que Mozilla ya está acabada. Dependió demasiado de Google, y ahora está a punto de perder incluso eso. Servo y Ladybird serán el futuro, y me impresiona mucho ver lo rápido que avanza Ladybird con tan poca gente.
Si Mozilla llega a abandonar Gecko, entonces será el momento de hacer un hard fork y salir de Mozilla. Y por aclarar: abandonar Gecko significaría pasarse a Chromium, no a Servo.
Siento que lograr que la gente pague por un navegador es difícil. Gastan sin problema en una cerveza de 10 euros, pero conocí a mucha gente que hacía todo lo posible por evitar pagar la licencia vitalicia de 0.99 euros de WhatsApp.
Todavía no entiendo por qué Mozilla renunció al futuro técnico de Firefox. Pero cuando miras a Mozilla al final todo se entiende más si sigues el flujo del dinero.
El cierre de Pocket también es un caso triste. A veces imagino una broma del Día de los Inocentes donde Mozilla anuncia que va a descontinuar Firefox para concentrarse en su negocio principal. Es una broma amarga, como si la "idea platónica" de su negocio principal fuera descontinuar de forma elegante productos populares.
Viendo varias salidas de gente y la forma en que se comunicaban, Mozilla parecía una empresa extremadamente política en esa época. Servo tenía muchísima actividad y Rust también tenía un ambiente muy bueno, así que pienso que quizá justamente eso incomodó a la gente de arriba. Mozilla sigue estando dirigida en gran parte por la vieja guardia, y creo que mucho de esto se debe a errores de la alta dirección.
Sigo creyendo firmemente que Servo todavía puede ser una alternativa real al monopolio de Chrome/Chromium. No entiendo por qué Mozilla lo abandonó ni por qué la Linux Foundation casi no le da apoyo.
La estrategia de Mozilla tiene cierta lógica si la ves desde la independencia a largo plazo del dinero de Google. De hecho, los ingresos no provenientes de Google aumentaron de 80 millones de dólares en 2022 a 150 millones en 2023. Los activos totales también crecieron 100 millones de dólares por año, llegando a 1,000 millones en 2023, y la proporción del dinero de Google bajó de 90% en 2020 a 75% en 2023. No es independencia total, pero sí muestra una dirección. A diferencia de lo que suele decir la gente, si solo miras el flujo de dinero quizá llegues a otra conclusión. Mucha gente critica que debieron haber seguido con Servo, pero la verdad es que, después de Quantum, no creo que Servo haya tenido un papel tan grande dentro de Firefox.
Pregunta si es cierto que la mayor parte de los ingresos de Mozilla provienen de Firefox.
También está Ladybird(sitio oficial) para desafiar el monopolio de Blink. No está claro qué va a pasar, pero tengo expectativas.
No me queda claro cuál es el objetivo de Ladybird. Es evidente que no es solo un proyecto de hobby, porque tiene ingenieros de tiempo completo y además recauda donaciones. Aun así, me cuesta imaginar que pueda competir con Blink, Webkit y Gecko en funciones, seguridad y rendimiento. Como no tienen equipos enormes, creo que hacer solo un motor sin adopción masiva no genera tanto impacto. Esto también aplica a Servo, pero Servo tiene metas técnicas más convincentes. En Ladybird no veo esa información tan clara.
Desde un punto de vista puramente técnico, no le veo mucho atractivo a Ladybird. Básicamente está hecho en C++, así que no parece diferenciarse de Gecko o Blink. Servo sí tiene diferencias claras de diseño técnico, como seguridad y paralelismo, y eso lo hace atractivo.
Espero que Ladybird tenga éxito. Ahora incluso ya se puede apoyar directamente, y me parece significativo. A diferencia de Mozilla, estoy seguro de que todo el dinero donado se usará por completo para desarrollar el navegador.
Me pregunto si Ladybird está intentando migrar a Swift. Si van a desarrollar un motor de navegador en C++, no me encanta, pero al menos se siente realista y enfocado en entregar resultados. Si fuera en Rust, le reconocería un aire más orientado al futuro. Pero hacer un motor en otro lenguaje como Swift me parece más bien una decisión de política interna de empresa. Me hace ruido que elijan deliberadamente un lenguaje cuyo ecosistema de soporte todavía es limitado (tuit de referencia).
La prueba de Dogemania funcionó de manera fluida a 60 FPS hasta 400 imágenes en una MacBook Pro M4 Pro, pero en Chrome mantuvo 60 FPS hasta 1400 imágenes, y después de eso me dio flojera seguir probando y lo cerré.
Yo hice el mismo experimento, y la diferencia entre Firefox y Chromium fue decepcionantemente grande. En Chromium siguió dando 100 FPS incluso después de pasar las 1000 imágenes, mientras que en Firefox cayó por debajo de 60 FPS apenas superó las 500. Quizá no fue una prueba completamente justa (Chromium no tenía extensiones y casi no lo uso), pero me dejó pensando mucho sobre el rendimiento comparativo.
Si en dogemania las imágenes se quedan quietas después de la animación, me pregunto si no sería un caso muy fácil de optimizar. Hasta me da la impresión de que computadoras viejas como la Amiga podrían manejar eso indefinidamente.
Llamar a Servo un motor "nuevo" me parece algo forzado.
Yo tenía entendido que Rust fue creado para el navegador web Servo.
Sobre la opinión de que “si solo queda una implementación del estándar, esa implementación pasa a ser el estándar”, no me queda claro por qué eso sería un problema. Si la implementación es open source y la especificación la define un comité administrado por múltiples partes, me parece aceptable. La situación actual, donde se queman recursos haciendo varios motores, me parece más bien un desperdicio. Creo que sería más eficiente tener un solo motor de navegador, como el kernel de Linux, y que solo variaran las distribuciones.
Por muy buenas que sean las intenciones, las implementaciones siempre dejan bugs y pequeños defectos. Si no existe una segunda implementación independiente, al final el bug mismo se convierte en el estándar porque "todo funciona". Y si las páginas web terminan dependiendo de esos bugs, entonces pasan a comportarse según defectos concretos de una implementación específica, no según la especificación. Esa es una de las razones por las que en MS Windows se fueron acumulando capas de UI vieja y mantener la compatibilidad se volvió una pesadilla. Cuando hay varias implementaciones independientes, el estándar realmente puede mantenerse, evolucionar y también optimizarse con más facilidad.
En teoría suena bien, pero en la práctica no creo que un solo desarrollador tenga siempre sus intereses alineados con los de los usuarios, así que un monopolio no es deseable. Sobre todo viendo casos recientes como la eliminación de manifest v2 en Blink, que a los usuarios no les gustó.
Mientras más motores de navegador haya, menor es el riesgo de que una sola vulnerabilidad de seguridad afecte a todos al mismo tiempo. Incluso con lenguajes memory-safe, los errores lógicos pueden causar daños, así que la diversidad importa.
Mencionaste la estrategia de “un motor y varias distribuciones”, pero para la gente acostumbrada a entornos BSD o a cosas como ZFS, precisamente al salirse del enfoque dominante es cuando se nota con claridad la estabilidad y madurez de otras alternativas.
Ya hoy las opiniones de Google y de su círculo tienen un peso enorme en la estandarización. Si todo termina girando alrededor de Chromium, la situación empeorará todavía más. Quizá haga falta una catástrofe de verdad para que todos reconozcan las limitaciones de lugares como W3C o WHATWG.
“La mayoría de los sitios web tienen pequeños bugs de renderizado y algunos simplemente no funcionan del todo; los resultados de búsqueda de Google tienen muchos elementos superpuestos y la portada de MacRumors se cae después de hacer scroll, pero Wikipedia, CNN Lite, sitios personales y el texto de NPR funcionan perfectamente”. Al ver observaciones así, casi nunca veo que la gente diga que Google o MacRumors deberían corregirse para que funcionen con Servo. En cambio, la conclusión siempre termina siendo que Servo debería comportarse como Chrome/Chromium, y eso me frustra bastante. Si seguimos esa lógica, entonces (a) una empresa de publicidad termina definiendo el estándar, y (b) quienes crean páginas web acaban con incentivos equivocados. Ajustarse a algo sencillo como Wikipedia o CNN Lite sería mucho más simple. Yo creo que el navegador "estándar" no debería definirse por popularidad, sino por cercanía al estándar real. Que funcione tanto en navegadores populares como no populares es lo que realmente se acerca al estándar. Al final, sostengo que la respuesta no está en arreglar el navegador web, sino en arreglar las páginas web. Yo todavía experimento con la biblioteca original libwww de la w3c y sus herramientas; con unos pequeños ajustes sigue funcionando muy bien incluso hoy, más de 30 años después, para optimizar páginas web basadas en texto. Internet es un bien público, y me da tristeza que hoy navegadores y páginas estén tan sesgados hacia optimizar publicidad y recolección de datos. Las páginas y navegadores realmente pensados para usuarios de la www deberían ser la prioridad. Abajo va un script sencillo para compilar un binario estático de libwww.
De verdad me da tristeza ver cómo Mozilla pasó de ser una empresa de navegadores competitiva a una organización con aire cada vez más activista. Por eso su producto principal parece haberse ido debilitando poco a poco.