Per i principianti, v8 precede (pubblica conoscenza di) TypeScript di diversi anni, TypeScript non è di Google, Google non è investito in esso, TypeScript è lontano da uno standard del settore e Google ha la sua lingua che prova a riempire una nicchia simile (Dart). E poi c'è il problema che nessuno distribuisce TypeScript ai siti web, è progettato per essere compilato su JavaScript ed è quello che fanno tutti. Ma non assumiamo nessuna di queste cose.
Non credo che ci siano guadagni in termini di prestazioni. Proprio perché è interoperabile con JavaScript, il sistema di tipo TypeScript non offre praticamente nessuna garanzia difficile . Certo, consente il completamento automatico praticabile nella maggior parte dei casi, ma non garantisce che i tipi siano corretti al 100%. Con le asserzioni di tipo ( <Type> something ), puoi copiare gli errori di tipo oltre il controllo di tipo e non è nemmeno un errore di runtime. Il codice TypeScript può e chiama nel codice JavaScript, che potrebbe violare qualsiasi garanzia in modi arbitrari. Quindi V8 non può contare su nulla che asserisca i tipi TypeScript.
I compilatori JIT possono già capire tutte le informazioni di cui hanno bisogno per l'ottimizzazione con la strumentazione runtime. TypeScript non può eliminare staticamente la necessità di tali controlli, quindi non fornisce alcun valore aggiuntivo.
Forse i tipi potrebbero dare al compilatore baseline un'ipotesi iniziale per le ottimizzazioni speculative (che verrebbero sovrascritte dai dati di profilazione runtime in fasi successive), ma:
- Il fatto che ci sia un vantaggio è una speculazione completa in questa fase.
- Il controllo dei tipi e l'inferenza richiedono tempo e il tempo è prezioso per l'esecuzione di base. I browser vogliono iniziare a eseguire gli script il prima possibile.
- Dovrebbe valere la complessità e lo sforzo di implementazione in più.
- guarda il primo paragrafo.