dos novedades de Node.js. Ojo, cuidado, Node.js. Acaba de salir la versión 22.7.0 y trae dos
novedades súper interesantes. Uno, más soporte de TypeScript y dos, detección automática de la
sintaxis de módulos. Y ahora os explicaré cómo funciona esto. Mirad, vámonos aquí, por ejemplo,
temporal, Node, 22, test y vamos a probar esto. Vamos a crear un archivo index.ts, o sea,
directamente de TypeScript. Recordad que ya vimos hace un tiempo, se podía hacer esto,
¿no? De string 1, ¿no? Y esto, bueno, claro, es que he puesto que es tipo string, no tiene
mucho sentido. Esto ya se podía utilizar con Node experimental strip types, si no me equivoco,
¿era así? ¿Puede ser? Vale, fijaos, Node experimental strip types y podías utilizar la sintaxis de
TypeScript. Porque esto normalmente, si haces así, ¿vale? Esto peta. ¿Por qué? Porque no entiende
la sintaxis de TypeScript. Node index.ts te dice, oye, no entiendo esta sintaxis. Esta sintaxis está
mal. Pero ya teníamos experimental strip types y entonces ya podías ejecutar código de TypeScript,
ignoraba los tipos y lo podías ejecutar. ¿Pero qué pasa? El problema que teníamos aquí es que si yo
tengo un enum, ¿vale? Le ponemos aquí red, green, blue, ¿vale? Y aquí vamos a poner pues rgb.red por
poner algo. Vamos a quitar aquí esto. Esto es un enum. Es una sintaxis que solo tiene TypeScript. Si
esto intento hacer esto, ¿qué te pone aquí? Enum no está soportado en strip only mode. ¿Por qué? Lo que
hace el strip mode, el strip types, lo que hace es eliminar los tipos. Los elimina directamente, ¿vale?
¿Qué pasa con los enums? Que si yo elimino los enums, no entiende cómo funciona esto, ¿vale? Ya no tiene
sentido, ya no funciona bien. Entonces, lo que ocurre es que han puesto un nuevo flag que se llama
experimental transform types, que lo que va a hacer es transformar los tipos y ahora sí va a hacer
ciertas compilaciones. Por ejemplo, experimental transform types index.ts y ahora pone cero porque el
red, como es un enum y no lo hemos puesto, esto sería cero, esto sería uno, esto sería dos. Le
podemos poner aquí lo que queramos, por ejemplo, el valor más bien con una cadena de texto y
ahora deberíamos ver red. Experimental transform types. Por ahora, lo único que está añadiendo
sería soporte para enum y namespace. Por ahora, que más adelante igual, pues le ponen a decoradores,
quién sabe, a lo que sea, ¿vale? Experimental transform types para transformar el código que
solo funcionaría en TypeScript en código de JavaScript. O sea, que ahí tenemos una novedad
bastante interesante. Dice, totalmente inservible porque lo que se manda Node.js es el transpilado.
Me parece un poco valiente decir totalmente inservible, especialmente cuando hablamos de
totalmente en cosas totales, ¿no? En blanco y negro. Yo lo que creo es que me parece que este tipo
de transformaciones es bastante útil en algunos corner cases. O sea, no significa que lo tenga que
utilizar todo el mundo y es verdad que se puede mandar el Node.js transpilado, pero también puede
ser que esto habilite la posibilidad de hacer pruebas muy rápido en Node.js, como por ejemplo,
pues sin necesidad de instalar ningún tipo de transpilador ni de nada. Pues tienes el archivo
aquí. Esto es experimental, pero eventualmente lo hará de forma automática sin necesidad de
indicar nada. Que lo haga de forma transparente y tú pongas index.ts y te funcione. A mí me parece
que va a ser algo que la gente va a utilizar potencialmente. A día de hoy es experimental,
igual tú no lo usarás porque, bueno, puede ser. Al final no significa que lo tenga que utilizar
todo el mundo, pero me parece que va a ser un añadido que mucha gente estaba esperando porque
no hay que olvidar que una de las demandas más grandes en la última encuesta del State of JS,
el State of JavaScript del año pasado, es el hecho de no poder utilizar tipos en su código
de JavaScript. Y esto te lo permite. Por lo tanto, yo creo que, hombre, totalmente inservible yo no
diría. A lo mejor a ti no te gusta, pero yo creo que hay gente que sí que lo va a disfrutar sin
ninguna duda. Si no te gusta esto, al menos vamos a ver otra novedad que tiene también esta versión
de Node.js. A ver qué os parece, que también tiene bastante buena pinta. Y es que, ¿qué problema
hemos tenido con Node.js en mucho tiempo? Pues que imaginad que tenemos aquí dos archivos,
¿vale? Module.js. Y aquí tengo un export const rgb, ¿vale? Vamos a poner también el mismo
rgb, pero como una constante, voy a importar rgb del módulo .js console.log rgb.r. Esto es JavaScript,
¿vale? Esto es JavaScript normal y corriente con el import y esto con el export. Y el problema
que tenemos en Node.js es que hacías Node.main.js y ahora funciona. Ahora funciona. Porque en esta
nueva versión de Node, en la versión 22.7.0, han activado la detección automática del sistema de
módulos por defecto. ¿Qué significa esto? Que ya no tienes que indicar en el package.json si es un
tipo módulo, si no es tipo módulo y tal. Para que lo veas bien, fíjate que si cambio la versión de
Node y pongo la versión 20 y ejecuto otra vez lo mismo, me va a petar. Y me va a decir,
oye, no puedes utilizar un import fuera de un módulo. Import no sé qué, no sé cuánto. ¿Por qué?
Porque tenías que crear un package.json y decirle que esto era de tipo módulo. Y entonces ahora
Node dice, ahora sí que puedo ejecutarlo porque son imports. Ahora sí lo entiendo. Bueno, pues esto es un
rollo, la verdad. Es un rollo. Y ahora, desde la próxima versión 22, tenemos la posibilidad de
indicarle, de no indicarle nada y automáticamente lo detecta. Lo cual, pues también una mejora bastante
importante. Algo que decían que era imposible de hacer. Esto decían que era imposible hacer. Igual
que poder mezclar Common.js con Enmascript Modules. Pero como BAN lo hizo, parece que Node.js ahora de
repente es capaz de hacerlo. Cosas que pasan. ¿Cuál es la diferencia entre Node, Dino y BAN? No entiendo.
Pues que son tres entornos de ejecución de tres compañías diferentes. Los tres básicamente harían
un poco lo mismo, o sea, la misma idea. Aunque hay algunos que tienen más funcionalidades, como BAN,
por ejemplo, tiene su propio empaquetador integrado. Pero la idea sería un poco la misma, solo que igual
que hay Chrome, Brave, Safari, Firefox, ¿vale? Son cuatro navegadores que son diferentes, pero son
navegadores. Pues esto sería lo mismo. Node, Dino y BAN son tres entornos de ejecución y cada uno,
pues, de creadores distintos. Y ya está. Ese sería el tema. Totalmente inservible usar TypeScript en
web porque se manda el transpilado. Hostia, pero, a ver, creo que es el mismo que lo he dicho antes.
Pero esto sería para el servidor. Esto no es para enviar. Este archivo no se envía al cliente. Esto
sería para ejecutar una línea de comandos, un servidor directamente. No sería para enviarlo al
cliente, ¿eh? No tenía mucho sentido. ¿Crees que el futuro de JavaScript sea incorporar tipos?
Creo que JavaScript va a incorporar tipos como comentarios. ¿Cómo pasa con Python? Pues
exactamente lo mismo. Yo creo que sí, ¿eh? Poco a poco dejarán de ser necesarios tanto
frameworks y configuraciones. Solo Node.js. Sin ninguna duda. Sin ninguna duda. Yo creo que
estas cositas que van añadiendo seguramente van a marcar la diferencia para no tener que
utilizar... Que ahora mismo, si alguien por lo que sea necesita utilizar TypeScript en Node,
lo más recomendable sería utilizar este paquete, que se llama TSX, que dice la forma más fácil de
ejecutar TypeScript en Node.js. Y es verdad que es súper fácil, que funciona muy rápido, que haces
TSX y el nombre del fichero y te olvidas de todo. Pero bueno, mientras por lo que sea, pues llega
Node.js a todas las versiones, pues ahí lo tenéis.
Midu, ¿te parece descabellado migrar de JavaScript usando Next a PHP usando LifeWare? Descabellado,
no me parece nada en esta vida, especialmente si tiene sentido para ti. Ahora, me parece lo
más adecuado o lo que seguramente le vaya a aportar más valor al producto, a no ser que
no te das ni idea en Next, no lo creo. Pero bueno, este tipo de decisiones al final cada
persona sabe cuál es el equipo, qué es lo que puede hacer o dejar de hacer.