Compartir:
){kind=small}
Actor de formación con una disertación sobre la comedia, llegué al desarrollo de PHP a través de la escena de las reuniones. Puedes encontrarme hablando y escribiendo sobre tecnología, o tocando/comprando discos raros de mi colección de vinilos.
Elige tu propia aventura JavaScript
Tiempo de lectura: 8 minutos
El hecho de que JavaScript (JS) se haya convertido de facto en el segundo lenguaje de programación para todos los desarrolladores de aplicaciones web tiene algo de extraordinario. Es impresionante, teniendo en cuenta que el propio nombre se eligió para alinearse con el lenguaje de programación Java a pesar de ser completamente diferente en lo fundamental. El año pasado escribí que el éxito de PHP se debe a su evolucióny ciertamente se podría argumentar que el único otro lenguaje que ha visto el mismo nivel, si no más, de esta evolución es JS. Pero, ¿cómo abordar esta vasta pila de opciones? Me inspiré en este ya legendario artículoque recuerdo haber leído en su momento y deleitarme con lo complejas que se habían vuelto las cosas. En este artículo, repasaremos los orígenes, ventajas y desventajas de lo que ha dado lugar a este complejo ecosistema.
Back To The BeginningLas limitaciones de Vanilla JS fueron cubiertas por el primer gran lanzamiento de la librería jQuery. Hoy en día, jQuery tiende a ser el blanco de las bromas debido a que los problemas que resolvía se incluían de forma nativa en el lenguaje, pero probablemente merezca la pena señalar que jQuery sigue teniendo una cuota de mercado del 90% en los sitios web en 2025. La complejidad de frameworks front-end modernos como Vue y React se ve totalmente compensada por la simplicidad de jQuery para aplicaciones más sencillas.
Ryan Dahl lo cambió todo en 2009. En ese momento, el motor V8 de Google en el navegador Chrome, JScript en Internet Explorer y SpiderMonkey en Firefox eran los principales motores de ejecución en uso para sus respectivos navegadores. En un verdadero momento de innovación, Ryan planteó la pregunta: "¿Y si sacas el motor V8 y lo ejecutas en un servidor en su lugar?". Y así fue, Node sin darse cuenta de que todos los futuros desarrolladores se confundirían al saber exactamente cómo se describe lo que realmente es a la gente. ¿Es un framework? No. ¿Es JavaScript? No. "Un tiempo de ejecución y cadenas de herramientas periféricas" es el bocado de una respuesta correcta.
Watch that node_modules directory grow!Una vez que se dispone de un lenguaje del lado del servidor, el siguiente paso lógico es contar con un sistema de gestión de paquetes. El gestor de paquetes Node (npm) fue la herramienta por defecto durante años, pero como ya hemos visto, el ecosistema JavaScript rara vez permanece quieto mucho tiempo. No contentos con el rendimiento que ofrecía la resolución de dependencias, Facebook creó Yarn en 2016. Yarn vio la introducción de un nuevo archivo de bloqueo y, lo que es más importante, el almacenamiento en caché sin conexión. La mejora del rendimiento podría verse como algo similar al desarrollo de PHP7 en respuesta a HHVMEn consecuencia, npm mejoró considerablemente sus velocidades de rendimiento y abordó los problemas que llevaron al desarrollo de Yarn en primer lugar. Por lo tanto, el viejo "depende de tu preferencia" es la respuesta realista a "¿Cuál debo usar?".
JavaScript no tenía originalmente un sistema modular que permitiera exportar archivos y propiedades/funciones. El auge de Node y el considerable escalado de las aplicaciones web hasta rivalizar con las aplicaciones nativas de los sistemas operativos, tanto en el front end como en el back end, obligaron a solucionar este problema. Esto llegó en forma de CommonJSun estándar que permitía importar usando el método require() de ayuda.
Como hemos visto en otros sitios, JavaScript está lleno de desarrolladores que intentan resolver problemas existentes, y uno de ellos fue Node habilitando las exportaciones con CommonJS. Por lo tanto, la solución permanente sería: ¿cómo conseguimos importar/exportar de forma nativa en JavaScript? En 2015, ECMAScript hizo precisamente esto con la adición de ESM (Módulos ECMAScript).
En un patrón que probablemente estés empezando a notar, tienes por lo tanto dos métodos diferentes para escalar aplicaciones. "¿Cuál debería usar?", te preguntarás. De nuevo, la respuesta técnicamente es "el que funcione para usted", pero eso no es del todo exacto. Para proyectos nuevos, se recomienda usar ESM debido a que es nativo, y a que incluye soporte para tree-shaking y análisis estático.
A Saviour Is BornLa cuestión con JavaScript en el motor del navegador o Node es que es un lenguaje débilmente tipado que intentará ejecutar prácticamente cualquier cosa que intentes hacer. Los que vienen del mundo de Java, C# y otros lenguajes compilados probablemente se estremecerían de horror ante la capacidad de los desarrolladores de JS para escribir montañas de código sin sentido (y lo hicieron: Recuerdo perfectamente una herramienta de frontend en la que todos los argumentos de la función de ayuda principal eran variables como letras sueltas que deletreaban el producto, que permanecerá en el anonimato). JS siempre tiene a alguien que viene a abordar sus limitaciones, y para este caso en particular, fue Microsoft.
Microsoft desarrolló un superconjunto de JavaScript que aportaba un sólido sistema de tipado en forma de compilador y tiempo de ejecución. un compilador y un tiempo de ejecución (que puede invocarse con npx). La adopción de TypeScript ha sido bastante fenomenal, especialmente cuando es probable que los requisitos de las aplicaciones se amplíen rápidamente. En Vonagenuestro propio SDK de Node fue totalmente reescrito en Chuck Reeves para la versión 3, que lo portó a TypeScript.
La introducción de npm como gestor de paquetes creó un problema único para los desarrolladores frontales: una nueva carpeta llamada node_modules en los proyectos, pero ¿cómo enviar estas dependencias al código del frontend? Antes de npm, Bower gestionaba las dependencias frontales. Sin embargo, npm prácticamente lo hizo redundante. Usado en conjunto con npm, Grunt y Gulp se usarían como ejecutores de tareas, más comúnmente usados con herramientas como Babel para transpilar a JavaScript de bajo nivel.
La solución de compilación unificada llegó en forma de Webpackque compilaría todo un front-end en un archivo JS unificado basado en un sistema de activos. Todos los archivos CSS, archivos fuente JS o de gestión de paquetes, archivos de imagen, lo que sea. Añade el compilador Typescript si lo necesitas y tendrás un potente constructor. Aunque siempre hay un "pero"...
He trabajado mucho con Webpack en trabajos de agencia y empresas comerciales, y puedo decir que una gran potencia conlleva una gran complejidad. Ejecutarlo en cada compilación lleva mucho tiempo, y la cantidad de veces que se caía por problemas de configuración me daban ganas de echarme a llorar rutinariamente. Así que, siguiendo con el espíritu del artículo: ¿adivinas qué pasó después? Así es, alguien vino y construyó otra cosa. El autor de la librería VueJS (personalmente, Vue es el único framework JS front-end con el que he disfrutado trabajando, pero ese es un tema para otro día) Evan You creó Viteun compilador y servidor escrito desde cero con benchmarks súper altos. Fue adoptado rápidamente por Remix, Laravel, Nuxty Astroque es una cartera de bastante alto perfil.
The Journey Never EndsEsta es la parte en la que realmente disfruté de la evolución de JS. Donde Node puso patas arriba la pila de aplicaciones web, el tiempo tenía planes para crear nuevos problemas. En 2009, Serverless y Cloud Native computation estaban en sus inicios. En 2016, los ingenieros de DevOps tenían expectativas de alto rendimiento al enviar cierres de funciones enteras en Node a través de los tiempos de ejecución de computación de las plataformas en la nube. En esta etapa teníamos dos problemas: el rendimiento a los millones de eventos en el bucle de eventos para aplicaciones de alta disponibilidad y el sistema de paquetes de Node (que a estas alturas también era responsable de todo en el front-end) entrando en un infierno de dependencias de proporciones similares a los memes.
El primer problema fue abordado por el creador original de Node. En 2018, Ryan anunció Denoy, dos años más tarde, vio el lanzamiento de producción de Deno. Obviamente, Deno no podía "resolver" el infierno de dependencias que había surgido de npm de la noche a la mañana, pero sí puso en marcha varios mecanismos que estandarizarían a cualquier adoptante del tiempo de ejecución:
Compatibilidad inmediata con Typescript, lo que supone un impulso hacia un código más robusto.
Sólo se utilizan módulos ESM por defecto, por lo que no es posible combinar ESM y CommonJS.
Eliminación de un gestor de paquetes por defecto. Con el descubrimiento de paquetes solo a través de URL, estandarizó el tiempo de ejecución para evitar que esté estrechamente acoplado a una herramienta de gestión (es decir, npm).
Una API más ágil. Uno de los principales problemas de Node era que pequeños trozos de código "se convertían efectivamente en el núcleo". Absorber las bibliotecas más vitales como una biblioteca estándar y cortar el exceso fue un movimiento inteligente, y uno que posiblemente podría detener cosas como que un par de líneas de código rompan Internet.
Entonces, ¿la conclusión no sería que todo el mundo se mudara a Deno? Pues no. Porque entonces:
Bun.sh se lanzó en 2021. Admito que me sorprendió que otro runtime del lado del servidor fuera lanzado. ¿Qué ha pasado aquí?
Bueno, Deno fue una reimaginación de Node por parte de su creador, con algunas decisiones de arquitectura para detener directamente los problemas de herramientas y ecosistema que vinieron después de Node. Bun, sin embargo, realmente fue a la ciudad: se lanzó para eliminar las herramientas opcionales de terceros esenciales para ejecutar JS del lado del servidor. Eso significaba:
Compatibilidad inmediata con TypeScript, al igual que Deno
Un ejecutor de pruebas integrado
Un gestor de paquetes integrado
Transpilador integrado
Un bundler incorporado (piense en Vite o en el bundler de Ruby)
Todos ellos se construyeron en Zigque es comparable a los nuevos lenguajes de programación de bajo nivel que han sustituido a C o C++, como Rust. "Pero, ¿cuál debería elegir?". vuelvo a oírle preguntar. La verdad es que no hay una respuesta correcta. Cualquiera que abogue por una se equivocará en otro aspecto de lo que está intentando hacer, y eso es sólo full-stack JS para ti.
Espero que hayas disfrutado de la vasta y extensa aventura que es la evolución de JS. La cuestión es que no hay una respuesta correcta o incorrecta cuando se trata de elegir pilas y herramientas. Ni siquiera llegué a Astroo Svelteo Remixo Nuxto Siguiente. Sólo soy un humilde desarrollador que intenta distribuir software. Con la tienda de comestibles de tiempos de ejecución y herramientas disponibles, lo que yo puedo hacer es aceptar sugerencias sobre con qué herramientas trabajar en artículos que usan las API de Vonage? Únete a nuestra próspera comunidad de desarrolladores en Slacko síguenos en X (antes Twitter), o suscríbete a nuestro Boletín para desarrolladores. Mantente conectado, comparte tus progresos y entérate de las últimas noticias, consejos y eventos para desarrolladores.
Compartir:
Actor de formación con una disertación sobre la comedia, llegué al desarrollo de PHP a través de la escena de las reuniones. Puedes encontrarme hablando y escribiendo sobre tecnología, o tocando/comprando discos raros de mi colección de vinilos.