Ahora vamos ya directamente con el bueno de Rómulo, porque Rómulo nos va a hablar del futuro de JavaScript.
Rómulo es que, Rómulo, ojo, que vamos a tener aquí una eminencia.
Rómulo es parte del TC39, así que si queréis que algo llegue a JavaScript, no es que él tenga todo el poder,
pero yo creo que si le intentamos decir, oye, si te doy esto, quizás puedes hacer que esta propuesta...
No, hombre, no funciona así. Él os va a explicar mejor que nadie cómo realmente funcionan las propuestas
y cuál es el futuro que nos va a llegar a JavaScript con las propuestas que llegan a JavaScript.
¿Qué es esto de JavaScript? ¿Qué es esto de JavaScript? ¿Por qué hay una cosa, un nombre diferente?
Rómulo nos lo va a contar, así que le vamos a dar la bienvenida al bueno de Rómulo.
¡Rómulo, cómo estás!
Hola, ¿qué tal, Miguel? ¿Todo bien? ¿Todo bien?
Súper bien.
Súper contento de tenerte aquí. Estuviste, creo que en la MiduConf el año pasado.
No sé si fue el año pasado, pero estuve hace tiempo.
Has estado seguro.
He estado seguro.
Es que es tremendo. Bueno, pues Rómulo, te dejo en los mandos para que te presentes,
para que la gente te conozca, porque cuando conozcáis a Rómulo y el impacto que tiene su trabajo
en el lenguaje de programación de JavaScript, pues vais a alucinar muy fuerte.
Así que nada, vamos a dejar al bueno de Rómulo que os explique el futuro de ECMAScript
y cómo esto impacta en JavaScript, las propuestas que se vienen y cómo funcionan las cosas.
Rómulo, te mando un abrazo enorme, muchísima suerte y me alegro muchísimo de verte.
Ojalá nos podamos ver en persona pronto y con una cerveza hablemos del futuro de JavaScript también.
A ti igual, Mido. Es que antes de ser JavaScript, creo que tenemos aquí una buena relación,
una amistad y he hecho mucho de menos ver en persona.
Totalmente. Pues venga, te dejo aquí con la charla y ahora yo estaré ahí pendiente
que esto está súper interesante. Suerte, Rómulo.
Perfecto. Bien, hablaremos hoy de C39, de ECMAScript y de su futuro.
Ya he dicho nada a todos, pero digo una vez más a todo el mundo ahí en casa para el MidoFest.
Yo soy Rómulo, yo trabajo en una empresa llamada Igalia.
Hacemos Open Source y enfocado a vectores, a engines y todo lo que es estándar también.
Tenemos muchos equipos. Ahí también tengo, me he cambiado el logo porque me encanta el antiguo logo de Twitter,
mi handle, si queréis seguirme en las redes sociales.
Y vamos a empezar, que es un cuerpo de estándars, que este es el 39,
y esto remonta a la solución de problemas muy graves.
Y el primero problema fue este, ¿no? ¿Os acordáis que en el mundo de emoji nadie sabía hacer una hamburguesa?
Si era el queso por arriba, si era el tomate, la lechuga, si llevaba pan, sin pan.
Bien, esto ha pasado porque en el mundo de las emojis no había una estandarización de cómo se hace la hamburguesa.
Y bien, y para estandarizar tenemos algunas, lo que llamamos las venues, ¿no?
Los cuerpos donde se pueden trabajar estándars.
El WG, W3C, que son más relacionadas a lo que son HTML.
ISO, que es lo que estándar muy conocido aquí en Europa también para casi todo.
El ECMA, que es el estándar que acoge el JavaScript o ECMAScript que todos conocemos.
Y Unicode, que es muy relacionado con todo que son temas de internacionalización.
Y en el caso que nosotros estamos dentro de ECMA, el TC39.
Podría ser TC11, TC12, TC15, no sé por qué es el 39.
Creo que será por orden.
Y es el comité técnico que define el lenguaje de JavaScript que todo el mundo lo usa.
Y es porque estamos aquí mucha parte de nosotros.
¿Quién puede participar en este grupo?
Bien, normalmente son los delegados.
Y los delegados vienen de tres maneras distintas, ¿no?
Implementers, que son la gente que tiene un engine, un browser.
Normalmente Google, Apple, etcétera.
Compañías, empresas que interesan por los estándars.
Todo esto, las compañías pagan como una suscripción anual para pertenecer.
Después tenemos las entidades como Diversidades, Open Gears Foundation y otras que pertenecen, no pagan.
Pero también tienen un voto y un asiento en el board o en la asamblea que hacemos.
Y ya explicaré un poco mejor.
Después hay el caso de los Invited Experts, que son gente que ha sido reconocida por algún motivo, ¿no?
Por su contribución dentro de lo que es la comunidad, las propuestas, ideas.
Y después todos los demás contributors, ¿no?
Todo el mundo que quiera estar aquí y ayudar y hacer reviews de propuestas, de ayudar a la comunidad.
Todo eso, o sea, todo el mundo puede pasar.
Yo la verdad es que pasé, creo que por las tres fases hasta el momento.
Por eso es posible.
Bien, un repasito antes de empezar con todo lo importante.
ECMA, ya hemos dicho, ¿no?
Es la entidad que garantiza el estándar.
ECMA262 es el número de la especificación que define el lenguaje ECMAScript,
ECMAScript, que al fondo todo el mundo la llama JavaScript.
El TG2, TG3, TG1 son los grupos de trabajo dentro de cada TC, de cada Technical Committee.
Y os explicaré un poco mejor.
Y el TCXX, bien, puede ser el 39.
Para JavaScript, el 53, creo que es Dart o JSON o lo que sea.
O sea, hay muchos TC's.
Podéis buscarlo.
Y, bien, ya sabemos lo que es el Standard Venue, ¿no?
O el TC39.
Y ahora, ¿cómo trabaja?
Es muy sencillo.
A través de consenso.
Todos tenemos que estar de acuerdo para que las cosas salgan adelante.
Lo que es súper, súper complejo y difícil.
Pero si no estamos de acuerdo, lo que hacemos es intentar, entendernos y aportar de manera constructiva
para que las cosas salgan adelante, ¿no?
Si no me gusta esto, el por qué no me gusta esto, lo podríamos hacer de otra manera.
Y así intentar tener un consenso para avanzar con las propuestas.
Y las propuestas se avanzan por fácil, ¿no?
Que le llamamos stages.
Aquí yo menciono cuatro stages, pero existen más.
A un nuevo que ha sido creado justo al final de 2023.
Y ya os lo explicaré un poco más tarde.
Y todos estos pasos demuestran la maturidad de la propuesta, ¿no?
Si vamos de stage zero, aumentando, aumentando, hasta que finaliza.
Lo que he comentado hace poco, los task groups.
Bien, el TGO, que es el principal, trata de lo que es el lenguaje, el JavaScript.
Después tenemos el 2, que es muy enfocado a la internacionalización.
El 3, a la seguridad.
Y estos dos nuevos, que es uno enfocado a source maps y otro a research on language standardization,
que es un grupo de trabajo que estudia el lenguaje y mejoras lo que se puede hacer dentro de lo que es JavaScript
y todos los lenguajes que puedan ser también trabajadas en el mismo ecosistema.
Lo trabajamos todo en GitHub.
Lo podéis ver ahí.
Es casi todo muy público.
La ECMAS Clip, este sería la receta que generamos cada año.
Aquí en la pantalla es de 2022, pero este año se lanzará una nueva receta
que los browsers la cogen e intentan implementar para cada navegador.
A veces lo hacen mejor o peor, por eso que a veces tenemos alguna diferencia,
pero eso ya lo miraremos de cómo intentamos solventar ese tipo de problemas.
Y hacemos 6 reuniones todos los años, 3 en persona y otras 3 en virtual.
La primera del año la hicimos en el continente americano,
lo fuimos a San Diego, la segunda online, la tercera será dentro de dos semanas en Helsinki,
que lo iré, y después la última del año presencial normalmente es en Japón.
O sea, nos dividimos e intentaré ir.
Y hacemos también varias llamadas cada mes para varias cosas, ¿no?
Educators, Tools, yo soy responsable de algunas de ellas,
he procrastinado en algunas y perdonó, pero así que vuelva a vosotros.
Estáis todos invitados.
Y bien, ahora empezaremos con lo que nos interesa más, ¿no?
La parte del código.
Y he puesto 2.7 porque la verdad es que los stages han cambiado,
pero ya lo comentaré más adelante.
La primera fase es la fase 0, ¿no?
Stage 0.
Que esto es en un café, estás con un amigo y te apetece hacer una propuesta
y pensar, oye, esto en JavaScript sería la bomba, ¿no?
Una idea cualquier que tengas.
Escribes un explainer y intentas discutir con alguien.
Existen explainers ya dentro del repositorio de propuestas en Stage 0.
Estas son propuestas que quizá no llegan a Stage 1 o propuestas que nunca fueron presentadas,
que son como un grupo de ideas que la gente tiene.
No quiere decir que nunca se vaya a hacer.
Yo, por ejemplo, mañana puedo coger una de estas propuestas y hacerme Champion
y intentar promoverla durante todas las fases.
Llegamos al Stage 1.
Stage 1 es cuando tenemos un Champion, que es el Champion, es la persona, ¿no?
Que se encarga de trabajar en una propuesta
y esperamos que cuando lleguemos ahí tengamos una idea un poco más o menos de lo que va a ser,
por lo menos la intención.
Y podemos trabajar en demos, podemos trabajar en algún polyfill,
pero se espera que esto cambie de hoy para mañana, ¿no?
Que cambie de nombre, que cambie de API o hasta que cambie la dirección de la propuesta.
Y, por ejemplo, en el caso de Stage 1, ahora tenemos una propuesta
que es de las que más me está como en plan alegrando
y es una propuesta llamada Signals o Signals o Sinales, como queramos decir en castellano.
Y antes de avanzar para lo que es la propuesta y que trata la propuesta,
es completamente distinta de la mayoría de las propuestas que estamos acostumbrados,
porque normalmente nos enfocamos a las propuestas para el desarrollo final.
Y en este caso, esta propuesta la puede ser usada por el desarrollo de los finales,
pero es muy enfocada a los frameworks, a las librerías.
Y, bien, ¿qué son Signals?
Nosotros estamos acostumbrados, ¿no?, con la programación reactiva,
en que usamos React, usamos librerías que nos ayudan a gestionar el estado.
Y en este caso, cuando hacemos un counter, ¿no?,
la variable para salvar o guardar la información que vamos incrementando al counter,
tenemos la función setCounter en este caso,
que es la función que nos va a incrementar el contador,
y renderizar, porque normalmente cuando hacemos UIs y un contador,
queremos no solamente que se incremente dentro de código,
pero lo queremos también pegar a la parte visual.
Y esto sería un counter que dice, ¿no?, par o impar,
y aquí sería, por ejemplo, un caso que tenemos este tipo de código.
Cuando queremos crear una librería como Signals,
lo que queremos hacer, básicamente, es no tener este tipo de código,
pero desde el navegador, desde la lenguaje,
darte un gestor de estados que sea lo más optimizado,
que puedas crear tu signal y puedas crear tu efecto,
y puedas, dentro del valor, por ejemplo,
Signal Computed, pasarle los finales, los callbacks,
y puedas gestionar esta mutabilidad de la manera,
o este estado, digamos, de la manera más eficiente posible.
¿Y por qué dicen?
Oye, pero ya hacemos esto desde librerías de JavaScript.
Es verdad.
Pero este es de los pocos momentos en que todas las fuerzas de frameworks
se han juntado para crear algo que es nativo dentro de la lenguaje, ¿no?
El API de Signals sería algo que está optimizado.
Creemos que escribir toda este tipo de gestión de estados
dentro de lo que es la lenguaje C++, ¿no?,
que es lo que sería implementado,
nos permitiría hacer más optimizaciones,
y desde lo que son los frameworks,
podríamos usar este API para hacer sus side effects,
para renderizar el DOM de la manera más eficiente,
aportando muchísimo más de lo que se hace hoy en día.
Y al ser algo del navegador,
todos los frameworks podrían construir encima de esto, ¿no?
Y además de eso, si a futuro podemos conectar esto
a lo que sería, por ejemplo, un DOM Parts o un API
que pudiera mutar el DOM de una manera muy, muy, muy, digamos, atómica,
podríamos tener los efectos de mutación de UI
de una forma súper, súper, súper smooth, ¿no?
Porque es de las problemáticas que tenemos
que el JavaScript puede actualizarse rápido,
pero tiene que reflejar en la vista, ¿no?
Y es por eso que se han creado el Virtual DOM,
muchísimas técnicas para optimizar ese proceso.
Stage 1, tenemos muchísimas propuestas que me encantan, ¿no?
Pattern Matching, que es como la mejora de nuestro conocido switch.
Type Annotations, que es una propuesta que yo soy uno de los champions también,
que me encanta un montón, que está un poco así en el limbo.
Décimal, que también, oye, para nosotros que cada vez más se usa
JavaScript dentro de lo que es el mundo financiero,
sino tenemos una buena estructura de números
y el decimal es muy importante,
se va perdiendo el dinero por ahí,
por estos números grandes, grandes, grandes,
que no es posible gestionarlos desde lo que es el JavaScript.
Y esto sería el Stage 1.
¿Cuándo llegamos a Stage 2?
Bien, atención, esto ya es algo muchísimo, muchísimo más serio.
Y bien, ya empezamos con lo que es la SPEC, ¿no?
La SPEC es la receta para los navegadores y los engines
que implementen nuestra idea.
Y es escrita de una manera muy específica en el ECMA Markup,
que es súper complejo.
Después que empiezas, te vas acostumbrado,
pero todos los días aprendiendo.
Y ya tienes que tener las semánticas,
las APIs que quieres tener, exponer,
todos, ¿dónde va a ir la cosa, no?
Y se espera que esto vaya hacia adelante, ¿no?
Ya has gastado tiempo estando en el Stage 1,
ahora, oye, vamos hacia adelante,
ya empieza a ser algo experimental.
Y, por ejemplo, este es un ejemplo de SPEC,
que yo mismo escribí para Number Format,
que, por ejemplo, tiene el Format Range,
el Format Range to Parts.
Y aquí tiene la receta, ¿no?
Cuando recibes un número,
hacer el Require Entry Slot,
que es como alocar el espacio, ¿no?
Del constructor del Number Format.
Y después le vas diciendo, ¿no?
Oye, si es definir, undefined,
o hacer el True del Error,
que es cuando empiezas a transformar el número.
Y ahí dentro de esta operación, por ejemplo,
puedes definir precision arbitraria del número
y muchísimas cosas ahí por detrás
que vosotros podéis ver que es todo público.
Pero, oye, es un rollo y es súper complejo
y hay muchísimos errores
que vamos a lo largo del proceso
arreglando y mejorando.
Y un ejemplo de Stage 2 Proposal,
que a mí me está encantando,
y creo que es,
solamente un caso muy peculiar,
y es de Julia,
mi amiga Julia y Nicoló,
mi co-worker,
mi compañero del trabajo.
Y es algo súper gracioso
porque nosotros,
al momento,
vamos siempre que vamos a ser lazy.
Lazy load,
lazy lo que sea.
Y cuando somos lazy,
la mayoría de los casos,
delegamos y somos lazy
porque no queremos que,
oye, estar network, bandwidth,
¿no?
o la conexión,
pero en algunos casos
que, oye,
no hay diferencias
si porque los ficheros
son en un servidor local
o porque esta es una aplicación
dentro de un servidor
o un electron,
no interesa la latencia
de carga
desde,
asíncrona.
Lo que te interesa
es el peso,
¿no?
que el JavaScript
tiene cuando se inicializa,
se evalúa,
se evalúa,
se inicializa,
¿no?
Y quieres que se cargue
porque lo quieres tener ahí
al momento,
pero solo quieres inicializar
y cuando habla inicializar
es evaluarlo
y hacer todo,
¿no?
el proceso que está por detrás
de cuando abres un fichero
de JavaScript,
¿no?
ver el gráfico de dependencias,
qué hace,
qué no hace,
el hoisting
y toda la parte de lo que sería
el engine,
lo haría,
lo haces después.
Esto también puede ser
un gano muy grande.
Ya hay algunas pruebas de concepto
que algunas aplicaciones desktop
y otras que usan también JavaScript,
hay un gano muy,
muy grande
en lo que sería la performance.
Por eso,
esto es una alternativa
si no necesitas de,
o no tienes problemas
de hacer el lazy load
de una manera distinta,
¿no?
Hacer el lazy,
digamos,
evaluation
y ya después del stage 2
normalmente vendría el Rage,
pero ahora tenemos el 2.7
¿y por qué el 2.7?
Bien,
cuando llegábamos a stage 3
había una problemática,
había propuestas
que eran stage 3
casi stage 4
y había propuestas
que eran stage 3
casi stage 2
y esto causaba
muchas problematías,
¿no?
El tema de
cuando los navegadores
empiezan las implementaciones,
la pie estaba estable
el suficiente
para que podamos
empezar a implementar,
no necesitamos
de más tests,
bien,
hay más comentarios,
hay cambios,
o sea,
porque no había
una estabilidad
confirmada
y era muy difícil
tener como una línea
muy firme
cuando la propuesta
estaba en condiciones
para implementar,
fue ahí que se ha creado
el stage 2.7
que fue creado
en la reunión,
creo que de noviembre
o de...
sí,
noviembre,
sí,
sí,
sí,
sí.
Bien,
¿qué esperamos
de stage 2.7?
Es que tengamos
el texto,
la spec completa,
¿no?
Que ya tengamos
todo lo que es necesario
para que estemos listos
para implementar
y ahí
los reviewers
empiezan,
los reviewers,
los editors,
porque tienes que
invitar gente
para que revise
tu spec.
Empiezan creando
los tests
y, bien,
alguna implementación,
algún polyfill
puede ir empezando.
Y después
tenemos aquí
un caso
que es el
Shutter Royale.
Fue la primera
propuesta
llegando
al stage 2.7
y muy gracioso
porque
esta propuesta
estaba en el stage 3,
ha sido
demoted
en inglés,
no sé,
o rebajada
en castellano
sería,
creo,
a stage 2
y cuando
volví a stage 3
se ha metido
este nuevo stage
que es el 2.7.
Eso ha vuelto
y ha vuelto
al 2.7.
¿Qué es Shadow Rims?
Shadow Rims.
Bien,
es una propuesta
que a mí también
me encanta.
No ha tenido
la mejor
de las fuertes
hasta el momento
porque
tiene bastante
complejidad
a nivel
de temas
de seguridad.
Pero la motivación
que tiene esta propuesta
es muy clara.
Esto viene
de la gente
de Salesforce
que tiene que interactuar
en sus aplicaciones
con muchas dependencias
de terceros,
¿no?
Desde Google Maps,
desde AMP,
que muchas de ellas
parcean
el global object
o lo cambian.
Y cuando tienes
software de terceros
dentro del mismo
entorno,
puede haber
este conflicto.
Si no,
pone esta
un feature
detection
para no ensuciar
o poluir
el global object.
Y en este caso,
lo que hace Shadow Rims
dentro del mismo heap
crea un real.
Un real
es como una capa
interna
que genera
un nuevo objeto global
que es un aislado
de la principal,
a pesar que
ejecutan el mismo thread,
ejecutan el mismo
contexto,
pero
en ese real.
Y la ventaja
es que puedes
inicializar,
por ejemplo,
en el primera
inicializa
la función
init
dentro del plugin framework
que es el inicio
del Google Maps
y la otra
inicializa
otra librería.
Y esto después
te devuelve
y puedes jugar
con los datos
sin interferir,
digamos,
en el global list.
Esto se puede hacer
al día de hoy
muy
poco liante
con
iframes,
post messaging,
pero cuando tienes
que hacer
este tipo
de aislamiento
lo tienes que hacer así.
Muchas veces
en casos
de authentication
se hace
un proceso
similar,
no igual,
pero sería
algo que nos permitiría
echar aislamiento
sin tener
que contar
con grandes cosas
y es una propuesta
que a mí
la verdad
que la veo
súper necesaria.
Cuando llegamos
al stage 3,
oye,
tenemos el
spec text
como con
el stamp,
con el sello
de los
implementers,
los
engines
empiezan
implementándolo
y ya
uno ya
se anticipa
y lo lanza
antes del flag.
Por eso
que ahora
el stage 3
y el 2.7
es más fácil
porque había
a veces
la carrera
de los engines,
¿no?
¿Quién quiere ir
primero?
Y a veces
alguno lo lanzaba
muy,
muy,
muy prematuro.
El caso
de Shadow
Reel
ha sido
lanzado
en Safari
antes de
tiempo
y después
ha vuelto
hacia atrás.
Por eso
os digo
que es muy
importante
la motivación
de stage 3.
Stage 3
tenemos propuestas
como Temporal,
ya hablé de ella,
pero bien,
es la propuesta
que nos va a permitir
trabajar con data,
con fechas,
con tiempo,
hacer operaciones
aritméticas
con fechas
y es una de las
propuestas
más complejas
que existe
en la lenguaje
hasta el momento.
Ya tienes que tener
en esta fase
el test 2.6.2,
¿no?
Lo que comentaba,
vosotros podéis ver
el resultado
de la compatibilidad
de los tests
en cada uno
de los engines
si vais a este link.
Es muy gracioso
porque todos los tests
se ejecutan
contra estos engines
y cuanto más
coverage
quiere decir
que es más
spec compliant,
¿no?
Se alinea más
con los resultados
de la spec
y los tests
que se ejecutan.
El caso de Temporal,
voy a pasar adelante
porque para mí
es de las mejores
propuestas.
En stage 3
hay algunas otras,
decorators,
etcétera.
Y ahora,
por tiempo,
llegamos a la stage 4
que es cuando
todo finaliza,
¿no?
Cuando la carrera
termina
y cuando queremos
pasar a la propuesta
a la nueva edición
de lo que es el libro
o la lenguaje.
Normalmente se pasa
cuando ya existe
más que dos engines
implementándola
y ya tiene
el grado
de maturidad
suficiente
para que sea utilizada
en aplicaciones
casi en producción.
Por eso,
llegando a stage 4,
bien,
es algo seguro
que no saldrá
de la lenguaje.
Y tenemos
algunas propuestas
que son súper interesantes,
¿no?
El array grouping,
que es algo muy sencillo,
pero nosotros
hemos estado años
con loadass
y con otras librerías.
En este caso,
tenemos un array,
un objeto,
si queremos
filtrarlos
o agruparlos,
¿no?
Por una cosa,
aquí enviamos
por alguna propiedad.
Aquí enviamos
el callback
y dentro del callback
hacemos el destructuring
del objeto
y a la cantidad,
si es menor que 6,
nos filtra,
nos da la cantidad
menor que 6.
Pero esto lo podemos hacer
también con objetos,
¿no?
Aquí,
por ejemplo,
con el object group by,
destructura automáticamente
y le dices
que lo filtre
o que grupe
por tipo
y nos pone
todo muy
guapo,
¿no?
los vegetables,
fruits,
meat,
porque estamos filtrando
por tipo
y esto es súper,
súper,
súper útil
y nos pasamos horas
con maps,
con filters,
con reduce
y esas cosas todas.
Stage 4,
set methods también.
Nosotros tenemos los sets,
nos ha salvado la vida
para generación de arrays
no duplicadas,
etc.
Ahora tenemos
métodos
que nos permiten
trabajar
con dos pares de sets,
¿no?
Por ejemplo,
saber la intercesión
entre dos,
la diferencia
entre dos sets
o hasta
intentar
hacer el merge
de los mismos,
o sea,
es espectacular
y es muy útil
que lo tenemos
que tener
y lo usábamos
y lo hacíamos
de manera
mucho más compleja
y así con una línea
lo tienes.
Promise with Resolves,
oye,
esto también era algo
de Capón,
¿no?
¿Quién no ha hecho esto?
La variable fuera
letResolveReject
y después la machacaba
sin querer
con algún otro
la Promise,
con Promise with Resolves,
estructuras
el resultado
de la Promise
y puedes hacer
todo tu trabajo
de manera
súper,
súper,
súper sencilla.
Muchas propuestas
en Stage 4,
¿no?
Array
o Atomic
Awaited Sync,
otras muy relacionadas
con cosas muy complejas
como Rejects,
como Unicode,
Strings,
pero podéis siempre consultar
y para vosotros
que queréis
o tenéis la posibilidad
de ser más valientes
usando las nuevas features
con TypeScript,
con Babel,
ESPILD,
todas estas herramientas
ya las podéis usar.
Todo lo que ha salido
hasta el último plenario
hará parte
del libro
de ECMAScript
para el año que viene
y el último paso
es cómo colaborar
y relacionarse
con un TS39.
Escribir test,
test son siempre bienvenidos,
ayudar a las propuestas,
¿no?
Hay un montón de propuestas
dentro de lo que es
el SCOOP de TS39,
documentación
y feedback con YouTube.
Aquí,
si queréis los slides,
es solo ir adelante
y mil gracias a todos
y ya está.
Bueno,
bueno,
bueno,
Rómulo,
oye,
muchas gracias
por el pedazo
de repaso
a ECMAScript.
Yo creo que mucha gente
no sabía
ni que ECMAScript
es como el recetario,
los ingredientes
para hacer JavaScript
y que
cómo no para
de evolucionar.
Es increíble
las diferentes fases,
todas las propuestas
que tenemos,
las cositas que se vienen
y mira que hay algunas
que han estado en el horno
durante mucho tiempo
como lo que le decías
lo de Temporan,
¿no?
Yo no sé,
te voy a hacer una pregunta,
no sé si te atreves.
¿Cuándo crees
que vamos a poder
trabajar con Temporal
ya en condiciones?
¿Este año,
el que viene,
2038?
¿Lo veremos?
¿No lo veremos?
Temporal está pasando
por una cosa muy compleja.
Nosotros estuvimos reunidos
con Google,
¿no?
Con Apple
y con Mozilla
desde febrero
en San Diego
y nos venían
con un problema,
¿no?
La complejidad
de la propuesta,
el tamaño
de la propuesta
para dispositivos
como Android,
por ejemplo,
y nos han dicho
si esta propuesta
va hacia adelante
o cambiáis
y optimizáis
el tamaño,
lo que mi colega
Philip Chimento
lo empezó haciendo,
pero después
han venido
y la complejidad,
porque hemos reducido
el tamaño
pero no la complejidad
y lo que estamos haciendo
es reducir el scope
con algunas partes
de calendarios,
con algunas partes
que no es que no sean necesarias
pero que entendemos
que posiblemente
no serán
tan impactantes
al usuario final
y la estamos reduciendo.
Este junio
en plenario
vamos a presentar
la versión
light de temporada
y esperemos
que sea la última
vez que presentamos
y vaya hacia adelante.
Si va hacia adelante
hay planes de implementación
nosotros mismos
queremos verlos libres
de temporada
y que sea una realidad
por eso
haremos implementar
el V8
y lo que sea.
Y otra pregunta
que tengo es
sobre los signals
porque es una de las propuestas
que ha rompido
con mucha fuerza
mucho hype
y tal
y yo sé
que a lo mejor
no debería preguntarte
estas cosas
y te meto en un lío
pero
de forma personal
¿tú cómo ves
los signals?
¿Crees?
¿Le ves oportunidades
y futuro
o lo ves complejo?
Vamos a dejarlo ahí.
Yo le veo
oportunidades y futuro
sinceramente
al día de hoy
no soy un usuario
que usa
signals
o
o hago mucho desarrollo
o no
que dependa de signals
pero me encanta
que estén ahí
pero
lo mejor
es que
que venga
TC39
no es
el contenido
de signals
es que vamos
a desarrollar
tooling
encima de signals
directamente
en DevTools
lo que
va a beneficiar
todo el mundo
porque cuando llegue
la propuesta
será algo nativo
la performance
porque cuando
mutas un árbol
de
300.000 nodos
de HTML
y no sé qué cuantos
de
tooltrees
de JavaScript
si lo haces
en JavaScript
es eficiente
pero si lo haces
usando
las capacidades
que tenemos
dentro de lo que es
la lenguaje
que se implementan
los engines
pensamos que puede
ser más eficiente
y no creo que sea
una propuesta
que vaya
a tardar
tanto
a viajar
a un estadio
que nos permita
pensar en estabilidad
Rómulo
es increíble
escucharte
es un placer
es un privilegio
tenerte
mucha gente se preguntaba
pero de dónde
de Rómulo
de dónde es
porque con ese
ese acento
y tal
y yo he dicho
es de Portugal
eres de Portugal
¿verdad Rómulo?
Sí
soy español
de nacionalidad
y brasileño
pero vivo en Portugal
ahora vives
claro
o sea vives en Portugal
era brasileño
vale vale
yo sabía que
estabas ahora viviendo
en Portugal
en Porto
pero que habéis estado
muchos años
en Barcelona
viviendo
y yo he dicho
no es porque
estamos en Barcelona
tanto tiempo
pero de nacer
naciste en Brasil
o en España
nací en Brasil
he sido creado en Portugal
junto a la frontera
por eso que he visto
muchas de las españolas
y he crecido
con la televisión española
para mí
Schwarzenegger
y Silvestre Stallone
eran españoles
hasta mis 10 años
que grande
o sea que
lo tienes todo
oye crack
pues muchísimas gracias
por pasarte
por compartir todo esto
espero y deseo
que a la gente
bueno yo la gente
lo estaba diciendo
mira dice
ese men vive
come y bebe
javascript
a la gente
le ha gustado
que crack
la gente le ha gustado
que se quede un rato más
hay gente
que se quede un rato más
que quiero saber más cosas
bueno ya lo traeremos
más adelante
Rómulo
vamos
lo secuestramos
para que nos explique
de más propuestas
porque es que
es más script
en este caso
ya veis que no para de evolucionar
y Rómulo
está ahí en todas
para enterarse
incluso
escribiendo especificaciones
que madre mía
eso también es para hablar
largo y tendido
como es escribir
una especificación
para en más script
eso ya nos explicarás
los secretos
y las salsas
que hay ahí detrás
Rómulo
un abrazo enorme
cuídate mucho
y muchos éxitos
y que te vaya genial
crack
mil gracias a todos
y que vaya todo bien
nos vemos pronto
chao crack
pues sabéis como me siento
una vez que escucho
a este pedazo
de maestro
me siento así
me siento así
que pasa
con en más script
Rómulo es un verdadero salvaje
es un crack
y me alegro mucho
que podamos escuchar
a gente de este nivel
además en español
y ver que
el impacto que tienen
en tantos
y tantos sitios
hemos podido hablar
con David East
o David Este
en español
Rómulo
en español
y es impresionante
porque muchas veces
pues vemos
el impacto
que realmente tiene
la comunidad hispanohablante
y poder disfrutar
de este nivel
de charlas
me pone muy contento
me pone muy contento