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

Rate this content
Bookmark

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.

27 min
21 Sep, 2023

AI Generated Video Summary

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

Short description:

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

Short description:

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.

¿Cómo hacer eso? Esa es la pregunta complicada que mucha gente ha hecho. Y esta propuesta sostiene que la forma de hacerlo es decir que, oye, motores de JavaScript, simplemente ignoráis este código. Lo tratáis como un comentario. Ahora, los comentarios ya están bastante bien definidos en JavaScript. Tenéis una barra, barra. Lo hacemos hasta el final de la línea. Y tenéis una barra, estrella. Lo hacemos hasta el final de una estrella, barra. Aquí estamos usando el término de forma un poco ambigua. No es un comentario en la forma en que normalmente pensamos en ellos. Pero está diciendo tanto a la persona que está tratando de entender esta propuesta, la idea es, simplemente lo ignoras. Y enseñamos a los navegadores cómo ignorar ese tipo de código. Y esa es la idea. Si realmente quieres profundizar en los detalles, puedes ir a los comentarios de TypeScript, voy a cometer ese error varias veces. La página web de la propuesta de comentarios de TypeScript. Y esta es una versión de nivel superior de la propuesta. Así que no requiere que seas un nerd del lenguaje, básicamente. Y si quieres realmente profundizar, deberías ver la charla de Gil Tyre sobre el preludio a su propuesta, porque él es uno de los que la están impulsando. Cómo y por qué consiguió cierto consenso de un montón de gente. Y más o menos por qué tiene sentido a largo plazo en comparación con él usando el soporte JSDoc 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

Short description:

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.

esta hermosa frase que resume todo. Tiene cuatro puntos principales que vamos a repasar uno por uno. Quieren la capacidad de ejecutar TypeJavaScript en cualquier lugar, quieren desunificar TypeScript de JavaScript, y quieren hacer de TC39 el lugar donde se lleva a cabo la discusión de la sintaxis. Y quieren que haya, como, una verdadera separación entre, como, qué es una cosa del sistema de tipos y qué es una cosa del runtime, y esta propuesta ayuda a todos esos. Entonces, para repasarlos uno por uno, en realidad quiero cambiar estos dos alrededor para poder trabajar con una mejor historia. Desunificar TypeScript a JavaScript, creo, puede ser mejor explicado tratando de averiguar la popularidad de TypeScript. Y una buena manera de medir eso es la cantidad de solicitudes de pull de código abierto que ocurren en GitHub. Entonces, esto va a ser un gráfico del porcentaje de todas las solicitudes de pull que son de un lenguaje específico. Así que vamos a mirar primero en JavaScript. Entonces, desde 2013, era aproximadamente el 17%. Y luego eso subió a alrededor del 25% antes de 2016. Entonces, tienes esto de todas las solicitudes de pull, JavaScript pasó de ser el 17% de todas las solicitudes de pull al 25% de todas las solicitudes de pull, lo que significa que a medida que el ecosystem de código abierto de GitHub estaba creciendo, el ecosystem de JavaScript estaba creciendo más rápido. Y luego empiezas a ver que disminuye. Y parte de eso, es un ecosystem en crecimiento de todos haciendo código abierto. Entonces, ya sabes, cuando más usuarios de Python entran, es un pastel más grande. Pero al mismo tiempo, hay casi un crecimiento lineal de TypeScript durante todo este período de tiempo también. Entonces, es difícil negar que TypeScript debe estar comiendo en la base de usuarios de JavaScript, de alguna manera, en GitHub para las solicitudes de pull de código abierto.

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

Short description:

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.

Microsoft. Es un poco preocupante para la gente de TC39, básicamente, tener a alguien que quizás simplemente les quite la alfombra de debajo. Para TypeScript, cuando estaba en el equipo, realmente di una charla sobre las restricciones que TypeScript se impone a sí mismo para asegurarse de que tiene el menor impacto negativo posible en el ecosystem de JavaScript, y cómo funciona eso, y por qué vale la pena leer sobre eso si realmente quieres profundizar en el tema. Pero no voy a entrar en eso, en general, aquí. Es poco probable que TypeScript haga eso, y esto ayuda a esos conjuntos de restricciones. Así que la forma en que pienso en cómo se usa el código hoy en día, la mayoría de las personas están escribiendo JavaScript, según sus estadísticas de BigQuery. Pero un porcentaje considerable está utilizando TypeScript, y hay una o dos personas de JS en medio que lo hacen un poco ambiguo. Pero la forma en que las personas interactúan con este código a través de herramientas y leyendo read-me's y cosas así, es en su mayoría, mucho más basada en TypeScript, porque tienes cosas como definitely typed, que proporciona comentarios en línea en tus editores, y eso realmente se come el espacio de interacción en el que las personas usan archivos JavaScript en general. Y aún así, de todo eso, el código real que puede ejecutarse en tu motor JavaScript es solo JavaScript. Y entonces te encuentras en esta posición en la que realmente no puedes explorar con este código, porque tiene que pasar por un transpilador para eliminar sus anotaciones de tipo. Pero se siente extraño una vez que empiezas a acostumbrarte a trabajar en un ecosystem como Deno o Bund donde TypeScript puede ser una característica nativa. Realmente empieza a confundirte con la idea de que estás ejecutando un archivo JavaScript. Empiezas a pensar que estás ejecutando un archivo TypeScript. Y eso no es generalmente bueno para TC39 porque, de nuevo, quieren que estés ejecutando un archivo JavaScript, los motores JavaScript. Eso es lo que es todo. Y esta propuesta ayuda a intentar traer a la gente de vuelta de TypeScript a JavaScript. TypeScript tiene mucha libertad ahora porque ejecuta su propia implementación del lenguaje. Y entonces, cuando, ya sabes, cuando se añaden características a TypeScript, pueden ser puestas donde quieran siempre y cuando tenga sentido y pueda ser utilizada en todas partes. Pero en el contexto de un mundo de tipos de comentarios, ya no es tan cierto. En este código, este tipo de característica simplemente no está disponible. No puedes añadir un post fijo, como satisfies. No puedes establecer una palabra clave arbitrariamente. Y satisfies podría ser relevante solo para TypeScript. Podría no ser relevante para otros sistemas de tipos. Y entonces, ya sabes, el equipo de TypeScript realmente tiene que ceder algo aquí. Y eso no son todo malas noticias, ¿verdad? Este es un problema que el equipo de TypeScript ya ha tenido que abordar al menos una vez, porque, ya sabes, el soporte de satisfies ya está en JSDock. Y, ya sabes, eso funciona bastante elegantemente. Y entonces, tienes esta cosa donde, como, ya sabes, hay todo este TypeScript en el mundo. Ya sabes, cualquiera que esté haciendo TypeScript hoy básicamente está haciendo un proyecto TypeScript con archivos .ts, y hay algunas personas de JSDock. Pero en el futuro, creo que va a ser mucho más como que hay una gran mayoría de personas que

5. Restricciones de TypeScript y Progreso de la Propuesta

Short description:

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.

están haciendo JavaScript con TypeScript. Y ellos representan la mayoría de la gente. Y, sabes, la versión de TypeScript que se ejecuta en el TypeChecker va a restringirse a encajar dentro del alcance de esta propuesta. Y las personas que realmente quieren total libertad sintáctica, todavía tienen la capacidad de hacerlo a través de los archivos .ts. Pero van a ser más de un caso marginal dentro del mundo de JavaScript, en mi opinión. Lo siguiente es que quieren separar las características de tipo versus las características de runtime para realmente especificar que, sabes, un tipo las extensiones de tipo realmente no pueden editar el código que se está ejecutando. Y, como, dentro del contexto de TypeScript, hay características que el equipo de TypeScript lamenta pero sigue apoyando para siempre. Y resulta que cuando miras el diagrama de Venn de estas dos cosas, en realidad son exactamente las mismas cosas. Sabes, las características que TypeScript no quiere necesariamente apoyar son todas características que son características a nivel de expresión.

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

Short description:

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.

el tipo si ves, por ejemplo, un signo igual. Y esto es bueno para una heurística de papel, pero en realidad, hay mucho código JavaScript complicado que necesita seguir existiendo. Por lo tanto, se necesita hacer mucha investigación para descubrir qué problemas conocemos y qué problemas aún no conocemos en este espacio. Pero todavía había suficiente para que la gente dijera, oye, esta propuesta, tiene una oportunidad. Existe la posibilidad de que esto pueda entrar. Y eso es realmente lo que sucedió con la etapa uno.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

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.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
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
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
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.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.