¿Qué es "TC39: Type Annotations" también conocido como la propuesta de Tipos como Comentarios

Muy bien. Hola a todos. Vamos a repasar la propuesta de Anotaciones de Tipo TC59, también conocida como Tipos con Comentarios. Esta es una propuesta que añade la capacidad de ejecutar código tipado en JavaScript. Ahora, mi nombre es Otto the Rocks. Solía trabajar en el equipo de TypeScript durante unos dos años y medio. Durante ese tiempo trabajé en el sitio web y en la documentación y un poco en las características del compilador aquí y allá. Y una de mis cosas favoritas cuando me fui fue que tenía este gran video de YouTube que describe todo el proceso del compilador que es realmente, realmente útil si estás, ya sabes, interesado en entender las herramientas que usas a diario. Así que, para empezar esta charla, queremos tener al menos un vocabulario compartido. Vamos a hablar un poco sobre TC39. Son un grupo de personas cuyo objetivo principal es tratar de averiguar cómo hacer evolucionar JavaScript de manera lenta y segura. Y la forma en que lo hacen es a través de estas propuestas. Estas propuestas, ya sabes, pasan por cinco etapas. Todas son cada vez más específicas con el tiempo. Y estamos hablando de una propuesta de TC39 que ahora está en la primera etapa. Así que, la propuesta en sí es lo que vamos a tratar primero. La repasaremos brevemente. Profundizaremos en por qué ahora tiene sentido. Porque no es la primera. Veremos cómo afecta a TypeScript. Eso es la mayoría. Y vamos a ver hacia dónde se dirige a continuación. Así que, este es el concepto subyacente. Que hay un problema con este código. Que no se ejecutará en un motor de JavaScript. Como la cadena de dos puntos va a fallar. Y eso significa que eso no es un lenguaje legítimo. Así que, queremos estar en una posición en la que eso no suceda.

Entonces, ¿por qué ahora? ¿Verdad? Como, ya sabes, ha habido muchos intentos de tratar de añadir un sistema de tipos a JavaScript. Y esta es más o menos la primera vez que uno ha llegado a un nivel de, ya sabes, gente que se preocupa. Creo que TypeScript realmente ha demostrado a la gente que hay una necesidad de JavaScript tipado a una escala razonable. TypeScript ahora está en una posición en la que está bien asumir algunas de las restricciones que serían necesarias para hacer esto funcionar. Y la idea ya ha sido probada en lenguajes anteriores que tienen restricciones similares, como lenguajes de tipo script, como Ruby y Python. El grado en que están totalmente de acuerdo con todas las compensaciones es algo que ahora podemos usar para averiguar qué debería parecer eso en JavaScript en comparación con la implementación de Ruby y Python, también. Así que no somos los primeros, estamos probando algo nuevo. Estamos probando algo que está razonablemente establecido. Ahora, lo que creo que a la mayoría de la gente en el contexto del Congreso de TS le interesa es cómo afecta esto a TypeScript, ¿verdad? Esta es una propuesta que añade algunas restricciones a TypeScript que pueden traer de vuelta a TypeScript a JavaScript. Hay muchas cosas pasando aquí. Y cuando pensé en cómo enmarcar esto, repasé las notas de la discusión original de TC39, y vi que Rob Palmer había

Pero lo interesante es que están empezando a converger, ¿verdad? Como, están acercándose mucho a ser aproximadamente el mismo número, que es en algún lugar alrededor del 10% para cada uno. Obtuve estos data de BigQuery, que es un proyecto de Google que te permite analizar todos estos grandes conjuntos de datos de código abierto, incluyendo cosas del gráfico de uso de GitHub. Y esto es, puedes ir a un sitio web llamado GitHub 2.0, que intentará mostrarte los exactos de cómo se miden estas métricas de popularidad. Pero es bastante razonable decir que aproximadamente TypeScript es el fork de JavaScript, que es tan popular como JavaScript para el código moderno. Es una división 50-50 entre si alguien va a usar JavaScript o TypeScript en un proyecto o al menos en una solicitud de pull en el código abierto. Y entonces, quién sabe cómo se ve eso en el código privado. Y, ya sabes, es difícil medir siempre la exactitud de cosas como esta. Pero no es tan difícil decir que esto podría ser así. Y entonces, cuando piensas en eso, eso es un poco preocupante para JavaScript como una cosa conceptual. Como JavaScript, como, el principal truco, si quieres, es que es un lenguaje impulsado por consenso que es muy útil para todas estas cosas del navegador web. Entonces, tenemos diferentes conjuntos de personas en TC39 que tienen diferentes conjuntos de restricciones. Pero juntos, encontraron un consenso que sigue asegurando que una página web construida hace 20 años todavía funciona hoy, porque la compatibilidad hacia atrás de JavaScript es bastante sólida. Pero lo extraño aquí es ahora, si hay un lenguaje que es dirigido por un conjunto de una empresa, Microsoft, ¿es un gran espacio para nosotros estar en donde hay este un lenguaje que es la parte subyacente que tiene a mucha gente trabajando juntos para tratar de averiguar la cosa correcta a hacer, pero por otro lado, hay una empresa que representa alrededor del 50% de todas las contribuciones de código abierto a ese lenguaje usando esos tipos de lenguajes. Es un poco demasiada presión para

Entonces, este pequeño meme que hice en algún momento, que es como una forma de decir, como, en algún momento, sabes, TypeScript decidió que, como, los enums y los espacios de nombres y estas características que como afectan al runtime, no son realmente las cosas que TypeScript quiere involucrarse y eso es como una responsabilidad para 2.6.39. Y este sistema de estilo de comentarios de tipos realmente ayuda a reforzar la, como, la línea entre esas dos responsabilidades.

Entonces, ¿dónde estamos ahora? Estamos un poco más adelante en el camino. Sabes, fue en marzo de 2022 cuando esta propuesta salió por primera vez. Sabes, la propuesta decía, hey, realmente estamos tratando de encontrar una forma de, como, hacer este tipo de cosas conceptuales de comentarios. Y llegaron a una etapa cero, que efectivamente significa, hey, esto podría, esto es algo. Nadie va a destrozarlo. Es realmente va a ser implementado como esto. Pero llegó a un punto en el que, cuando hablaba con el resto de los equipos de TC39, la gente concluyó que hay algunas buenas preguntas que mirar para empezar a pensar para la etapa uno, y volvieron un año después y empezaron, sabes, respondiendo a algunos de los, respondiendo a algunos de esos problemas. El primero era tratar de averiguar, hey, si construimos un sistema de tipos como este, ¿debería poder interactuar con el runtime en absoluto? Como, sabes, la idea general de TypeScript hoy en día es que puedes pasar de un archivo de TypeScript a un archivo de JavaScript simplemente presionando delete. Ese es el objetivo. Y eso significa que cualquier cosa que hagas en tipos no puede tener un efecto en el runtime. De lo contrario, no puedes simplemente presionar delete. Eso no es lo mismo cosa. Y así, la propuesta, sabes, codifica esto. Y, sabes, después de volver y hablar con un montón de gente, hay mucha gente que dice, como, esto simplemente no es navegadores simplemente bloquearía esto si les exigiera construir un comprobador de tipos para saber correctamente si algo debería ser del tipo correcto o no en diferentes momentos. Y así, si eso es un bloqueador, entonces eso es genial. Porque eso libera a los tipos como comentarios para ser tipos como comentarios en lugar de tipos como performance hints, tal vez. El siguiente es tratar de evitar este problema de sopa de tokens. La idea general es que, como, es difícil ahora mismo poder especificar realmente qué puede vivir en un tipo y qué no. La heurística aproximada ahora mismo es si es una llave abierta tiene que haber una llave cerrada. Y puedes mirar de izquierda a derecha y contar tus llaves de esta manera y contar tus cierres de esta manera. Y una vez que hayas terminado, entonces podrías haber terminado con

Entonces, estamos llegando. En este momento, las personas que estaban trabajando en la propuesta están tratando de averiguar cómo pueden cuantificar los efectos de cambiar para apoyar este tipo de estilo de comentario. Ignorar puede funcionar. Los navegadores estarían de acuerdo con un pequeño golpe en el performance para apoyar el alcance de esta idea. Pero es posible que no estén de acuerdo con intentar hacer eso si viene con demasiados compromisos de performance porque la única forma en que podemos realmente declarar esto es el espacio de tipo es que requiere hacer un poco de análisis, volver y volver a analizarlo, ahora que sabemos que están en un contexto diferente, y cosas así. Es algo complicado de implementación del compilador y si realmente quieres averiguar esos detalles, ve a ver mi charla, Cómo el Compilador Compila, y puedes ver cómo funciona un tokenizador en general. El siguiente es tratar de averiguar el alcance de la community, ver qué personas están interesadas en este espacio. Quieren las opiniones de muchos grupos de personas, por lo que habrá personas de JavaScript que no creen que debería haber tipos allí, y habrá personas de documentation que dirán, oye, ¿por qué no hacemos nuestra propia cosa en este espacio en lugar de solo usarlo para tipos. Va a haber muchas personas haciendo un trabajo realmente creativo en ese espacio de tipos, y yo creo que ese es el objetivo de la talla, pero también quieres tener cuidado con eso. Y luego tratar de averiguar, ¿cómo resolvemos este problema de la sopa de tokens al tratar de definir realmente un área que podría ser razonablemente ambigua, pero al mismo tiempo no ser ambigua, para que puedas declarar fácilmente, oye, esta es un área de código que simplemente no se va a ejecutar. Con los comentarios, eso es fácil porque hay delimitadores de fin fáciles, pero esto no es tan cierto con la cosa que estamos mirando.

Entonces, ¿cómo puedes involucrarte? Bueno, en primer lugar, tal vez sigue el repositorio de GitHub. Tenemos muchos, tenemos relativamente pocos problemas con el tiempo. Mucha de esa actividad ocurrió en los primeros seis meses, y ahora mucho de eso es solo gente que está tratando de explorar alternativas a este tipo de sistema de tipos de estilo de comentario que están muy interesados en ser creativos, por lo que siempre vale la pena echar un vistazo, pero sería bueno tener a algunas personas allí que digan, oye, sí, como que muchas de estas son respuestas resueltas, y hay muchas personas que ya tienen código que se parece mucho a esto que podría ser, podría ser bueno tener a algunas más personas diciendo ese tipo de cosas allí, y el otro sería participar en las encuestas de la community. Como muchas de las veces, ya sabes, las anotaciones de tipo son la característica más solicitada y eso es, ya sabes, bueno para esta propuesta, porque proporciona respaldo para decir, ya sabes, la gente quiere esto, y también, ya sabes, va a haber encuestas de la gente que realmente escribe estas propuestas sobre cómo averiguar, como, qué tipo de intercambio son aceptables. Si alguna vez ves alguno de esos, creo que la mayoría de esas personas están en Masterband y idealmente, todos deberían estarlo, así que también revisa esos. Y creo que eso es suficiente. Como, todos, quiero decir, espero que esto entre, porque creo que esto será realmente bueno para JavaScript, porque me encantaría ver, como, la defoliación de TypeScript, creo que eso es uno de los grandes mayores para mí, porque entonces, ya sabes, todos volvemos a ser ingenieros de JavaScript estándar de nuevo, es un poco como el segundo paso después de que se agregó el soporte de Babel a TypeScript y de repente todos estos proyectos de JavaScript estaban disponibles, tenemos la misma oportunidad para que lo mismo vuelva a suceder, así que estoy fuera de las rocas, puedes encontrarme en Masterband y en mi sitio web, y que tengas un buen día, ¡disfruta, adiós!