logo

midulive


Transcribed podcasts: 605
Time transcribed: 13d 3h 7m 36s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

Ahora seguiremos sorteando cositas. Vamos a ver ahora la siguiente charla, que es de un verdadero crack.
Bueno, es que a ver, solo estamos trayendo cracks, la verdad, las cosas como son.
Estamos trayendo gente de primer nivel.
Y por eso tenemos al bueno de Rómulo, Rómulo del TC39,
que nos va a explicar cómo evoluciona el lenguaje de programación JavaScript.
Cómo se va desde una propuesta hasta estar en la especificación de Mmascript.
Así que tenemos aquí a Rómulo.
¡Romu! ¿Cómo estás?
Hola, ¿qué tal?
¿Qué tal, crack? ¿Cuánto tiempo?
Es un placer estar aquí. Hola a todos.
Nunca he hablado para tanta gente, la verdad.
Me siento un poco intimidado.
¿Pero qué dices, Rómulo? Es speaker internacional.
Ha viajado, yo lo conocí en Rusia, que dimos una charla allí en Moscú,
pero ha estado en Estados Unidos, Polonia, Suecia, Finlandia.
Vamos, Rómulo, no me digas esto, Rómulo.
De paseo, de paseo.
De paseo, sí. Paseo para ti va a ser la presentación.
Bueno, pues nada, te dejo el stage para ti, ¿vale?
Para que hay 9.323 personas que están deseando escucharte.
Así que os dejo con Rómulo, que lo disfrutéis mucho.
¡Chin, chin!
Perfecto.
Bien.
Ok, bien.
Hoy hablaremos de ECMAScript, o sea, el JavaScript,
y hablaremos de la propuesta hasta la lenguaje paso a paso.
Primero, antes de todo, hola a todos de Middleconf.
Es un placer estar aquí.
Y soy Rómulo.
Podéis seguirme en las social networks.
Hago algún trabajo en TC39, ECMAS402,
pero trabajo por una compañía llamada Igalia,
donde nos enfocamos muchísimo a lo que son estándares,
a los engines, implementaciones en varios engines,
y vosotros, aplicable, estamos siempre contratando.
Vamos al grano, ¿no?
¿Qué son cuerpos de estándares o el TC39?
Bien, muy sencillo.
Un cuerpo de estándares o un standards body es una institución
o una corporación o una compañía que se dedica a estandarizar,
que es crear reglas o definir reglas para que podamos utilizar
como si fuera algo uniforme, ¿no?
Y nos facilita el que podamos después implementar nuestro código
o implementar cualquier cosa siguiendo una norma, ¿no?
Y suelo decir que son apenas un lugar donde se unifica
y uniformizan cosas, ¿no?
El caso que suelo dar es la tortilla, ¿no?
Si queremos uniformizar la receta de tortilla, lo que hacemos,
bien, intentamos pensar en alguna entidad, ECMA, Unicode,
que nos pueda uniformizar la receta de la tortilla
para que todos en casa podamos, cuando implementemos la tortilla,
la implementemos de una manera unificada,
usando la misma receta, el mismo tipo de huevo,
el mismo tipo de sartén, el tamaño, etcétera, etcétera.
Bien, es solo un lugar donde uniformiza un set de reglas
y nos permite aplicarlas.
Mucha gente piensa que el TC39 son los guardianes del JavaScript
y están muy equivocados porque apenas son la gente
que ayuda a definir lo que es la lenguaje, ¿no?
La lenguaje que todos nosotros nos gusta tanto
y que utilizamos tanto en servidor como en navegadores
y otros entornos ahora cada vez más alternativos.
Y este comité lo que hace es coger la información, feedback,
y intentar llevarlo hasta lo que son las features que conocéis,
muy conocidas, y que os hablaré dentro de nada.
Antes de empezar la charla de verdad y empezar con cómo funciona,
hay ciertas terminologías que me gustaría que tuviéramos todos en común.
El ECMA básicamente sería la entidad que estandariza el JavaScript,
o sea, es la casa que hemos escogido desde la comunidad de JavaScript
para que acoja la lenguaje y la estandarice.
El ECMA 262 es apenas el nombre del estándar en sí mismo,
o sea, porque ECMA estandarizaría la tortilla,
que podría ser ECMA 263,
como estandarizaría la lenguaje de JavaScript.
El ECMA script y el JavaScript son los productos de esta estandarización,
son la lenguaje en sí.
El JavaScript es lo que usamos por la calle, ¿no?,
que todos conocemos como JavaScript,
pero su nombre oficial sería el ECMA script.
Y el TCXX podría ser TC39, 45, 53,
dependiendo del comité técnico que trabaja para la especificación.
Para Dart sería, por ejemplo, 53,
para otros sería un número que queramos.
Teniendo esto, este conocimiento,
y teniendo esto en cuenta,
bien, ¿cómo el TC39 funciona?
Yo estoy poniendo los numeritos dentro de la presentación
porque vosotros ya lo vais a entender.
Pero primero, funcionamos con consensos.
Todo el mundo tiene que estar de acuerdo
con lo que queremos implementar
y traer al lenguaje, lo que es muy fácil.
No, es una broma, no es nada fácil.
Tener consensos dentro de una sala
con posiblemente 50 personas,
con opiniones distintas,
con intereses distintos,
es muy difícil.
Pero el objetivo del TC39
es que con los implementers,
que son gente que implementa en los engines,
con los practitioners,
que son gente que usa muchos JavaScript,
champions, que son la gente que lleva las propuestas
y ayuda a que las propuestas lleguen a Stage 4,
que idealmente sean publicadas,
intentamos no tener objeciones.
O sea, intentamos que cuando haya algún problema
hablemos mucho
y intentemos concordar y acordar
cuál es el mejor paso
para ir hacia adelante con la propuesta.
Por eso que a veces tarda muchísimo.
Y esto funciona a través de Stages.
Yo le llamo 1 más 4,
que sería el Stage 0 hasta el Stage 4.
Y cada paso tiene su criterio de entrada
y criterio de salida
y cada cupo de responsabilidades
que hay que cumplir durante estos Stages.
Teniendo esto en cuenta,
ahora, cuándo y cómo lo hacemos, ¿no?
Hay cerca de 4 o 8 reuniones
a nivel en diferentes continentes,
tanto que esta semana la reunión es en Tokio,
pero como la reunión ha sido online,
nosotros lo que hacemos es despertamos
a las 3 de la madrugada
y atendemos a la reunión
en el time zone de la reunión.
Si fuera in person,
tendríamos que posiblemente deslocarnos allí
para tener la reunión todos juntos.
Hay cerca de 4, 6, 8 reuniones.
La próxima será en España, en La Coruña,
por lo que será muy fácil
para nosotros que vivimos aquí.
Y después hay otras reuniones intermedias
que funcionan para enfocarse en propuestas,
por ejemplo, de Coreitos, Temporo,
que son mensuales,
y TG2, que es la reunión que hacemos
para enfocarnos a lo que es ECMA 402,
que es la API de internacionalización,
y otras que ya os comentaré
porque algunas son abiertas
a que todo el mundo participe.
Ahora, el proceso, ¿no?
Hemos hablado de fase 0, fase 1, fase 2.
Estamos en el Stage 3,
casi terminando la presentación,
pero aún hay bastantes cosas.
Primera parte, Stage 0, es apenas la idea.
Hemos hablado que estamos estandarizando
la receta de tortilla.
Aquí tendremos que tener una idea válida, ¿no?
Queremos una tortilla,
pero ¿de qué tamaño?
¿De qué color?
¿Qué tipo de huevo?
¿De dinosaurio?
¿De galina?
¿De qué tipo de cosa, no?
Y con esta idea,
nosotros nos acercamos a un champion
o alguien del TC39
e intentamos que esa idea pase adelante.
Bien, hay muchas ideas
que no llegan a pasar a Stage 1,
que se quedan en Stage 0
porque no cumplían quizá
todos los requisitos
para ir a Stage 1.
Por ejemplo,
queremos una tortilla
y no hemos explicado de qué
o no hemos explicado
el contenido principal
y las motivaciones para ella.
Y algunas de las propuestas
que están en esta lista
también son champions
que las pusieron aquí
y piensan un día más tarde
posiblemente pedir en Stage Advancement,
que es lo que se pide
cuando quieres progresar
y ir a otro Stage.
Stage 1.
Bien, este es cuando ya tienes una idea,
sabes que sabes la tortilla,
es de patata,
el huevo será de galina
o de crocodilo
o de dinosaurio,
sabes que medirá
entre 20 y 50 centímetros,
pero te falta saber
un poco más y concretar.
Y aquí el comité te da espacio,
tiempo, ¿no?
Para que alguien pueda usar
el tiempo del comité
que se reúne, ¿no?
Las cuatro o ocho veces al año
para poder exponer
y preguntar sobre la propuesta,
pedir feedback,
ir trabajando,
iterando sobre ella.
Y aquí podemos esperar
grandes cambios, ¿no?
Y un ejemplo de propuesta
sería la Type Annotations
que posiblemente conocéis,
que es una propuesta
que también soy uno de los champions
y es una propuesta muy sencilla.
Básicamente lo que queremos
es traer la facilidad
y acomodar tipado
dentro de lo que es el JavaScript.
Si tuvieras este código
y tuvieras un Type Checker
como TypeScript, Flow, Hegel
u otro cualquiera
que venga en futuro
y mirar este código,
podría inferir el Type
y poder mostrar el error
al usuario,
pero al navegador
le daría igual
porque todo que quepa
dentro de ese cupo
de Type
sería un comentario
para el navegador.
O sea,
no habría ninguna diferencia
para el navegador
y podrías copiar el código
de tu fichero TypeScript
prácticamente tal y cual
y ponerlo en el navegador
y el código rodaría
y se ejecutaría
de la manera tal y cual
como se ejecutaría
después de ser transpilado,
paseado
y transformado en JavaScript.
Esto sería un ejemplo
de propuesta en Stage 1.
Está en Stage 1
muchos cambios,
muchas cosas
tienen que venir hacia adelante
y aquí podríamos navegar
a Stage 2.
Stage 2 ya empieza
teniendo el tema
del aspect text
que es la especificación,
empiezas teniendo
las semánticas más definidas,
o sea,
ya sabes que es tortilla,
sabes que es patata, huevo
y tendrá 30 centímetros
y tendrá esta cantidad de sal,
tendrá esta cantidad de aceite,
la temperatura de cocción
será más o menos esta
y ya empieza siendo algo
que a futuro
muy seguro
que la gente
estará interesada en usar,
por eso
le daremos más tiempo
y empecemos a trabajar
en formalizar
todas estas APIs,
¿no?
Y esto es un caso,
por ejemplo,
de lo que es el spec text.
El spec text,
este caso,
creo que fui yo
que uno de los cambios
que hemos hecho
recientemente
en Number Format
versión 3,
que añadimos
el Format Range,
Format Range 2 Parts,
que lo que hacemos
es especificar
la receta
para que los engines,
¿no?
V8,
Spider Monkey,
JavaScript Core
pueda implementar
para que más tarde o temprano
pueda salir
en navegadores
que conocemos
y ellos se siguen
la receta
y si la receta
está muy bien definida
es muy fácil,
si no,
una tortilla sale
con más sal,
otra con más pimienta,
etcétera,
etcétera,
aún no con chorizo
como,
porque la receta
no está el perfect.
Bien,
tenemos aquí el ejemplo,
por ejemplo,
de un Stage 2
que sería
Recording Tuple,
que es traer
la inmutabilidad
a las estructuras
de datos
de JavaScript,
es una propuesta
que me encanta,
los chicos
que la están haciendo,
Robin,
Ashley
y Rick
son muy buenos,
estamos también
nosotros de Igal
implementando
en Spider Monkey,
o sea,
para Firefox
y lo que trae
es básicamente
un tipo de array,
un tipo de objeto
que son inmutables,
deep immutables,
o sea,
todo lo que hay
por dentro
son inmutables
y dos nuevas primitivas,
que serían
equiparadas
a lo que es
Number,
String
y Symbol
y esta inmutabilidad
lo que nos permite
es hacer comparación
de objetos
de Records
en Tuples
de manera
muy simplista
sin tener que hacer
todo lo que hacíamos,
iterar
y un nuevo
concepto
y estilo
de programación
que puede derivar
de lo que son
Records en Tuples
que ya existen
otras lenguas.
Stage 3,
bien,
aquí
el Complete Spec Text,
o sea,
ya tenemos que estar
casi seguros
de la receta final
de Tortilla
y lo que queremos
llevar
hacia la mesa
del cliente.
Tenemos ya
implementers
y editors
que van a revisar
toda la spec
para ver si ya está
todo correcto
y después empezamos
a este
Coverage
Test 262
que son
los tests,
digamos,
unitarios
a la spec
que respetan
la spec
y van
ejecutando
esos tests
dentro
de lo que son
los engines
y algún navegador
ya empieza
a implementar
y aquí sería
por ejemplo
lo que puedes ver
en un
Test Report
que ejecuta
los tests
contra un engine
y después
va mirando
los que cumplen
con la especificación,
los que no cumplen,
los cambios
que hay que hacer,
recientemente,
por ejemplo,
ayer por la noche
o hoy por la mañana
hemos puesto
algunos cambios
en Ember Format V3
porque estamos partiendo
digamos
la compatibilidad
con la internet
y un ejemplo
de propuesta
de Stage 3
es Temporal
que no me canso
de venderla
porque es
la mejor propuesta
que hay
que nos trae
el Moment.js,
el Date.fns
y todas las librerías
de fechas
y de tiempos
en uno
y dentro del navegador
internacionalizada
con calendarios,
time zones,
todo disponible
en el navegador.
Esto es
lo que esperamos
hace muchísimos años
y es una
de las mejores propuestas
pero más complejas
a la vez
que hay
en el momento
de la lenguaje.
¿Cuándo llegamos
a Stage 4?
Bien,
es cuando tenemos
todo lo que hemos hablado
resuelto,
el Spec Text
es mergeado
a la rama principal
de Test 262
o de ECMA
402,
hay dos implementaciones
que entran
ya en release
en algún navegador
en Safari,
en Firefox
o Chrome
o Edge
y después
ya es incluida
en la próxima
salida
digamos
de ECMA Script
2020
y algo,
¿no?
Y un ejemplo
es el Top Level
I Wait.
No voy a explicar mucho
porque al final
es algo
que parece súper sencillo
pero por detrás
hay una complejidad
absurda,
¿no?
aquí porque al final
son dependency graphs
cómo tratan
un poco los datos
pero bien,
nos permite usar
el Await
fuera de un bloque
async
lo que es súper útil
y muy bueno
para todos nosotros,
¿no?
Y así
cuando llegamos
a Stage 4
tenemos aquí
un montón
de cosas
que sale este año
el HasOn,
el ClassFields,
Private Instance,
etcétera
que mi colega Joey
que también
ha participado,
la verdad
que ha sido
la persona
que ha implementado,
el HasOn
que es muy útil
y muchas otras
que son muy guays
y vosotros
normalmente por junio
es cuando sale
el ECMAScript
este año ya
ha salido el libro
que hay en formato PDF
pero hay en formato HTML
y bien,
todo que esté en Stage 4
a partir de junio
va a salir
el año que viene
en ECMAScript 2023
podéis usar ya
algunas features
en TypeScript
o Babel
transpilando
o transformando
el código
y bien,
la última parte
es cómo colaborar
y get involved
es muy sencillo
escribir tests
participar
en los GitHub issues
la mayoría
de las cosas
es todo pública
aquí tenéis
un enlace
a un gist
con algunos links
que os paso
hay calls mensuales
para educators
para tools
para frameworks
las que podéis participar
y bien
aquí también
tenéis los links
para los slides
si queréis
de alguna manera
también
hay un
cuestionario
para valorar un poquito
y para feedback
y bien
es esto
y muchas gracias
por tenerme aquí
creo que hemos hecho
los 15 minutos clavados
pues muy bien
lo has clavado
directamente
Romulo
ha sido del palo
pam
aquí
15 minutos
lo tenías bien preparado
Romulo
oye
mucha gente está
diciendo
que le estaban cantando
que bien pinta
lo que se viene
en javascript
yo tengo una pregunta
para ti Romulo
bueno
espera
que te han muteado
que te has muteado
no no
estoy aquí
estoy aquí
ah vale
digo
a ver si
no se te va a escuchar
el tema es
¿cuál es tu favorita
de todas?
que digas
ostras
esta es la que va a marcar
la diferencia en javascript
esto va a ser una locura
type annotations
porque soy uno de los champions
para mí
es mi favorita
en este momento
pero hay muchas
me encantan todas
de inter
de internacionalización
porque también
estoy muy involucrado
y empecé en tc39
ahí
por eso
todo que venga de intel
duration format
number format
list format
relative time format
todo esto que podamos usar
para hacer nuestros sites
más asequibles
a nivel de internacionalización
son mis favoritas
pero hay algunas nuevas
que son de flipar
hoy va a ser presentada una
que no puedo hablar mucho
que posiblemente
stage 1
que también puede ser
muy muy chula
pero hay muchas cosas
change rate by copy
que también es muy buena
un montón
pero como que no puedes hablar mucho
pero si
pero porque no puedes hablar
si eso se supone que es de código abierto
Romulo
no queremos información
no no es que no pueda hablar
es que
no quiero dar mala suerte
para la presentación
porque la van a presentar
hoy de madrugada
para stage 1
y quiero que vaya todo bien
más que nada
para no dar mala suerte
vale vale
será algo que hablaremos
creo
decía por aquí alguien
que
pero si no
a ver para 2040 javascript
porque es que en esta conferencia
hemos tenido a Freddy Vega
de Platzi
y una de las frases
ha dejado muchas frases
y una de las frases
es que ha dicho
pero que más da
si en 2040
ya no estaremos desarrollando
con javascript
Romulo
2040
nos veremos tú y yo
hablando de javascript o no
yo creo que sí
hay mucho espectrum
de trabajo paralelo
¿no?
muy enfocado por ejemplo
a todo lo que es
WASM
transpilación
compilación de código
formateo
de
formateo no
pero
pero conversión de código
a
low level code
que
que será
algo
muy bueno
pero creo que el javascript
seguirá existiendo
quizás no
como lo conocemos
pero diferente
por lo menos yo creo que estaré aquí
si no
ya nos pasaremos a otra cosa
pero creo que estaremos aquí
vale pues amigos
vamos a sortear
mira vamos a dejar a Romulo por aquí
mientras
que se quede con nosotros