Sigues sin tener ni la más mínima idea de que cojones es todo eso de los "módulos" de JS y a estas alturas ya te da hasta corte preguntar? O a lo mejor simplemente quieres tener más munición para cagarte en toda la estirpe de JS? En cualquier caso este es tu hilo! ⬇
Todo empezó hace muchos años, cuando alguien decidió que meter 84 toneladas cúbicas de JS en cada página para hacer un sinfín de virguerías molestas era buena idea.
Y así nacieron los "utils.js" de un peso medio más alto que la mama de tu peor enemigo y de un contenido de dudosa calidad, fruto de meses y meses de copiar y pegar de foros daniweb y yahoo answers. Pero incluso los peores chapuceros javascripteros se dieron cuenta...
...que copiar y pegar el "utils.js" de proyecto en proyecto era una 💩 inviable de mantener. Así que descubrieron el concepto de "librería". Lo que cualquier otro lenguaje no oligofrénico (no, tu no, PHP, a ti también te faltó oxígeno al nacer) te ofrece.
Para hacer una librería el lenguaje ha de tener alguna manera de importar y exportar código. JS no la tiene, así que se formó un equipo de expertos encargado de desarrollar una especificación para la implementación de JS que permitiera esJHAHJAHJAHJHJAHJAHJAJ no. Se hizo una ñapa
Como los navegadores tienen una variable global llamada "window", se usó eso para exportar/importar. Vamos a llamar a esto "ECMAScript module v1".
¿Y si querías usar 2 librerías que, por alguna casualidad, tuviesen una función llamada igual?
Pues...
Luego alguien pensó que las 84 toneladas cúbicas de JS en el front no eran suficientes y había que meter más en el backend. Y así nació Node.JS
Menos mal que Node.JS estaba formado por profesionales que, esta vez sí, estaban determinados a arreglar el problema de raíz porqJHAHJAHJAHJHAHJAHJAJAHHJAHJA.
Hicieron otra ñapa: CJS (o "CommonJS", que de "common" tenía lo que yo te diga)
Se montaron una sintaxis propia para exportar funciones de manera parecida que en los navegadores, pero en vez de "window" usaron "exports". Y para importar "require()".
Todo perfecto. Excepto que la operación de importar librerías era síncrona y encima no funcionaba en navegadores.
Pero la comunidad de JS tiene soluciones para todo. Nacen "webpack" y "browserify", que te permiten usar siempre "require()"...
...sin importar si estás picando código para frontend o para backend. Lo hacen convirtiendo de CJS a ECMAScript module v1 (nace el concepto de "compilar" / "transpilar")
"Pero y si quiero usar una librería de frontend en mi backend?"
Pues... por un lado, esas preguntas pasan cuando los javascripteros no tienen un depredador natural.
Por otro lado, nace "Babel" con varios plugins, uno de los cuales permite convertir de ECMAScript module v1 a CJS
El caso es que browserify se las apaña para meter 940 universos de JS adicionales completamente innecesarios, así que la comunidad se pone a crear (de nuevo).
Nace AMD.
AMD es como CJS, pero en vez de usar "exports" usa "define". Y funciona únicamente en navegadores. Eso sí, este ya es asíncrono.
"Pero y si quiero usar una librería hecha con AMD en NodeJS?"
Babel empieza a parir mas plugins. Uno para convertir de AMD a CJS, otro para convertir de CJS a AMD, uno de AMD a ECMAScript module v1, uno de ECMAScript module v1 a CJS, etc...
Todo se convierte en un espectáculo lamentable. Reina el caos total y completo. La gente que pica las librerías más famosas del momento (jQuery, lodash, underscore, backbone, etc...) no tienen ni pajolera idea de por donde tirar.
Hay quienes empiezan a sacar versiones de sus librerías adaptadas a todos los formatos, hay quienes eligen un formato en particular y obligan a la gente a convertirla a lo que necesiten.
A estas alturas no usar Webpack ya no es una opción.
Alguien se da cuenta de que todo esto sobrepasa los límites de la inmundicia permitidos por las leyes internacionales y decide arreglarlo.
Formando un grupo de expertos y dándoles como tarea crear unas especificaciones para JS que permitan implementar una funcionalidad de importar / exportar código?
Casi. Bueno no, ni de lejos...
Nace UMD.
UMD es, literalmente, CJS y AMD metidos a presión dentro de una función con un if/else.
Plugins de Babel?
De AMD a CJS, de CJS a UMD, de AMD a UMD, de UMD a CJS, de CJS a ECMAScript module v1, de ECMAScript module v1 a UMD, de UMD a AMD, de AMD a UMD.
No, espera, este último ya lo he dicho. O no? Yo que se ya... La situación escala a DEFCON 1.
UMD es lo más compatible, porque funciona tanto con Node.JS como con los navegadores, pero literalmente la mitad de todo el código generado por webpack / babel es wrappers de wrappers de sistemas de importar / exportar código.
El JS que le llega al navegador prácticamente duplica el tamaño "original" del código (lo que ocupa el código sin estar envuelto en varias capas de estupideces).
Ahora sí, tras años de 💩 completamente rebozando las alcantarillas de la comunidad JS, entra en juego el equipo de expertos encargado de implementar alguna forma de importar / exportar código.
Nace ESM (2015).
No podía ser de otra forma, la sintaxis no es igual a ninguno de los anteriores "estándares", sino que tiene tintes de cada uno.
Pero oye, al menos es compatible tanto con Node.JS como con los navegadores.
Entonces... ¿problema solucionado?
Resulta que al equipo de expertos se les olvidó un pequeño detalle. Tanto AMD como UMD soportaban importar código de manera asíncrona (bastante importante para el tema de rendimiento en los navegadores), pero ESM no lo permite.
Oops...
Nace SystemJS.
SystemJS es una especie de ESM con tintes de CJS. Lo bueno es que funciona tanto en NodeJS como en navegadores y es asíncrono. Lo malo es que es otro hack mas por encima de todos los hacks anteriores; no es una solución nativa del propio lenguaje.
Como dice el dicho, a la trigésimo octava va la vencida. El equipo de expertos se reúne una vez más, y nace ESDM (ES11 dynamic module o ECMAScript 2020 o como queráis llamarlo).
ESDM es una mezcla entre ESM y SystemJS, funciona en todos los sitios y permite importar código de manera asíncrona.
El año que viene cuando salgan 6 o 7 estándares nuevos de importar y exportar código, continuo con este hilo.
Hasta otra!!
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.