This graph shows how many times the word ______ has been mentioned throughout the history of the program.
Pues resulta que JavaScript evoluciona.
Porque esta misma semana ha habido avances importantes en el lenguaje de programación de JavaScript.
Porque ya sabéis que hay un comité, que es el TC39, que es el responsable de desarrollar y mantener JavaScript, ¿vale?
Y entonces, bueno, JavaScript. Es un poco complejo de explicar.
Porque en realidad lo que evoluciona es ECMAScript.
Porque JavaScript es una marca registrada de Oracle.
Entonces, ECMAScript sería JavaScript, pero la marca blanca.
Digamos, ¿vale?
Sería como la receta para hacer JavaScript.
Total, que esta especificación en la que están evolucionando, hay un montón de propuestas y tal.
Han estado evolucionando, pasando hacia adelante un montón de nuevas características de JavaScript.
Un montón.
Por ejemplo, Deferred Import Evaluation.
Que esto suena como, ¿qué me estás hablando, Midu?
¿Qué es esto de import? ¿Qué es esto?
Pues está súper interesante esto.
Te lo voy a explicar rápidamente porque te va a volar un poco la cabeza, ¿vale?
El tema es que a día de hoy en JavaScript tenemos un problema bastante...
No sé si decir que es importante.
Sí que es importante, ¿vale?
Porque obviamente tiene problemas de rendimiento.
Pero el tema es, fijaos en este código.
Que este código parece normal y corriente.
No pasa absolutamente nada.
Claro, aquí lo que tenemos es que este import, pues, es dinámico.
Y se está haciendo cuando se ejecuta esta función, ¿no?
Y esto está bien porque esto lo que va a hacer es que solo cuando se ejecuta esta función va a importar este módulo dinámicamente.
Pero, ¿qué es lo que ocurre?
Lo que ocurre es que muchas veces cuando vosotros hacéis un import así, ¿veis?
Hacéis un import así, tal cual.
Pues, ¿sabéis lo que pasa?
Que ese módulo, aunque tú no lo utilices o lo utilices más tarde, se evalúa en ese instante.
Y eso lo que hace es que tiene un problema de rendimiento.
Porque si tú te pones a importar de todo, por más que tú lo utilices, mira, para que os hagáis una idea.
Podría hacer un ejemplo con código, pero claro, tampoco quiero aburriros aquí con el ejemplo de código.
O sea, ejemplo de código quiero decir con un proyecto grande.
Pero os voy a enseñar esto.
Mira, import superheavydependency, ¿vale?
From dependency.
Imaginad que tenéis esta función que se llama suma.
Bueno, suma no.
Do something, ¿vale?
Do something, ¿vale?
Y aquí ejecuta superheavydependency.
Pues esto te va a volar la cabeza.
Pero esto, aunque no ejecutes do something, el problema es que se evalúa la dependencia dependency, ¿vale?
Y esto tiene un problema.
Lo del teclado se hace raro.
Bueno, bueno, lo puedo quitar, ¿eh?
Esto soy yo probando cosas muy creepys.
Si queréis, lo quito.
O me puedo callar, mira.
¿Sabéis lo peor?
Es una aplicación, en realidad.
Es una aplicación.
Esto es muy friki.
Es una aplicación que se llama Clack.
O sea, en realidad no estáis escuchando el teclado.
Es una simulación.
Y encima le podéis cambiar las teclas.
Fijaos.
Este me gusta menos.
Y entonces le he puesto el que menos...
Este, le he puesto este.
Bueno, ¿por qué puede ser interesante?
Bueno, para que escuchéis cuando estoy tecleando.
Y ya está, ¿eh?
Pero si os molesta, lo quitaremos.
No os preocupéis, ¿eh?
No os preocupéis.
Yo soy aquí probando.
Mira, gente que dice que sí, que no.
Me gustaría quitarle un poquito más de sonido.
Pero bueno, no pasa nada.
No pasa nada, pasa nada.
El tema.
Que esto es interesante porque aunque no ejecute la función do something, JavaScript va a evaluar toda la dependencia.
Toda, toda esta dependencia.
Lo cual es bastante bestia.
Entonces, van a sacar una cosa que va a ser nueva, donde cuando tú importes un módulo, vas a poder indicarle el defer.
¿Veis aquí?
Import, defer.
Esto va a ser nuevo.
Import, defer, como, no sé qué, no sé cuánto.
¿Veis esto?
Entonces, lo que va a ocurrir es que solo cuando lo utilices lo va a evaluar.
Y esto va a tener un montón de ventajas porque hoy en día un problema que tenemos en muchos códigos de JavaScript es que la inicialización del código es muy costosa por culpa de todos los inputs que tenemos que en realidad no estamos utilizando o que los estamos utilizando después de un clic o cosas así.
Entonces, está muy interesante y es una de las cosas que ha evolucionado ya en la fase 2.27.
Y esto significa que nos va a permitir optimizaciones de rendimiento a la hora de retrasar la ejecución de inputs de módulos que han sido importados cuando son explícitamente necesitados.
Están muy, muy interesantes, de verdad.
Pero, bueno, me imagino que en vuestro día a día esto ya lo puedo utilizar.
No lo podéis utilizar porque ahora mismo no lo soporta nadie, pero lo digo porque el día de mañana, muy pronto, más pronto que tarde, igual empezáis a ver ese defer y os va a volar la cabeza.
Pero va a ser una evolución que va a tener el lenguaje de JavaScript.
Luego tenemos el error.isError, que sí que es raro, pero esto es básicamente para poder testear si algo, si un valor es del tipo error.
Que a día de hoy será un poquito más complicado y esto te permite depurar mejor tu código.
Lo de promise.try, que esto lo que te va a permitir es envolver cualquier función en una promesa y esto te permite mejorar el manejo de errores, por ejemplo, el hecho de simplificar tu código.
Porque hay veces que te viene algo que no sabes si es una promesa o si es una función que puedes ejecutar y tal.
Entonces dices, vale, voy a probar si es una promesa y esto te lo envuelve siempre en una promesa indiferentemente si lo era o no lo era.
Así que, mucho mejor.
Y luego, otra de... Hay un montón. O sea, JavaScript se están moviendo las pilas de una forma bestia.
Vale, de todas estas, de todas estas, voy a destacar dos, porque si no, estaríamos aquí todo el día.
Pero voy a destacar dos. Una, la de decimal y otra, la de signals.
Entonces os explico. Signals no ha evolucionado de fase, ¿vale? No ha pasado una nueva fase, pero sí que han estado hablando de ella.
Y entonces, los signals, por si no lo sabéis, es esta propuesta de añadir señales en JavaScript, que sería una forma de tener reactividad nativa en JavaScript, sin necesidad de dependencias, ¿vale?
Y esto está muy bien porque normalmente en UIs, por ejemplo, ahora hay muchas bibliotecas, todas, excepto RIA, que utilizan signals.
Por ejemplo, Angular ahora está utilizando muchos signals. Y esto, pues, te hace como observar un valor y se va a renderizar automáticamente y todo esto.
Y esto te lo simplifica mucho. Tiene bastante, bastante buena pinta, la verdad.
Y no ha evolucionado, pero han hablado bastante de ella y no pinta mal.
Y la propuesta, que sí que ha evolucionado a la siguiente fase, que es una muy demandada en el lenguaje de JavaScript, que va a pasar ahora sí.
No, ah, bueno, no ha evolucionado, pero va a evolucionar, porque van a hablar de ella esta semana.
Pero que tiene buena pinta es la de decimal. Esta nueva propuesta, que va a llegar un nuevo tipo, un nuevo valor a JavaScript para poder trabajar bien con decimales.
Porque, no sé si sabéis, pero hay un montón de problemas con los decimales. Bueno, me imagino que el típico este de 0.1 más 0.2, este típico, ¿vale?
Que te hace este problema. Que esto no es un problema. Esto no es un problema de JavaScript, ¿vale?
Esto no es un problema de JavaScript, por más que la gente siempre está, es que JavaScript, es que no sé qué.
Esto no es un problema de JavaScript. Esto, en realidad, es cómo funciona el coma flotante en un montón de lenguajes de programación.
Y, de hecho, esto está identificado en un estándar. Un estándar que te indica cómo tiene que funcionar coma flotante en muchos lenguajes de programación.
O sea, no es un problema que tenga el lenguaje, sino que, en realidad, es una especificación.
Y le pasa a Python, le pasa a PHP, le pasan un montón de lenguajes.
Pero, bueno, hay gente que se queda como, ¡JavaScript! ¡Eres lo peor! ¡JavaScript! Bueno, pues no JavaScript.
Sí que es cierto que lo malo de JavaScript es que no tienes una alternativa.
O sea, no tienes una forma fácil de arreglar este desaguisado, ¿vale?
Tendrías que redondear valores, tendrías que hacer cosas muy raras, podrías utilizar o instalar una dependencia, una biblioteca...
Pero no quiero eso. Quiero que el lenguaje me lo arregle.
Y por fin, por fin, lo vamos a tener, ¿vale?
Por fin vamos a tener un nuevo que se llama decimal 128, en este caso.
Creo que va a haber diferentes niveles de decimales, si no me equivoco.
No solo van a ser de 128, sino que va a haber diferentes.
Y te va a permitir hacer cálculos mejores.
O sea, no que estén mal, como el que hemos visto.
¿Ves? Podríamos crear aquí new decimal y lo que puedes hacer es sumas.
Hacer, por ejemplo, la suma, la multiplicación, la división y todo este tipo de cosas.
Son operaciones sobre decimales y que te va a dar el cálculo correcto.
Así que esto es muy interesante porque hasta hoy siempre necesitamos algún tipo de dependencia.
Yo tengo que decir que no soy muy fan de la API.
Me parece como demasiado rara porque han creado como que tengas que crear objetos.
Y a mí me chirría un poco porque hace poco hicieron vkint en MDN.
Lo podemos ver.
Vkint, que es un valor numérico para números muy grandes,
que ponías el sufijo n al final y ya lo tenías.
O podías utilizar también aquí el constructor, ¿no?
Bueno, este no es un constructor.
Es una forma de crear el primitivo un poco especial.
Pero bueno, el tema es, es como para transformar, ¿vale?
Esto no es el constructor porque fijaos que no tiene el new delante.
Pero con el sufijo n ya se podía hacer.
Y resulta que aquí no lo van a hacer con un sufijo,
que creo que hubiera tenido sentido.
Pero lo comentan aquí.
¿Por qué no lo van a hacer?
Y bueno, entiendo que esta gente es más lista que yo
y tendrán sus razones.
Pero a mí personalmente me sigue chirriando un poco
porque me hubiera gustado más que hubiera sido con un sufijo
y ya está, ¿no?
Pero si le ponen el punto simplemente rompería bastantes cosas.
No, ya.
Simplemente el punto no puede ser, ¿eh?
Pero yo, por ejemplo, sí que creo que podrían haber hecho algo así.
O sea, con el punto lo entiendo,
pero a lo mejor haber hecho algo así.
Con la D, ¿vale?
Por decir algo.
O no sé, ¿qué más podría ser?
Con la M, ¿no?
Con la M también.
Pues algo así, no sé.
¿Ves?
Support for the experimental syntax decimal.
Bueno, pero esto no va a llegar al final a JavaScript con un sufijo.
Me parece, o con la F.
Bueno, con la F un poco polémico,
pero con la F también podría ser.
Pero no sé.
A mí me parece un error.
Me parece un poco error, la verdad.
Pero al menos tendremos una forma nativa de arreglarlo.
Lo cual ya está bien.
Es verdad, no me gusta.
Tiene vibraciones de New Day.
Tienes toda la razón.
Skullsame.
Tienes toda la razón.
Creo que la lía con strings, eso que dices.
Puede ser.
A ver, alguna cosa habría, pero también es verdad que, por ejemplo, esto se puede hacer.
Bueno, ¿invalid?
¿Por qué me dice que es inválido?
¿Por qué me dice que es inválido por el más?
Ah, no.
Me dice que es inválido.
Vale.
Me dice que es inválido por el punto.
¿Vale?
Pero esto sí que se puede hacer.
Y esto es un vkint.
Porque no sé si lo sabéis.
Que, por ejemplo, si ponéis esto.
¿Vale?
Fijaos.
A ver si soy capaz de poneros un número para que veáis bien el error.
Este ejemplo, ¿no?
Si vosotros sumáis un número muy grande más uno, fijaos lo que pasa aquí.
Que se pierde precisión también.
Esto pasa justamente lo mismo, ¿no?
En cambio, para arreglar esto, porque se pierde precisión para números enteros muy grandes,
lo que tenéis que hacer es utilizar el vkint.
Entonces hacéis así, tú y tú.
Y ahora veréis que hace correctamente la suma.
Pues creo que hubiera sido muy bonito tener algo así, pero con los decimales.
Hubiera sido genial.
No sé si con la D, con la F, con lo sea.
El tema es que no lo tenemos.
No lo tenemos.
Me da un poco de rabia.
Me da un poco de rabia, ¿eh?
Me da un poco de rabia.
Me da un poco de rabia.
Me da un poco de rabia.