Hoy vamos a aprender Dino desde cero.
¿Qué es Dino? ¿Por qué es interesante? ¿De qué trata Dino? Y todo esto.
Vale, Dino básicamente es un entorno de ejecución moderno para JavaScript y TypeScript.
Y esto de que sea para TypeScript es súper importante y súper interesante.
¿Por qué? Porque Node.js es un entorno de ejecución, pero solo de JavaScript.
En cambio, Dino, aparte de ser de JavaScript, también lo es de TypeScript.
¿Esto qué significa? Pues que vamos a poder ejecutar nuestro código de TypeScript sin necesidad de instalar ningún tipo de dependencia.
No vamos a tener que descargar TSC, no vamos a tener que hacer nada. Ya lo soporta de forma totalmente nativa.
Dino además está escrito con Rust. Y Rust ya lo hemos visto aquí unas cuantas veces, es un lenguaje de programación de sistema muy rápido.
Y esto hace que Dino también tenga, en cuanto a rendimiento, un muy buen rendimiento.
Al ser moderno, que ya te puedes fijar que lo dice aquí, no tiene tanta mochila de muchos años de desarrollo como sí que tiene Node.js.
Así que esas serían algunos de los beneficios que tiene. Pero tiene más, por supuesto. ¿Qué tiene más?
Bueno, pues que es seguro por defecto. ¿Qué quiere decir? No tienes acceso a los archivos, a la network, a las variables de entorno por defecto.
Eso es una cosa que sí que pasa en Node.js. Tú en un proyecto en Node.js ya tienes acceso a leer archivos, a escribir archivos, a hacerlo todo de golpe.
De hecho, Dino, para que te quede clarísimo, Dino es del creador de Node.js.
El mismo creador de Node.js, que es Ryan Dahl, es el creador de Dino. ¿Y por qué ha creado Dino?
De hecho, Dino, si te fijas, es no de. ¿Vale? ¿Por qué lo hizo?
Bueno, hay una charla muy buena que te recomiendo en la gs.conf, en la que dice todas las 10 cosas que se arrepiente de haber hecho de Node.js.
Y es Ryan Dahl, el creador de Node.js. Y te explica por qué hizo Dino.
Y estas 10 cosas, te dice, bueno, pues no me gustan los Node.js, no me gusta el tema de que no es seguro.
Este tipo de cosas te las explica. Y está muy bien la charla, son 26 minutos, pero te lo recomiendo un montón.
Aquí lo tendríamos en la seguridad, NPM, en la resolución de los nombres, el hecho de que no soporte TypeScript por defecto,
opciones de compilador, compatibilidad de cosas de la web, por ejemplo, cosas así.
Así que tiene un montón de cosas y eso lo vamos a ir viendo.
Bueno, que soporta TypeScript fuera de la caja, que puedes compilarlo todo en un simple ejecutable también, que es muy chulo.
Luego tienes un montón de utilidades como el linter, el formateador de código.
Y luego que tienes un montón de paquetes y librerías en estándar, ¿vale? La estándar library.
Esto es súper interesante porque aquí tienes un montón de cosas que la propia gente de Dino está soportando
para acceder al file system, para tener cosas de permisos, paz.
Es parecido a lo que ya tendría Node, pero digamos que lo tienes separado del core.
Y esto es una ventaja muy grande, porque de una forma tú puedes ir actualizando Dino,
mientras que lo que sería la librería estándar está totalmente separada, lo cual está súper bien y súper interesante.
Entonces la puedes importar y ya veremos cómo lo importamos, que esto es bastante curioso, ¿vale?
Luego veremos cómo se importan las cosas.
Vamos con la instalación. Aquí tendría la instalación para cada uno de los temas.
Además, yo no sé si instalé, utilicé Braille, no me acuerdo si utilicé Brew o utilicé Shell.
Yo creo, voy a utilizar este, voy a utilizar este, o igual yo ya tengo Dino, sí, yo ya tengo Dino,
pero si no lo que podéis hacer es ejecutar este comando o utilizar el de Brew install Dino.
No lo voy a ejecutar porque no me acuerdo con cuál de los dos lo hice y si lo hago con uno que no es el correcto,
igual la lío para, ¿vale? Pero si tenéis Brew, pues utilizad Brew y si no, pues con lo de Shell.
Este sería para Linux y Mac y este sería para Windows y si tenéis gestores de paquetes como Brew, Choco y tal,
pues podéis utilizar cualquiera de este, ¿vale? Entonces ya lo tendríamos instalado, ya nos dice el Getting Started,
ya tendríamos el ejecutable de Dino, en este caso lo tengo aquí, podríamos poner Dino Version
y esto nos va a decir si realmente tenemos instalado Dino en nuestra máquina, ¿vale?
En este caso ya tengo la versión 1.18.1 y aquí tendría la versión, este V8, este es el motor que utiliza Chrome de JavaScript
y vemos que tiene la versión 9.8 y TypeScript que tiene la 4.5.2, ¿vale?
Lo que podemos hacer ya es ejecutar nuestro primer script, nuestro primer script.
En este caso, fíjate que puedes hacer un Dino Run y le puedes indicar una URL externa
que lo que va a hacer es ejecutar directamente este archivo en tu máquina.
Esto es una cosa que también es bastante diferente respecto a cómo funciona Node, ¿vale?
Así que vamos a darle y vamos a ponerlo y ya podemos ver, bueno, Welcome to Dino.
Esto es todo lo que hace este script.
Si le echamos un vistazo, pues ya veremos lo que tiene.
Console.log, Welcome to Dino, ya está.
Con un copy and write, no vaya a ser que alguien se copie esta línea de código, ¿no?
Y ya está.
Y dice, Alejandro, haz una muy buena pregunta.
¿Y eso no es peligroso?
Pues en este caso vamos a ver que no es peligroso.
¿Por qué?
No es peligroso justamente porque no tiene permisos Dino por defecto.
Si este script, por lo que fuese, intentase hacer una llamada a una API
o intentase escribirnos ficheros o leernos ficheros o variables de entorno,
no podría porque no le hemos dado permisos.
Esto es totalmente diferente a cómo funciona Node.
es una cosa que iremos viendo, ¿vale?
Entonces, bueno, aquí tendríamos un primer ejemplo de hacer un servidor.
Vamos a hacerlo, si os parece.
Dino Example, Dino Example y vamos a abrir Visual Studio Code y empezamos con todo.
Vale, cuando abrimos Visual Studio Code, una cosa interesante es que os instaléis justamente
la extensión de Dino, ¿vale?
Es esta de aquí, a Language Server Client for Dino.
Bueno, es este el correcto.
No tiene muchas descargas.
La verdad es que Dino no lo peta mucho y yo creo que cada vez va a ser bastante más interesante.
Bastante más interesante.
Así que creo que yo le iría empezando a echar un vistazo porque realmente le veo bastante potencial.
Aunque veo que la gente, a lo mejor es porque no hay muchas ofertas de trabajo,
pero aún así yo empezaría a aprenderlo y además creo que se puede aprender cosas muy interesantes.
Lo mejor es que como tiene muchas cosas de la app y de la plataforma web, pues puedes aprender JavaScript
mientras estás aprendiendo Dino.
Vale, pues os instaláis esta extensión porque, voy a poner aquí ya nuestro fichero index.js.
Lo que tienes que hacer para utilizar la extensión por defecto viene desactivada en tu workspace.
Lo que tienes que hacer es activarla, buscas aquí en los comandos, buscas Dino
y aquí verás que tienes Dino Initialize Workspace Configuration, ¿vale?
Así que le das y aquí te dice Enable Dino Linting, le damos que sí.
Si quieres activar las APIs no estables, le vamos a decir que no.
Y ahora sí se ha activado la extensión correctamente, ¿vale?
Así que tenedlo en cuenta porque no está activada por defecto, no detecta que este es un proyecto con Dino.
Y ya podemos ver que no tenemos ni un package JSON, no tenemos absolutamente nada.
Simplemente he inicializado la extensión y ya está.
No es como un npm init porque todavía no necesitamos inicializar nada.
O sea que no hacemos ni siquiera un npm init.
En este caso es más que nada la integración con el editor lo que hemos hecho.
Bueno, cosas que pasan.
Mira, aquí tenemos Uncatch or Missing Remote URL.
¿Y qué nos está diciendo aquí?
Pues nos está diciendo que claro, como...
Bueno, vamos primero a leer el código.
Os explico un poco el código que ya veis que es bastante simple,
pero que ya están pasando unas cuantas cosas.
Estamos importando ser de una URL.
Dino lo que utiliza desde el principio ya son los ECMAScript Modules.
No tiene require.
No puedes hacer como hacéis en Node.js, que hacemos un require de lo que sea.
Esto no existe en Dino.
Solo utiliza ECMAScript Modules.
Por eso dice que es moderno, entre otras cosas.
Y como podéis ver, en los ECMAScript Modules podéis hacer un import directamente de una URL.
Esto ya lo hemos visto unas cuantas veces, por ejemplo, en Codilink.
En Codilink aquí podemos importar...
A ver si me acuerdo...
Confetti...
Canva.
Siempre es el mismo ejemplo, ¿vale?
Pero ya veis que cuando le damos, aquí podemos hacer un import justamente de una URL.
Esto es una cosa que puedes hacer con los ECMAScript Modules y que es súper, súper interesante.
¿Vale?
Y ya está funcionando.
Pues esto mismo lo hace también Dino, lo cual hace que sea súper fácil sin necesidad de instalar.
Yo no he hecho ningún npm install, no he hecho absolutamente nada.
Y ya estamos aquí utilizando un paquete totalmente externo de una librería.
De hecho, es de DinoLand, de la librería STD, que es la estándar de Dino.
O sea, esto es una librería que están manteniendo el agente de Dino.
La versión la podemos ver aquí.
Podemos no ponerla.
Y entonces utilizaría la última, ¿vale?
Pero puedes indicar justamente la versión que quieres utilizar.
Y de aquí lo que estamos utilizando es del http barra server.ts.
¿Que esto es un rollo?
Pues quizás sí.
Quizás sí, pero bueno, vamos a ver cómo podríamos paliar esto.
Lo veremos después.
Porque claro, si cada vez que quieres utilizar una dependencia tienes que importarla de esta forma,
pues puedes ser un poco rollo, puedes traerte versiones diferentes, puede ser un poco caos.
Pero bueno, luego veremos cómo lo podemos solucionar esto, ¿vale?
Y así sí, así sí, así mismo se usa en producción.
O sea, así mismo, tal cual.
¿Por qué?
Porque esto lo que hace, como ya veis aquí el error, que veis que pone no está cacheado o falla esta URL remota.
Claro, lo que hace Dino es que cuando intenta ejecutar esto, lo vamos a ver ahora mismo y lo veremos funcionando,
lo que hace, básicamente, es que se lo descarga y lo cachea en la máquina.
Entonces, en producción haría exactamente lo mismo.
Una vez que lo despliega, descargaría este fichero si no lo tiene cacheado en la máquina y lo utilizaría y ya está.
¿Vale?
Luego vemos aquí un console lock, le decimos dónde es la URL y dónde estamos escuchando.
Utilizamos este método serve y respondemos a cada request con una respuesta que diga hello world en el puerto 8000, ¿vale?
Así que voy a guardar los cambios, aunque ya podemos ver aquí que me está fallando por algunas cosillas,
que me dice, oye, que esto no está bien, que no sé qué.
Esto es el linter de Dino, ¿eh?
Que Dino ya tiene un linter incorporado.
Voy a abrir aquí la terminal y vamos a poner dino run index.js.
Le damos al enter y fíjate, fíjate, vale, aquí vemos unas cuantas cosas, unas cuantas cosas en muy poco tiempo,
lo cual está súper genial, ¿vale?
Lo primero que estamos viendo es que, fíjate que ha hecho un download.
¿Qué ha pasado aquí?
Cuando hemos hecho el Dino run, ha hecho un download.
¿Por qué está haciendo este download?
Básicamente está haciendo el npm install, el típico npm install de Node.
Lo está haciendo al vuelo, lo está haciendo en este momento.
Mientras estamos ejecutando esto, cuando lo ejecutamos dice, ostras, que tienes esta dependencia,
pues me la descargo.
Ahora cuando lo volvamos a ejecutar, vamos a ver que ya no se la vuelve a descargar.
Es muy interesante porque no se la va a volver a descargar, ¿vale?
Entonces, y ahora además tenemos un error.
Y de, oye, es que estás intentando hacer un servidor y necesitas tener acceso a la red.
Porque en este puerto 88000, en este caso el 8000, no lo puedes escuchar porque no tienes permisos.
Tienes que ejecutarlo con un flag allow net.
Ya podemos ver que justamente Dino es seguro por defecto.
Tienes que estar justamente diciéndole qué permisos tiene para poder ser utilizado.
O sea, que no puede hacer peticiones a la red si tú no se lo dices.
Así que en esto Dino run, voy a hacer un escrito más grande, para lo veáis.
Aquí vamos a tener que añadir justamente la banderita allow.
Mira, tenemos allow net, que además lo puedes hacer por host.
Lo podemos decir allow env, que sería para leer variables de entorno.
Allow FFI, que sería para cargar librerías de forma dinámica.
Para tener high resolution time, ¿vale?
Que esto es para medir, para leer, para ejecutar, para escribir.
Y esto sería para aceptarlo todo.
Para decir, bueno, pues lo permito todo.
Lo cual seguramente no está muy...
No es la idea.
No es la idea.
Así que vamos a decirle que vamos a hacer el allow net.
Vamos a darle.
Vale, y nos dice que igualmente...
A ver, ¿qué he hecho yo?
Allow net, run again with the allow net...
Vale, pues se lo he puesto.
Lo he puesto...
A ver si es que hay que ponerlo después.
Vale.
Sí, primero hay que ponerle los flags y luego el archivo, ¿vale?
Ahora sí podemos ver que esto se ha ejecutado perfectamente.
Fíjate que no ha vuelto a hacer un download, ¿vale?
No ha vuelto a hacer un download.
Así que tenedlo en cuenta que no ha vuelto a hacer un download.
Esto ya lo ha descargado una vez y entonces ya lo deja cacheado.
Es como un npm install.
Ha hecho una vez en la instalación.
Punto.
Pero fijaos que el npm install ha sido rapidísimo.
O sea, es inmediato casi el npm install.
Lo cual es increíble.
¿Hace una carpeta oculta?
Vale, muy buena pregunta, Maxe.
No estoy seguro, pero creo...
Vamos a verlo.
Vamos a verlo.
Dino help.
No es que hace una carpeta oculta en tu proyecto,
sino que lo que tenemos aquí...
¿Ves que tiene aquí como environment variables?
Una de ellas es que tiene...
¿Ves?
Set cachet directory.
Es que tienes una variable de entorno en tu máquina,
seguramente en una carpeta de tu usuario,
donde está cacheando todas estas descargas.
No la está haciendo aquí en tu...
Aunque lo puedes hacer.
Lo podríamos hacer.
Podríamos hacer que lo guardas aquí.
Podríamos subir las dependencias.
Las podríamos subir al repositorio para que fuese súper rápido.
Podría hacer un montón de cosas.
Pero lo que está haciendo en este caso...
No sé si lo podríamos ver.
No sé si...
No.
Bueno, así no lo podemos ver.
Denodir.
Está el root.
Seguro que se puede ver de alguna forma.
Vale.
Dino info.
Vale.
Aquí lo tendríamos.
Mira.
Con denodir podemos ver que denodir en location está en users,
new dev, library, cache, dino.
Si vamos aquí, seguramente vamos a encontrarnos que tenemos devs.
Tenemos aquí un montón de cosas.
En devs deberá estar el HTTPS,
que es justamente el que estamos importando aquí.
HTTPS.
Y aquí estarán los ficheros.
Bueno, denoland.
Vale.
Y vamos a encontrar aquí los ficheros con un formato más interno.
Pero bueno, ya sabéis.
¿Vale?
Vale.
Perfecto.
Entonces, ya hemos visto un poco esto.
Esto al final no importa.
Porque, bueno, una cosa que sí es interesante ya.
Os voy a explicar esto.
Esto lo que hace justamente este serve.
Podríamos ver cómo funciona si vamos directamente a la URL.
Que esto es una cosa muy interesante de Dino.
Cuando a esta URL tú puedes ir directamente y ver el código.
O sea, tal cual.
Si no, lo que puede ser más interesante es que vayamos a HTTP
y le damos un poquito la documentación, ¿no?
Cómo funciona exactamente esto y tal.
Pero lo que sí que vais a notar mucho en Dino
es que esto es lo que yo creo que es mucho más interesante que Note.
En el sentido de que está utilizando APIs nativas de la plataforma web.
Por ejemplo, este new response, ¿dónde está este response?
Pues, en realidad, está en Windows.
Y como podemos ver, Windows, en este caso dice for compatibilidad entre Windows y tal.
Llamar a web apps con Windows está, o sea, no disallow.
Tenemos que utilizar global disk.
Pero como habéis visto, si yo pongo Windows, existe.
Y aquí tenemos todo, todo de Windows.
Tenemos el fetch.
Tenemos todo lo que puedes hacer en Windows.
Lo tendríamos aquí.
El local storage, todo lo tendríamos aquí.
O sea, Dino lo que tiene mucho es que tiene toda la web API,
la tiene disponible.
Y puedes utilizar justamente, podrías utilizar Windows e intentar utilizarlo.
Si no, lo ideal sería utilizar global disk, que es lo correcto, ¿vale?
Pero este response viene del objeto global.
Que en el caso de Dino, tendríamos aquí que Windows es igual a global disk.
Esto debería ser lo mismo, exactamente.
Y si no, también tendríamos Dino.
Dino, punto, y aquí tenemos más cositas, ¿vale?
O sea, que tenemos como diferentes variables globales ya disponibles directamente, sin hacer ningún import, sin hacer nada.
Y lo que es increíble es eso, que tenemos acceso a cosas que son normalmente del objeto, como por ejemplo, response.
Response, para que, si no lo conoces, básicamente es parte de la API de fetch.
Por lo tanto, vamos a poder hacer fetch.
Vamos a poder hacer un montón de cosas, ¿vale?
Y lo que representa esto es la respuesta que quieres devolver.
Como podéis ver, es mucho más nativo que como lo haríamos en Node, que utilizamos Express y todo este tipo de cosas, ¿vale?
Así que, bueno, esto para que más o menos lo veamos, lo que hacemos aquí, este serve, lo que hace es, bueno,
por cada petición, cada request que entre, lo que hacemos es ejecutar esto de aquí, ¿vale?
Por cada request devolvemos la response, hello world.
No hemos visto nuestro proyecto, pero vamos a verlo en ejecución.
Si vamos aquí, aquí lo tenemos, hello world.
Esto es el servidor más sencillo del mundo, ¿vale?
Es el sencillo más sencillo del universo.
¿Cómo le decimos que aplique el permiso a la UNED solo el método serve?
No se puede hacer solo a un método, pero sí que lo puedes hacer solo a un host.
Por ejemplo, en este caso, claro, si quieres acceso a, a ver, a la UNED, ¿ves?
Y aquí tendríamos, ¿ves que acepta host?
Tú lo que puedes hacer aquí en la UNED es ponerle una lista de host.
En este caso sería 0, 0, 0, 0.
Pero, por ejemplo, luego, pues, a PokeAPI, ¿vale?
O sea, vamos a tener una lista de host que vamos a aceptar.
No sería tanto por método, sino que sería por host que sí que le permites que tenga acceso a la network.
Ese sería el tema, ¿vale?
Bueno, esto es un ejemplo un poco, no tonto, porque la verdad es que está interesante.
Solo para que lo sepas y para que te hagas un poco la idea, porque, claro, alguien puede decir,
pero ¿cómo puede ser?
¿Cómo puede ser entonces que, sabes?
O sea, si yo tengo diferentes archivos, siempre voy a importar esto.
A ver, una forma que puedes hacer es tener, por ejemplo, una carpeta DEVS, o sea, una carpeta o un fichero DEVS.
Por ejemplo, podrías tener un fichero DEVS y que fuese ahí donde realmente podrías exportar SERV y aquí tener toda la lista de tus dependencias.
De forma que aquí importaríamos directamente SERV y lo haríamos desde barra DEVS, ¿vale?
Y esto nos debería funcionar exactamente igual, si no he hecho nada raro, ¿vale?
Y ya nos debería funcionar.
De esta forma estamos como que dejando todas nuestras dependencias en un archivo en concreto.
Y así, cada vez que necesitemos una dependencia, la ponemos aquí, la exportamos y ya está.
En lugar de en todos tus ficheros, estar constantemente importando con una URL que, además, luego es muy difícil que puedas estar, pues,
siempre utilizando la misma versión, acordarte de la versión, es un poco rollo, ¿vale?
Esta podría ser una idea o si tienes demasiadas dependencias, al final puedes tener diferentes ficheros,
donde sea HTTPS y eso te exporte todo lo que hay, cosas así, ¿vale?
Muy bien, muy bien.
Bien, vamos a seguir viendo un poquito, vamos a quitar esto, vamos a seguir un poquito de Dino con el tema del manual
o si queréis, podemos intentar, no sé, a ver, cosas que se, vamos a hablar un poco, cosas que se diferencian de Node, ¿vale?
Solo para que tengamos un poco las diferencias claras.
Solo podéis utilizar ECMAScriptModules, no tenéis que utilizar MPM.
MPM, aparte tiene acceso a la API de la web, ¿vale?
También es seguro por defecto, tenemos que decirle qué permisos tienen nuestros scripts.
Podemos importar scripts que están en una URL, ¿vale?
Así que ya tenemos ahí unas cuantas diferencias.
Y el más importante, obviamente, que podemos utilizar TypeScript, de hecho lo vamos a ver aquí ahora mismo, ¿vale?
Estoy utilizando index.ts, podemos utilizar TypeScript sin necesidad, sin necesidad de hacer absolutamente nada.
O sea, no estamos, bueno, aquí no sé qué le ha pasado, se me ha quedado, se ha quedado tonto.
Ay, ¿qué he puesto tonto aquí? Vale, ya.
Vale, estoy ejecutando TypeScript, un archivo de TypeScript sin necesidad de descargar ninguna dependencia, de hacer absolutamente nada.
O sea, tan increíble como eso.
Ya, vamos aquí, mira, hello world, podemos hacer a hello TypeScript.
Vale, creo que hay un, creo que ahora hay un nuevo, no sé si hay un nuevo, no sé si esto se puede utilizar, el reload este.
Pero creo que lo que hace, vale, esto creo que son los cachés, a ver, javascript, no.
Eso es solo para, pensaba que a lo mejor hacía cambio el reload y tal, pero no, es solo para recargar la caché, ¿vale?
Ok, pues vamos por aquí y bueno, vais a ver que está funcionando correctamente.
Hello TypeScript, sin necesidad de hacer absolutamente nada y por supuesto, pues tiene tipos.
O sea, tú aquí si pones const a o let a y le ponemos que es un string, hola, ¿vale?
Y le ponemos a 3, pues se va a quejar y esto si intentas ejecutar este código se va a quejar también, ¿eh?
Vais a ver que le da el error de TypeScript, o sea que ya tiene el type checking, también lo tiene incorporado.
Así que, sin necesidad de instalar nada, o sea, es que esto es brutal, justamente.
Ah, es watch. Pensaba que con reload era. Es watch.
Ah, unstable. Pues sigue sin ser estable, porque es una cosa que pensaba que...
Vale, vamos a quitar esto, a ver.
Cierto. Vale, pues mira, con un watcher también incorporado, para que tengas ahí justamente...
Watcher, vale, y si nos vamos otra vez al proyectito, pues aquí ya tengo.
Hello Watcher.
Hello Watcher, ah...
Vale, pues ya está funcionando con Watcher, sin necesidad de no money ni nada.
Todo incorporado directamente aquí.
Vale, pues a ver, ¿qué más tenemos?
Bueno, tiene su propio formateador, tiene su propio testing, tiene todo este tipo de cosas.
Y iremos viendo algunas de las cosas. Yo creo que ya hemos hecho unas cuantas cosas por aquí.
Vale, se puede bundelizar el proyecto en un solo ejecutable.
Esto es una cosa que también es bastante interesante.
Vamos a ver si somos capaces.
Denovundleindex.ts.
Vale.
Y aquí lo que podemos ver, justamente, nos ha hecho el bundle.
Lo que pasa es que no le hemos dicho que nos lo guarde en un fichero.
Bueno, pero fíjate que nos ha hecho este bundle, que aquí tiene tanto las dependencias como lo que sería nuestro código fuente.
Así que de esta forma ya tenemos un distribuible en un solo archivo, mucho más fácil que no tener una estructura de carpetas y todo esto.
De hecho, a ver si tenemos aquí...
Quiet.
Bueno, lo podemos hacer...
Bundle.ts.
Fíjate que con denovundleindex.ts el output lo llevamos a bundle.ts y ya tenemos aquí en bundle.ts este archivo, pues básicamente para ser distribuido, súper fácil, con todas sus dependencias.
Ya sin necesidad de empaquetar ni webpack ni nada.
Así que otra cosa bastante interesante de Dino.
Vámonos.
¿Se puede importar un módulo desde E-Hub?
Claro que sí, Rapustin.
Es súper interesante.
Súper, súper interesante.
Tú te vas a denoland y muchas de las cosas que vemos aquí, por ejemplo, third-party modules.
Vamos a ver third-party modules.
Vamos a ver...
Mira, Ramda.
No sé por qué salía...
Mira, Ramda, que es la alternativa rápida.
Este módulo que puedes ver aquí, si nos vamos al Ritme, que estaba cargando el Ritme, estaba cargando.
Vale, normalmente ves que en un proyecto con Node, en NPM harías eso, ¿no?
Del import, Ramda, no sé qué, no sé cuánto.
Lo que puedes hacer aquí, justamente, podríamos importarlo directamente.
O sea, fíjate que aquí podrías importar el archivo desde row.githubusercontent.com, ta, ta, ta.
Y esto funcionará perfectamente.
Vamos a probarlo.
Vamos aquí.
Vale.
Esto es normal.
Lo que nos está diciendo es que no tenemos cacheada esta dependencia todavía.
Nos vamos a ir...
Vamos a utilizar...
Vamos a quitar el Compose.
Vamos a hacer algo sencillo aquí, solo para ver cómo funciona.
Vamos a hacer un console.log de la suma de 1 y 2.
Pero vamos a ver, cuando ejecute esto, que ahora no necesitamos, por ejemplo,
ahora no necesitamos el allow.net.
Vale, pues lo quitamos.
Y aquí lo que vamos a tener...
Bueno, se ha descargado la dependencia, pero ha sido súper rápido.
Y aquí ya tenemos el resultado.
O sea, estamos importando módulos al vuelo.
Directamente.
Estamos importando módulos al vuelo.
Y además, podemos mezclar JavaScript con TypeScript sin ningún tipo de problema.
En este caso, tenemos un Mascrit módulo de JavaScript.
Lo hemos importado y ya está.
Luego, para quitar esto, lo que podéis hacer es cachearlo.
Por ejemplo, ¿veis que pone caché?
No sé qué, no sé cuánto.
Le podéis dar aquí a caché.
Y ya se cachea justamente el módulo.
Y ya está.
Podemos hacer cambios.
Y aquí iríamos viendo los nuevos resultados y ya está.
O sea, que si quieres utilizar una librería, lo único que tienes que hacer es decir,
ah, pues quiero esta librería.
Y ya está.
En este caso, hemos utilizado Randa, que es una alternativa a Randa, súper rápido,
sin ningún tipo de problema.
Y ya está.
Hemos ido a su ritmo, nos hemos copiado esto, no hemos hecho un npm install, no hemos hecho nada.
De hecho, la instalación ha sido instantánea, ni nos hemos dado cuenta.
Vale, más cositas.
Hemos visto lo del bundle, hemos visto lo del run, ya hemos visto algunas cositas con esto.
Vale, tiene un configuration file que es básicamente muy parecido al JSON config o TS config, que pueden tener cualquier proyecto.
Así que aquí podríamos hacer esto de que permita JavaScript, el tema de los aliases.
Y aquí tenemos el linter y el formateador.
Que como podéis ver aquí, el formateador es bastante parecido al que tenemos en Prettier.
Por ejemplo, vamos a intentar utilizar el formateador.
Si yo pongo esto y utilizo deno fmt y le digo index.ts, fíjate que me ha formateado el código.
O sea, si fijaos bien, que hago así, guardo los cambios y le digo deno fmt, que es de formater, index.ts.
Pues me lo formatea, ¿vale?
Y esto mismo tú lo puedes configurar como quieras.
Que sí que te envuelva el punto y coma, que no te ponga el punto y coma.
En este caso, por defecto, te pone el punto y coma, pero creo que en las opciones se puede quitar.
Y puedes hacer que no lo use y todo este tipo de cosas.
El tema de permisos ya lo he comentado.
Aquí tenemos todos los permisos que podríamos utilizar.
Y debugging del código, porque puedes inspeccionar.
Esto sería exactamente igual que en Node.
Vale, estabilidad, ¿vale?
Estabilidad, bueno, ahora ya está en la versión, como hemos visto antes.
La versión v1.0 o algo.
1.18.
Todavía hay algunas APIs que no son estables.
Entonces, hay veces que si hay algunas APIs que no son estables que quieras utilizar,
tienes que utilizar este flag de unstable.
Y entonces le dices cuál es la cosa que quieras utilizar.
Pero, bueno, normalmente no es necesario.
No sé que tengan muy claro que lo quieres por alguna cosa.
Fijaos en una cosa, para que veáis hasta qué punto llega el tema de la...
Que es compatible con la API de Windows.
Es que tenemos la oportunidad de hacer un addEventListener de load y de la unload.
O sea, podemos escuchar el evento de cuando se ha cargado el programa,
cuando se ha dejado de cargar.
Y esto es como si fuese un documento.
Todo lo que podéis hacer con Windows, AddEventListener y tal, es exactamente, exactamente igual.
¿Vale?
Permisos en APIs.
Esto es para saber justamente qué permisos tenemos.
Lo podemos leer, lo que no podemos leer.
Tengo el permiso, por ejemplo, tengo el permiso este, el de leer en el path tal.
Entonces te dices, sí, lo tienes disponible.
Esto es por si quieres evitarte algún error en tu programa antes de hacer alguna cosa.
Por ejemplo, escribir un archivo y cosas así.
Aquí tenemos lo de web platform APIs y aquí tenemos el del fetch.
Entonces hay gente que me dice, que está Arian, dice,
¿el fetch en Dino es afectado por course?
No hay afectación.
El course no afecta cuando se hacen fetch entre servidores.
O sea, Node no está afectado por course.
El que está afectado es el cliente.
Esto es un error muy común que no sé por qué la gente cree que es un problema del servidor.
O sea, el servidor lo que debería hacer es dar las cabeceras correctas.
Pero es el cliente el que tiene el problema.
O sea, si tu servidor no devuelve que ese cliente pueda hacer la petición,
el problema lo va a tener el cliente.
Pero un servidor, si tú haces una petición entre servidores,
no debería haber ningún problema de course, justamente.
Así que ya lo tendrías.
Ya lo tendrías.
Y en el caso de Node o Dino, lo que tienes que hacer,
si quieres que un cliente pueda hacer una petición,
sería la cuestión de devolver un course o con el asterisco
o con el dominio que quieres que funcione y ya está.
¿Vale?
Bueno, importantísimo.
Web Platform APIs.
¿Qué tienes esto?
Pues tienes justamente soporte para fetch.
O sea, o sea, o sea.
Vamos a probar esto porque esto es la bomba.
Esto lo que quiere decir es que tú haces fetch aquí.
De hecho, a ver, es verdad que ahora esto puede sonar un poco menos sorprendente
porque Node justamente está trabajando en ello.
Pero todavía no ha llegado.
Pero el tema es que en este caso todos,
es que estamos hablando de todos, todos,
todas las versiones de Dino,
todas han tenido acceso a fetch.
Vale.
Voy a intentar ejecutarlo.
Vamos a ver que voy a tener un problema por un tema de permisos.
¿Vale?
Fíjate que me dice Permission Denied.
Esto lo que quiere decir es que tienes que estar utilizando el AllowNet este.
Si quieres hacer un fetch, aunque sea a una API donde tú quieras,
tienes que decírselo.
Le tienes que decir, vale, yo sé lo que estoy haciendo.
AllowNet.
Necrozma, esto que es un nombre muy raro,
esto es el nombre del Pokémon que está aquí en el 800.
Vale, que he devuelto aquí el response.name.
Pero fíjate, vamos a...
Mira, bueno, ya estaba funcionando.
Esta sería lo que devuelve el objeto en la Poké API,
pero lo estamos haciendo con fetch.
Y podríamos hacer window.fetch.
Y fíjate que funciona perfectamente.
O sea, funciona perfectamente.
Tú haces window.fetch y funciona.
Podrías hacer globaldisk.fetch y funciona también.
O sea que toda la API de Windows la tienes ahí disponible.
Lo cual es increíble.
A mí me parece lo más increíble.
Bye bye Axios.
Bueno, a ver.
Axios lo podéis seguir utilizando.
¿Vale?
Eso sí que es verdad que lo podéis seguir utilizando.
Otra cosa muy interesante de Dino,
que a ver, esto en realidad no es una cosa que solo sea de Dino.
Hay mucha gente que dice,
¡Ah! Y es que Dino soporta esto.
También lo soportan las últimas versiones de Node.
Pero bueno, creo que es bastante impresionante justamente cuando utilizas con fetch.
Es el hecho de que puedes utilizar top level await.
¿Qué quiere decir esto?
Pues que podéis hacer las peticiones, el await,
lo podéis hacer directamente en la raíz.
Sin necesidad de hacer nada más.
Podéis hacer aquí un await.
Luego aquí tendrías el JSON.
Pues hacéis await de response.json.
Y en el JSON, pues podéis hacer console.lot de json.name.
Y esto lo podéis hacer así.
Y lo que vamos a ver, ¿ves?
Necrozma.
O sea, está funcionando correctamente.
Podríamos hacer aquí justamente el top level await.
Es una cosa que soporta de primeras y ya está.
O sea, maravilloso.
Vale, más cositas.
Bueno, a ver, esto es un ejemplo de la API de fetch.
Pero piensa que tienes custom events.
O sea, puedes enviar eventos nativos.
Puedes hacer event listeners.
¿Para qué se utilizaría la API de Windows en el entorno del servidor?
Por ejemplo, ¿por qué usar una de listeners si no hay DOM?
Muy buena pregunta, Dartiles.
Pero la verdad es que tiene mucho más sentido de lo que parece.
Por ejemplo, el tema es que aunque es verdad que son eventos del DOM, lo que puedes hacer justamente es enviarte tus propios eventos.
Y al final hay muchas librerías de terceros, como por ejemplo Meet, ¿vale?
Meet, Meet, Meet, ahí.
Meet es una librería con la que puedes enviar eventos y puedes hacer un pub sub.
Pues este tipo de librerías al final lo que está haciendo es implementar algo que ya tiene la plataforma web.
Por ejemplo, esto del custom event.
Tú puedes enviar un evento, un custom event, y ya podrías escucharlo con el event listener.
Es utilizar la plataforma nativa que ya tiene la web para justamente hacer lo mismo.
Es verdad que no vas a escuchar un click.
No tiene sentido escuchar un click, obviamente, ¿vale?
No hay ningún sentido utilizar click.
Pero lo bueno de estos eventos que tendríamos aquí es que están basados en la API nativa,
que ya está documentada y que ya se sabe cómo funciona.
En lugar de estar otra vez recreando justamente un mismo sistema de eventos que tienes que crear desde cero.
Entonces, la idea de Dino, que me parece muy acertada,
es el hecho de que reutiliza todas las APIs que la gente conoce o debería conocer.
Como por ejemplo, todas estas APIs.
La del blob, para crear blobs.
El broadcast channel, que estas las vimos, la de console.
Console, en Node sí que la tiene.
El encoding API, por ejemplo.
Pues el text decoder, el text encoder.
¿Ves?
Estos son APIs que tienen los navegadores.
Y en cambio, Node tiene su propia API que no tiene nada que ver con la API de los navegadores.
Y no tiene mucho sentido porque podrían utilizar esto.
Podrían utilizar esto y de esta forma unificar la API.
Al final lo que están haciendo Dino, fíjate.
Mira, en este caso, Node también la añadió con sentido.
O sea, al final, Node lo añadió, aunque tardó lo suyo, pero tiene todo sentido del mundo.
¿Por qué?
Porque lo que estás haciendo es unificar la misma API en lugar de volver a recrear otra vez lo mismo.
Así que me parece muy interesante.
Lo mismo con el web storage.
Tienes local storage.
Tienes acceso al local storage, al session storage, a los web sockets, al URL pattern.
Esto, muchas cosas de estas cosas que veis aquí, ya las va haciendo Node.
Porque se está dando cuenta, justamente, que se estaba quedando un poco atrás con esta idea.
Pero me parece muy bien, justamente, por esto.
También tienes acceso directamente a crear tu propio server.
Es súper fácil.
Lo hemos visto aquí con el server.
Esto es lo que hemos visto antes.
Y luego tiene, y esto está también muy bien,
el hecho de una API a bajo nivel.
Una API a bajo nivel, ¿qué quiere decir?
Quiere decir que es una API que no es tan cómoda con la que trabajas,
pero como que te da más fine tuning.
No sé en castellano cómo decirle.
Básicamente, como que te da más opciones, más posibilidades de toquetear cosas muy específicas.
No es la forma recomendada, seguramente, de trabajar, porque es muy de bajo nivel,
pero normalmente tiene mejor rendimiento o puedes toquetear cosas que de otra forma.
Quizás no sería tan fácil.
Solo para que lo sepáis, porque esto es una cosa que os puede interesar para cosas de alto rendimiento, justamente.
Fine tuning, no. Fine. Fine.
De fine.
No de fine, de terminar con D.
Sino fine. Fine.
Tenéis hasta la location API.
La location API es justamente de la URL, ¿vale?
De ser capaz de saber de la URL, recuperar a qué URL se están haciendo las peticiones, este tipo de cosas.
El web storage con el local storage.
Hay gente que me preguntaba, ¿pero para qué sería interesante el local storage?
En realidad, el local storage es bastante interesante porque muchas veces en Node se utilizan cosas como pilas o cachés en memoria.
Entonces, tener local storage en el servidor lo que te permite es poder guardar cierta información que quieres que esté disponible
mientras tu servidor está encendido.
Cada vez que, obviamente, bueno, el local storage lo podríamos probar.
Vamos a probarlo.
Vamos a probarlo.
Por ejemplo, si yo hago aquí local storage.setItem y le ponemos aquí el name, ponemos el json name, ¿vale?
Entonces, aquí me ha debido guardar necrozma.
Vamos a quitar esto para que nos haga ese console name.
¡Ay! Ahora, espérate, porque como lo tengo aquí en watch, la vamos a liar.
Vale, vamos a quitar esto.
Esto y ahora local storage.getItem, creo que lo he llamado name, console lock.
Mira, pues se guarda entre ejecuciones.
Claro, el local storage se guarda entre ejecuciones.
O sea, que puedes apagar el servidor, puedes volver a encenderlo y el local storage lo tienes.
Lo que no tendrás, obviamente, es el session storage.
Pero está muy bien esto, ¿no?
Porque al final, si quieres guardar alguna información que quieres que perdure entre, que baja el servidor y sube, lo puedes hacer en el local storage.
Obviamente, no metáis en el local storage, no lo utilicéis como una base de datos, porque no es lo correcto.
Pero sí que podéis hacer que perdure cierta información, lo cual está bastante bien.
Y al final lo tienes así, con local storage, punto pelota.
También tenéis acceso a workers, que sean web workers, para paralelizar cualquier trabajo.
De esta forma, no necesitáis bloquear el thread principal, por ejemplo.
¿Cuándo se borraría el local storage?
Pues es una buena pregunta, porque pensaba que iba a ser cuando se cerrase.
Mira, tiene 10 límites de storage.
Vale, mira, de global storage solo se persiste cuando el contexto de ejecución está todavía en uso.
O sea, el session storage, mientras el servidor está levantado, se usaría.
Y con local storage solo persiste la información entre ejecución, o sea, la persiste entre ejecución y ejecución.
¿Vale?
En el navegador, local storage, vale, vale.
A ver, pues no lo pone, no lo pone.
Pero yo supongo que seguramente puede ser que lo deba guardar en algún tipo, si miramos aquí en denoinfo.
¿Ves que pone origin storage?
Aquí este location data.
Yo imagino que este location data es el que tiene la información.
Podríamos intentar verlo.
Y a lo mejor aquí.
Ah, vale.
Cat.
Cat, a ver.
Vale.
Mira, cat local storage.
Mira, aquí lo tenemos.
Mira, pues se está utilizando, creo que es indexdb.
Y aquí tenemos el name, el necrox max, este del Pokémon.
O sea, que lo está guardando justamente en el file system.
Pero claro, tened en cuenta que vosotros si guardáis algo en el local storage y luego desplegáis la aplicación, no tiene acceso al local storage de vuestra máquina.
Entonces, mientras no borres esta carpeta, esta carpeta de aquí, mientras no borres la carpeta donde se guarda la caché.
O sea, si esta carpeta persiste en la máquina, pues tendrás acceso a esto y ya está.
O sea, por siempre.
Por siempre, por siempre.
Vale, bueno, tenemos aquí un montón de cosas.
Aquí tenemos algún tema de compatibilidad.
Hay un modo de compatibilidad con Node.js.
Está un poco verde, la verdad.
Está un poquito verde.
Pero tiene buena pinta de que van a intentar que sea compatible el código de Node.js con justamente Dino.
Y bueno, lo que os decía, que podéis utilizar paquetes de CDN, como hemos visto antes.
Mira, esto sería un ejemplo bastante interesante.
A ver si podemos hacer una aplicación de React en un momento.
A ver, a ver.
Esto.
Ah, can't find.
Ah, pensaba que sí que se iba a utilizar.
Ah, claro.
Si podemos utilizar aquí TSX.
Sin hacer nada, ¿no?
Has any, no sé qué.
Vamos a intentar hacer, por ejemplo, export default function app.
Y hacemos aquí h1.
Hola, mundo.
Vale, quitamos esto.
Existe.
Hostia, eso sí que me...
No entiendo muy bien este...
¿Por qué da este problema?
Pero es como que no tiene interfaz.
Como que no encuentra esta interfaz, pero...
A ver.
No.
Pues no va a funcionar.
Justamente por eso.
A ver, vamos a intentarlo con J6.
A ver.
Y aquí hacemos...
Vamos a copiar esto.
Y aquí...
No sé si esto existirá.
Vamos a verlo.
Sí que existe.
Vale.
React DOM.
Y esto sería sin babel, sin hacer ninguna...
Absolutamente nada.
Render to string.
Y vamos a intentar aquí...
Pero claro...
Claro, render to string no sería.
Sería render to static markup, me parece.
Render to static markup.
Creo que sería así.
Y esto sería...
Ay, no.
Es que esto sería react DOM server.
Esto sería así.
Vale, vale.
React DOM server.
Y esto no sería react DOM.
A ver si me acuerdo de cómo es la API del server.
React DOM server...
Render to string, me parece que es.
Render to string.
Vale.
Render to string del react...
De esto.
De hecho, podemos pillarnos directamente esta.
Render to string.
Vamos a hacer un console log de esto.
Vale.
Vale, parece que...
¡Oh!
O sea...
Amigos, acabamos de hacer sin ningún problema, ¿sabes?
O sea, hemos importado de SM este, que esto es una CDN.
Hemos importado react, hemos importado react DOM.
Estamos escribiendo JSX.
Estamos escribiendo JSX.
¿Vale?
Y acabamos de hacer un server-side rendering con React.
En NAI menos.
En 8 líneas de código sin instalar dependencias, sin hacer absolutamente nada.
Sí, esto es server-side rendering, justamente.
Hemos hecho...
¿Veis?
Aquí se ve server-side rendering.
Esto sería el string que tú cuando entras a una web te devolvería.
Esto sería el HTML.
De hecho, pues, hacer un...
Por ejemplo, un servidor.
Mira, pongamos...
Pongamos que hacemos un servidor en un momento, ¿vale?
Hacemos un servidor...
¿Queréis que hagamos un servidor en un momento?
Para que veáis que realmente es server-side rendering.
Vamos a hacer el server.
HTML server.
Habíamos visto que esto era import-serve.
¿Vale?
Nos vamos a traer también el serv.
Esto es de tal.
Y entonces, habéis visto que el serv, el handler...
¿Vale?
Vamos a hacer serv.
Del serv tendríamos...
Aquí era rec.
Creo que era así.
Rec.
Y aquí se le ponía el port.
¿Vale?
Vamos a poner el port 8000, que era el que estaba utilizando antes.
¿Vale?
El render to string, pues, lo que podríamos hacer es básicamente hacerlo aquí.
Hacemos aquí app.
Render to string de la app.
Y ahora lo que necesitamos sería devolver con la response, ¿no?
¿Vale?
Me estaría bien tener esto.
Lo de los headers, body, rectext...
No.
New response.
Es lo que necesitamos.
Esto, mira.
New response.
Vamos a hacer justamente esto.
Lo que vamos a necesitar es un return new response.
¿Vale?
Response.
Justamente lo que creamos es un objeto de respuesta.
Y le vamos a decir que vamos a devolver la app.
Y entre los headers vamos a tener un content type.
Content type.
Que será el de HTML.
Text barra HTML con el chur set.
¿Vale?
Pues, con esto, básicamente...
Vamos a ver si funciona.
Vamos a ver si funciona.
Vale.
No me dice nada.
Voy a intentar entrar directamente.
8000.
Ya está.
Acabamos de hacer un server side rendering.
Brutal.
O sea...
Y para que veáis que funciona.
Que esto en realidad...
Podríamos hacer más, ¿eh?
O sea...
Que tendría los...
El fragment.
No sé si el fragment funcionará tal cual.
Parece que sí.
¿Sí?
Vale.
Genial.
Hola mundo.
Button.
Hola.
Vamos a ponerle unos estilos aquí.
Style.
Font.
Family.
System UI.
¿Vale?
Ay.
Perdona.
Esto tiene que ser así.
Display grid.
Hostia, a este no le va a gustar.
Claro.
Es que esto tiene que ser con el set.
Dangerously.
O dangerously.
Setting el HTML.
HTML.
Es que esto es un poco...
Esto es un poco pirata, ¿eh?
O sea, esto lo estoy haciendo.
Pero esto no es como se hacen las cosas.
Pero bueno.
Es solo para que veáis que realmente es un server side rendering.
Que tenemos...
Y que estamos haciendo server side rendering con React en un momento.
Supply center.
Margin 0.
Vale.
Vale.
Mira.
Ya está.
Tenemos una aplicación.
O sea, estamos haciendo justamente una aplicación.
Claro.
Ahora lo interesante es, ¿qué es lo que pasa, no?
O sea, ¿qué es lo que pasa con esto?
Esto es el server side rendering.
Si yo miro el código fuente, ¿veis?
Aquí podemos ver que tenemos el HTML.
Muchas veces me preguntáis, ¿cómo se hace un server side rendering?
¿Qué es un server side rendering?
¿Qué no sé qué no sé cuánto?
Aquí lo tenéis.
Lo hemos hecho en 15 segundos.
O sea, lo hemos hecho en un momento.
Esto es un server side rendering.
Estamos haciendo un serve.
¿Qué se podría hacer?
Es que aquí, a partir de aquí, ya se podría hacer un montón de cosas.
Porque una vez que aquí tiene la request, claro, si miramos qué tiene la request, en la request vamos a tener el objeto nativo de la web de request.
Y con esto podríamos detectar qué es lo que estamos intentando cargar aquí, me imagino.
¿Sabes?
Yo aquí pongo, por ejemplo, login.
Y aunque vamos a ver el mismo contenido, aquí voy a tener justamente, ¿veis?
Aquí tenemos en la request, tenemos, bueno, esta es porque también se hace la request de Fabicon.
Muy interesante esto también.
¿Ves?
Se ha hecho la URL de login.
Pues, ¿qué podríamos hacer?
Es que podríamos hacer aquí ya un router.
Porque tú tienes de la request, tendríamos la URL de la request, y esta URL se la podrías pasar a React Router, al React Router estático, y que aquí decidiese qué es lo que debe enseñar.
Por ejemplo, a ver, lo voy a hacer un poco pirata para que no lo hagamos muy bestia, ¿vale?
Pero imaginamos que le pasamos la URL aquí, ¿vale?
Bueno, sí, la URL.
La URL, ¿podríamos pillar solo el path?
O estaba dando toda la URL.
A ver, un momento.
Request, tatatá, es toda la URL.
Vale, a ver.
Lo bueno, mira, lo bueno de Dino es que si en algún momento dices, ostras, quiero probar algo, no hace falta muchas veces que lo pongamos directamente, o sea, que lo hagamos en Dino.
Porque como funciona exactamente con la, o sea, funciona sin ningún tipo de problema en las herramientas de desarrollo, en la consola, en el navegador.
O sea, que lo que podríamos hacer, por ejemplo, digo, vale, quiero probar a ver si puedo recuperar fácilmente el pathname, ¿no?
Pues puedes hacer new URL, aquí le pasaríamos este HTTP, localhost 3000.
Esto es para que veáis que realmente funciona exactamente la API web con la API de Dino, ¿vale?
Tendríamos aquí una URL.
Esto es el objeto, el constructor de URL y url.pathname nos debería dar barra login.
Pues esto mismo lo podríamos hacer aquí.
O sea, este código que he hecho aquí me lo voy a traer aquí, ¿vale?
Esto en lugar de, sería URL object.
O bueno, podría traerme directamente el pathname, así, ¿vale?
Y esto le vamos a pasar a la URL.
De forma que aquí le pasamos el pathname y aquí tendríamos el pathname, ¿vale?
Y a partir del pathname, aquí ya podríais estar, es que esto serve ese rendering puro y duro.
Porque aquí ya podríais poner, por ejemplo, a ver, para que se vea bastante la diferencia.
Si el pathname es barra login, creo que sería, ¿no?
A ver, barra login, entonces, pues, form, input, playholder, login, ¿vale?
Y esto así, pathname, si es este, entonces, vamos a hacer todo esto, ¿vale?
Esto, el real router y este tipo de cosas tienen una alternativa para hacerlo.
Bueno, pero como real router 6 hace tiempo, bueno, hace tiempo, no lo toco, no la vamos a liar, ¿vale?
¿Veis? En esto tengo aquí la ruta de login, estoy haciendo el service rendering de mi aplicación del login
y si vamos aquí al, aquí, pues, estamos haciendo el otro.
O sea, ya además estarían funcionando las rutas, tal cual.
Entonces, aquí lo que estamos haciendo, amo la API URL y URL search params.
Buah, yo también, son la caña.
¿Midu, has tenido un 431 request header fields too large en una API de Next?
No, la verdad es que no.
¿Dino es el spell de backend?
Creo que sí, me parece una muy buena definición, estoy de acuerdo.
¿Para cuándo lo malo de Dino?
A ver, claro que tiene cosas malas Dino.
Para mí, lo peor que seguramente tiene Dino es que no tiene la madurez que tiene Node.
Eso para empezar, o sea, eso es impepinable.
La falta de paquetes, claro que tiene un montón de paquetes Dino, de dependencias y tal,
pero la riqueza que tiene ese Node es enorme.
También el tema de cuánto interés hay, ¿no?
Por ejemplo, hoy lo vemos.
A mí me parece que Dino es súper interesante,
pero si hubiera hecho un curso desde cero hoy de Node,
seguramente a lo mejor estábamos el doble de personas aquí.
Lo cual me parece muy triste para el pobre Dino,
porque me parece muy interesante porque puedes aprender un montón de cosas de la web API.
Entonces, el interés, el ecosistema, el contenido que te puedes encontrar,
esas son las cosas malas de Dino.
Por más que tenga mucha gente detrás que esté el creador de Node,
todavía le falta un poquito de cosillas, ¿no?
Le falta que haya grandes proyectos que lo utilizan,
que realmente se vea una diferencia.
Creo que va a importar mucho el tema de la compatibilidad con Node.
Van a intentar hacer que Dino sea totalmente compatible con Node.
Y si consiguieran que además, haciéndolo totalmente compatible,
fuese más rápido, ahí lo petaban.
Ahí lo petaban.
A Dino solo le falta ser popular, claro, pero es complicado.
Ya está, Dino no ha matado a Node porque no lo dejan.
Bueno, es que no siempre gana el mejor.
Eso es una cosa que hay que entender mucho.
No siempre gana el mejor.
No siempre gana el mejor.
Y es una cosa que la historia de la tecnología nos la han enseñado muchas veces.
Desde las cintas de video con VHS y beta,
CDs, música, con todo, con todo.
La tecnología es así.
Es así.
Denorras tanto para aprender.
Midu, ¿subirás estos ejemplos a Github?
Bueno, a ver, los he ido petando.
Sí que subiré.
Vamos a intentar ejecutar, si os parece.
¿Y la hidratación del cliente cómo la harías?
Claro, a ver, la hidratación del cliente es un poco más complicada
porque ahora lo que tienes que hacer es que este componente app,
lo que habría que hacer es sacarlo del servidor.
Ahora está en el servidor, ¿vale?
Lo que habría que hacer aquí es, por ejemplo, tenerlo fuera, ¿no?
Entonces, tú tendrías aquí el index.jsx.
Aquí tendrías esto.
Te traes la app.
Entonces, tú importas la app del source index.jsx, ¿vale?
Bueno, espera, que no he puesto esto.
JSx, ¿vale?
Esto le tendrías que poner export function, ta, ta, ta.
Y el import de React y todo esto.
Y lo que tendrías que hacer es, igual que tenemos aquí un index.tsx,
o sea, esto sería el servidor, deberíamos tener también la parte del cliente.
Y el cliente tendría que tener un punto de entrada.
Y por su lado deberíamos, claro, lo que pasa es que tendría que compilarlo.
Esto sería un poco rollo, ¿vale?
Pero aquí tendrías que hacer el run react.dome.hydrate.
Le pasarías lo mismo a app con el pathname.
El pathname.
Y aquí le deberías decir dónde lo está justamente document.getElement.byRot.
Entonces, lo que tienes que hacer con esto, aquí, lo que habría que hacer para ser capaz de hidratarlo,
en la respuesta, esto, lo tendrías que hacer dentro del root.
Entonces, tú haces esto, esto dentro del root.
Esto ya lo tendrías en el cliente.
Vale, me he cargado.
Ah, no.
Vale, ha funcionado bien.
Entonces, lo que tienes que hacer, ves que está dentro de div y de root,
pues lo que debes hacer ahora en el cliente sería esto.
Sería exactamente esto.
Solo tienes que hacer esto.
No tienes que hacer nada más.
Bueno, aparte de importar, claro, tienes que importar la app del source, source, index.js, y ya está.
Bueno, el pathname, tendrías que traerte el pathname, que es todo en window.location.pathname, en realidad.
Aquí lo tendríamos aquí.
Sería así.
A ver, es una pena, es una pena que no lo, o sea, que tendríamos que compilarlo y tal,
pero si lo tuvieramos compilado, podríamos verlo funcionando.
Porque esto funcionaría correctamente.
Esto sería correctamente.
Mira, perdona mi ignorancia, pero ¿cómo y dónde se desplega Dino?
Pues mira, justamente Dino lo puedes desplegar a un montón de sitios.
Pero no, justamente tiene esto que se llama deploy, que te va a volar la cabeza.
Porque esto me parece increíble.
Increíble.
A ver, voy a hacer un syncing.
Esto lo que tienes en Dino es que, bueno, ves, esto yo ya tenía aquí uno instalado.
Vale, puedes hacer un playground si quieres, para empezar.
Gracias por la hidratación.
Mira, pues aquí lo que puedes hacer es, aquí habíamos hecho esto.
Mira, vamos a desplegar mi aplicación, mi service al rendering.
Vamos a ver si le gusta o no le gusta.
React is declared.
Ah, vale, claro.
Este React no lo necesitamos aquí.
Vale.
No sé si podríamos tener, bueno, parece que no podríamos tener aquí diferentes archivos, por desgracia.
Bueno, también es verdad que es que yo he elegido el, ay, he elegido el playground.
Vale.
O sea, he hecho el playground cuando en realidad podría hacer, haber hecho el proyecto entero.
Porque ves que pone aquí new project, puedes crear un proyecto.
Deploy from GitHub.
Y esto ahora mismo es totalmente gratis.
Entonces podríamos desplegar desde GitHub.
Es lo mismo que voy a hacer aquí en el playground, ¿vale?
Lo que pasa es que para simplificar, en lugar de tenerlo en diferentes archivos, voy a poner ahí mi fichero, ¿vale?
Este de app, lo voy a poner exactamente aquí.
Vale.
React.
Esto es raro.
React es de app, pero no, no, no.
Vale.
Y si guardamos los cambios, y esto pone que están en 8000, vamos a ver.
Vale.
H is not defined.
Hmm.
Esto, esto es porque, esto debería ser JSX.
Pero esto es por culpa de este React, que no me está pillando el pragma.
¿Veis este H is not defined?
Esto es porque aquí está intentando que cuando está buscando esto, en lugar de utilizar ReactElement, está utilizando el de H.
JSX pragma.
A ver si somos capaces de arreglar esto en un momento.
Y así lo veis ahí desplegado.
Vamos a ver si...
Ta, ta, ta.
Pragma, pragma, pragma.
Ta, ta, ta, ta, ta, ta.
Bueno, a ver si alguien me ha puesto la solución.
Pero puedes hacer un demo bundle, ¿no?
Solo de archivo del cliente.
Sí, lo que pasa es que en este caso tenemos, estábamos mirando de hacer el, en el playground, ¿vale?
A ver, JS.
Magic, comment, JS, pragma.
TypeScript.
Es que debería ser una configuración esto.
Debería ser una configuración.
Es que no me acuerdo porque, claro, hace tanto tiempo que no utilizo este del pragma, pero se supone que aquí hay una configuración que es algo así.
Que es algo así.
Y entonces tú le puedes decir que utilice el pragma, en lugar de utilizar el H este, pues puedes decirle que utilice el que tú quieras.
Pero ahora no me acuerdo cómo es, no me acuerdo, no me acuerdo cómo es, JS, mira, custom pragma.
Es que no lo vamos a encontrar, porque esto es una cosa que ya no se lleva.
Bueno, es una pena.
Ah, mira, sí, es esto.
Es esto.
Es esto.
Vamos a ver si esto cuela, ¿eh?
Esto debería ser...
React.jx
React.fragm
No sé si va a colar.
No sé si va a colar.
No.
It's not a function.
Vale.
El de fragment creo que está bien.
Ahí vamos a probar con el createElement.
A ver.
A ver.
Mmm.
Ya está.
Vale.
Pues ya lo tendríamos.
Y entonces ahora si entráis en esta página, ya lo tenemos desplegado, nuestro CSS rendering.
Ya lo tenéis ahí.
¿Vale?
Vale.
Pues venga.
¿Queréis que hagamos el Wordle o no?
¿Vendemos nuestra idea por un millón de dólares?
¿Queréis que hagamos nuestro Wordle este?
¿Pero con Dino?
¿Tenemos lo que hay que tener para hacerlo?
¿Estáis preparados?
¿Estáis ready?
¿Os está gustando Dino por ahora o no?
A ver.
Que si no me está gustando, me lo podéis decir.
De una.
Véndelo a la mundo por 10 millones.
Vale.
La verdad es que no.
No le está gustando a Beltez.
Hostia.
A mí me encanta.
La verdad.
¿Qué le ves de malo a Dino por ahora?
O sea, ¿qué le ves realmente de malo?
Aparte de que no lo quieras usar por qué motivo.
Pero que digas, uff, es que...
Porque a mí, la verdad es que es imposible que no te guste.
Es imposible que no te guste Dino en el sentido de...
Es que es la web API.
O sea, todo lo que tienes es la web API.
Y eso es una cosa que está muy bien porque entonces lo que obliga es que la gente no pueda...
No puedas estar en contra de ello porque es que ya lo tienes todo en navegadores.
Me parece muy inteligente por su parte que lo haya hecho.
Menos C.
C es horrible, hombre.
Ya.
Voy a empezar un proyecto pequeño y quiero usar Dino.
Bueno, pues ya habéis visto dónde lo podéis justamente desplegar.
No me agrada lo de las dependencias.
Bueno, en Dino 2, en la segunda versión, van a hacer que puedas utilizar dependencias de NPM, me parece.
Así que...
Así que bastante bien.
¿Cuáles son los beneficios?
A ver, los beneficios los hemos dicho al principio y los hemos listado.
Seguro por defecto, bastante más moderno, escrito en RAST por temas de rendimiento, que utiliza la web API nativa.
Tiene un montón.
No me gusta eso de Dino 2.
Bueno, a ver, será opcional.
Tampoco pasa nada si queréis utilizar las dependencias de NPM y si no queréis, pues nada.
Beneficios.
Ah, mira, gracias Juan Dier Ruiz.
Apenas aprendí HTML, CSS y JavaScript, me siento muy perdido con toda esta info.
Bueno, Wallow Town, lo bueno de Dino es que yo creo que es bastante sencillo.
Yo creo que es más aproximable Dino que Node-Node.
Lo que pasa es que ya muchos de nosotros sabemos Node.
Así que, claro, como ya sabemos Node, pues estamos acostumbrados.
Pero Dino me parece mucho más aproximable.
O sea, yo si estuviese aprendiendo CSS, HTML y JavaScript, Dino sería un paso más natural que no Node.
Lo que pasa es que Node, pues tiene mucho más ecosistema, claramente.
¿Se puede usar para producción?
Sí, claro que se puede usar para producción, ¿eh? Sin problema.
Si Dino es tan bueno, ¿por qué se tardan tanto en sacar un Dino 2?
¿Qué pregunta es esa?
A ver, si Dino es tan bueno, ¿por qué se tardan tanto en sacar un Dino 2?
A ver, no tiene nada de malo.
Eso es una muy mala concepción respecto al software, ¿no?
Y justamente Google Chrome se aprovechó de esa concepción a la hora de sacar nuevas versiones de su navegador.
¿Por qué?
Porque está la concepción que tiene la gente de que, ah, no, si no se saca una nueva versión o una nueva mayor cada semana,
es que debe ser algo malo.
Entonces, la verdad es que no tiene por qué ser así.
Igual es que es lo suficientemente estable para no romper la API.
Y es una cosa positiva, en realidad.
Lo importante es que evolucione con el tiempo, no que vaya rompiendo la API cada dos por tres
y que saque Dino 1, 2, 3, 4, 5.
Eso no es así.
Lo que pasa es que tenemos esta concepción, ¿no?
De que si sacan mayors más rápido, es como que evoluciona más rápido.
Y esto lo hace mucho Chrome, ¿no?
Chrome ahora ya va por la versión casi 100, va por la 99.
98 acaba de salir.
Y así da la sensación de que evolucionaba mucho más rápido que sus competidores.
Que, por ejemplo, Internet Explorer, que eso era verdad.
O Firefox, que antes iba también, las mayors iban de forma mucho más lenta.
Entonces, no creo que tenga nada que ver de que por qué se demoran por sacar las dos.
Pues igual es algo positivo, porque no quieren romper la compatibilidad
y todo tu código funciona durante un montón de tiempo.
Es así.
Pero también Angular.
Angular, por ejemplo, ha adoptado esto porque justamente la gente cree
que las mayors hace que...
Y por eso ahora queda dos por tres.
Viernes de Dino para fomentar su uso.
Bueno, hoy estamos haciendo eso.
Para la Giphy dijiste que hiciste el backend en Dino para probarlo.
¿Te pareció difícil?
En aquel momento me pareció más difícil que ahora.
Me pareció más difícil que ahora.
Hola, Midu, ¿cómo vas?
¿A qué aprovecharé de hacer coworking con ustedes?
Hombre, pues bienvenido.
Está fabuloso, pero mi pregunta es la siguiente.
¿Tú la usarías para un proyecto real a día de hoy?
Yo a día de hoy en mi empresa no lo usaría.
No lo usaría en mi empresa.
No lo usaría en mi empresa por diferentes motivos.
Primero, no lo usaría en mi empresa por un tema de dónde desplegarlo.
De que la infraestructura que tenemos está mucho más preparada para proyectos con Node.
Tendríamos que prepararnos bien.
Dino, dónde lo podemos correr, qué problemas vamos a tener, nos vamos a encontrar.
La segunda razón por la que no lo usaría en mi empresa es justamente porque nadie en mi empresa sabe Dino.
No hay mucho interés por Dino, cosa que me da penita, porque me parece muy interesante.
Pero en mi empresa nadie sabe Dino.
Entonces, no sería buena idea utilizar Dino a no ser que la gente empiece a conocer Dino y todo esto.
Lo tercero es un tema de recruiting, de contratar a gente.
No vamos a encontrar muchos perfiles que sepan Dino.
Y es la realidad.
Entonces, yo en mi empresa no lo usaría.
O sea, te soy totalmente honesto.
Te soy totalmente honesto.
Pero, ¿me parece interesante aprenderlo?
Sí, por muchas cosas.
Me parece interesante aprenderlo porque tiene bastante futuro.
Yo lo veo mucho futuro.
Lo segundo es que está basado en la web API.
Todas las cosas de Dino solo te van a hacer mejor programador o programadora JavaScript.
Es que todo lo que hemos visto es nativo.
No ha habido ninguna magia rara.
Y eso es lo mejor que tiene Dino.
Vas a aprender qué es el response.
Vas a aprender la fetch API como mucho más allá de hacer el fetch.
Ya hemos visto el objeto request, el objeto response.
Cómo sacar el path name.
Es que es lo bueno que tiene.
Que no tienes que mirar la documentación de Dino.
Es que puedes mirar la documentación de MDN.
Eso es increíble.
Yo creo que no somos conscientes de lo increíble que es eso.
De verdad os lo digo.
Y me sabe mal.
Me sabe mal porque a veces la gente que quiere aprender programación no ve el valor de estas cosas.
Y al final es lo que le ponen delante y ya está.
Pero esto es lo que realmente te puede hacer entender la plataforma.
Está muy chulo por eso.
Me parece muy chulo.
Y si era tan inteligente, ¿por qué se murió?
Esa también sería una buena frase.
Yo los haré cuando esté en la versión 5.
Por la rima a lo mejor.
¿Crees que hay mucha oferta y poca demanda para el front?
No hay mucha oferta y poca demanda.
Hay mucha oferta y mucha demanda, me parece.
Me parece a mí.
Dino, Dino, Dino.
Dino.
Quiero Dino.
Amo Dino.
Qué bueno.
A ver.
¿Cómo ha colocado lo de Dino 2?
¿Cómo ha colocado?
Si mi Dudef es tan bueno, ¿por qué no hay un Midudef 2?
Ay, buena pregunta esa.
Qué bueno, ¿eh?
Nos contratas a nosotros, hombre.
¿Aprender Dino antes de Node?
Depende.
Depende.
A ver, si vas a aprender Node porque quieres trabajar ya, yo aprendería Node.
Pero de verdad me parece que de forma natural Dino tiene mucho más sentido después de JavaScript que Node.
porque es lo que os digo, de verdad, que Dino me da la sensación que aprendes mucho más JavaScript.
Y incluso TypeScript, encima TypeScript que tienes.
O sea, lo veo como una, todo, porque es que es de la plataforma, todo lo que vas a aprender en Dino lo puedes utilizar en JavaScript en el navegador.
Eso, ¿cómo de increíble es eso?
Es que es increíble.
A mí me parece increíble.
Me parece brutal.
¿Dino Run y un archivo JS sería el reemplazo de los NPM scripts para Dino?
No conozco, no sé si es Dino Run, no.
No, porque Dino Run, o sea, Dino Run sería como los scripts, pero sería como en el NPM Run, sería algo parecido así.
Entonces, si tengo un proyecto pequeño, ¿la oportunidad?
Yo creo que sí.
Yo creo que sí.
Con proyectos pequeños yo sí me animaría.
¿Qué opinas de Node o Dino para stream de vídeos?
Pues me parece bien.
¿Llegaremos este mes a mil?
No creo que lleguemos a mil subs.
¿Si la arepa es tan buena, por qué hay una arepa a dos?
Bueno, en realidad hay dos arepas.
Están las de Venezuela y las de Colombia.
Entonces, ¿conoces algún caso de éxito de Dino?
La verdad es que no, pero sí que sé que están empezando a utilizarlo en algunas...
A ver, ¿no lo ponía aquí?
¿Dónde lo estuve leyendo?
Mira, compañías interesadas en Dino.
Mira, claro, interesadas en Dino suena un poco...
Aquí te puede...
Puede ser cualquiera.
Puede ser cualquiera.
Pero no sé dónde, no sé qué compañía estuve leyendo.
Ah, es que me da mucha rabia porque ahora no me acuerdo cuál era.
Si lo encuentro, lo pasaré en Discord porque era muy interesante.
Total, que estaban migrándolo todo a Dino porque habían encontrado que en temas de rendimiento
y de cuántas requests podían soportar era mucho mejor que Node.
Y entonces había bajado los costes de infraestructura.
Era una burrada, un 50%, una cosa así.
Una cosa así.
Entonces parecía bastante interesante.
Y me parecía sorprendente que estaban dando tanta caña.
Me parecía muy sorprendente.
Así que...
Ah, y de hecho en Netlify...
No, en Netlify no.
A ver...
No sería...
No.
Bueno, ya lo buscaré porque tenía bastante buena pinta.