3 puntos por GN⁺ 2025-10-07 | 2 comentarios | Compartir por WhatsApp
  • Ladybird alcanzó el umbral del 90% de aprobación de Apple en las pruebas automatizadas de estándares web llamadas web-platform-tests
  • Estas pruebas miden de forma integral la compatibilidad con estándares web del navegador, incluidos HTML, CSS y JavaScript
  • Al registrar una alta tasa de aprobación al nivel de los navegadores de Apple, principalmente Safari, Ladybird demuestra que sus algoritmos centrales y su implementación de estándares web han alcanzado una confiabilidad comparable a la de los navegadores líderes de la industria
  • Este es un hito importante que muestra que un nuevo navegador de código abierto puede competir de forma real con los actores dominantes del mercado

2 comentarios

 
shakespeares 2025-10-08

Espero que pueda estar a la altura de Blink y WebKit.

 
GN⁺ 2025-10-07
Opinión de Hacker News
  • Como alguien que ha participado profundamente en web-platform-tests, hay que tener cuidado al usar la tasa de pruebas aprobadas como métrica. No lo digo para restarle mérito al logro de Ladybird; su progreso rápido es realmente sorprendente, y si web-platform-tests le sirve de ayuda al equipo, eso ya es algo bueno en sí mismo. Me da mucho gusto ver nuevas implementaciones de la plataforma web como Ladybird, Servo y Flow. Pero web-platform-tests fue optimizado originalmente como una herramienta de ingeniería, no diseñado como una métrica objetiva. Por ejemplo, la proporción de pruebas relacionadas con decodificación dentro del total es excesivamente alta. La razón no es que sean especialmente difíciles en el desarrollo de navegadores, sino que son fáciles de generar. Además, intentamos bajar las barreras técnicas y sociales para que se puedan aportar libremente pruebas útiles. Eso no encaja bien con crear una buena métrica, pero sí con tener un buen recurso de ingeniería. El Interop Project resuelve parcialmente este problema con otros trade-offs y un subconjunto selectivo de pruebas, pero el sistema actual está diseñado para apuntar solo a quienes ya implementaron un motor de navegador web casi completo
    • En el tuit se menciona que esta métrica es un criterio arbitrario que Apple le impuso al equipo de Ladybird. En las actualizaciones mensuales de Ladybird también publican el número de pruebas aprobadas excluyendo las de codificación, ya que elevan demasiado la tasa de éxito
    • Me pregunto si no sería posible usar como métrica un subconjunto seleccionado de pruebas
    • Entonces habría que decírselo directamente a Apple. Apple fue quien creó ese criterio
    • No entiendo por qué mencionan eso aquí. No es una métrica de Ladybird, sino un requisito de Apple para iOS
  • Es realmente genial que el navegador Ladybird parezca estar acercándose a una etapa de uso práctico. Pensé que faltaban algunos años más, pero no imaginé que llegaría a ser competitivo tan rápido
    • No lo he usado directamente, pero sí vi algunos videos de resumen mensual. Pasar pruebas y tener suficiente rendimiento para usarse rápido en el día a día son temas completamente distintos. No parece que Ladybird sea tan rápido por ahora. Aun así, el logro de desarrollo de todo el equipo es impresionante
    • Me pregunto si el dicho de que “el 90% de la completitud toma el 90% del tiempo, y el 10% restante toma otro 90%” también aplica a Ladybird. Aunque así fuera, me parece un tiempo de desarrollo bastante bueno en general
    • Recomiendo no emocionarse demasiado. Vi el informe de desarrollo de septiembre y todavía hay muchísimas cosas por corregir. Sin duda es un avance enorme, pero parece que a Ladybird todavía le faltan varios años para estar terminado
    • Hace 3 años era escéptico con Ladybird. Pero primero, ya tienen 8 ingenieros de tiempo completo, lo cual no esperaba, y segundo, realmente ya pasaron 3 años. Así que ahora soy bastante más optimista. Claro, todavía está muy lejos de competir con Chrome, y sigo teniendo dudas sobre el valor de construirlo desde cero en vez de hacer un fork de un motor existente
    • Antes pensaba que crear un motor de navegador completamente nuevo llevaba décadas, pero me sorprende ver a gente tan dedicada como el equipo de Ladybird logrando algo así
  • En un tuit relacionado se menciona que este es un hito importante para que Ladybird sea considerado como motor de navegador alternativo en iOS
    • Ahora entiendo por qué Apple aparece en el título del artículo
    • Pero al menos eso solo aplica dentro de la UE; fuera de ahí, Apple no lo permitiría aunque el motor fuera muy bueno
  • Es muy impresionante que Ladybird, un proyecto independiente y no corporativo, haya crecido tan rápido
    • Entiendo la expresión "non-corpo", pero en realidad la propia organización de Ladybird sí es una entidad legal. Véanse los documentos relacionados
    • Si piensas en cuántas cosas hace un navegador, un proyecto de este nivel es realmente enorme. Ya de por sí es impresionante construir un gran renderizador de HTML/CSS y un motor de JS, pero una vez que entras al ecosistema, también tienes que seguirle el ritmo a todos los cambios futuros. Chrome puede resistirse a nuevas propuestas, pero los navegadores pequeños parecen estar casi siempre obligados a seguir la corriente
    • Dudo que Ladybird sea realmente no corporativo. Recuerdo que recibió algo de patrocinio empresarial. En ese sentido, no diría que sea mejor que Gecko, que es de una organización sin fines de lucro y tiene a Firefox
    • Si Ladybird mantiene de forma constante este ritmo, espero que para finales de 2027 pueda ser un competidor serio. Aun así, personalmente creo que también hace falta un esfuerzo igual de concentrado en Servo, que probablemente sea el siguiente motor con más funcionalidades. FF/Mozilla no parece muy interesada, así que hace falta un proyecto de navegador aparte
    • Lograr que las pruebas pasen de forma segura es un tema completamente distinto. Estas son pruebas de conformidad, no pruebas de seguridad. Aun así, es sumamente impresionante
  • Me pregunto qué tan difícil será ese último 10%. En un proyecto de software típico, alcanzar ese último 10% requeriría más de un 90% de esfuerzo adicional
    • Y el último 1% seguiría cambiando y nunca terminaría del todo. Ese 90% es según el criterio de Apple. Pero me pregunto cuál sería el nivel que exigen los usuarios comunes
    • Históricamente, los navegadores han sido de los proyectos más grandes y difíciles. No veo por qué deberíamos esperar que esto se vuelva fácil. Si ofrecieran una recompensa de 20 mil dólares por encontrar un segfault, pensaría que ya está realmente cerca de estar terminado
  • Compilé y ejecuté Ladybird personalmente. Sorprendentemente, ya abre bastante bien muchos sitios web. Pero YouTube todavía no funciona, y en Vimeo o en la caja de comentarios de Reddit se cae. Aun así, el resultado es muy alentador. La compilación requiere alrededor de 6 GB de espacio en disco HDD
  • ¡Se ve un gran salto en la gráfica! Me pregunto qué cambio produjo esa mejora
    • En el hilo de Twitter alguien en realidad se lo preguntó a Andreas, y la causa fue integrar la especificación de la API CSS Typed Object Model
    • Con este Pull Request pasaron aproximadamente 6400 pruebas más relacionadas con CSS. Aun así, no parece suficiente para explicar por completo el pico que se ve en la gráfica, aunque claramente ayudó. Detalles del PR
    • La gráfica no tiene ejes, así que no se sabe si realmente fue un gran salto. Por ejemplo, podría haber subido de 89% a 90.2%. Puede que este cambio no haya sido especialmente más grande que aumentos anteriores que no aparecen en la parte izquierda de la gráfica
  • Me pregunto cómo va el desarrollo relacionado con Ladybird gtk
  • Me pregunto qué motor de JS usa Ladybird
    • Usa su propio motor, LibJS. GitHub de LibJS
    • Todo el código fuente es original
  • Desde la perspectiva de un ingeniero, sorprende que una megacorporación defina estándares de calidad y limite el acceso a APIs para software de terceros. Desde la perspectiva del cliente, da gusto saber que existen estándares estrictos de calidad y restricciones de API a nivel de OS para validar la seguridad
    • Desde la perspectiva del consumidor, las actualizaciones del navegador se vuelven lentas porque tienen que pasar la revisión de Apple, incluso las de bugs o seguridad. En Mac u otras plataformas no hace falta eso. Apple hace que los navegadores que no usan Safari ni siquiera funcionen bien, y en Mac u otros sistemas operativos no existe ese entorno. Y aunque en la UE finge permitir motores alternativos, en la práctica solo ha aumentado el cumplimiento malicioso, así que los motores alternativos son poco más que algo teórico. Al final también perjudica al consumidor
    • Desde la perspectiva del consumidor, incluso usar servicios como GitHub o Threads en el navegador oficial del OS da problemas
    • Lo que me pregunto como ingeniero es si el navegador de Apple también cumple sus propios estándares. Safari es el único que parece tener ciertos bugs con una frecuencia increíble. También tiene muchos errores comunes que cualquiera que haya hecho páginas web probablemente haya visto al menos una vez
    • Me pregunto si realmente existe la opción de no usar un navegador roto
    • No me parece sorprendente; creo que se trata de mantener el control de una forma anticompetitiva e injusta