En la agenda del TC39, el TC39 es el comité que evoluciona JavaScript,
ha habido una presentación que ha hecho saltar muchas banderitas en Twitter
entre gente bastante reputada como el propio creador de JavaScript.
Y lo tenemos aquí.
No hay nada de extraño aquí.
Los implementadores ya limitaron las funciones a WebAssembly solamente.
Esto se aceleraría sin límite debido a la economía del propietario del monitor.
¿Qué es lo que se refiere aquí?
Lo que se refiere básicamente es, bueno, que cada vez más no se están haciendo
nuevas features para JavaScript, sino que se están enviando para que se hagan
más en WebAssembly, o sea, separados del motor de JavaScript, porque así lo que
estamos haciendo también es de alguna forma evitar que los navegadores sean
tan costosos, porque son muy difíciles de hacer.
O sea, cada vez es como más difícil, complicado el poder crear todo lo que
un navegador necesita para funcionar con HTML, CSS y JavaScript, ¿no?
Y básicamente es una crítica en realidad.
Lo que Brendan dice, esto es más una crítica.
No entendáis como que lo entiende, sino que es una crítica.
Y aquí viene esto.
Viene básicamente por este artículo que tendríamos aquí, que os voy a comentar.
Este artículo de Daniel Erenberg, ¿vale?
¿Qué dice Daniel al respecto?
Lo que dice Daniel es que el octubre del 2024, en el meeting del TC39, teníamos
a Shuyu Wu presentando los problemas relacionados con la evolución del lenguaje
de JavaScript, ¿vale?
Y aquí, pues, obviamente ha habido bastante polémica y aquí es lo que está hablando
y aquí comenta todo.
Obviamente, para no comentarlo todo, porque si no os voy a aburrir aquí como una
ostra, os digo, ¿no?
El problema es que cada vez JavaScript es más grande y que no es realista que vamos
a poder implementarlo todo, ¿no?
Y lo que se está hablando es tener motores de JavaScript que solo implementen una parte.
O sea, no implementen todo JavaScript.
Lo tenemos aquí, ¿vale?
En el lenguaje y la evolución.
¿Qué es lo que pasa?
Pues aquí tenemos un montón de gente.
Es como ahora funciona.
Tenemos los desarrolladores, crean TypeScript y JavaScript.
Lo pasamos por TypeScript, Babel, Webpack y tal.
Lo transforma a JavaScript.
Luego llega a los navegadores y llega a los usuarios.
¿Y cuál es el tema?
Es que JavaScript es especial.
Dice que, o sea, es más grande que cualquier otra cosa.
Tiene millones y millones de desarrolladores, miles de millones de usuarios y que encima,
además, se tienen que mantener diferentes implementaciones.
¿Cómo evolucionar este lenguaje y tal?
Pues aquí dice que queremos ayudar a los desarrolladores para que sean más productivos,
para que tengan mejor rendimiento y todo, ¿no?
Pero claro, ¿qué es lo que pasa con todo esto?
¿Qué es lo que quieren los usuarios en realidad?
Lo que quieren es seguridad, performance, estabilidad y más features de las aplicaciones.
Pero dice, según esta presentación, que el hecho es que en realidad son como dos cosas que están en tensión.
Ayudar a los desarrolladores que sean más productivos está en tensión con hacer lo que está bien para los usuarios.
O sea, que en realidad el problema es que ahora mismo estamos aquí, estamos más cerca de ayudar a los desarrolladores a ser más productivos en lugar de hacer lo que está bien para los usuarios.
En cuanto a JavaScript, no sé si estás de acuerdo, no sé si piensas así, yo solo os digo lo que dice la presentación, ¿vale?
Entonces, ¿cómo hemos llegado aquí?
Claro, ¿cómo hemos llegado aquí?
Pues dice que hemos tenido discusiones muy amplias y que al final, pues siempre hemos intentado partir de una solución, ¿no?
Y luego hay que tener en cuenta que hay nuevas sintaxis, nuevas APIs, nuevas capacidades del lenguaje, un montón de casas.
¿Y qué es lo que quieren los motores?
Quieren asegurarse la seguridad, el rendimiento y estabilidad para los usuarios.
Y dice que los navegadores van a ser más conservadores con nuevas funcionalidades del lenguaje.
O sea, que cada vez más vamos a ver que los navegadores van a intentar añadir menos funcionalidades al lenguaje.
¿Cuál es la posible solución?
Ojo, porque esta es la solución que es la preferida por Google, ¿vale?
Que no significa que todos los implementadores, o sea, Apple a lo mejor no está de acuerdo con esto, pero Google dice esto, ¿eh?
Dice, bueno, motores, quien dice motores, estamos hablando también de navegadores, ¿vale?
Porque por motores estamos hablando de V8, estamos hablando de todos los motores que utilizan básicamente en todos los navegadores,
pero TC39 casi todos son navegadores.
Por ejemplo, la gente de van no está aquí dentro, sino que van, aunque es que tampoco,
porque el motor de van también se utiliza en un navegador, que es el de Safari.
A final de cuentas, todos los navegadores, todos los motores importantes que están en TC39 están en algún navegador.
Entonces, dice que los motores van a ser conservadores y que esto no significa, obviamente, que vaya a ser,
que vaya a parar de evolucionar el lenguaje, ¿eh?
Pero bueno, vamos a ver esto.
¿Cuál es el punto que dice?
El punto es que los desarrolladores han abrazado las herramientas, ¿no?
Dice que a día de hoy TypeScript no para de subir en popularidad,
que Babel ya tiene más de 50 millones de descargas a la semana,
y mira que Babel ha dejado de evolucionar al nivel que otras herramientas con RAS.
TypeScript, el uso de TypeScript ya es mayor que el propio JavaScript
y que dice que del 55 al 99% de desarrolladores están utilizando frameworks, ¿vale?
Entonces, las herramientas existen y además se utilizan mucho.
Así que vamos a hacer un win-win con esto.
Y es que están hablando de hacer dos sabores de JavaScript.
Estandarizar JavaScript en cómo lo utiliza el ecosistema.
JavaScript 0, que sería el lenguaje de JavaScript implementado por los motores,
y JavaScript Sugar, que serían las funcionalidades que tendrían que ser compiladas
por las herramientas para que funcionen en JavaScript 0.
O sea, para nosotros como desarrolladores tendríamos JavaScript,
que sería la suma de JavaScript 0 y JavaScript Sugar.
Para los usuarios solo sería JavaScript 0,
y para las herramientas y tal tendrían que añadir JavaScript Sugar.
Los nombres son los que se han inventado,
no significa que este vaya a ser el nombre definitivo.
Pero lo que estaríamos viendo, ¿vale?
Es que van a estandarizar, o la propuesta,
es que JavaScript no evolucione tanto,
sino que tengamos un JavaScript intermedio que se tenga que compilar
para, de alguna forma, añadirle nuevas funcionalidades
sin necesidad de que sean los navegadores los que tengan,
o navegadores o los motores los que tengan que implementarlo.
Y esta sería un poco la idea, ¿no?
Los desarrolladores harían TypeScript y JavaScript Sugar con JavaScript 0.
Esto, los implementadores ahora, en lugar de ser solo los motores,
también serían TypeScript, Babel, Webpack y tal,
porque tendrían una serie de funcionalidades
que tendrían que implementar como de JavaScript Sugar
para que funcionasen en JavaScript 0.
Entonces ya vemos que lo que se está buscando,
para que entendamos,
es que ahora mismo, no estoy de acuerdo ni con lo que voy a decir,
pero para que entendamos, ¿no?
El tema es que ahora mismo,
el problema que quieren solucionar
es que la responsabilidad de las funcionalidades
de las nuevas features está aquí, ¿no?
O sea, ahora mismo, los motores,
V8, el que tiene Safari, el de Firefox y tal,
son los que tienen que estar implementando constantemente
para asegurarse que llegue aquí la funcionalidad, ¿no?
Por ejemplo, si hay un nuevo método de Array, ¿vale?
Pues aquí está la responsabilidad,
el nuevo método de Array y tal.
En realidad, no es del todo cierto
porque ya ocurre que Babel, TypeScript y tal,
ya están poniendo estas funcionalidades
y ya las transpilan.
Pero bueno, entiendo que lo que quieren es
quitarse un poquito de responsabilidad
como implementador, los motores,
y de alguna forma hacer que parte ahora sea
menos responsabilidad y ahora parte de la responsabilidad
también pase a ser aquí, ¿vale?
Esto es lo que quieren con esta propuesta, ¿no?
Dice, permitir futuras sintaxis
y características que sean,
que estén en la especificación
como JavaScript Sugar, ¿no?
Las herramientas van a contar como implementadores
con las features de JavaScript Sugar.
¿Esto qué quiere decir?
Que van a tener responsabilidad
de que realmente cumplan
con unas propuestas oficiales
que tendrán que sí o sí, de alguna forma,
tener Babel, TypeScript y tal,
para que sean compatibles, de alguna forma, ¿no?
El futuro de la API y las capacidades de las features
irían a JavaScript Zero, ¿no?
O sea, que esto, en realidad,
hay cosas que seguirían funcionando en JavaScript Zero.
Los runtimes también se contarían como implementadores
y que todavía solo habría un estándar.
Tendríamos motores que cumplen para soportar JavaScript Zero,
o sea, que tendríamos como dos versiones,
y también herramientas que soportan pasar de JavaScript Sugar
a JavaScript.
Claro, tendríamos un estándar, pero como dos certificados,
donde tendríamos el certificado de los motores
que soportan JavaScript Zero
y el certificado de las herramientas
que pueden pasar de este JavaScript futuro
al JavaScript normal.
O sea, lo que están diciendo aquí es,
para que lo entendáis,
Babel ya existe y ya hace esto, ¿no?
El tema es que, en lugar de hacer
que todas las cosas que llegan a Babel
luego también lleguen al navegador,
lo que quieren es,
oye, si Babel ya es capaz de transformarlo
a la versión que entiende el navegador,
ya no va a hacer falta
que el navegador también entienda esta sintaxis
porque ya la transforma a Babel.
Esto es lo que están diciendo, básicamente,
para que nos entendamos más o menos.
O sea, por ejemplo,
me parece una mierda enorme.
Ya, ya, a ver,
la verdad es que es una cosa bastante polémica.
Mira, los decoradores.
Los decoradores...
No sé, los decoradores se podrían utilizar.
Mira, de los decoradores.
Claro.
Un decorador, un decorador,
lo tenemos por aquí, ¿no?
Es una sintaxis que ahora mismo todavía no están en...
Pero fijaos aquí, pues, todo lo que transformamos.
Diríamos que esto de la derecha es JavaScript 0, ¿no?
Le estamos ahorrando trabajo al navegador.
¿A qué coste?
Obviamente.
Y esto sería el trabajo de...
Imaginemos que los decoradores
pasan a ser JavaScript sugar,
para que lo entendamos.
Decoradores.
Pues lo que se esperaría es que Babel te hace este trabajo
y ahora lo que va a ocurrir es que el navegador
ya no soporta los decoradores,
sino que simplemente sí que soporta JavaScript 0
y por lo tanto lo que hace es que
el trabajo de soportar decoradores está a este nivel
y los navegadores JavaScript 0.
Esto obviamente tiene algo muy importante
en el cambio de JavaScript
y es que podrías seguir utilizando JavaScript en los navegadores,
pero solo podrías utilizar la sintaxis de JavaScript 0,
el JavaScript que realmente soporta el navegador.
No podrías ya...
Hay cierta parte de JavaScript,
que es este JavaScript sugar,
que solo iría en otra parte.
O sea, esa parte,
ese set de características, sintaxis, APIs,
solo funcionarían si utilizas una herramienta,
un framework o lo que sea.
Entonces, esto también es una propuesta
que está llamando más participación de herramientas
en el TC39, por ejemplo,
pues integrar gente de Babel,
de Webpack, de Turbo Pack,
de Bit, de lo que sea.
Entonces, esta sería un poco la idea de la propuesta.
Que esta JS 0,
que sería como una capa mínima
para asegurarse que todos los navegadores
o todos los motores tienen este soporte
y a la que el JavaScript sugar se tiene que compilar.
Las features de JavaScript sugar
tienen que demostrar que se pueden debugar
mientras lo estás ejecutando con Source Maps
y que además es bastante posible
que haya funcionalidades de JavaScript sugar
que puedan moverse a JavaScript 0
si se ve claramente que son una ventaja.
O sea, dice, no se cierra la posibilidad
de que si tenemos suficiente experiencia y datos,
movamos cosas de JavaScript sugar a JavaScript 0.
Entonces, aquí dice que si es un win-win,
JavaScript sugar se enfoca en la experiencia de desarrollo,
JavaScript 0 sería la simplicidad, seguridad y performance
y esa sería un poco la idea, ¿no?
Obviamente, esto es un poco polémico, ¿vale?
Aquí hay un montón de preguntas.
Aquí lo que dice, vamos a...
Claro, la idea es con esto,
es que vamos a necesitar ahora sí casi seguro
tener algún tipo de bundling o de tool para compilar.
Como utilizamos ahora TypeScript sí o sí para compilar,
pues lo que está abriendo aquí un poco la idea sería esto, ¿no?
El hecho de decir, oye, pues claro,
vamos a necesitar tener herramientas.
Si quieres utilizar JavaScript sugar,
sí o sí vas a tener que tener alguna herramienta, ¿no?
Y es lo que dice por aquí,
como lo que pasa con CoffeeScript.
¿Qué pasa con esta propuesta?
No sé qué, no sé cuánto.
Dice, cada propuesta se va a chequear de forma individual
para ver dónde debería llegar.
O sea, hay algunas propuestas que a lo mejor
sí que pueden seguir a JavaScript 0
y otras a JavaScript sugar.
Y bueno, aquí dice que la representación de las herramientas
tiene que mejorar el TC39, que quizás se necesita otro grupo de trabajo
y a ver qué pasa con todo esto.
Y la que ha liado con esto es un tema tremendo,
porque obviamente estamos hablando después de esto
que el futuro de JavaScript está en juego o está en peligro
tal y como lo conocemos ahora mismo.
Y es que, fijaos, Null dice,
la presentación de TC39 me ha preocupado por el futuro de JavaScript
y no le gusta esta frase, ¿no?
Y empieza a chequear todo, ¿no?
Todas estas cosas, todo lo que os he ido comentando.
Pues él da su opinión.
En algunas cosas estamos de acuerdo,
en otras, pues, no estamos de acuerdo.
Pero esto es un poco la idea.
Hay cosas en las que dice, por ejemplo, en las slides,
que dice que hay cosas que han implementado en JavaScript
que no se están utilizando, como por ejemplo los Vikings.
O por ejemplo, hostia,
que se me ha calentado, se me ha calentado la cámara.
No, no, no, la batería no.
Bueno, pues nada, no puedo encender la cámara
porque se me ha sobrecalentado.
No pasa nada.
Pues nada, igualmente lo dejamos aquí.
Hostia, no sé, iré con cuidado porque se me apaga la cámara.
Así que, bueno, lo dejamos aquí.
Os dejo igualmente con esto.
Ya lo que os quería comentar os lo he comentado,
o sea que no pasa nada.