Panel Discussion: The Future of JavaScript

Hola a todos. Somos todos delegados de TC39. Y si no estás familiarizado, TC39 es el comité de estándares que efectivamente hace tu lenguaje de programación favorito, JavaScript. Pero legalmente, tenemos que llamarlo ECMAScript.

Dato curioso. Soy Maggie Johnson-Pinn. Trabajo para Microsoft. Soy una PM en el equipo de Azure SDK. También he sido una participante activa en TC39 a lo largo de los años. Más notablemente, originalmente traje la propuesta temporal. Así es como terminé involucrada. Fui mantenedora de Moment.

js. Necesitábamos algo diferente a eso. Así que el equipo de Moment decidió involucrarse en TC39. Voy a hacer que todos se presenten. Y voy a hacer que todos digan su propuesta favorita próxima. Así que ya hice mi presentación. Notaré, porque no puedes, ya sabes, como impulsar tu propia propuesta, que voy a elegir registros y tuplas como mi propuesta favorita próxima. Eso proviene de mi historia con DateTime. Muchas veces necesitábamos construcciones inmutables. Veamos.

¿Con quién iré a continuación? Rick, ¿quieres ir tú a continuación? Sí, claro. Así que, como ella dijo, mi nombre es Rick Button. Trabajo para Bloomberg en infraestructura de software, específicamente trabajando en nuestra pila de JavaScript. He estado con TC39 durante aproximadamente dos años, creo. Eso suena correcto. Terminé involucrado en TC39 debido a registros y tuplas. Mi compañero de trabajo y co-campeón Robin Ricard se le ocurrió esta idea loca y trabajó internamente en ello por un tiempo, y luego unimos fuerzas para trabajar en ello. Sí.

Hola a todos. Todos somos delegados de TC39. Y si no estás familiarizado, TC39 es el comité de estándares que efectivamente crea tu lenguaje de programación favorito, JavaScript. Pero legalmente, tenemos que llamarlo ECMAScript. Dato curioso. Soy Maggie Johnson-Pinn. Trabajo para Microsoft. Soy PM en el equipo de Azure SDK. También he sido un participante activo en TC39 a lo largo de los años. Más notablemente, originalmente traje la propuesta temporal. Así es como terminé involucrada. Fui mantenedora de Moment.js. Necesitábamos algo diferente a eso. Así que el equipo de Moment decidió involucrarse en TC39. Voy a hacer que todos se presenten. Y voy a hacer que todos digan su propuesta favorita próxima. Así que ya hice mi presentación. Notaré, porque no puedes, ya sabes, como promover tu propia propuesta, que voy a elegir registros y tuplas como mi propuesta favorita próxima. Eso proviene de mi historia con DateTime. Muchas veces necesitábamos construcciones inmutables.

Veamos. ¿Con quién iré a continuación? Rick, ¿quieres ir tú a continuación? Sí, claro. Así que como ella dijo, mi nombre es Rick Button. Trabajo para Bloomberg en infraestructura de software, específicamente trabajando en nuestra pila de JavaScript. He estado con TC39 durante aproximadamente dos años, creo. Eso suena correcto. Terminé involucrado en TC39 debido a registros y tuplas. Mi compañero de trabajo y co-campeón Robin Ricard se le ocurrió esta idea loca y trabajó internamente en ello por un tiempo, y luego unimos fuerzas para trabajar en ello. Sí. Y como ella dijo, mencionar tus propias propuestas, es un poco como llevar la camiseta de tu banda favorita en su concierto.

Estoy muy emocionado por ello. Creo que el siguiente es probablemente Hemant. Gracias, Rick. Soy Hemant. Trabajo en PayPal como miembro del personal técnico y, ¿cómo llegué a TC39? Bueno, lo he estado siguiendo durante bastante tiempo, 2008, 2009 y he estado molestando a Yarden mucho. Y en ese momento, cuando me uní a PayPal, no pude asistir al comité porque era en persona y estaba en una zona horaria diferente y todo eso. Y luego, sucedió que me mudé aquí hace un par de años y entré en el comité con un apoyo increíble y todo eso de los miembros del comité y personas súper inteligentes y hoy estoy trabajando en algunas propuestas como string.

bdint o error causado y array equality y lagos. Y quería decir que mi propuesta favorita eran registros en QPL y la segunda era pattern matching, pero ahora ambas están cubiertas y definitivamente temporal MAGI cubrió eso también. Así que probablemente iría con esta propuesta llamada aplicaciones parciales que probablemente no muchos de ellos habrían escuchado, lo que definitivamente haría que la programación funcional sintaxis fuera un poco más interesante en JavaScript. Con eso, me gustaría pasar a Jordan. Hola, soy Jordan. Trabajo en Coinbase. He mantenido cientos de proyectos de código abierto y he estado en TC39 desde 2014. Ha pasado mucho tiempo. Y fui editor de la especificación durante aproximadamente tres años. Así que, veamos, mi propuesta favorita.

No mencionaré las que ya se han mencionado y no mencionaré la mía. Creo que realmente me gustan las do expressions y las async do expressions. Esas son dos propuestas separadas, pero las estoy agrupando.

Así que, mi propuesta favorita próxima es definitivamente, probablemente coincidencia de patrones. Es, realmente soy un fan del estilo expresivo de lenguajes de programación funcionales tipo Lispy. Así que un día sucederá. Estoy muy emocionado por ello. Creo que el siguiente es probablemente Hemant.

Gracias, Rick. Soy Hemant. Trabajo en PayPal como miembro del personal técnico y, ¿cómo llegué a TC39? Bueno, lo he estado siguiendo durante bastante tiempo, 2008, 2009 y he estado molestando a Yarden mucho. Y en ese momento, cuando me uní a PayPal, no pude asistir al comité porque era en persona y estaba en una zona horaria diferente y todo eso.

Y luego, casualmente, me mudé aquí hace un par de años y me uní al comité con un apoyo increíble y todo eso de los miembros del comité y personas súper inteligentes y hoy estoy trabajando en algunas propuestas como string.bdint o error causado y igualdad de arreglos y lagos. Y quería decir que mi propuesta favorita eran registros en QPL y la segunda era coincidencia de patrones, pero ahora ambas están cubiertas y definitivamente temporal MAGI cubrió eso también. Así que probablemente iría con esta propuesta llamada aplicaciones parciales que probablemente no muchos de ellos habrían escuchado, lo que definitivamente haría que la sintaxis de programación funcional fuera un poco más interesante en JavaScript. Con eso, me gustaría etiquetar a Jordan.

Simplemente, hay muchos lugares donde es conveniente usar algunas declaraciones en posición de expresión. Estoy ansioso por la simplicidad de poder hacer eso.

Hoy vamos a estar un poco sin moderación. Nos haremos preguntas unos a otros solo por diversión. Así que comenzaré con la primera pregunta. La primera pregunta va a ser para Jordan y es una grande. Y es esta pregunta de por qué. ¿Por qué es importante estandarizar JavaScript? ¿Cómo es el proceso? ¿Cómo ocurre una propuesta? ¿Cómo sé cuándo viene una propuesta? ¿Cómo funciona toda esta máquina, Jordan? Sí. Está bien.

Bueno, ¿por qué importa? Bueno, estandarizar cualquier cosa importa en el sentido de que asegura que todos estamos haciendo las cosas de la misma manera y todos podemos hablar el mismo, ya sabes, sin doble sentido, hablar el mismo idioma sobre lo que sea que se esté estandarizando. Así que JavaScript tiene esta arruga adicional que se ejecuta en los navegadores web que todos usamos, como, todo el tiempo, ya sabes, para hacer todo. Así que se vuelve realmente importante que tú puedas escribir un sitio web de una manera que todos puedan usar de la misma. Así que todo lo que se estandariza es una cosa menos de la que tienes que preocuparte mientras despliegas a un número infinito de dispositivos que no controlas en todo el mundo. Así que en cuanto a cómo es el proceso, eso puede variar ampliamente. Puede ser divertido.

Puede ser tortuoso. Puede ser muy pedante. Sabes, creo que hay momentos en que se necesita un tipo especial de personalidad para no salir corriendo de la habitación. Y, pero dicho eso, realmente disfruto. Creo que ha sido muy esclarecedor considerar muchas perspectivas y casos de uso diferentes, más allá de los que normalmente habría considerado, al intentar diseñar características para lenguajes. Y ha modificado y templado mis opiniones sobre las cosas mucho a lo largo de los años. Cuando llegué por primera vez, estaba un poco esperando, como, entrar y odiar un montón de cosas. Y resulta que, como, cuando entiendo las razones por las que las cosas son como son, que es mucho. Puedo sortearlo, en lugar de simplemente quejarme de algo que no me gusta. En cuanto a cómo se termina una propuesta, ¿verdad? Después de ES2015 o ES6, añadimos un nuevo proceso de etapas. Así que hay etapas de cero a cuatro. La forma rápida y sucia en que las describo es que la etapa cero es, como, tengo una idea loca. La etapa uno es que tal vez la idea no sea tan loca, ¿verdad? Ahí es cuando el comité ha dicho, como, sí, queremos pasar más tiempo investigando el problema. ¿Cómo resolvemos el problema que estamos mirando?

Y luego, más o menos, afinamos todos los detalles dentro de la etapa dos. Y luego la etapa tres es el momento para que todos comiencen a implementarlo y enviarlo.

Y en ese punto, generalmente solo esperas cambios cuando no podrías haber anticipado algo antes del momento en que lo envías. Y luego la etapa cuatro es como la misión cumplida. Es cuando realmente lo fusionas en la especificación y se vuelve oficial.

Y en cuanto a cómo sabes cuándo vienen las propuestas, hay muchos lugares donde puedes mirar. Ciertamente podrías leer las notas de cada reunión, que son largas y muy arcaicas. O no arcaicas, oscuras. Pero puedes leer esas que se publican aproximadamente 10 días después de cada reunión. Pero también tenemos el repositorio de propuestas en GitHub, TC39/proposals. Y eso se actualiza típicamente durante la reunión. Así que puedes navegar por la lista de propuestas en cada etapa. Y cada una enlazará a su propio repositorio donde puedes hacer preguntas o leer sobre la propuesta. OK, bueno, así que la siguiente pregunta, en realidad se la voy a hacer a Maggie de nuevo. ¿Cómo puede una persona hacer un caso de negocio para que su organización se involucre con TC39 y otros estándares web? Claro. Así que hay una especie de pregunta subyacente allí, por supuesto, que es cómo se involucra cualquiera con TC39 y estándares web. Y vale la pena señalar que oficialmente, para participar en el proceso de TC39, necesitas estar con una empresa miembro de ACMA. Así que ACMA es esta organización de estándares o estándares internacionales. ACMA estandariza muchas cosas, no solo JavaScript. Hay un montón de estándares de IoT, estándares de dispositivos portátiles.

Hay muchas cosas en ACMA. Y técnicamente, para participar en TC39, serías un delegado de una organización miembro. Así que Microsoft es una organización miembro de TC39. Y hay una tarifa de membresía. Así que lo que se reduce es que si tú quieres ser un delegado oficial, necesitas que tu organización decida que esto vale la pena para ellos. Creo que es interesante. Obviamente, en Microsoft, donde tenemos un navegador y TypeScript y cosas, tenemos un caso de negocio bastante fuerte para involucrarnos en TC39. Pero muchas organizaciones se han involucrado. Y creo que se reduce a encontrar lo que realmente importa. Cuando traje por primera vez Temporal, no me di cuenta de cuánto apoyo recibiría de Bloomberg, que acaba de unirse a ECMA.

y algunos años hay muy pocas cosas que están en ello. Es más, lo que he encontrado más útil de ello es que tratamos la especificación como un estándar vivo ahora. Así que la especificación que se muestra en GitHub y en el sitio web de TC39.es, como esa es la última versión del estándar y la instantánea anual ya no es particularmente útil. Es necesario para la forma en que opera ECMA y es necesario, algunas herramientas y libros y cosas como referirse a un año de edición específico. Pero los navegadores no implementan realmente características en bloques de un año a la vez. Así que puede haber algunos navegadores o motores que tienen características de ES2019 pero les falta una característica de ES2016. Así que el año realmente no te ayuda demasiado, es solo una especie de nota histórica de cuándo terminó el proceso. Así que creo que el...

Creo que uno de los mayores desafíos es ¿cuándo decimos que no? Hay muchas personas en la sala en la reunión de CS39 y todos tienen prioridades y filosofías ligeramente diferentes sobre las cosas. Algunas personas son muy entusiastas sobre agregar cosas al lenguaje, mejorar el lenguaje, ¿verdad? Y ese es un objetivo admirable. Pero creo que hay otras personas que están más preocupadas por prevenir algo que pensaríamos que es un error en unos años que luego tenemos que soportar durante los próximos 50. Una frase que he escuchado mucho con el tiempo es el futuro es más largo que el pasado.

Básicamente, cualquier decisión que enviemos en JavaScript es permanente. Y así que para mí, al menos, creo que es muy importante que seamos cautelosos. Y que aunque es genial que podamos tener un, que podamos mover las cosas a través del proceso de propuesta rápidamente cuando parecen ser la elección apropiada, creo que tenemos que hacerlo de una manera medida y cuidadosa para asegurarnos de que no estamos, ya sabes, cometiendo un error que no podemos deshacer. Genial. Bien, creo que eso fue... Así que para la siguiente pregunta, le voy a preguntar a Rick. ¿Cuáles son algunos de tus recursos favoritos para compartir con otros que quieren aprender más sobre la estandarización? Sí, está bien. Así que esta es una pregunta un poco compleja y te daré, espero, una respuesta menos compleja porque la estandarización es esta extraña bestia donde no es realmente programación en un sentido. Es más como ser un abogado, pero tienes que tener un trasfondo en programación primero. Así que es un poco raro. Y voy a mencionar un montón de enlaces que publicaré en el canal de Discord de Q&A después de que terminemos aquí, o después de que termine con esto, respondiendo a esta pregunta. Así que no sientas que tienes que escribir todo esto. Pero hay muchos recursos. El beneficio de que trabajemos en el lenguaje que ejecuta la web es que ponemos mucha de esta información en la web. Así que supongo que la primera parte es solo la especificación en sí. Así que la especificación, tal como mencionó Jordan, es una especie de especificación de película viva. Está alojada en internet. Así que puedes ir a tc39.es.

y cuál es el resultado entregable es un poco extraño. Así que además de eso, hay una fantástica serie de publicaciones en el blog escritas por Marcia en el equipo de V8. También enlazaré esto, llamado Entendiendo ECMAScript. Está escrito en cuatro partes, y detalla cómo se escribe la especificación y lo que realmente significan las complejidades de la especificación. Así que creo que eso es un nivel superior a leer la especificación en sí, es leer la especificación en sí desde la perspectiva de alguien que definitivamente es un experto en la especificación y trabaja en V8. Ese es un recurso realmente bueno. Otra cosa, si eres un poco más orientado al código y solo quieres visualizar cómo funcionan los métodos del prototipo de array en la especificación, pero en código, puedes mirar algo como Engine 2.

6.2. Engine 2.6.2 es efectivamente, es un proyecto de código abierto escrito por un miembro de la comunidad slash Delegado de TC39, dev-snick, que es esencialmente una implementación de JavaScript en JavaScript. Y está bastante cerca de la especificación. Si miras, por ejemplo, el código de V8 o Firefox, el código que implementa todos los estándares no necesariamente siempre, no se ve igual que la especificación. La especificación es como la parte del abogado. La implementación es como la forma en que realmente, las palas, la forma en que hacemos las cosas.

Engine 262 le gusta parecerse a la parte del abogado. Así que es una muy buena manera de simplemente recorrer un fragmento de código y decir, oh, así es como implementarías esto si lo escribieras en código. Así que esas son algunas de las cosas introductorias sobre cómo se ve el entregable en sí, pero hay mucha historia en JavaScript y hay mucho de que está vivo, siempre está en movimiento y es el lenguaje más popular del planeta. Así que una de las cosas que salió recientemente que me encanta compartir con la gente es en realidad este documento escrito por Alain Westbrock y Brendan Eich llamado La Historia de JavaScript Los Primeros 20 Años, y también enlazaré esto. Y es un recurso fantástico para la evolución de JavaScript porque a diferencia de un lenguaje que podrías diseñar en una clase de lenguaje o como un grado de PL o simplemente desde primeros principios, JavaScript tiene mucho legado. Y como mencionó Jordan, la web no se rompe. Al menos ese es nuestro objetivo. Así que para entender muchas de las decisiones en torno al diseño de JavaScript, tienes que entender un poco toda la historia y entender de A a B a Z, qué exactamente sucedió y por qué se tomaron decisiones. Y aclara mucho de cómo pensamos sobre la estandarización a lo largo del tiempo y cómo tratamos de poner un paraguas sobre la historia para proporcionar a las personas un buen lenguaje para usar. Tengo un par de cosas más. Tenemos, si estás interesado en cómo opera TC39 específicamente, tenemos el repositorio cómo trabajamos.

Así que TC39 opera este repositorio que intenta documentar todos nuestros procesos tanto como sea posible desde cómo llevamos a cabo la plenaria y cuáles son las discusiones reales que tenemos, cómo documentamos las propuestas, qué hacen, como más detalles sobre lo que significan las etapas, cosas así. Así que ese es un recurso realmente bueno si solo estás interesado en más sobre las cosas legales.

Y luego mencionamos esto antes que las notas de las reuniones son muy importantes. Cuando empecé y yo, como el día después de que fui a mi primera reunión de TC39, lo primero que hice fue buscar todas las propuestas que amaba y luego averiguar en la agenda, que también publicamos, que también publica un enlace a cuándo se habló de eso. Y luego revisé las notas y leí las discusiones y no leí todo de manera literal. Hay muchas notas. Algunas de las notas de las discusiones de TC39 son como de 40 páginas de largo. Pero si solo lo aislas a una sola propuesta puedes obtener una buena idea de cómo se ve esa discusión. Y hay una cantidad increíble de discusión que ocurre a lo largo de todo el espectro del lenguaje en términos de cómo las características interactuarán con otras características y cómo la complejidad de implementación de una característica podría afectar las decisiones de diseño que si solo miras el estándar en sí podrías no capturar. Así que es realmente importante capturar esa discusión en sí también. Así que hay muchos enlaces. Publicaré todos estos en el canal de Discord para que podamos tener enlaces a ellos. Pero eso es un poco como, si quieres aprender sobre estandarización internet es la solución y te daré tantos enlaces como sea posible. Así que eso es un poco eso. Si entiendo, debería pasarlo a Hemanth porque tengo una pregunta para ti que es ¿cómo probamos las características antes de que se lancen? Gracias, Bing. Así que ¿cómo probamos las características o más bien usamos características antes de que se lancen? Bueno, hay muchas maneras.

Lo primero es que la mayoría de las propuestas probablemente vendrán con un plugin de Babel o un Polyfill. Así que consulta su repositorio si tienen un Polyfill o un plugin de Babel. Bueno, no es realmente parte del proceso pero la mayoría de las propuestas que son Polyfillable tienden a tener Polyfills. Y luego cuando llega a la etapa tres y cuando busca comentarios de los desarrolladores, normalmente estará bajo un flag que puede ser donde se implementa en un navegador o node y similares. Así que normalmente tiendo a usar JS Fu, uno de los módulos de node que te ayudará a obtener todos los motores de tiempo de ejecución tal vez como V8 o SpiderMonkey, Rhino y V8-T-Bug y similares. Así que obtendría todos ellos y me prepararía para un HarmonyFlags. Ahí es donde normalmente las características que buscan comentarios estarán implementadas bajo el flag. Ejecutaría esos motores con los HarmonyFlags y trataría de experimentar con ello. Y algunas de las propuestas también tienen masterclasses como Temporal o Rekords Incubatables tienen buenas masterclasses donde ya han polyfilled las cosas requeridas y tienen buenos ejemplos sobre cómo funciona el código, de qué se trata la característica, buenos ejemplos de código y puedes ir y probar eso y obtener una comprensión. Si quieres profundizar un poco más, podrías abrir la especificación y ver la solicitud de extracción que se realizó para los cambios en la especificación y ver cómo es la especificación existente y cómo esta propuesta está cambiando la especificación existente. Así que obtendrás algunos detalles sobre cuáles son los cambios que se realizaron en la característica.

Así que si no, no estás en un estado para simplemente usarlo y probarlo. Tendrás una idea de cómo sería la característica y cuáles son todos los, probablemente en sintaxis o los cambios que esta propuesta está trayendo.

Así que esa es una de las maneras en que podrías manejarlo. La otra manera es que vas y lees la especificación y tratas de analizar.

Puede que no realmente entiendas si no estás en la lectura de especificaciones. Y yo y uno de mis amigos estamos llevando a cabo el espectáculo llamado Read the Spec with Us donde estamos leyendo partes de la especificación y tratando de traducirlo a código. Como mencionó Rick, hay una prueba, un 262 que tendría las implementaciones de prueba de estas propuestas, que es parte del proceso donde deberías tener estas pruebas para que puedas ir a la prueba, ver las diferentes variaciones para que cubra todo el espectro. Puedes entender cómo funciona. Así que hay muchas maneras diferentes, pero también veo que hay un pequeño inconveniente aquí a veces cuando ya hay un calificador que está ahí la gente comienza a usarlo y la especificación cambia un poco pero el plugin no está alcanzando la especificación. O por ejemplo, los decoradores son un ejemplo de eso donde TypeScript ha implementado una versión particular de decoradores pero la especificación ha cambiado mucho desde allí y hay un poco de actualización que necesita suceder.

Y Babel dejó claro que, hey, estas son propuestas en etapa así que deberías tener mucho cuidado sobre cómo las estás usando y no realmente listas para producción y las cosas pueden cambiar y romperse. Así que siempre hay dos caras, como la cara de una moneda. Como, tienes los pros y los contras pero definitivamente podrías explorar de muchas maneras y siguiendo el repositorio de propuestas, mirando los problemas te dará más información. Con eso, se lo devolveré a Rick con mi pregunta sobre, creo que Rick cubrió la mayor parte de ello pero tenía esta pregunta sobre el pipeline que ¿cómo contribuyo con TD39? Como, cuando hablo en un foro público esta es la pregunta común que me hacen, decir que tengo una idea o tengo una idea para una propuesta y quiero llevarla al comité o ¿dónde está el punto de entrada? ¿Cómo empiezo? Sí. Así que esta también es una pregunta interesante. Depende de si eres, bueno, depende de muchas cosas. Hemos tocado muchas de estas cosas a lo largo del panel. Una de las maneras más inmediatas y directas es si tu empresa ya es miembro de TC39 entonces contacta a las personas internamente quienes son esos delegados. Nosotros, sabes, averiguamos eso y luego contribuimos de esa manera. Esa es la opción más directa o como se mencionó anteriormente, convence a tu empresa para unirse a ECMA lo cual es muy beneficioso tanto para ECMA, TC39 para obtener más aportes de más partes interesadas y beneficioso para la empresa porque puedes ayudar a que el lenguaje crezca. Luego puedes contribuir de esa manera. También hay cada propuesta tiene su propio repositorio de GitHub al que puedes publicar. Puedes abrir problemas, puedes leer la documentación. Para cada propuesta, al menos el formato estándar, esto no es técnicamente requerido, pero la mayoría de las propuestas junto con la diferencia de especificación que realmente cambia la especificación, hay un gran explicador. Sé que una de las propuestas en las que trabajo, Rekord y Tuple, tiene un enorme explicador que pasa por, en detalle, muchas de las decisiones de diseño. Y si estás interesado en contribuir, el primer paso es leer ese explicador en su totalidad y luego generar tus propias ideas sobre cómo debería funcionar, y luego puedes abrir problemas. Muchas personas abren problemas en esos repositorios para hacer preguntas o para obtener aclaraciones sobre ciertas partes del diseño o para sugerir alternativas. Hay una gran cantidad de problemas en la mayoría de las propuestas, y animo a todos a participar en eso porque la gente responderá. Sabes, hay muchas personas realmente inteligentes trabajando en estas propuestas que hablan con la gente todo el día por trabajo. Así que ciertamente es una manera de involucrarse con la comunidad. Fuera de GitHub mismo y fuera de las propuestas, en la tierra más experimental, hay nuestro discourse, que es nuestro foro de alguna manera.

Así que es realmente importante que escuchemos de tantas personas como sea posible. {{^}}Así que es realmente importante que ese esfuerzo sea de bajo fricción.

Así que eso es todo. Sí, así que nos hemos quedado sin preguntas preparadas. Así que lo que voy a hacer ahora es improvisar. ¿Tenemos en Discord, tenemos? Sí, solo iba a mencionar uno. Veamos, la primera que pensé fue una buena pregunta sobre la carga de implementación, que no, cualquiera puede responder esto. Solo lo mencionaré en voz alta. Metin en Discord pregunta, ¿podríamos tener un JS2 principal para que podamos tener dos versiones de JS? ¿Es eso una solución a nuestros problemas? ¿Alguien quiere tomar eso? Claro, eso definitivamente no es una solución. Esto se ha intentado de alguna manera en el pasado. Firefox solía enviar un, solían enviar dos tipos diferentes de JavaScript. Solían enviar el estándar que conocemos en la web y luego uno específico de Mozilla que tenía algunas extensiones. Así que hay sintaxis para cada uno y algunas cosas y tenían let y const muchos años antes de que ES 2015 lo hiciera. Se comportaba un poco diferente. Pero, mi entendimiento es que esto hizo que fuera realmente difícil para las páginas web porque si digamos que hay dos versiones de JavaScript, el navegador aún tiene que enviar ambas versiones para siempre. Y puede hacer que sea realmente difícil compartir código entre esos entornos. Si escribo, como, digamos que era jQuery, ¿puedes usar jQuery? ¿Podrías usar jQuery en ambas versiones de JavaScript? La única manera de que eso sea el caso es si jQuery hiciera dos copias de sí mismo, una para cada uno, o si hubiera una manera interoperable compatible hacia atrás de escribir jQuery. Y así termina que la mayoría de las cosas termina siendo lo que sea la forma interoperable. Y, sabes, lo que significa que terminas teniendo solo el mismo lenguaje básico que tenemos ahora, y aún estás atrapado y restringido por decisiones anteriores. Así que, hay un tipo similar de, así que la respuesta general que he escuchado es que nadie quiere hacer versionado más. Y de manera similar cuando ES5 agregó modo estricto, como un pragma, para intentar arreglar algunas cosas sobre el lenguaje, las correcciones son buenas. A todos les gustan las mejoras, pero la reacción general dentro de TC39 es no más modos, no más pragmas.

Que hacer esto de esta manera fue, sabes, no necesariamente un error, pero tampoco es algo que nadie quiera repetir. Eso magnifica el número de permutaciones con las que todos tienen que lidiar, y hace que el lenguaje sea más confuso y más difícil de construir a largo plazo.

¿Puedo añadir un comentario sobre- No tengo más pensamientos, adelante. Solo para comentar sobre las interrupciones, sabes, estabas hablando de, no nos gustan los pragmas, usar estricto fue útil, pero de alguna manera rompió las cosas, rompió hacia atrás y hacia adelante de alguna manera. Creo que fue realmente interesante para mí con TC39, me tomó un tiempo después de que comencé a asistir para entender algo que dijo Rick, que es que es el lenguaje de programación de todos. Nadie va a romper un sitio web de 1995. Puedes pensar que no importa, pero puede importar profundamente al pequeño propietario de un negocio que no puede permitirse que se rehaga. ¿Verdad? Como vamos a intentar dar continuidad de una manera que es inesperada. Si estás acostumbrado a ser un desarrollador de software en una organización que pensaría, Oh, bueno, todo el código se reemplaza en un arco de cinco años de todos modos, ¿verdad? Has oído a la gente decir eso sobre el software, pero simplemente no es, no es el lugar mental. Solo imagina, como, incluso si fueras como, no sé, he recogido un, sabes, Super Nintendo y he intentado volver a jugar viejos juegos de vez en cuando. ¿Qué pasaría si quisieras buscar una guía para superar una parte difícil, y esa guía estaba en un sitio web que no se ha actualizado en 25 años? Sabes, sería realmente decepcionante si eso no funcionara porque alguien quería alguna nueva característica del navegador. Sabes, hay muchas maneras, creo, de hacer lo que todos están hablando y encontrar una razón para ti mismo que te ayude a entender por qué es, de hecho, el lenguaje de programación de todos y por qué realmente no quieres que un grupo de, sabes, un número relativamente pequeño de personas en una habitación tome una decisión que excluya algo porque ¿qué te detiene de ser excluido? Rick, estás en silencio. Me disculpo. Solo iba a decir que, como, no para seguir con esto, para seguir, algo más en lo que pensar, lo mencionamos un par de veces, es que JavaScript es un estándar vivo. Si alguien lanza una nueva versión de un lenguaje, como un nuevo entorno de ejecución, como Python o algo así, que rompe muchas cosas, simplemente puedes no actualizar. Quiero decir, eventualmente te quedarás sin actualizaciones de seguridad, pero, como, no tiene un impacto tan grande, pero si rompemos la web y todos los Chrome se actualizan y ahora el sitio web no funciona, eso es un negativo inmediato.

Hemant, creo que ibas a decir algo. Sí, estaba tratando de recoger otra pregunta en Discord, pero parece que estamos justo a tiempo. En realidad, te quedan cinco minutos. Oh, ¿es así? Está bien. Así que hay muchas preguntas en el grupo. Así que probablemente elegiré una al azar que podamos responder rápidamente. ¿Cómo es ser un asociado público con TC39? ¿Te presionan en línea para agregar la característica favorita de alguien? ¿O ves a personas quejándose del lenguaje contigo? Sí. Así que es una pregunta divertida. Diría que no es que estemos siendo presionados por la gente, sino que muchas personas probablemente nos preguntan cómo lo conseguimos, ¿verdad? Alguien tiene una idea brillante o todos nosotros tenemos personas que vienen a nosotros con ideas y dicen, hey, tengo una idea para una propuesta y ¿cómo la incluyo? Esa sería la pregunta básica y no hay presión como dijimos, todo funciona por consenso. No es como si nos hubiera presionado alguna empresa y lo estuviéramos haciendo. Así que todos estos comités están de acuerdo en una característica y hay mucho proceso de pensamiento involucrado y por qué importa y qué está tratando de resolver y si realmente está resolviendo un problema del mundo real o si ya se está resolviendo. O si se presentó una propuesta similar hace muchos años o se descartó por estas razones y no va a suceder. Así que estas son las cosas que básicamente se consideran y la gente se queja del lenguaje y no solo fuera del comité, dentro del comité también y ese es un argumento saludable para tener. Pero no solo terminamos con quejas sino que buscamos cómo podríamos mejorarlo y tratamos de encontrar soluciones para hacerlo mejor. Y eso es lo que siento y Dawden o Maggie pueden leer si tienen opiniones, la gente habla sobre esto o hay muchas preguntas en realidad en el canal. Diré que ocasionalmente alguien se molesta apasionadamente por una propuesta. He visto eso un par de veces. Estoy pensando en un comentarista en particular sobre Temporal que estaba muy en contra al principio. Jordan recuerda este incidente, creo. Así que a veces la gente realmente aplica mucha presión. En su mayoría, la gente es muy amable. Usualmente es una excepción y suele ser en nuestros foros en línea cuando recibimos a alguien que no lo es. Un minuto. Hubo una rápida que probablemente podría terminar o tener esta charla aquí. Dijeron, ¿tienes una historia jugosa del mundo? ¿Cuál es la razón más sorprendente o inesperada para rechazar una propuesta? Creo que Maggie estaba probando esas partes con el temporal. Así que probablemente recogeremos las preguntas y las responderemos en el canal. ¿Quieres dar alguna nota, Maggie o Rick? Quiero decir, la razón más sorprendente para rechazar una propuesta. Así que esto no fue alguien del comité, para ser justos esto fue un comentarista aleatorio en internet pero tuve a alguien que me dijo que temporal estaba motivado emocionalmente y no había necesidad real de mejora para la fecha en JavaScript. Eso fue, yo estaba como, ¿en serio?

Hola, soy Jordan. Trabajo en Coinbase. He mantenido cientos de proyectos de código abierto y he estado en TC39 desde 2014. Ha pasado mucho tiempo. Y fui editor de la especificación durante aproximadamente tres años. Así que, veamos, mi propuesta favorita. No mencionaré las que ya se han mencionado y no mencionaré la mía. Creo que realmente me gustan do expressions y async do expressions. Esas son dos propuestas separadas, pero las estoy agrupando. Simplemente, hay muchos lugares donde es conveniente usar unas pocas declaraciones en posición de expresión. Estoy ansioso por la simplicidad de poder hacer eso.

Hoy vamos a estar un poco sin moderación. Nos haremos preguntas solo por diversión. Así que comenzaré con la primera pregunta. La primera pregunta va a ser para Jordan y es una grande. Y es esta pregunta del por qué. ¿Por qué importa estandarizar JavaScript? ¿Cómo es el proceso? ¿Cómo ocurre una propuesta? ¿Cómo sé cuándo viene una propuesta? ¿Cómo funciona toda esta máquina, Jordan? Sí. Está bien. Bueno, ¿por qué importa? Bueno, estandarizar cualquier cosa importa en el sentido de que asegura que todos estamos haciendo las cosas de la misma manera y todos podemos hablar lo mismo, ya sabes, sin intención de hacer un juego de palabras, para hablar el mismo idioma sobre lo que sea que se esté estandarizando. Así que JavaScript tiene esta arruga adicional que se ejecuta en los navegadores web que todos usamos, como, todo el tiempo, ya sabes, para hacer todo. Así que se vuelve realmente importante que puedas escribir un sitio web de una manera que todos puedan usar de la misma manera. Así que todo lo que se estandariza es una cosa menos de la que tienes que preocuparte mientras despliegas a un número infinito de dispositivos que no controlas en todo el mundo. Así que en cuanto a cómo es el proceso, eso puede variar ampliamente. Puede ser divertido. Puede ser tortuoso. Puede ser muy pedante. Sabes, creo que hay momentos en los que se necesita un tipo especial de personalidad para no salir corriendo de la habitación. Y, pero dicho eso, realmente disfruto. Creo que el intentar ha sido muy esclarecedor para considerar muchas perspectivas y casos de uso diferentes, más allá de los que normalmente habría considerado, al intentar diseñar características para lenguajes.

Y ha modificado y templado mis opiniones sobre las cosas mucho a lo largo de los años. Cuando llegué por primera vez, estaba un poco esperando, como, entrar y odiar un montón de cosas. Y resulta que, como, cuando entiendo las razones por las que las cosas son como son, que es mucho. Puedo sortearlo, en lugar de simplemente quejarme de algo que no me gusta.

En cuanto a, ¿cómo se termina una propuesta, verdad? Después de ES2015 o ES6, añadimos un nuevo proceso de etapas. Así que hay etapas de cero a cuatro. La forma rápida y sucia en que las describo es que la etapa cero es, como, tengo una idea loca. La etapa uno es que tal vez la idea no sea tan loca, ¿verdad? Ahí es cuando el comité ha dicho, como, sí, queremos pasar más tiempo investigando el problema. ¿Cómo resolvemos el problema que estamos mirando?

La etapa dos es cuando estamos bastante seguros de que la solución se ve así. Así que ahí es cuando el comité básicamente dice, estamos bastante seguros de que esto va a entrar en el lenguaje. Estamos bastante seguros de cómo se verá la forma de la solución que se va a ver. Y luego, más o menos, resolvemos todos los detalles dentro de la etapa dos. Y luego la etapa tres es el momento para que todos comiencen a implementarlo y a enviarlo. Y en ese punto, generalmente solo esperas cambios cuando no podrías haber anticipado algo antes del momento en que lo envías. Y luego la etapa cuatro es como la misión cumplida. Es cuando realmente lo fusionas en la especificación y se vuelve oficial.

Y en cuanto a cómo sabes cuándo vienen las propuestas, hay muchos lugares donde puedes mirar. Ciertamente podrías leer las notas de cada reunión, que son largas y muy oscuras. O no oscuras, arcaicas. Pero puedes leer esas que se publican aproximadamente 10 días después de cada reunión. Pero también tenemos el repositorio de propuestas en GitHub, TC39/proposals. Y eso se actualiza típicamente durante la reunión. Así que puedes navegar por la lista de propuestas en cada etapa. Y cada una enlazará a su propio repositorio donde puedes hacer preguntas o leer sobre la propuesta.

OK, bueno, así que la siguiente pregunta, en realidad se la voy a hacer a Maggie de nuevo. ¿Cómo puede una persona hacer un caso de negocio para que su organización se involucre con TC39 y otros estándares web? Claro. Así que hay una especie de pregunta subyacente allí, por supuesto, que es cómo se involucra cualquiera con TC39 y estándares web. Y vale la pena señalar que oficialmente, para participar en el proceso de TC39, necesitas estar con una empresa miembro de ACMA. Así que ACMA es esta organización de estándares o estándares internacionales. ACMA estandariza muchas cosas, no solo JavaScript. Hay un montón de estándares de IoT, estándares de dispositivos portátiles. Hay muchas cosas en ACMA. Y técnicamente, para participar en TC39, serías un delegado de una organización miembro.

Así que Microsoft es una organización miembro de TC39. Y hay una tarifa de membresía. Así que lo que se reduce es que si tú quieres ser un delegado oficial, necesitas que tu organización decida que esto vale la pena para ellos. Creo que es interesante. Obviamente, en Microsoft, donde tenemos un navegador y TypeScript y cosas, tenemos un caso de negocio bastante fuerte para involucrarnos en TC39. Pero muchas organizaciones se han involucrado. Y creo que se reduce a encontrar lo que realmente importa. Cuando traje por primera vez Temporal, no me di cuenta de cuánto apoyo recibiría de Bloomberg, que acaba de unirse a ECMA. Y la realidad era que Bloomberg estaba sintiendo una necesidad empresarial realmente fuerte cuando piensas en el tipo de negocio que Bloomberg maneja para tener una gran API de fecha y hora.

Y así que eso fue, creo, uno de los principales impulsores de que ellos vinieran a la mesa. No es que quiera hablar, Rick, por tu empresa. Pero creo que es encontrar ese lugar donde tu negocio ve una brecha y realmente ve una necesidad de avanzar, ya sea en el espacio de rendimiento, ya sea en APIs que crees que te faltan. También creo que hay mucho de, hay un argumento que se puede hacer por el goodwill, por la participación de la comunidad, por decir que queremos ser buenos jugadores de la comunidad y algo que usamos tanto. Pero lo más importante es encontrar ese caso donde dices, este es un camino crítico para el producto que hacemos, y podemos ser mejores a través del proceso de estándares.

Genial. Supongo que la siguiente pregunta que abordaremos, esta va de regreso a Jordan, es cuáles son algunos de los desafíos de estandarizar el lenguaje a largo plazo, especialmente, ya sabes, estabas hablando sobre las actualizaciones anuales de la especificación, especialmente dado las actualizaciones anuales de la especificación. Sí, quiero decir, uno de los mayores preceptos que tiene el comité es no romper la web. El ejemplo canónico que siempre usamos es el sitio web de la película Space Jam de 95. Creo que es muy difícil diseñar un buen lenguaje de programación de todos modos, y hay muchos lenguajes de programación para mirar tanto por cosas buenas como por errores, y es aún más difícil cuando ese diseño está restringido por cada decisión que has tomado en el pasado.

No podemos simplemente hacer una nueva versión de JavaScript. Tenemos que mantener la web que ya tenemos. Así que ese es un gran desafío y hay muchas cosas que decidimos hacer, no porque lo habríamos hecho si lo estuviéramos diseñando desde cero, sino porque es la evolución más sensata desde el estado actual del lenguaje hasta el siguiente lugar al que queremos llevarlo. Creo que las actualizaciones anuales de la especificación han sido realmente beneficiosas. Algunos años hay muchas cosas y algunos años hay muy pocas cosas que están en ello. Es más, lo que he encontrado más útil de ello es que tratamos la especificación como un estándar vivo ahora. Así que la especificación que se muestra en GitHub y en el sitio web de TC39.es, como esa es la última versión del estándar y la instantánea anual ya no es particularmente útil.

Es necesario para la forma en que opera ECMA y es necesario, algunas herramientas y libros y cosas como referirse a un año de edición específico. Pero los navegadores no implementan realmente características en bloques de un año a la vez. Así que puede haber algunos navegadores o motores que tienen características de ES2019 pero les falta una característica de ES2016. Así que el año realmente no te ayuda demasiado, es solo una especie de nota histórica de cuándo terminó el proceso. Así que creo que el... Creo que uno de los mayores desafíos es ¿cuándo decimos que no? Hay muchas personas en la sala en la reunión de CS39 y todos tienen prioridades y filosofías ligeramente diferentes sobre las cosas.

Algunas personas están muy entusiasmadas por agregar cosas al lenguaje, mejorar el lenguaje, ¿verdad? Y ese es un objetivo admirable. Pero creo que hay otras personas que están más preocupadas por prevenir algo que pensaríamos que es un error en unos años que luego tenemos que soportar durante los próximos 50. Una frase que he escuchado a lo largo del tiempo mucho es que el futuro es más largo que el pasado. Básicamente, cualquier decisión que enviemos en JavaScript es permanente. Y así que para mí, al menos, creo que es muy importante que seamos cautelosos. Y que, aunque es genial que podamos tener un, que podamos mover las cosas a través del proceso de propuesta rápidamente cuando parecen ser la elección apropiada, creo que tenemos que hacerlo de una manera medida y cuidadosa para asegurarnos de que no estamos, ya sabes, cometiendo un error que no podemos deshacer.

Genial. Bien, creo que eso fue... Así que para la siguiente pregunta, le voy a preguntar a Rick. ¿Cuáles son algunos de tus recursos favoritos para compartir con otros que quieren aprender más sobre la estandarización? Sí, está bien. Así que esta es una pregunta un poco compleja y te daré, espero, una respuesta menos compleja porque la estandarización es esta bestia extraña donde no es realmente programación en un sentido. Es más como ser un abogado, pero primero tienes que tener un trasfondo en programación. Así que es un poco extraño. Y voy a mencionar un montón de enlaces que publicaré en el canal de Discord de Q&A después de que terminemos aquí, o después de que termine con esto, respondiendo a esta pregunta. Así que no sientas que tienes que escribir todo esto. Pero hay muchos recursos. El beneficio de que estemos trabajando en el lenguaje que ejecuta la web es que publicamos mucha de esta información en la web. Así que supongo que la primera parte es solo la especificación en sí. Así que la especificación, tal como mencionó Jordan, es una especie de especificación viva, como una película. Está alojada en internet. Así que puedes ir a tc39.es. Puedes leer la especificación. Está escrita en inglés. Es sorprendentemente legible en su mayor parte. Sabes, si ignoras toda la elevación de variables y todas las tonterías que JavaScript ha acumulado a lo largo de los años, es sorprendentemente legible. Tiene documentación sobre cómo opera la mayoría de ella. Y es un recurso realmente bueno y útil para lo que se ve como el objetivo final de la estandarización. Porque uno de los primeros problemas con la estandarización es, bueno, ¿qué haces realmente? Porque al final del día, varios proveedores de navegadores envían código que ejecuta JavaScript, pero hay un montón de pasos intermedios, y visualizar lo que eso significa y cuál es el resultado entregable es un poco extraño. Así que además de eso, hay una fantástica serie de publicaciones de blog escritas por Marcia en el equipo de V8.

También enlazaré esto, llamado Comprendiendo ECMAScript. Está escrito en cuatro partes, y detalla cómo se escribe la especificación y lo que realmente significan las complejidades de la especificación. Así que creo que eso es un nivel superior a leer la especificación en sí, es leer la especificación en sí desde la perspectiva de alguien que definitivamente es un experto en la especificación y trabaja en V8. Ese es un recurso realmente bueno.

Otra cosa, si eres un poco más orientado al código y solo quieres visualizar cómo funcionan los métodos del prototipo de array en la especificación, pero en código, puedes mirar algo como Engine 2.6.2. Engine 2.6.2 es efectivamente, es un proyecto de código abierto escrito por un miembro de la comunidad slash Delegado de TC39, dev-snick, que es esencialmente una implementación de JavaScript en JavaScript. Y está bastante cerca de la especificación.

Si miras, por ejemplo, el código de V8 o Firefox, el código que implementa todos los estándares no necesariamente siempre, no se ve igual que la especificación. La especificación es como la parte legal. La implementación es como la forma en que realmente, las palas, la forma en que hacemos las cosas. Engine 262 tiende a parecerse a la parte legal. Así que es una muy buena manera de simplemente recorrer un fragmento de código y decir, oh, así es como implementarías esto si lo escribieras en código. Así que esas son algunas de las cosas introductorias sobre cómo se ve el entregable en sí, pero hay mucha historia en JavaScript y hay mucho de que está vivo, siempre está en movimiento y es el lenguaje más popular del planeta.

Así que una de las cosas que salió recientemente que me encanta compartir con la gente es en realidad este documento escrito por Alain Westbrock y Brendan Eich llamado La Historia de JavaScript Los Primeros 20 Años, y también lo enlazaré. Y es un recurso fantástico para la evolución de JavaScript porque a diferencia de un lenguaje que podrías diseñar en una clase de lenguaje o como un grado de PL o simplemente desde los primeros principios, JavaScript tiene mucho legado. Y como mencionó Jordan, la web no se rompe. Al menos ese es nuestro objetivo. Así que para entender muchas de las decisiones en torno al diseño de JavaScript, tienes que entender un poco toda la historia y como entender de A a B a Z, qué exactamente sucedió y por qué se tomaron decisiones. Y aclara mucho sobre cómo pensamos sobre la estandarización a lo largo del tiempo y cómo tratamos de poner un paraguas sobre la historia para proporcionar a la gente un buen lenguaje para usar.

Tengo un par de cosas más. Tenemos, si estás interesado en cómo opera TC39 específicamente, tenemos el repositorio cómo trabajamos. Así que TC39 opera este repositorio que intenta documentar todos nuestros procesos tanto como sea posible desde cómo llevamos a cabo la plenaria y que son como las discusiones reales que tenemos, cómo documentamos propuestas, qué hacen, más detalles sobre lo que significan las etapas, cosas así. Así que ese es un recurso realmente bueno si solo estás interesado en cosas más legales. Y luego mencionamos esto antes que las notas de la reunión son muy importantes. Cuando comencé y yo, como el día después de ir a mi primera reunión de TC39, lo primero que hice fue buscar todas las propuestas que amaba y luego averiguar en la agenda, que también publicamos, que también publica un enlace a cuando se habló de ello. Y luego revisé las notas y leí las discusiones y no leí todo de manera literal. Hay muchas notas. Algunas de las notas de las discusiones de TC39 son como de 40 páginas de largo. Pero si solo lo aislas a una sola propuesta puedes obtener una muy buena idea de cómo se ve esa discusión. Y hay una cantidad increíble de discusión que ocurre a lo largo de todo el espectro del lenguaje en términos de cómo las características interactuarán con otras características y cómo la complejidad de implementación de una característica podría afectar las decisiones de diseño que si solo miras el estándar en sí podrías no capturar.

Así que es realmente importante capturar esa discusión en sí también. Así que eso es un montón de enlaces. Publicaré todos estos en el canal de Discord para que podamos tener enlaces a ellos. Pero eso es un poco como, si quieres aprender sobre la estandarización internet es la solución y te daré tantos enlaces como sea posible. Así que eso es un poco eso. Si entiendo, debería pasárselo a Hemanth porque tengo una pregunta para ti que es ¿cómo probamos características antes de que se lancen? Gracias, Bing. Así que ¿cómo probamos características o más bien usamos características antes de que se lancen? Bueno, hay muchas maneras. Lo primero es que la mayoría de las propuestas probablemente vendrán con un plugin de Babel o un Polyfill. Así que revisa su repositorio si tienen un Polyfill o un plugin de Babel. Bueno, no es realmente parte del proceso pero la mayoría de las propuestas que son Polyfillable tienden a tener Polyfills. Y luego cuando llega a la etapa tres y cuando busca comentarios de los desarrolladores, normalmente estará bajo una bandera que puede ser donde está implementado en un navegador o node y cosas así. Así que normalmente tiendo a usar JS Fu, uno de los módulos de node que te ayudará a obtener todos los motores de tiempo de ejecución tal vez como V8 o SpiderMonkey, Rhino y V8-T-Bug y cosas así.

Así que recogería todos ellos y me prepararía para un HarmonyFlags. Ahí es donde normalmente las características que buscan retroalimentación se implementarán bajo la bandera. Ejecutaría esos motores con los HarmonyFlags y trataría de experimentar con ello. Y algunas de las propuestas también tienen playgrounds como Temporal o Rekords Incubatables tienen buenos playgrounds donde ya han polyfilled las cosas requeridas y tienen buenos ejemplos sobre cómo funciona el código, de qué se trata la característica, buenos ejemplos de código y puedes ir y probar eso y obtener una comprensión.

Si quieres profundizar un poco más, probablemente podrías abrir la especificación y ver la solicitud de extracción que se realizó para los cambios en la especificación y ver cómo es la especificación existente y cómo esta propuesta está cambiando la especificación existente. Así que obtendrás algunos detalles sobre cuáles son los cambios que se realizaron en la característica. Así que si no, no estás en un estado para simplemente usarlo y probarlo. Obtendrás una idea de cómo sería la característica y cuáles son todos los, probablemente en sintaxis o los cambios que esta propuesta está trayendo. Así que esa es una de las maneras en que podrías manejarlo.

La otra manera es que vas y lees la especificación y tratas de analizar. Puede que no realmente entiendas si no estás en la lectura de especificaciones. Y yo y uno de mis amigos estamos llevando a cabo el espectáculo llamado Read the Spec with Us donde estamos leyendo partes de la especificación y tratando de traducirlo a código. Como mencionó Rick, hay una prueba, un 262 que tendría las implementaciones de prueba de estas propuestas, que es parte del proceso donde deberías tener estas pruebas para que puedas ir a las pruebas, ver las diferentes variaciones para que cubra todo el espectro. Puedes entender cómo funciona. Así que hay muchas maneras diferentes, pero también veo que hay un pequeño inconveniente aquí a veces cuando ya hay un calificador que está ahí la gente comienza a usarlo y la especificación cambia un poco pero el plugin no se está actualizando con la especificación. O por ejemplo, los decoradores son un ejemplo de eso donde TypeScript ha implementado una versión particular de decoradores pero la especificación ha cambiado mucho desde allí y hay un poco de actualización que necesita suceder. Y Babel dejó claro que, oye, estas son propuestas en etapa así que deberías tener mucho cuidado sobre cómo lo estás usando y no realmente listo para producción y las cosas pueden cambiar y romperse. Así que siempre hay dos caras, como la cara de dos lados de una moneda. Como, tienes los pros y los contras pero definitivamente podrías explorar de muchas maneras y seguir el repositorio de propuestas, mirar los problemas te dará más información. Con eso, se lo devolveré a Rick con mi pregunta sobre, creo que Rick cubrió la mayor parte de ello pero tenía esta pregunta sobre la pipeline que ¿cómo contribuyo con TD39? Como, cuando hablo en un foro público esta es la pregunta común que me hacen, decir que tengo una idea o tengo una idea para una propuesta y quiero llevarla al comité o ¿dónde está el punto de entrada? ¿Cómo empiezo? Sí. Así que esta también es una pregunta interesante. Depende de si eres, bueno, depende de muchas cosas. Hemos tocado muchos de estos temas a lo largo del panel. Una de las maneras más inmediatas y directas es si tu empresa ya es miembro de TC39 entonces contacta a las personas internamente quienes son esos delegados. Nosotros, sabes, averiguamos eso y luego contribuimos de esa manera. Esa es la opción más directa o como se mencionó anteriormente, convence a tu empresa para unirse a ECMA lo cual es muy beneficioso tanto para ECMA, TC39 para obtener más aportes de más grupos y beneficioso para la empresa porque puedes ayudar a que el lenguaje crezca. Luego puedes contribuir de esa manera. También hay cada propuesta tiene su propio repositorio de GitHub al que puedes publicar. Puedes abrir problemas, puedes leer la documentación. Para cada propuesta, al menos el formato estándar, esto no es técnicamente requerido, pero la mayoría de las propuestas junto con la diferencia de especificación que realmente cambia la especificación, hay un gran explicador.

Sé que una de las propuestas en las que trabajo, Rekord y Tuple, tiene un gran explicador que detalla, en profundidad, muchas de las decisiones de diseño. Y si estás interesado en contribuir, el primer paso es leer ese explicador en su totalidad y luego generar tus propias ideas sobre cómo debería funcionar, y luego puedes abrir problemas. Muchas personas abren problemas en esos repositorios para hacer preguntas o para obtener aclaraciones sobre ciertas partes del diseño o para sugerir alternativas. Hay una gran cantidad de problemas en la mayoría de las propuestas, y animo a todos a participar en eso porque la gente responderá. Sabes, hay muchas personas realmente inteligentes trabajando en estas propuestas que hablan con personas todo el día por trabajo. Así que ciertamente es una forma de interactuar con la comunidad.

Fuera de GitHub mismo y fuera de las propuestas, en el terreno más experimental, está nuestro discourse, que es nuestro foro de alguna manera. Pondré un enlace en el Discord también para esto. No es Discord, es Discourse. Es es.discourse.group. Es un foro donde hay una variedad de temas en los que puedes poner sugerencias para nuevas características y hablar sobre propuestas y hacer preguntas en un entorno más detallado estilo foro. Esa es la mayoría de las formas. Siempre estamos buscando más grupos para contribuir porque la web, como JavaScript específicamente, y la web, que tiene JavaScript y el nodo de back-end, todo eso, Deno, es como una gran plataforma. Así que excluir a alguien es incorrecto. Así que es realmente importante que escuchemos de tantas personas como sea posible. Así que es realmente importante que ese esfuerzo sea de baja fricción. Así que eso es todo.

Sí, así que nos hemos quedado sin preguntas preparadas. Así que lo que voy a hacer ahora es improvisar. ¿Tenemos en Discord, tenemos? Sí, solo iba a mencionar una. Veamos, la primera que pensé fue una buena pregunta sobre la carga de implementación, que no, cualquiera puede responder esto. Solo lo mencionaré en voz alta. Metin en Discord pregunta, ¿podríamos tener un JS2 principal para que podamos tener dos versiones de JS? ¿Es eso una solución a nuestros problemas? ¿Alguien quiere tomar eso? Claro, eso definitivamente no es una solución. Esto se ha intentado de alguna manera en el pasado. Firefox solía enviar un actual, solían enviar dos tipos diferentes de JavaScript. Solían enviar el estándar que conocemos en la web y luego uno específico de Mozilla que tenía algunas extensiones. Así que hay sintaxis para cada uno y algunas cosas y tenían let y const muchos años antes de que ES 2015 lo hiciera. Se comportaba un poco diferente.

Pero, mi entendimiento es que esto hizo que fuera realmente difícil para las páginas web porque si digamos que hay dos versiones de JavaScript, el navegador aún tiene que enviar ambas versiones para siempre. Y puede hacer que sea realmente difícil compartir código entre esos entornos. Si escribo, como, digamos que era jQuery, ¿puedes usar jQuery? ¿Podrías usar jQuery en ambas versiones de JavaScript? La única forma de que eso sea el caso es si jQuery hiciera dos copias de sí mismo, una para cada uno, o si hubiera una forma interoperable compatible hacia atrás de escribir jQuery. Y así termina que la mayoría de las cosas termina siendo lo que sea la forma interoperable. Y, ya sabes, lo que significa que terminas teniendo solo el mismo lenguaje básico que tenemos ahora, y aún estás atrapado y limitado por decisiones anteriores.

Así que, hay un tipo similar de, así que la respuesta general que he escuchado es que nadie quiere hacer versionado más. Y de manera similar cuando ES5 agregó modo estricto, como un pragma, para intentar arreglar algunas cosas sobre el lenguaje, las correcciones son buenas. A todos les gustan las mejoras, pero la reacción general dentro de TC39 es no más modos, no más pragmas. Que hacer esto de esta manera fue, ya sabes, no necesariamente un error, pero tampoco es algo que nadie quiera repetir. Amplifica el número de permutaciones con las que todos tienen que lidiar, y hace que el lenguaje sea más confuso y más difícil de construir a largo plazo. ¿Puedo agregar un comentario sobre- No tengo más pensamientos, adelante. Solo para comentar sobre las interrupciones, ya sabes, estabas hablando de, no nos gustan los pragmas, usar estricto fue útil, pero de alguna manera rompió las cosas, rompió la compatibilidad hacia atrás de alguna manera.

Creo que fue realmente interesante para mí con TC39, me tomó un tiempo después de que comencé a asistir para entender algo que dijo Rick, que es que es el lenguaje de programación de todos. Nadie va a romper un sitio web de 1995. Puedes pensar que no importa, pero puede importar profundamente al propietario de un pequeño negocio que no puede permitirse que se rehaga. ¿Verdad? Como vamos a intentar dar continuidad de una manera que es inesperada. Si estás acostumbrado a ser un desarrollador de software en una organización que pensaría, Oh, bueno, todo el código se reemplaza en un arco de cinco años de todos modos, ¿verdad? Has oído a la gente decir eso sobre el software, pero simplemente no es, no es el lugar mental. Solo imagina, como, incluso si fueras como, no sé, he recogido un, ya sabes, Super Nintendo y he intentado volver a jugar viejos juegos de vez en cuando. ¿Qué pasaría si quisieras buscar una guía para superar una parte difícil, y esa guía estaba en un sitio web que no se ha actualizado en 25 años? Sabes, sería realmente decepcionante si eso no funcionara porque alguien quería alguna nueva característica del navegador. Sabes, hay muchas maneras, creo, de hacer lo que todos están hablando y encontrar una razón para ti mismo que te ayude a entender por qué es, de hecho, el lenguaje de programación de todos y por qué realmente no quieres que un montón de, ya sabes, un número relativamente pequeño de personas en una sala tomen una decisión que excluya algo porque qué te detiene de ser excluido. Rick, estás en silencio. Me disculpo. Solo iba a decir que, como, no para seguir con esto, para seguir, algo más en lo que pensar, lo mencionamos un par de veces, es que JavaScript es un estándar vivo. Si alguien lanza una nueva versión de un lenguaje, como un nuevo entorno de ejecución, como Python o algo, que rompe muchas cosas, simplemente puedes no actualizar. Quiero decir, eventualmente te quedarás sin actualizaciones de seguridad, pero, como, no tiene un impacto tan grande, pero si rompemos la web y todos los Chrome se actualizan y ahora el sitio web no funciona, eso es un negativo inmediato. No es algo de lo que puedas optar por salir, o como la naturaleza de la seguridad en la web y la naturaleza de la seguridad en el año 2021 significa que no deberías desactivar las actualizaciones en tu navegador. Como eso es una muy mala idea. Así que también es un equilibrio de eso, de como las preocupaciones de implementación de los navegadores y cómo queremos lidiar con el ecosistema y la seguridad a largo plazo. Hemant, creo que ibas a decir algo. Sí, estaba tratando de recoger otra pregunta en Discord, pero parece que estamos justo a tiempo. En realidad te quedan cinco minutos. Oh, ¿es así? Está bien. Así que hay muchas preguntas en el grupo. Así que probablemente recogeré una al azar que podamos responder rápidamente. ¿Cómo es ser un asociado público con TC39? ¿Te presionan en línea para agregar la característica favorita de alguien? ¿O ves a la gente quejándose del lenguaje contigo? Sí. Así que es una pregunta divertida. Diría que no es que estemos siendo presionados por la gente, sino que muchas personas probablemente nos preguntarían cómo lo conseguimos, ¿verdad? Alguien tiene una idea brillante o todos nosotros tenemos personas que vienen a nosotros con ideas y dicen, hey, tengo una idea para una propuesta y ¿cómo la meto? Esa sería la pregunta básica y no hay presión como dijimos, todo funciona por consenso. No es como si nos hubieran presionado por alguna empresa y lo estuviéramos haciendo. Así que todos estos comités están de acuerdo en una característica y hay mucho proceso de pensamiento involucrado y por qué importa y qué está tratando de resolver y si realmente está resolviendo un problema del mundo real o si ya se está resolviendo. O si se presentó una propuesta similar hace muchos años o se descartó por estas razones y no va a suceder. Así que estas cosas son las que básicamente entran y la gente se queja del lenguaje y no solo fuera del comité, dentro del comité también y eso es un argumento saludable para tener. Pero no solo terminamos con quejas sino que más bien buscamos cómo podríamos mejorarlo y tratamos de encontrar soluciones para hacerlo mejor. Y eso es lo que siento y Dawden o Maggie pueden leer si tienen opiniones, la gente habla de esto o hay muchas preguntas en el canal.

Diré que ocasionalmente alguien se molesta apasionadamente por una propuesta. He visto eso algunas veces. Estoy pensando en un comentarista en particular sobre Temporal que estaba muy en contra al principio. Jordan recuerda este incidente, creo. Así que a veces las personas realmente aplican mucha presión. En su mayoría, la gente es muy amable. Normalmente es una excepción y suele ser en nuestros foros en línea cuando tenemos a alguien que no lo es.

Un minuto. Hubo uno rápido que probablemente podría terminar o tener esta charla aquí. Dijeron, ¿tienes una historia jugosa del mundo? ¿Cuál es la razón más sorprendente o inesperada para rechazar una propuesta? Creo que Maggie estaba probando esas partes con el temporal. Así que probablemente recogeremos las preguntas y las responderemos en el canal. ¿Quieres dar alguna nota, Maggie o Rick? Quiero decir, la razón más sorprendente para rechazar una propuesta. Así que esto no fue alguien del comité, para ser justos esto fue un comentarista aleatorio en internet pero tuve a alguien que me dijo que temporal estaba motivado emocionalmente y que no había necesidad real de mejora para la fecha en JavaScript. Eso fue, yo estaba como, ¿en serio? Así que, pero en su mayoría la gente es positiva.

Quiero enfatizar eso. Creo que estamos cerrando, pero lo tendremos en el Discord. Muy bien. Nos veremos todos en Discord y fue increíble poder charlar. Que tengas un gran día. Cuídate. Nos vemos la próxima vez. Adiós.