Un análisis profundo de la propuesta que podría deshacer la bifurcación de TypeScript y traernos de vuelta a todos nosotros como "JavaScripters, pero con algunos tipos de TypeScript." Cubriremos los motivos del autor, cómo podría funcionar, por qué ahora y cómo va.
¿Qué es "TC39: Type Annotations" también conocido como la propuesta de Tipos como Comentarios
Video Summary and Transcription
La propuesta de Anotaciones de Tipo TC59, también conocida como Tipos con Comentarios, introduce la capacidad de ejecutar código tipado en JavaScript. Su objetivo es traer TypeScript de vuelta a JavaScript y crear una separación entre el sistema de tipos y el tiempo de ejecución. La popularidad de TypeScript está a la par con JavaScript, lo que genera preocupaciones sobre la influencia de Microsoft. La propuesta avanza abordando la interacción en tiempo de ejecución y la sopa de tokens en las especificaciones de tipo. La investigación, la participación de la comunidad y la cuantificación de los efectos de apoyar este estilo de comentario son objetivos importantes.
1. Introducción a la Propuesta de Anotaciones de Tipo TC59
Vamos a repasar la propuesta de Anotaciones de Tipo TC59, también conocida como Tipos con Comentarios, que añade la capacidad de ejecutar código tipado en JavaScript. La propuesta se encuentra actualmente en la primera etapa del proceso TC39. Discutiremos su concepto subyacente y cómo afecta a TypeScript.
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.
2. El impacto de la propuesta en TypeScript y JavaScript
Esta propuesta sostiene que los motores de JavaScript deben tratar el código como un comentario, permitiendo a los navegadores ignorarlo. No es un comentario tradicional, sino una forma de indicar que el código debe ser ignorado. TypeScript ha demostrado la necesidad de JavaScript tipado, y esta propuesta se basa en lenguajes anteriores como Ruby y Python. El enfoque principal es cómo esta propuesta afecta a TypeScript y lo reintegra en JavaScript.
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
3. Desunificando TypeScript y JavaScript
Tiene cuatro puntos principales: la capacidad de ejecutar TypeJavaScript en cualquier lugar, desunificar TypeScript de JavaScript, hacer de TC39 el lugar para la discusión de la sintaxis, y crear una verdadera separación entre el sistema de tipos y el tiempo de ejecución. La popularidad de TypeScript se mide por el porcentaje de solicitudes de pull abiertas en GitHub, lo que muestra el crecimiento de TypeScript y su impacto en JavaScript. TypeScript se está volviendo tan popular como JavaScript, con una división del 50-50 en el uso. Esto plantea preocupaciones para JavaScript como un lenguaje impulsado por consenso y plantea preguntas sobre la influencia de una sola empresa, Microsoft, en el lenguaje.
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
4. Impacto de TypeScript en JavaScript
Es preocupante para TC39 que alguien les quite la alfombra de debajo. Las restricciones de TypeScript minimizan el impacto en JavaScript. Las personas interactúan más con el código en TypeScript, aunque se ejecute como JavaScript. Esta propuesta tiene como objetivo traer a las personas de vuelta de TypeScript a JavaScript. La libertad de TypeScript está limitada en un mundo de tipos de comentarios. El equipo de TypeScript ya ha abordado problemas similares. TypeScript se está convirtiendo en la mayoría en los proyectos de JavaScript.
5. Restricciones de TypeScript y Progreso de la Propuesta
La propuesta tiene como objetivo restringir TypeScript dentro del alcance de esta propuesta, separando las características de tipo de las características de tiempo de ejecución. TypeScript quiere evitar el soporte de ciertas características a nivel de expresión que afectan al tiempo de ejecución, como los enums y los espacios de nombres. La propuesta ha avanzado de la etapa cero a la etapa uno después de abordar preguntas sobre la interacción con el tiempo de ejecución y evitar la sopa de tokens en las especificaciones de tipo.
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
6. Investigación, Alcance y Participación Comunitaria
Se necesita realizar investigaciones para identificar problemas conocidos y desconocidos en este espacio. La propuesta está en la etapa uno, y se están haciendo esfuerzos para cuantificar los efectos de apoyar este estilo de comentario. El alcance comunitario y la definición de un área de código no ambigua son objetivos importantes. Involúcrate siguiendo el repositorio de GitHub, explorando alternativas y participando en encuestas comunitarias.
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!
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.