Typescript Es TAN LENTO...¿O No Lo Es?

Hola a todos. Me llamo Mike. Estoy muy emocionado de estar aquí y contarles sobre mi amor por TypeScript. Una rápida muestra de manos, porque quiero tener una pequeña idea de todos. ¿Quién no está usando TypeScript? Solo levanten un poco la mano. Sí, estamos virtualmente. No podemos vernos realmente. No sé si realmente están levantando la mano, pero si están levantando la mano y no están usando TypeScript, está totalmente bien. No hay juicio de mi parte, pero la mayoría de la gente está usando TypeScript hoy en día.

Es como la expectativa por defecto, especialmente cuando consideras a las personas que están usando prácticas de desarrollo asistido por agentes, ya sea que estén ejecutando sus aplicaciones en Cursor, Windsurf, cualquier editor que estén usando. La mayoría de las veces, si están generando proyectos y están generando código, va a ser por defecto generar TypeScript. Cuando miras un ecosistema de terceros, es bastante fácil ver por qué TypeScript es tan ampliamente adoptado. Ya sea que estés usando un agente para generar tu código, los tipos le dicen a ese agente si han generado el código correcto o no. Si todavía estás escribiendo código a mano, todavía obtienes el beneficio de eso. Los tipos no cambian nada, dependiendo del código que estén escribiendo. De hecho, hacen las cosas mucho mejor.

Ya sea que estés trabajando con los varios frameworks de Node, todos tienen APIs muy similares. Si estás haciendo, digamos, un sistema de back-end, hay firmas ligeramente diferentes que podrían ser confusas si saltas entre múltiples frameworks. Si estás trabajando con herramientas que equilibran un poco el front-end y el back-end, ya sea que estés trabajando con cosas como Next y Nux, que tienen un poco de ambos dentro de sus bases de código, tener esos tipos allí hace que la transición entre el frente y el fondo sea mucho más fácil de hacer. Y así, los tipos y tener un sistema de tipos en su lugar realmente hace que todo esto sea esencial. O hay un inconveniente en todo esto. TypeScript es un poco lento. Estoy seguro de que no soy la primera persona en mencionar esto o notarlo. TypeScript es muy, muy lento. Vamos a hablar de eso.

Así que, como dije, me llamo Mike. Trabajo en una empresa llamada Prisma. Hago algunas cosas de DevRel. Hacemos bases de datos. Si quieren seguirme en Blue Sky, es mhardington.

Pero volvamos a la parte de TypeScript. Dije que TypeScript es lento. Y esto es cierto. TypeScript es lento. En situaciones muy únicas, sin embargo. Y lento en sí mismo como palabra puede significar muchas cosas diferentes. Entonces, ¿qué quiero decir con lento? Bueno, tenemos dos casos que queremos ver hoy. Velocidades de construcción y velocidades del editor. Y me voy a centrar en las velocidades de construcción durante gran parte de esta charla.

Porque siento que esto es algo que la gente podría no creer que realmente existe. Especialmente si estás trabajando localmente. La velocidad de construcción realmente no importará. ¿Con qué frecuencia estás construyendo todo tu proyecto? Pero cuando estás en un entorno CI, las velocidades de construcción probablemente pueden ser tu mayor fuente de frustración. ¿A quién le encanta esperar 20 minutos para que su CI complete para desplegar una pequeña aplicación? ¿O incluso una aplicación un poco más compleja?

Aquí es donde las cosas se Aquí es donde las cosas se vuelven realmente... Aquí es donde las cosas se vuelven realmente importantes. Y muy... Aquí es donde las cosas se vuelven muy impactantes. Porque si no tenemos buenas construcciones... Esto es donde las cosas se vuelven muy impactantes. Porque si tenemos construcciones lentas, simplemente va a significar que enviamos cosas más lentamente. Así que, comencemos con este pequeño hecho. Decir que tu construcción es lenta no significa que lo estemos atribuyendo a una sola herramienta. Estoy diciendo que TypeScript es lento y tus construcciones son lentas debido a TypeScript. Pero realmente, es una especie de culminación de algunas cosas diferentes. TypeScript solo puede hacer tanto. Node solo puede hacer tanto. ¿De dónde viene realmente esta lentitud? Así que, veamos una aplicación que tenemos aquí aquí. Y lo que tenemos aquí es una aplicación relativamente compleja. Hemos generado un par de archivos. Hemos trabajado con un agente.

Probablemente estamos creando todo esto por nosotros mismos. Si piensas en cualquier proyecto grande que ha existido durante mucho tiempo y estás usando tipos, podrías tener algunos de estos proyectos. Podría ser legado. Lo que hay en todos estos archivos realmente no importa. Pero tenemos muchos de ellos. Y vamos a intentar ejecutar una construcción rápidamente.

Así que, vamos a cronometrar esto y realmente ejecutar la construcción. Podemos ver que solo vamos a ejecutar el comando TSC no emit. Así que, esencialmente solo vamos a verificar todos los tipos a través de este proyecto. No estamos técnicamente haciendo una construcción completa. Así que, vamos a aislarlo a TypeScript en sí mismo. Esto va a tomar un poco. TypeScript, está pensando, está tratando de mirar nuestro proyecto. Está tratando de ver todos los archivos que tenemos. Realmente cuestionando sus elecciones. Haciéndome cuestionar mis elecciones en la vida.

Va a tomar un tiempo. Vamos a volver a esto porque solo tenemos tanto tiempo. Te voy a decir ahora mismo que esta construcción va a tomar mucho tiempo. Unas cuantas veces que lo he ejecutado antes, es aproximadamente entre 115 y 120 segundos. Lo cual en un portátil relativamente bien equipado se siente un poco extraño. ¿Por qué un proyecto que solo está haciendo una verificación de tipos tarda tanto en ejecutarse? Y te diré una razón por la que está tardando tanto. Es simplemente el tamaño de este proyecto.

TypeScript solo puede procesar una cantidad limitada de archivos a la vez. Y si tenemos un proyecto grande, va a tardar un poco en procesarlo. Vamos a comprobar si ya ha terminado. Todavía no ha terminado.

Entonces, si nuestro proyecto es grande y tenemos muchas cosas que estamos tratando de verificar, ¿cuál es una manera fácil de reducir el número de archivos y aislar las cosas? Dejamos de construir proyectos grandes. Un poco en broma, pero también un poco en serio aquí. Si dejamos de meter todo en un solo proyecto, realmente vamos a poder ver una gran mejora en nuestras velocidades de construcción.

Vamos a verificar esa construcción anterior. Oye, es un poco más rápido, 109 segundos. Aún no es ideal. Entonces, si dejamos de construir proyectos grandes, ¿cuál es la opción? Construimos cosas más pequeñas y las construimos de forma aislada usando monorepos. Los monorepos son una configuración perfecta para esto porque podemos realmente tomar esos módulos grandes y todos esos fragmentos y simplemente aislarlos en subpaquetes más pequeños. Suena mucho más complicado de lo que podría ser, pero la mayoría de los gestores de paquetes soportan este tipo de estructura. Lo llaman workspaces, pero esencialmente estamos haciendo lo mismo.

Entonces, si nos movemos a este nuevo proyecto, lo abrimos, podemos echar un vistazo a cada uno de esos módulos y la aplicación principal en sí misma es su propio proyecto con su propio package JSON, su propio script. Todo aquí está completamente aislado. Podemos echar un vistazo al package JSON por sí mismo y solo tiene ese paquete o solo tiene esa clave de workspace con una entrada que apunta a todos los paquetes dentro del directorio de paquetes.

Ahora, si queremos confirmar y ver cuál es la diferencia en las velocidades de construcción, ejecutemos nuestro tiempo nuevamente y vamos a ejecutar la aplicación principal, que va a incorporar todos los tipos de los que dependemos. Ejecutemos esto por un segundo. Y volvamos a las diapositivas y vamos a dejar que esto se sincronice por un poco. Ahora, te daré una pista, la velocidad en realidad no es mucho mejor.

Y hay una razón muy importante para esto. Hacer cosas con workspaces y tener esa configuración mínima de modelo repo en realidad no beneficia demasiado. Si abrimos nuestro editor nuevamente, ¿cómo estamos realmente obteniendo todos estos paquetes dentro de nuestra aplicación principal? Bueno, te daré una pequeña pista. La forma en que lo estamos haciendo es usando esta entrada de path. Ahora, esto requerirá que sepamos un poco cómo funciona TypeScript. Y si tienes un proyecto grande donde estás importando un montón de cosas desde una configuración de proyecto único, como nuestra primera demostración, cuando te mueves a una configuración de modelo repo, podrías pensar, vamos a usar algo llamado un alias de path.

Y un alias de path te permite reescribir todas tus importaciones para usar este tipo de sintaxis similar a node, o esta sintaxis similar a módulo, donde estás haciendo referencia a un paquete, y luego a una cosa específica que quieres importar. Pero esto es solo un alias, está literalmente en el nombre de la clave alias de path. Cuando TypeScript realmente procede a intentar verificar los tipos de todo. No está haciendo nada diferente, solo lo está apuntando a una dirección diferente.

Así que todos nuestros paquetes realmente solo apuntan de nuevo a otra cosa. Así que no hemos cambiado nada, todavía estamos haciendo resolución basada en archivos, que es realmente solo el punto doloroso de lo que son los paths. Y si miramos los documentos de TypeScript, solo decimos que vemos el desde allí desde la referencia de ello, un path es una serie de entradas, que son importaciones remapeadas a la búsqueda de ubicaciones relativas en relación con la URL base establecida o al archivo ts config en sí mismo path te permite declarar cómo TypeScript debería resolver una importación. No cambia realmente cómo se resuelve esa cosa, solo dice ve a mirar en esta ubicación.

Y los tipos son básicamente lo suficientemente inteligentes como para decir tengo esta clave para este paquete, voy a ir a mirarlo en esta ubicación. Así que esto no resuelve realmente ninguno de nuestros problemas. Solo se traduce a esto, es un alias, no está realmente resolviendo nada. Así que si se le pide a TypeScript que resuelva algo usando ubicaciones de archivos, no tenemos realmente ningún aislamiento de código y no obtenemos realmente los principales beneficios que nos gustaría obtener. Aquí es donde entran los workspaces. Y este es nuestro siguiente paso para adoptar una buena configuración de monorepos, pero también hacer que TypeScript sea más rápido.

Y está soportado en todos los principales gestores de paquetes, npm, yarn, pnpm, bun. Todos estos están integrados. Todos estos gestores de paquetes tienen soporte integrado para workspaces.

Lo que es un workspace, si nunca lo has usado antes, es solo una entrada dentro de tu package JSON que apunta a una ubicación donde te gustaría decirle a tu gestor de paquetes, estos son subproyectos dentro de este workspace.

Así que en este caso, tenemos dos ubicaciones que queremos que se consideren workspaces, o parte de este workspace, tenemos una app, así que vamos a listar cada carpeta dentro de apps. Y luego tenemos un packages para que podamos dividir lo que se considera proyectos de nivel superior de tipo app y paquetes que se usan dentro de esas apps.

Cuando procedemos a instalar todas nuestras dependencias, realmente podemos decirle a cada uno de esos paquetes, me gustaría usar la biblioteca ABC o uno, dos y tres, referenciarlos usando una sintaxis diferente.

En lugar de dar un número de versión, solo vamos a decir workspace. Y node actuará, tu node en tu gestor de paquetes realmente los enlazará a los node modules. Ahora todos tus paquetes se resuelven como si vinieran de node modules, y si fueran solo tu viejo paquete npm.

Así que eso es genial, funciona bien, pero no resuelve todo todavía. Y ahí es donde llegamos a las referencias de proyecto. Porque si tenemos todas estas cosas enlazadas en nuestros node modules, ¿cómo nos aseguramos de que esos tipos estén incluidos? ¿Y cómo nos aseguramos de saber de dónde vienen todos estos paquetes?

referencias de proyecto? ¿Alguien ha oído hablar de referencias de proyecto antes? De nuevo, estoy actuando como si esto fuera en vivo, y pudiera verte. Lo más probable es que la mayoría de la gente no haya oído hablar de referencias de proyecto. Fue algo que salió en TypeScript tres, y solo lo había oído el año pasado.

Las referencias de proyecto son una forma de referenciar otros proyectos en un proyecto de TypeScript. Bastante, bastante autoexplicativo. Así que si pensamos en nuestro punto de dolor de usar alias de path, recuerda, sigue siendo una mentira. Estos no resuelven ninguno de nuestros puntos de dolor. Estos no hacen que TypeScript sea rápido.

Sin embargo, esto puede hacer que TypeScript sea rápido, asegúrate de que estoy usando mis palabras correctamente, puede hacer que tu TypeScript sea rápido. Lo que estamos haciendo aquí es en lugar de apuntar a un proyecto real, como a un punto de entrada real como hicimos con los paths, realmente estamos apuntando de nuevo a un directorio que tiene un TS config allí.

Así que aunque esto se ve muy similar, es fundamentalmente un enfoque diferente de cómo podemos tener TypeScript pre todo en aislamiento. Así que la propiedad path es realmente una referencia a otro TS config. Y un proyecto que quieres solo o cualquier otro archivo de configuración que quieras decirle a TypeScript, este es un subproyecto, esto es algo que se va a construir, aislado de todo lo demás.

Así que referencias, todo esto simplemente funciona. Y volvamos a nuestro editor. Y oye, mira, nuestra construcción de antes realmente se completó, puedes ver que tomó alrededor de 106 segundos. La primera construcción tomó alrededor de 109. Así que una ligera diferencia.

Volvamos a esta, que en realidad está usando workspaces, workspaces y referencias de proyecto. Así que podemos ver que en lugar de usar paths, tenemos todas estas referencias configuradas y las estamos ejecutando aquí. Así que cada una de estas, si vamos a ver este archivo en sí, en realidad nos va a señalar un directorio con un TS config. config. Vamos a ejecutar nuestra construcción. Y nos quedaremos aquí, esperando un segundo. Y la construcción en realidad se completa en aproximadamente nueve segundos.

¿Qué pasa aquí? ¿Cómo pasamos de una construcción significativamente más larga a algo que es corto? Bueno, hay un poco de magia detrás de escena aquí. Pero lo que realmente podemos hacer es con referencias de proyecto, almacenar en caché los resultados de esas construcciones. Así que podríamos tenerlos almacenados localmente en disco en nuestro proyecto. Y nuestra construcción podría detectar si algo ha cambiado. No, entonces no necesitamos ejecutar nada, simplemente podemos omitirlo.

Y hay algunas otras cosas sobre esto que también son interesantes. Así que si volvemos a nuestro ejemplo anterior, sé que tenemos una función aquí que se usa en todas partes. De hecho, probablemente podríamos simplemente tomar todo el proyecto y encontrarla. Pero esto podría darnos falsos positivos o lo que sea. Tenemos TypeScript aquí para ayudarnos, podríamos simplemente pedirle todas las referencias.

Te das cuenta, probablemente no lo ves aquí, pero tengo un pequeño error dentro de mi editor diciendo que no se encontraron resultados. Pero acabamos de ver que en realidad lo tenemos en montones de lugares por todo este proyecto. Bueno, si volvemos a nuestra otra demo, recuerda, esto está usando referencias de proyecto. Vamos a abrir esa misma función. Y luego vamos a verificar que de hecho está en todas partes.

Vamos a pedirle a TypeScript que nos dé todas las referencias. Así que toma un poco de tiempo, principalmente porque es un proyecto grande. Cada editor va a ser un poco más lento, pero en realidad nos está dando los resultados correctos. Solía decir que esto era más correcto, pero me corrigieron. En realidad nos está dando los resultados correctos. No hay más corrección, es simplemente como debería haber sido. Originalmente, el otro ejemplo estaba equivocado.

Así que las referencias de proyecto son un gran asunto que pueden hacer que tu compilador sea mucho más rápido, pueden almacenar en caché los resultados de todas tus construcciones. De esa manera no tienes que recalcular cosas si no han cambiado. Y hace que la velocidad de construcción para cada proyecto sea mucho más rápida. Ahora hay otra cosa que quiero mencionar que la gente podría pensar que no es tan importante. Y esa es la velocidad del editor. Ya vimos que en un proyecto grande, el propio LSP de TypeScript puede ser bastante lento. Pero quiero hablarte sobre otra demo. Puede que no parezca gran cosa, pero probablemente te hayas enfrentado a esto antes. Y así cuando alguien intenta ser ingenioso, e intenta ser ingenioso con sus tipos, y trata de ser ingenioso con cómo construyen las cosas, y termina convirtiéndose en una tomfoolery de TypeScript. Hay otras palabras que podemos llamar a esto, pero verás a lo que me refiero.

Así que tengo un proyecto por aquí. Y lo que tenemos es un tipo de rutas profundamente anidadas que estamos haciendo en el back end, estamos creando un montón de cosas con TRPC. Esto no es culpa de TRPC. Es solo que alguien estaba siendo ingenioso. Así que todos estos diversos endpoints que podríamos alcanzar, si vamos a nuestro front end, tenemos un montón de tipos adicionales. Y luego tenemos esta cosa aquí abajo, completion target. Vamos a intentar activar la finalización aquí. Así que diremos completion target. Vamos a esperar. Oh, está bien. Tomó un poco. Vamos a hacer otro. Está bien. Y hay este retraso cada vez que intentamos activar la finalización. No es específico de esta biblioteca en estos proyectos. Si estás usando algunos ORMs varios que existen por ahí, si estás haciendo evaluación en vivo de todos esos tipos, si estás haciendo algo con un modelo y un esquema, esa evaluación en vivo puede ser bastante lenta. No parece que debería ser tan impactante. Pero si estás esperando tanto tiempo, cada vez que intentas escribir algo, puede ser bastante frustrante mientras esperas que tu editor te alcance.

Sin embargo, esto se puede resolver. Tenemos el mismo proyecto por aquí. Pero lo que tenemos es un script de pre-construcción. Así que este script de pre-construcción en realidad va a pasar y ejecutar una construcción de nuestro proyecto. Puedes ver que en realidad tenemos todas las diferencias de archivos por aquí. Lo que esto está haciendo es pre-compilar todos los diferentes tipos que podríamos estar calculando dentro de nuestra aplicación. Podrías hacer algo como un script de instalación de host para hacer esto. De esa manera no es algo que tengas que configurar cada vez o incluso recordar hacer. Pero en lugar de tener esa espera de varios segundos, en realidad tenemos algo que devuelve prácticamente de inmediato. Y si puedes escribir correctamente, como yo no puedo, obtienes la finalización de inmediato. Es una configuración bastante agradable y te da toda esa información de inmediato al alcance de tu mano. Es una pequeña nota al pie sobre esto, pero importa mucho más a medida que comienzas a escribir tus proyectos.

Así que no hagas evaluaciones en vivo de tipos si tu proyecto es muy grande. Ten algo allí que pueda pre-calcularlos. Intenta no anidar tus tipos demasiado profundamente porque simplemente no es bueno. Pero lo más probable es que probablemente no enfrentes esto a menos que estés trabajando en una base de código muy grande y madura que ha existido durante varios años. Así que pre-construye si puedes. Si tienes muchos tipos, puede ayudarte.

Esto nos lleva al final, pero hay algo que necesita ser mencionado. Y eso es el port de TypeScript a Go. TypeScript Go, TS Go, TypeScript Native, como sea que termine llamándose el paquete final, pone una pequeña advertencia sobre esto porque esto podría cambiar por completo. Podríamos tener algo completamente diferente, y ninguna de estas preocupaciones realmente importará más. Todavía falta un poco. TypeScript estable ahora mismo es 5.9.3. TypeScript, el port a Go, la versión nativa está programada para la versión siete. 5.0 salió en 2023.

Así que la vida de una versión principal en TypeScript es muy larga. Todavía falta un poco, pero soy muy optimista. De hecho, ejecuto TypeScript, la versión nativa, como mi motor de finalización, como mi motor LSP, y ha sido significativamente más rápido. He realizado algunas pruebas con algunos de estos proyectos, y no ha sido una mejora tan grande como esperaba. Pero realmente no importa porque tener TypeScript nativo no elimina el hecho de que podríamos estar haciendo nuestras construcciones en CI. Y con recursos limitados en esa máquina, todavía necesitamos encontrar formas de afinar nuestra configuración de proyecto y afinar cómo se calcula la velocidad de todo.