Qual è la motivazione dietro TypeScript?

A me sembra che si tratti di un linguaggio basato sulla classe tipicamente statico che viene compilato in JavaScript. È una buona idea e una che ha altri.

I vantaggi dovrebbero essere ovvi per chiunque sia sviluppato in linguaggi basati su classi sia staticamente sia in JavaScript:

• In primo luogo, un compilatore. Essere in grado di verificare i problemi di ovvia correttezza causati da errori di battitura o incuria prima della distribuzione è qualcosa che la maggior parte degli sviluppatori dà per scontato fino a quando non devono fare lo sviluppo web e poi improvvisamente viene tirato fuori da sotto i loro piedi. I browser sono progettati per rendere piacevole l'esperienza di navigazione a scapito delle corrette funzionalità di test e debugging, e la soluzione standard, JSLint, non sostituisce un compilatore reale in quanto perde alcuni problemi di ovvia correttezza e mescola un sacco di lamentele di checker stile in con i suoi rapporti. Avere un compilatore reale è un enorme passo avanti.
• E lungo linee simili, un sistema di tipi . I sistemi di tipo migliorano il tuo codice rendendolo più facile da leggere (sai esattamente cosa viene passato in una funzione, e cosa può fare, semplicemente guardando l'elenco dei parametri, ad esempio) e applicando un certo grado di correttezza alla compilazione tempo. (Se ti aspetti un tipo di oggetto specifico, passare un intero è un errore. JavaScript ti permetterà di farlo e poi esploderà quando proverai ad eseguirlo, un compilatore con un sistema di tipi lo prenderà e segnalerà un errore per si.)

Quindi, come vediamo, l'idea di base è molto buona. Detto questo, non posso dire nulla sulla lingua stessa perché non ne ho esperienza. Ma ho usato Smart (collegato a sopra) e l'ho trovato uno strumento incredibilmente potente e utile per lo sviluppo web.

Ci sono alcuni buoni motivi per usare TypeScript, per quanto posso vedere. Prima di tutto, come ha detto Mason Wheeler, un compilatore . O piuttosto tutto il controllo di un compilatore. JSLint e altri strumenti sono utili, ma mancano alcuni problemi e a volte sono semplicemente sbagliati. Certamente accolgo con favore questa "innovazione".

Quindi esiste un vero sistema di tipi , che migliora la leggibilità e applica i tipi corretti. Dopotutto, questo aumenta la velocità di sviluppo.

Per me, una delle grandi cose è il supporto degli strumenti . Questo è probabilmente un effetto collaterale del sistema di tipi, ma comunque ottimo. E davvero necessario, dato che il supporto di strumenti JavaScript è oltre utile.

TypeScript tenta di estendere JavaScript . Il compilatore genera JavaScript davvero piacevole. Inoltre, segue le proposte ECMAScript 6 . (Ad esempio sintassi della funzione freccia , valori di default dei parametri , moduli e così via.

Rende più facile lavorare con moduli e classi . In realtà è possibile e abbastanza comune lavorare con classi e moduli in JavaScript, ma richiede una certa quantità di codice boilerplate. E non è davvero facile da leggere. TypeScript consente di scrivere istruzioni di classe, interfaccia e modulo proprio come in Java o C #, il che è di gran lunga più semplice se me lo chiedi.

Dopotutto, è ancora solo JavaScript . Non è necessario imparare una nuova lingua o sintassi. L'unica cosa che aggiunge è il sistema di tipo opzionale (che è ottimo e in ritardo).

Poi c'è la "library delle definizioni" , il che significa che posso utilizzare tutte le mie librerie JavaScript senza riscrivere, o persino rattopparle. Tuttavia, ora ho il sistema di tipo aggiuntivo.

Ci proveremo sicuramente!

Un'ultima cosa, non c'è competizione tra HTML5 e TypeScript. Ma questa è un'altra storia.

We had JavaScript, then we had Flash, then we had Silverlight and then HTML5 ownd them all.

Questo è semplicemente NON vero . Html5 non li possiede, introduce nuovi markup che semplificano l'utilizzo di contenuti multimediali ed esplora i vantaggi dei browser di nuova era (come l'utilizzo dell'accelerazione hardware durante il rendering di html).

So what is the motivation behind TypeScript?

Le motivazioni potrebbero essere motivate da ragioni per utilizzarlo. Tutte le funzionalità di TypeScript: controllo statico, navigazione basata su simboli, completamento di istruzioni e refactoring del codice sono motivi molto validi per considerarlo.

Inoltre, offre classi, moduli e interfacce per aiutarti a creare componenti robusti. Queste funzionalità sono disponibili in fase di sviluppo per lo sviluppo di applicazioni ad alta affidabilità, ma sono compilate in JavaScript semplice.

Può essere trattato come uno strumento per gestire lo sviluppo di javascript piuttosto che un nuovo linguaggio totale che compila in JS. Non vuole essere un linguaggio di sviluppo lato server come Dart, e non ha una sintassi diversa come CoffeeScript. Non voleva prendere un linguaggio popolare (ed è una libreria di base) e compilarlo a JS come GWT o script #. Anche TypeScript segue la stessa sintassi di "classe" proposta per la prossima versione di JS.

Penso che la maggior parte dello sviluppo web sia fatto oggi utilizza javascript reale, solo dal lato client. Lingue o strutture come Dart, GWT non sono adatte a questo. Se vai per coffeescript, viene fuori una nuova sintassi. E devi capire sia il coffeescript che JS. Mentre TypeScript aggiunge semplicemente alcune funzionalità aggiuntive orientate al tipo, combinate in JS, che salvano gli sviluppatori dagli errori specifici del tipo (che è una grande porzione di errori JS) e forniscono agli strumenti di sviluppo maggiori informazioni sull'intento degli sviluppatori.

Questo approccio non è nuovo. Vai alla sezione "Static Typing" di

Questo articolo indirizza la tua query- link

Penso che sia uno sforzo per trasformare un pezzo di crap (javascript) condiviso e inaffidabile in un linguaggio proprietario che possa essere effettivamente utilizzato per progetti sostanziali.

Dovrebbe essere paragonato a GWT, che ha una serie di obiettivi simili ma ha adottato un approccio più pulito rendendo javascript non parte della lingua; e con applet Java o Flash, che adottano l'approccio molto pulito di definire un ambiente runtime completo indipendente dal browser.

La tua opinione può variare, ma penso che sia condannata a patto che dipenda dai browser fornendo nativamente le (varianti, incoerenti) implementazioni javascript e modelli DOM.