- La reciente tendencia de reescribir herramientas de Node.js en lenguajes más rápidos como Rust, Zig o Go resulta preocupante, y aquí se ordenan algunas inquietudes objetivas.
[Rendimiento]
- Se considera que todavía no se han explorado todas las posibilidades para acelerar las herramientas de JavaScript.
- En ESLint, Tailwind y otros todavía hay muchas áreas que se pueden mejorar fácilmente.
- En el navegador, JavaScript es "lo suficientemente rápido" para la mayoría de las cargas de trabajo.
- Entonces, ¿por qué en las herramientas CLI se intenta abandonar JavaScript?
Reescrituras a gran escala
- Durante mucho tiempo, el ecosistema de herramientas de JavaScript se ha enfocado en "hacer que funcione".
- Ahora que la mayoría de las API ya están estabilizadas, todos quieren "lo mismo, pero más rápido".
- Una herramienta nueva puede ser más rápida porque se escribe desde cero pensando en el rendimiento y porque la API ya está definida, lo que ahorra tiempo de desarrollo.
- Si se reescribe algo de A a B y mejora la velocidad, es fácil afirmar que B es más rápido que A.
- Pero la propia reescritura podría ser la razón de la mejora (porque en el segundo intento se sabe más y se pone más atención al rendimiento).
Bytecode y JIT
- En el navegador se da por sentado, pero ahí se obtienen los beneficios de la caché de bytecode y del JIT (compilador Just-In-Time).
- Si JavaScript se almacena correctamente en caché, el navegador no necesita parsear ni compilar el código fuente a bytecode.
- Las funciones que se ejecutan con frecuencia se optimizan aún más a código máquina (JIT).
- En los scripts de Node.js no se obtiene prácticamente ningún beneficio de la caché de bytecode.
- Pero ahora también se puede usar caché de compilación en Node (
NODE_COMPILE_CACHE configurando la variable de entorno).
- El JIT necesita ejecutar una función varias veces para que se "caliente", así que en scripts de una sola ejecución es difícil aprovecharlo.
- En Pinafore se intentó reemplazar una librería de blurhash en JavaScript por una versión en Rust (Wasm), pero para la quinta iteración la diferencia de rendimiento desaparecía.
- También podría considerarse compilar scripts de Node con AOT usando herramientas como Porffor.
- Usar Wasm implica una pérdida de rendimiento frente a una herramienta puramente nativa.
[Facilidad para contribuir y depurar]
- Este es el principal escepticismo frente al movimiento de "reescribir todo en nativo".
- JavaScript es un lenguaje popular por sus tipos permisivos, su facilidad de aprendizaje y su soporte en navegadores.
- Durante mucho tiempo, en el ecosistema de JavaScript tanto los autores de librerías como sus usuarios han usado JavaScript.
- Esto ayuda a reducir la barrera para contribuir.
- Pero si los autores de librerías de JavaScript usan otro lenguaje, esa ventaja se rompe.
- Además, modificar una dependencia de JavaScript localmente es sencillo (editándola directamente en
node_modules).
- En cambio, si está escrita en un lenguaje nativo, hay que hacer checkout del código fuente y compilarlo.
- Al depurar una librería de JavaScript, se pueden usar las conocidas herramientas de desarrollo del navegador o el depurador de Node.js.
- En Wasm tampoco es imposible depurar, pero requiere otro conjunto de habilidades técnicas.
[Conclusión]
- Es positivo que esté surgiendo una nueva generación de herramientas para el ecosistema de JavaScript.
- Las herramientas existentes parecen ser muy lentas y podrían beneficiarse de la competencia.
- Pero no se considera que JavaScript sea intrínsecamente lento ni que ya no tenga margen de mejora.
- Al ver las mejoras recientes en las herramientas de desarrollo de Chromium, da la impresión de que todavía queda mucho camino por recorrer.
- Preocupa cómo sería un mundo que termine siendo territorio exclusivo de desarrolladores de Rust y Zig.
- Un desarrollador promedio de JavaScript podría sentirse impotente al enfrentarse a un bug en una herramienta de build.
- Eso podría terminar enseñando indefensión aprendida a los jóvenes desarrolladores web.
- Este es un camino desconocido y podría traer consecuencias no deseadas.
- En cambio, existe otro camino menos riesgoso con el que se podría obtener casi el mismo resultado.
- Pero el rumbo actual no muestra señales de desaceleración.
Opinión de GN⁺
- Reescribir en Rust, Zig u otros lenguajes no siempre tiene por qué ser la mejor opción. Parece que todavía hay más margen de mejora dentro de JavaScript, por ejemplo con el compile cache.
- Es válido preguntarse si realmente es bueno exponer a desarrolladores principiantes a problemas complejos como un segfault. Más que ayudar, podría enseñarles impotencia.
- Hay que pensar si realmente vale la pena acelerar las cosas sacrificando ventajas del ecosistema construido durante años en JavaScript, como la modificación libre entre librerías o un entorno de depuración familiar.
- También parece necesario mantener los esfuerzos de mejora sobre las librerías actuales de JavaScript. El potencial de JavaScript todavía no se ha explorado por completo.
- Aunque la tendencia dominante parece difícil de frenar, esta dirección necesita una discusión y una reflexión comunitaria mucho más serias.
15 comentarios
La forma de operar de un negocio pequeño y la de una gran empresa pueden ser algo distintas. Más que adoptar una postura crítica sobre el hecho de cambiar en sí, creo que es más sano pensar en el significado de este fenómeno.
Puede parecer que se cambia por gustos o por seguir modas, pero normalmente las empresas no toman decisiones así.
¿Python o JavaScript en sí mismos son lentos? Aunque no necesariamente diría que sí,
¿las herramientas de uso frecuente hechas con Python o JavaScript son lentas? Creo que sí.
Uso varios dispositivos de bajo consumo, y de verdad hay muchas herramientas desesperantemente lentas..
En la comunidad de Python también se repite casi el mismo repertorio de argumentos.
JavaScript no está escrito en JavaScript, pero a la mayoría de los desarrolladores de JavaScript eso no les importa. Que para los "desarrolladores principiantes" o los "jóvenes desarrolladores web" no sea un problema que JavaScript no esté escrito en JavaScript, pero sí lo sea que las herramientas de desarrollo de JavaScript no estén escritas en JavaScript, no es una idea muy coherente. Más bien, los desarrolladores a los que realmente les importa eso son apenas una minoría ínfima dentro de ambos grupos.
Incluso sin negar que, con suficiente optimización, se pueden lograr velocidades casi iguales, ¿de verdad vale la pena?
Lo que pasa es que hemos llegado a una transición: de una época en la que era más rentable escribir herramientas de desarrollo en JavaScript en lugar de C++, a una época en la que es más rentable escribirlas en Rust que en JavaScript.
La forma de revertir esta tendencia no es lanzar una campaña de gastar más para optimizar JavaScript, sino apuntar a crear un entorno donde se puedan desarrollar herramientas eficientes de JavaScript con menores costos de desarrollo. (Puede parecer algo parecido, pero la diferencia está en dónde se pone el esfuerzo)
Estoy de acuerdo. Creo que hay que redefinir la rentabilidad poniendo en el centro a los usuarios de las herramientas.
Siento que, hasta ahora, la rentabilidad ha sido una métrica pensada más para los desarrolladores de herramientas que para quienes las usan. Las ineficiencias y problemas de rendimiento que tienen que experimentar los usuarios de estas herramientas parecían quedar relativamente relegados en las prioridades. En lo personal uso mucho uv y vite, y si es posible prefiero evitar herramientas como pip o create-react-app.
Me cuesta estar de acuerdo porque creo que las herramientas CLI deberían poder funcionar sin un runtime.
Si me dicen que se puede crear un ejecutable independiente con WASM, como también se menciona en el texto, habría una caída de rendimiento.
Así como no es común escribir CLI en Java, creo que con JavaScript pasa lo mismo.
Parece que el autor confunde que, como tanto las SPA como el desarrollo de herramientas de JavaScript usan JavaScript, entonces también requieren las mismas capacidades adicionales. Creo que las herramientas de JavaScript requieren conocimientos del ámbito de la programación de sistemas y de compiladores.
Aunque el lenguaje sea el mismo, el entorno de ejecución es distinto entre el navegador y NodeJS, y parecería que solo quienes pueden cruzar esa brecha podrían contribuir a las herramientas de JavaScript. Como los entornos de ejecución son distintos, ¿no habría que verlos como ecosistemas diferentes?
Creo que esto también sobreestima la cantidad de personas capaces de cruzar la frontera entre el desarrollo de SPA y el desarrollo de herramientas de JavaScript. Es excesivo exigir a un desarrollador frontend conocimientos comparables a los de programación de sistemas. ¿No es cierto que los usuarios de herramientas solo pueden entender mensajes de error superficiales o los síntomas visibles? No creo que sea un problema que se resuelva solo por conocer el lenguaje.
Parece que están mezclando herramientas y librerías. En cuanto a las librerías, puedo estar de acuerdo hasta cierto punto, pero con las herramientas... no sé.
Los desarrolladores de otros lenguajes también están acostumbrados a que las herramientas estén escritas de forma nativa.
Personalmente, ya sea una herramienta o una librería, si está escrita en JavaScript, los desarrolladores familiarizados con JavaScript pueden depurarla y, si hace falta, contribuir. Pero si se reescribe en Rust, las contribuciones de código abierto terminan quedando limitadas solo a desarrolladores de Rust. Como la base de desarrolladores de JavaScript es abrumadoramente más grande que la de Rust, en el ecosistema de código abierto puede ser más conveniente que tanto las herramientas como las librerías estén escritas en JavaScript.
Creo que JavaScript tiene un entorno de ejecución fragmentado entre el navegador y NodeJS, y por eso una comparación simple entre la cantidad de usuarios del lenguaje tiene límites como argumento. Los desarrolladores backend de Spring y los desarrolladores del JDK, así como los desarrolladores de React/Angular/Vue y los desarrolladores de herramientas de JavaScript, tienen intereses y posturas distintas, y están en una relación de consumidores y productores.
Personalmente, pienso que si el objetivo es mejorar el rendimiento y la usabilidad de las herramientas de JavaScript, cambiar el lenguaje de implementación, que es un medio, también puede ser una opción válida.
Me parece difícil distinguir claramente entre los consumidores y los productores de herramientas de desarrollo. A medida que una empresa crece, muchas veces personaliza la cadena de herramientas o implementa plugins adicionales según las reglas que quiere seguir, y en esos casos creo que usar el mismo lenguaje por sí solo ya es una gran ventaja.
También hay muchos casos en los que los usuarios de la herramienta se interesan por sus mejoras o por su implementación y terminan contribuyendo de forma natural.
Creo que quien se interesa en la personalización del toolchain o realiza ese trabajo está asumiendo un rol que va más allá del de consumidor, más bien el de prosumidor o incluso productor. En el caso de los plugins, considero que se mueven dentro del contrato del plugin entre productor y consumidor. En esa situación, también coincido en que usar el mismo lenguaje ayuda, tanto técnicamente como en costos de comunicación, más que ofrecer un formato de archivo de configuración separado o puntos de extensión.
Sin embargo, no creo que los problemas de rendimiento de las herramientas de JavaScript o el problema de la latencia del JIT de NodeJS estén dentro del margen de decisión del consumidor. Esto se debe a que quienes definieron esa arquitectura y esas especificaciones de funcionamiento fueron los productores de herramientas y los desarrolladores del runtime.
Es dudoso que, solo porque el ecosistema de JavaScript sea grande, eso signifique que habrá más desarrolladores que puedan contribuir a las bases de código de compiladores/transpiladores. Creo que las bibliotecas, los frameworks y las herramientas de infraestructura son ámbitos completamente distintos.
Pero reescribir en sí mismo podría ser la razón por la que es más rápido -> viéndolo en retrospectiva, esto sí que es muy cierto...
Estoy de acuerdo con lo que dice esta persona precisamente porque es muy selectivo.
Aun así, en otro nivel, creo que el hecho de que existan diversas soluciones además de JS es un elemento muy importante para el progreso tecnológico, así que también pienso que la situación contraria debería ser respetada.
Opiniones de Hacker News
Existe la opinión de que JavaScript es inherentemente lento. Muchos ingenieros han intentado hacerlo más rápido, pero aun así sigue siendo más lento que los lenguajes con tipado estático. Para programas a gran escala, los lenguajes con tipos claros son más adecuados.
JavaScript no es fácil de aprender y tiene un sistema de prototipos y de tipos complejo. TypeScript lo compensa, pero aun así sigue siendo complejo.
Solo con cambiar de lenguaje, el rendimiento puede mejorar mucho. Al cambiar un sistema existente de JS y PHP a Go, se experimentó una mejora de rendimiento de 8 a 10 veces.
Se está pasando por alto la importancia del procesamiento en paralelo. Rust es adecuado para escribir código en paralelo, mientras que JS no lo es.
JavaScript ahora tiene una velocidad similar a la de Java y es de 2 a 4 veces más lento que C++. Para mejorar el rendimiento, hay que salir de la zona de confort.
Los programas en Rust, Zig y Go permiten revisar el código fuente y compilarlo fácilmente. Aprender un nuevo lenguaje influye en la forma de resolver problemas.
Se considera que todavía no se han agotado todas las posibilidades para mejorar el rendimiento de las herramientas de JavaScript. Construir sobre una base mejor es más eficiente.
Rspack es una reescritura compatible de Webpack hecha en Rust, con una mejora de rendimiento de 5 a 10 veces. Puede reemplazar fácilmente a Webpack.
En JavaScript es fácil modificar dependencias localmente, pero Rust tiene menos bugs, así que hay menos necesidad de corregirlos. Rust es difícil de aprender, pero a través de él se puede llegar a ser mejor programador también en otros lenguajes.