3 puntos por GN⁺ 2023-11-28 | 1 comentarios | Compartir por WhatsApp
  • Prettier, el formateador de código JavaScript, buscó impulsar una competencia de rendimiento mediante una implementación compatible basada en Rust, ahora que su lógica de formateo está cerca de ser estable
  • El 9 de noviembre, Prettier ofreció una recompensa de 10 mil dólares con la condición de aprobar el 95% de su suite de pruebas; con aportes adicionales de Guillermo Rauch, CEO de Vercel, y napi.rs, el monto total llegó a 22,500 dólares
  • Biome recibió la recompensa después de que varias personas mejoraran la compatibilidad durante unas 3 semanas, y en el proceso se amplió rápidamente el alcance real de compatibilidad con Prettier
  • Al ajustar las pruebas, también salieron a la luz bugs y decisiones cuestionables de Prettier, lo que le dio al equipo de Prettier fundamentos concretos para mejorar
  • Prettier ha venido pagando 1,500 dólares al mes a 2 mantenedores con donaciones, pero su presupuesto actual solo tiene 8 meses de runway, por lo que necesita donaciones adicionales

Biome recibió la recompensa de Prettier

  • Prettier es un formateador de código JavaScript ampliamente adoptado porque maneja con cuidado las formas muy diversas en que las personas escriben código
  • Su lógica de formateo ya está en un estado sólido, y se considera que llegará a una etapa satisfactoria cuando se incorporen los cambios de ternaries
  • El siguiente desafío es mejorar el rendimiento
    • Prettier originalmente no era una herramienta rápida, pero era lo suficientemente veloz para la mayoría de los casos de uso
    • Para no quedarse en el estado actual, impulsó mejoras mediante una competencia amistosa
  • Condiciones de la recompensa y participación

    • El 9 de noviembre, se presentó una $10k bounty para un proyecto escrito en Rust que lograra aprobar el 95% de la suite de pruebas de Prettier
    • Guillermo Rauch, CEO de Vercel, sumó la misma cantidad, llevando el total a 20 mil dólares
    • napi.rs agregó 2,500 dólares
    • Algora creó una landing page para la recompensa
  • Logros de Biome

    • El proyecto Biome recibió la recompensa
    • Durante unas 3 semanas, alrededor de 12 personas se reunieron para mejorar la compatibilidad
    • Los detalles están en el full report de Biome
    • En el proceso de ajustar las pruebas también se encontraron muchos bugs and questionable decisions de Prettier, lo que permitirá a Prettier mejorarlos

La presión creada por la competencia de rendimiento

  • La razón por la que el equipo de Prettier financió a otro proyecto fue crear una competencia de rendimiento
    • Prettier tenía una posición dominante en el área de formateadores de código JavaScript
    • La falta de competencia reducía los incentivos para mejorar el rendimiento y corregir varios casos límite
  • Ahora Biome tiene una implementación compatible con Prettier y mucho más rápida, y los usuarios pueden migrar
  • Fabio Spampinato perfiló correctamente la CLI de Prettier a partir de este desafío y encontró varias ineficiencias extremas
    • Esos problemas se corregirán antes de fin de año

Donaciones y presupuesto de mantenimiento de Prettier

  • La recompensa y la operación continua de Prettier fueron posibles gracias a grandes donaciones de varias personas y empresas
  • Principales donaciones de empresas

    • Indeed: 20,000 dólares
    • Frontend Masters: 10,850 dólares
    • Sentry: 10,529 dólares
    • Salesforce: 10,025 dólares
    • Airbnb: 8,426 dólares
    • Cybozu: 6,086 dólares
  • Principales donaciones individuales

    • Shintaro Kaneko: 1,635 dólares
    • Suhail Doshi: 1,000 dólares
    • icchiman: 500 dólares
    • Mariusz Nowak: 270 dólares
    • Benoît Burgener: 270 dólares
    • Jeremy Combs: 270 dólares
    • f_subal: 230 dólares
    • Gracias a estas donaciones, durante los últimos 2 años Prettier ha podido seguir lanzando releases mientras paga 1,500 dólares al mes a dos personas
    • Fisker Cheung y Sosuke Suzuki desempeñan ese rol
    • Con el presupuesto actual solo queda runway de 8 meses, por lo que se necesitan donaciones adicionales
    • Si usas Prettier y te ha ayudado, puedes donar en https://opencollective.com/prettier
    • Open Collective ayuda mucho a la operación del proyecto
    • Los mantenedores pueden registrarse sin proporcionar información personal
    • Funciona como un banco y permite enviar y recibir dinero en todo el mundo
    • Gestiona adecuadamente los documentos fiscales
    • Prettier recaudó un total de 110 mil dólares, de los cuales redistribuyó 75 mil dólares
    • Esta recompensa es algo puntual, pero el objetivo es inyectar energía al ecosistema de formateo de código para crear una mejor experiencia de desarrollo

1 comentarios

 
GN⁺ 2023-11-28
Opiniones en Hacker News
  • Me preguntaba por qué el equipo de Prettier estaba financiando otro proyecto, pero la respuesta no me termina de convencer
    Podrían poner una recompensa por mejorar Prettier; no queda claro por qué crear un proyecto competidor para motivar mejoras en Prettier
    También me pregunto si el objetivo final es abandonar Prettier y moverlo a una herramienta basada en Rust, y parece que fragmenta innecesariamente un ecosistema que ya es confuso

    • Parece haber tres razones por las que esto terminó siendo un proyecto separado y no una recompensa para mejorar Prettier
      Primero, escribir un formateador en Rust es de una naturaleza distinta a mejorar el codebase de Prettier. Prettier no está escrito en Rust, y como Rust ya demostró ser una opción sólida para implementar formateadores, el objetivo en sí se parece más a escribir un formateador en Rust
      Segundo, $20k no es muy atractivo para pedir que alguien escriba un formateador en Rust propiedad de Prettier. Para un desarrollador excelente equivale a unas 100 horas, lo cual no alcanza para terminar el proyecto; pero si la recompensa es un proyecto que él mismo va a poseer, resulta mucho más atractivo
      Tercero, si Prettier es dueño del proyecto ganador, el equipo de Prettier también asume la responsabilidad de mantenimiento. El equipo que lo creó originalmente tendría menos incentivos para seguir manteniéndolo, y al desaparecer la competencia, el ecosistema se vuelve menos activo
    • Desde el punto de vista de un mantenedor open source, me importa más que el problema se resuelva que que todo el mundo use mi implementación específica
      Tampoco obtengo un beneficio directo porque alguien use mi código; trabajé para crear una solución accesible. Si me apasionara el formateo de código JS, creo que me alegraría bastante que alguien resolviera ese problema de una forma más rápida
    • Hay una gran diferencia entre “somos el líder establecido y los desarrolladores de JavaScript no tienen una alternativa usable” y “alguien del lado de Rust lo logró y ahora existe una alternativa bastante viable”
      Se parece más a un problema de salir de un óptimo local. Puedes mirar el mayor cuello de botella de rendimiento y decir que puedes mejorarlo, pero si no tienes un punto de comparación objetivamente mejor, es difícil estar seguro
      La imitación es la forma más sincera de elogio, y el simple hecho de que un problema difícil también pueda resolverse en otro lenguaje genera valor durante el proceso competitivo
      Si no hay una alternativa real, tampoco hay competencia completa. Si una implementación en Rust puede pasar por alto como máximo un 5% del test suite y aun así ser más rápida, eso dice mucho sobre los límites teóricos de este problema frente a la implementación estándar
      No conozco esta área en profundidad, pero creo que siempre hay valor intangible en tener una implementación similar en otro lenguaje
    • Cuando implementan personas con perspectivas e intenciones distintas, pueden aparecer nuevas direcciones de mejora
      https://biomejs.dev/formatter/#differences-with-prettier
      Biome encontró varios puntos de fricción en los que se aparta de las mismas decisiones de Prettier, y eso por sí solo ya demuestra el valor del desarrollo en paralelo
    • Un enfoque con restricciones y cargas distintas puede encontrar áreas de mejora que no eran visibles en el proyecto original
      Puede ser porque no estaba atrapado en la llamada mentalidad Prettier
  • Mucha gente menciona razones, pero parece no considerar esta parte: “Al pasar todos los tests, el proyecto Biome descubrió muchos bugs y decisiones cuestionables de Prettier, lo que permitió mejorarlos”
    Para mí eso significa que una implementación distinta permitió hacer un sanity check de la propia implementación

  • Esta noticia me entusiasma mucho
    El equipo de Biome logró una compatibilidad del 95% con Prettier a una velocidad sorprendentemente rápida https://github.com/biomejs/biome/issues/720
    Gracias a Rust, se puede aumentar mucho la velocidad del formateo de JavaScript, siguiendo la línea del formateador de Python ruff
    Aunque no aparece en el artículo, Wasmer también puso una recompensa de $2,500 para compilar Biome a WASIX, y fue bueno ver al equipo trabajar en eso
    Espero que Biome pronto corra en Wasmer: https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • Es la primera vez que veo WASIX y, por lo que leí, parece la reencarnación de la JVM
      Me pregunto si esa interpretación es correcta. Si puede acceder al sistema y no es un sandbox real, no entiendo cuál es la ventaja de ejecutar código en WASIX
    • Me pregunto si alguien sabe por qué quieren que sea posible compilarlo a WASIX
  • Las mejoras de velocidad siempre son bienvenidas, pero me gustaría que Prettier fuera un poco menos dogmático
    En particular, no deja en paz mi formato cuando se trata de la longitud de línea. El código formateado con Prettier es mucho menos legible que el código sin formatear, y es un problema que no tengo con otros formateadores como rustfmt

    • Me da curiosidad si hay ejemplos de código con Prettier que sea mucho menos legible
      Yo no he tenido mucho ese problema y he estado bastante conforme con Prettier
    • Me pregunto si ya probaste la opción print width: https://prettier.io/docs/en/options.html#print-width
    • El verdadero problema de Prettier es que se volvió casi un estándar de facto
      Personalmente no me gusta nada Prettier, pero sí me gusta Svelte, y hasta donde sé el formateador oficial de Svelte usa Prettier. Así que uso Prettier para Svelte, y lo mismo con algunas otras cosas
      Si el usuario está en una situación donde puede elegir la herramienta, el principio de “somos muy dogmáticos, si quieres configuración ve a otro lado” puede ser excelente. Pero cuando se vuelve prácticamente la única opción para cierto grupo de usuarios, debería ser un poco más configurable
    • Con la longitud de línea, Prettier tiene efectos secundarios más sutiles, y por eso evito los formateadores dogmáticos
      Prettier cambia los diffs de formas no intencionales
      Si en una asignación por desestructuración quitas un miembro y quedas por debajo del límite de longitud de línea, el diff puede pasar de 0/-1 a +1/-5. Para quien revisa, no es fácil ver de inmediato qué se eliminó exactamente entre 5 líneas borradas y 1 línea agregada
      Si intentas corregir un typo en un commit anterior con un rebase interactivo de Git, Prettier puede volver a formatear todo el bloque de código y hacer que los commits siguientes quizá ya no apliquen
      Si configuras Prettier en un hook de pre-commit y luego intentas hacer stage solo de parte de los cambios de un archivo, aparecen otros problemas entretenidos. Paso
    • Estoy de acuerdo. Iría más allá y diría que habría sido mejor si Prettier nunca hubiera existido
  • Todavía me molesta que varios plugins de eslint hayan eliminado linters perfectamente buenos y los hayan reemplazado por Prettier
    Prettier es demasiado impositivo, difícil de razonar, y otra herramienta más que nunca pedí

    • Las reglas de estilo obsoletas se portaron a un proyecto nuevo: https://eslint.style/guide/why
    • Justamente el objetivo de herramientas así es terminar con las discusiones de estilo
    • No tengo muy claro en qué casos habría que “razonar” sobre Prettier
      Lo único que se me ocurre son problemas ocasionales con conflictos de merge
  • Aunque existe esta tendencia de portar a Rust, Prettier se ejecuta cada vez que guardas, así que la mejora de velocidad será bastante grande
    Voy a probar Biome pronto, y felicidades al proyecto Biome

    • Nunca sentí latencia cuando Prettier se ejecuta sobre un solo archivo
      Donde el rendimiento importa es al formatear todo un repositorio
      Para uso interactivo se debería usar un proceso persistente y ya calentado; así, el tiempo de inicio de Node no importa. Idealmente, la verificación de tipos, el linting, el resaltado y el formateo deberían vivir dentro de un único servicio de lenguaje que haga parsing incremental en cada pulsación y actualice un AST compartido
    • Este trabajo me recuerda el entusiasmo de la comunidad de Python por ruff
      Se esperan mejoras de eficiencia y velocidad con un impacto amplio
    • Recomiendo usar la herramienta lint-staged para que Prettier se ejecute solo sobre los archivos modificados al guardar, no sobre todo
      En proyectos grandes la diferencia es enorme
  • “Ahora podemos enfocarnos en el siguiente aspecto importante: el rendimiento. Prettier nunca fue inherentemente rápido, pero era suficientemente rápido para la mayoría de los usos. Eso siempre me dejó insatisfecho, y por eso quería hacer algo. ¿Qué mejor que una competencia amistosa? El 9 de noviembre puse una recompensa de $10k para un proyecto en Rust que pasara el 95% de la suite de pruebas de Prettier”
    No veo cómo del hecho de que algo esté escrito en Rust se desprenda un mejor rendimiento. También se podría haber simplemente transpileado el codebase existente a Rust y cobrado la recompensa

    • Cuando veo la palabra “simplemente”, pienso que lo que viene después no va a ser simple
      Si de verdad fuera simple, no haría falta calificarlo así
      En este caso no sé si transpilear un codebase de JavaScript a Rust sea simple. Los dos lenguajes tienen modelos mentales, bibliotecas usadas y formas de escribir código bastante distintas, y aunque existiera un transpilador de JS a Rust, dudo que sea lo bastante robusto para un codebase del tamaño de Prettier
    • El Rust idiomático suele ser 5 a 10 veces más rápido que código JavaScript/TypeScript de aspecto similar, incluso sin optimizaciones especiales
      Depende de la tarea y no siempre es así, pero los parsers con mucha manipulación de strings son definitivamente un caso donde aplica
    • En procesamiento de strings, Rust es mucho más rápido que JS
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • La respuesta que recibí de vjeux fue esta: “Hoy hay muchas herramientas web rápidas escritas en Rust”
      https://twitter.com/Vjeux/status/1722769322299609565
      No me convence, y parece que vjeux se subió a la moda de Rust
  • El proyecto ganador, Biome, es un fork o cambio de nombre del proyecto Rome, iniciado hace algunos años por Sebastian McKenzie, creador de Babel
    Parece que sebmck estuvo ausente durante aproximadamente el último año, y como muchos accesos a recursos del proyecto los tenía solo él, los contribuidores no podían actualizarlo, así que hicieron un fork
    Espero que él esté bien y, aparte de eso, me alegra que el proyecto Biome parezca ir por buen camino

  • No entiendo por qué tenía que ser necesariamente Rust
    ¿No bastaba con que fuera “algo más rápido”? ¿La implementación en Rust realmente es rápida? También me pregunto si la seguridad de memoria o las fugas son de verdad tan importantes en un programa como Prettier.

    • En especial en HN hay mucha gente con una voz fuerte que cree que Rust es actualmente el lenguaje más rápido y seguro.
      Así que, hasta cierto punto, pudo haber sido un desafío con recompensa de “si eso dicen, demuéstrenlo ustedes mismos”.
  • Me pregunto si los benchmarks de Biome están en algún lado.
    ¿Exactamente cuánto mejor es su rendimiento frente a Prettier?

    • Encontré algo aquí: https://github.com/biomejs/biome/blob/main/benchmark/README.md
      Afirman que es 25 veces más rápido, pero las cifras son antiguas, así que no sé si todavía se puedan tomar al pie de la letra ahora que se agregaron muchas funciones. Aun así, si está cerca de eso, es un logro enorme.