Hoy apareci\u00f3 un documento que se\u00f1ala que Deno dejar\u00e1 de usar TypeScript en su c\u00f3digo interno, citando varios problemas con el entorno actual. Los problemas mencionados involucran tiempos de compilaci\u00f3n de TypeScript, estructuraci\u00f3n y organizaci\u00f3n del c\u00f3digo, entre otros. En el futuro, Deno utilizar\u00e1 JavaScript puro para su c\u00f3digo interno.<\/p>\n
Las situaciones desfavorables que el equipo de Deno est\u00e1 experimentando actualmente al usar TypeScript<\/a> para su c\u00f3digo interno son:<\/p>\n El tiempo de compilaci\u00f3n de TypeScript cuando se cambian archivos lleva varios minutos, lo que hace que la compilaci\u00f3n continua sea un proceso terriblemente lento<\/p>\n<\/li>\n La estructura de mecanografiado que est\u00e1n usando en los archivos fuente que crean el ejecutable real de Deno y las API orientadas al usuario est\u00e1 creando problemas de rendimiento en tiempo de ejecuci\u00f3n.<\/p>\n<\/li>\n TypeScript no est\u00e1 demostrando ser \u00fatil para organizar el c\u00f3digo de Deno. Por el contrario, el equipo de Deno est\u00e1 experimentando el efecto contrario. Uno de los problemas mencionados es que terminaron con clases de cuerpo independientes duplicadas en dos ubicaciones https:\/\/github.com\/denoland\/deno\/issues\/4748<\/a><\/p>\n<\/li>\n El c\u00f3digo interno y las declaraciones de TypeScript en tiempo de ejecuci\u00f3n deben sincronizarse manualmente, ya que el compilador de TypeScript no es \u00fatil para generar los archivos d.ts.<\/p>\n<\/li>\n Mantienen dos hosts compiladores de TS: uno para el c\u00f3digo interno de Deno y otro para el c\u00f3digo de usuario externo, aunque ambos tienen un objetivo similar.<\/p>\n<\/li>\n<\/ul>\n El equipo de Deno<\/a> tiene como objetivo eliminar todas las verificaciones de tipo TS en tiempo de compilaci\u00f3n y la agrupaci\u00f3n para el c\u00f3digo interno de Deno. Esperan mover todo el c\u00f3digo de tiempo de ejecuci\u00f3n a un solo archivo JavaScript .<\/a> Sin embargo, seguir\u00e1n usando un archivo d.ts complementario para conservar las definiciones de tipo y la documentaci\u00f3n.<\/p>\n Vale la pena mencionar que Deno dejar\u00e1 de usar TypeScript solo para el c\u00f3digo interno de Deno: el c\u00f3digo de usuario de Deno seguir\u00e1 estando en TypeScript y, por lo tanto, se verificar\u00e1.<\/p>\n Si bien TypeScript a veces se ve como una versi\u00f3n mejorada de JavaScript, este caso muestra que, de hecho, no lo es. Tiene defectos como cualquier otro idioma. Uno de los m\u00e1s importantes es su lento tiempo de compilaci\u00f3n. Si bien es posible que los proyectos peque\u00f1os no experimenten un gran aumento en el tiempo de compilaci\u00f3n al cambiar de JavaScript puro a TypeScript, se notar\u00e1 en proyectos grandes como una aplicaci\u00f3n React<\/a> compleja. Dado el gran tama\u00f1o de su tiempo de ejecuci\u00f3n, no sorprende que Deno deje de usar TypeScript.<\/p>\n La seguridad de la verificaci\u00f3n de tipos durante el desarrollo tiene su costo en el momento de la compilaci\u00f3n. No en vano, el proyecto TypeScript tiene un extenso documento sobre c\u00f3mo abordar y mejorar el tiempo de compilaci\u00f3n<\/a>. Uno de los enfoques m\u00e1s interesantes es usar Project References<\/a>, que permite a los desarrolladores dividir una gran pieza de c\u00f3digo de TypeScript en piezas m\u00e1s peque\u00f1as.<\/p>\n La discusi\u00f3n completa sobre la decisi\u00f3n de eliminar TypeScript del c\u00f3digo interno de Deno y usar JavaScript en su lugar se puede encontrar en este documento<\/a>, donde Ryan Dahl y sus colaboradores analizan el problema, su soluci\u00f3n y c\u00f3mo se implementar\u00e1.<\/p>\n\n
Eliminaci\u00f3n de TypeScript en el c\u00f3digo interno de Deno<\/h2>\n
Lea m\u00e1s sobre por qu\u00e9 Deno dejar\u00e1 de usar TypeScript<\/h2>\n