Un documento \u00e8 emerso oggi indicando che Deno smetter\u00e0 di utilizzare TypeScript nel suo codice interno, citando diversi problemi con l’ambiente attuale. I problemi menzionati riguardano, tra gli altri, i tempi di compilazione, la strutturazione e l’organizzazione del codice di TypeScript. Andando avanti, Deno utilizzer\u00e0 JavaScript puro per il suo codice interno.<\/p>\n
Le situazioni sfavorevoli che il team Deno sta attualmente vivendo durante l’utilizzo di TypeScript<\/a> per il suo codice interno sono:<\/p>\n Il tempo di compilazione di TypeScript quando la modifica dei file richiede diversi minuti, rendendo la compilazione continua un processo estremamente lento<\/p>\n<\/li>\n La struttura Typescript che stanno utilizzando nei file di origine che creano l’eseguibile Deno effettivo e le API rivolte all’utente sta creando problemi di prestazioni di runtime<\/p>\n<\/li>\n TypeScript non si sta rivelando utile per organizzare il codice Deno. Al contrario, il team di Deno sta subendo l’effetto opposto. Uno dei problemi menzionati \u00e8 che si sono ritrovati con classi di Body indipendenti duplicate in due posizioni https:\/\/github.com\/denoland\/deno\/issues\/4748<\/a><\/p>\n<\/li>\n Il codice interno e le dichiarazioni TypeScript di runtime devono essere mantenute sincronizzate manualmente poich\u00e9 il compilatore TypeScript non \u00e8 utile per generare i file d.ts<\/p>\n<\/li>\n Stanno mantenendo due host del compilatore TS: uno per il codice Deno interno e un altro per il codice utente esterno anche se entrambi hanno un obiettivo simile<\/p>\n<\/li>\n<\/ul>\n Il team di Deno<\/a> mira a rimuovere tutti i controlli di tipo TS in fase di compilazione e il raggruppamento per il codice Deno interno. Non vedono l’ora di spostare tutto il codice di runtime in un unico file JavaScript<\/a>. Tuttavia, utilizzeranno comunque un file d.ts complementare per conservare le definizioni e la documentazione del tipo.<\/p>\n Vale la pena ricordare che Deno smetter\u00e0 di usare TypeScript solo per il codice Deno interno: il codice utente Deno sar\u00e0 ancora in TypeScript e quindi il tipo controllato.<\/p>\n Sebbene TypeScript sia talvolta visto come una versione migliorata di JavaScript, questo caso mostra che in realt\u00e0 non lo \u00e8. Ha difetti come qualsiasi altra lingua. Uno dei pi\u00f9 importanti \u00e8 il suo lento tempo di compilazione. Mentre i piccoli progetti potrebbero non vedere un enorme picco nei tempi di compilazione quando si passa da JavaScript puro a TypeScript, sar\u00e0 evidente in progetti di grandi dimensioni come un’app React complessa.<\/a> Date le grandi dimensioni del suo runtime, non sorprende che Deno smetta di usare TypeScript.<\/p>\n La sicurezza del controllo del tipo durante lo sviluppo ha i suoi costi al momento della compilazione. Non \u00e8 un caso che il progetto TypeScript abbia un ampio documento su come affrontare e migliorare i tempi di compilazione<\/a>. Uno degli approcci pi\u00f9 interessanti \u00e8 utilizzare Project References<\/a>, che consente agli sviluppatori di suddividere un grosso pezzo di codice TypeScript in pezzi pi\u00f9 piccoli.<\/p>\n La discussione completa sulla decisione di eliminare TypeScript dal codice Deno interno e utilizzare invece JavaScript pu\u00f2 essere trovata in questo documento<\/a>, dove Ryan Dahl e collaboratori discutono del problema, della sua soluzione e di come verr\u00e0 implementato.<\/p>\n\n
Rimozione di TypeScript nel codice Deno interno<\/h2>\n
Leggi di pi\u00f9 sul motivo per cui Deno smetter\u00e0 di usare TypeScript<\/h2>\n