Differenze tra TypeScript e Dart [chiuso]

Microsoft ha recentemente presentato Typescript, un nuovo linguaggio di programmazione simile a JavaScript. Qualche tempo fa, ho sentito parlare di Dart, un nuovo linguaggio di programmazione creato da Google per risolvere problemi relativi a Javascript come prestazioni, scalabilità, ecc.

Lo scopo di entrambe le nuove lingue mi sembra lo stesso. Cosa ne pensi?

Gli scopi delle lingue sono gli stessi?

Quali sono le reali differenze su di loro?

Citando Bob Nystrom :

TypeScript sembra carino se ti piace la semantica JS o hai una base di codice JS di grandi dimensioni in cui sei investito ma hai problemi di manutenzione su larga scala. Il suo percorso per il successo è molto più agevole poiché è (principalmente?) Retrocompatibile con JS.

Il dardo sta prendendo una scommessa più rischiosa. È più lontano da JS in molti modi, penso, per lo più, buono come programmatore quotidiano di Dart, ma aumenta la barriera dell'entrata. Ma in cambio di quella più alta barriera d'ingresso, ottieni:

• Agitazione dell'albero
• Getter e setter (anche se presumo che TypeScript li otterrà alla fine)
• Sovraccarico dell'operatore
• Ambito blocco reale, nessun sollevamento, no IIFE s
• Una VM nativa
• Semantica di uguaglianza sana
• Nessuna strana follia di conversione implicita
• Legato in modo lessicale this ovunque
• mixins
• annotazioni
• Un sistema di importazione
• Operatori di sottoscrizioni definiti dall'utente
• Generici, con reificazione
• specchi
• Migliori classi di raccolta
• Un'API DOM più pulita

Inoltre, scrive in http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd :

Faccio parte del team Dart di Google, quindi lo guardo naturalmente da quel punto di vista. Ecco alcune cose a caso che hanno attirato la mia attenzione, paragonandole principalmente a Dart. Ho passato solo pochi minuti a scremare, quindi non prenderti troppo sul serio ...

Nessun generico

Immagino che alcuni tipi siano migliori di nessun tipo, ma è davvero difficile perderli. TypeScript ha tipi di array incorporati e tipi di oggetto coprono alcuni casi d'uso di tipo "map". Ma non essere in grado di definire i propri tipi generici è una seccatura. I documenti dicono che una volta aggiunti, i generici funzioneranno usando la cancellazione del tipo, che è quello che mi aspetterei dato che è in stile "compilare in JS leggero", ma anche questo può essere una seccatura. È bello poter fare cose con i tuoi argomenti di tipo in fase di esecuzione a volte.

Tutti i tipi sono nullable

Il dardo è allo stesso modo. Mi rende triste in entrambi i casi.

La sintassi dell'annotazione del tipo è buona

Quasi ogni lingua con annotazioni di tipo opzionali (ML, Scala, F #, Kotlin, ecc.) Va con "postfix after a:. Dart cerca di usare le annotazioni di tipo C che causano alcuni cattivi casi angolari. Mi piace ciò che TypeScript ha qui, in particolare la sintassi per i tipi di funzione:

function takeCallback(callback : (n : number) => number)
{ ... }

Le interfacce sono tipicamente strutturate, le classi sono tipicamente nominate

Ha senso dato che è JavaScript, ma sembra abbastanza pulito. Essere in grado di implementare implicitamente un'interfaccia è bello. Ma TypeScript non sembra lasciarti andare dall'altra parte: data una classe, non puoi creare un nuovo tipo compatibile con esso senza estenderlo concretamente a causa delle cose del marchio. In Dart, grazie alle interfacce implicite, puoi farlo.

Il miglior tipo comune può fallire

Ciò significa che si tratta di un errore di tipo:

[1, true]

È possibile sovraccaricare le interfacce mediante la firma dei parametri

Questo è davvero bello perché ti dà un modo per avere un flusso di inferenza di tipo più preciso attraverso una chiamata di funzione che fa un cambio di tipo dinamico. Per esempio:

interface Doubler {
  double(s : string) : string;
  double(n : number) : number;
}

Con ciò, quando il compilatore vede raddoppiare una chiamata, può fornire correttamente un tipo di ritorno preciso basato sul tipo di argomento dedotto. Quello che non sono sicuro è come implementare effettivamente una classe che implementa quell'interfaccia e rende felice il controllo del tipo. In realtà non puoi sovraccaricare metodi concreti e il mio tentativo di cinque minuti di renderlo felice con il controllo dinamico del tipo non sembra funzionare.

C'è una sintassi dedicata per i tipi di array

Ha senso poiché non ci sono generici. È anche bello e conciso, il che è buono, ma personalmente preferisco i generici per tutti gli usi piuttosto che le raccolte di casi speciali una tantum.

Non c'è downcasting implicito

Una delle caratteristiche del sistema di tipo più insolito di Dart è che la compatibilità delle assegnazioni è bidirezionale: è possibile effettuare il downcast senza preavviso. A parte il tipico caso speciale di assegnazione a / da qualsiasi (dinamico in altre lingue), TypeScript non lo consente. Devi digitare assert. Personalmente, mi piace l'approccio di TypeScript qui.

Freccia funziona e questo lessicale

Questa è solo la maternità e la torta di mele. Mi piace. (Anche Dart ha questo, e questo è sempre legato in modo lessicale.)

Nel complesso, sembra piuttosto pulito. Se vuoi esattamente la stessa semantica JS (buona e cattiva) ma vuoi anche un'infarinatura di tipi, TypeScript sembra decente. È come il compilatore di chiusura ma con una sintassi migliore.

Se vuoi qualcosa che sia un passo più aggressivo lontano dalla sintassi e dalla semantica di JS, allora sembra che TypeScript non sia quello.

Mentre la domanda era "Gli scopi delle lingue sono gli stessi?", La vera domanda è: "Come possiamo migliorare la programmazione web da dove siamo?" .

Entrambi i progetti cercano di farlo considerando

• linguaggio di programmazione (TypeScript fa un passo piccolo ma molto pulito, Dart fa la mossa più rivoluzionaria che è ancora in movimento)

• interoperabilità con il codice js esistente (0 transizione in TypeScript che si compila in js, complicata in Dart, poiché 2 VM parlano tra loro)

• pratiche di ingegneria del software (solo Dart, componenti Web e Shadow Dom)

Negli ultimi 3 giorni mi sono tuffato in profondità in Dart e poi in TypeScript. La mia base di codice CoffeeScript è passata alle righe di codice degli anni 2000, troppo per essere gestita con CoffeeScript delizioso ma troppo soffice. I problemi che ho dovuto affrontare erano che CoffeeScript non ha funzionalità che i linguaggi progettati per la programmazione su media e larga scala hanno: interfacce, moduli, sicurezza dei tipi. Ma c'era una ancora molto più grave problema con caffè e js: I js "questo puntatore" stranezza influenzato la mia sanità mentale e CoffeeScript non aiuta nulla qui.

Quindi qui i miei risultati dopo 3 giorni di valutazione e utilizzo:

Dardo

Ho studiato a fondo il tutorial, leggendo 1 libro, sfogliando il 2 ° libro e provando le demo. Ho pensato, Dardo che è il futuro . Quindi ho provato a migrare la mia app su Dart. Era il mio entusiasmo che è passato da 100 a 10. Ecco perché:

1. Il Dart Editor è l'unico modo per programmare Dart. Sebbene esistano plugin per Sublime Text, non forniscono funzionalità come intellisense, completamento del codice (correggimi se sbaglio). Il Dart Editor è comunque in qualità pre alpha. Mentre supporta cose magiche da supercool come l'aggiornamento della pagina Web quando si modifica il file CSS (! Davvero fantastico) si blocca o si blocca più volte al minuto. Quindi digiti 5 lettere e 2 volte devi aspettare 2 secondi o 15 secondi tra la digitazione. E avevo un progetto con alcune righe di codice, quindi non volevo aspettare che cosa succedesse quando sono presenti le righe 1000s. Spostato un file da una cartella all'altra all'interno di Dart Editor, crash. Debugcon Dart Editor è a prima vista migliore di tutti gli strumenti di debug js che conosco (Chrome è la mia scelta), ma mancano ancora troppe cose: nessuna finestra immediata (questo rende js il debug molto meglio al momento), niente orologi.

2. Politica e possibilità di fuga : alcuni sostengono che Apple, MS e Firefox non forniranno mai VM Dart. Bene, non ne sono così sicuro, ma almeno per Apple questo sembra al momento molto sicuro. Per gli altri è più probabile del contrario. Quindi nessun problema, possiamo convertire Dart in JavaScript. Il modo in cui funziona questa integrazione è davvero eccezionale, Dart mantiene uno stub js che mantiene il codice js collegato al Dart Editor, quindi print()un'istruzione appare ancora in Dart Editor, interessante. Ma ecco che arriva il ma: l'impronta di tale codice convertito è alta. 150 kB circa (prima della minificazione). Non ho scavato troppo nelle dimensioni esatte, quindi non mi inchiodare su questo.

3. Maturità linguistica . A parte i problemi troppo seri con Dart Editor che mi appare in faccia 3 volte al minuto, ho anche trovato inaccettabile che ogni fonte di codice Dart che trovi utilizza un Dart diverso. La lingua cambia ogni giorno. Hai trovato un post di 5 settimane fa? È obsoleto. Provi gli esempi dal tutorial di Google? Almeno 1 campione non viene compilato da quando un'API è stata modificata. Anche le cose banali, come collegare un evento a un elemento DOM, sono in buone condizioni .

4. L'integrazione con le librerie js esistenti è un po 'complicata. 2 VM devono comunicare qui, è complicato.

In conclusione, non puoi usare seriamente Dart da oggi e tuffarti non è troppo divertente a causa di 1 e 3. Entrambi i punti si dissolveranno nel tempo. Circa il punto 2, Google ha pubblicato alcuni giorni fa benchmark delle prestazioni dimostrando che i loro j compilati sono migliori dei j scritti a mano. I miei complimenti, ottimo lavoro. Il tempo di caricamento potrebbe essere ancora indietro a causa del problema dell'impronta, come detto. Tuttavia, se il codice footprint viene utilizzato da molti siti, potrebbe essere disponibile anche nella cache e voilà, scomparendo.

Quindi: considero Dart un grande progetto, usarlo al momento comporta una buona porzione di rischio imprevedibile e ci vorrà quest'anno per portarlo a un buon livello stabile.

Dattiloscritto

La valutazione di TypeScript è molto semplice, richiede 1 o 2 ore e sai tutto. Leggendo il documento sulle specifiche della lingua e rivelando un breve libro (rivelato da TypeScript), sapevo tutto e ho iniziato a programmare. Sono stato quindi sorpreso di scoprire che le aggiunte di TypeScript a JavaScript soddisfano ogni esigenza seria che ho avuto per migliorare la mia programmazione client . Ecco i punti salienti:

1. Interfacce . L'incapsulamento e le interfacce mi consentono di strutturare facilmente il mio codice. Perfetto!

2. Stato classe . TypeScript consente di esprimere lo stato che le istanze di una classe portano esplicitamente, o meglio lo impone. Questo è un grande passo migliore rispetto a js o caffè.

3. thischiamare la follia mitigata . All'interno delle funzioni freccia, TypeScript rende il thispuntatore come qualsiasi cittadino che si comporta normalmente.

4. Editor, Intellisense . TypeScript viene fornito con il 100% di intellisense perfettamente perfetto che reagisce nell'intervallo di micro o millisecondi utilizzato da Visual Studio durante la programmazione di C #. Esistono anche intestazioni TypeScript per tutte le importanti librerie js . Ottimo, fantastico.

5. Esperienza e rischio . L'uso di TypeScript non comporta alcun rischio, il linguaggio è chiaramente definito, perfettamente stabile, è solo js con zucchero, niente di imprevedibile.

In realtà, questi miglioramenti mi danno tutto ciò di cui avevo bisogno. L'unica cosa che vorrei vedere in futuro sono le raccolte generiche. Ma quelle sono noccioline.

E le prestazioni? Mentre mi considero un maniaco delle prestazioni, non credo che ci sia alcun progetto che possa fare la scelta della tecnologia in base alle prestazioni. Entrambi sono nella js liga.

Se sei interessato al futuro della programmazione web, entrambi sono grandi sforzi, TypeScript è molto più pragmatico e utilizzabile ora, Dart è un progetto di laboratorio molto interessante che sarà utilizzabile una volta che saranno disponibili editor e debugger maturi e l'ambito dei progetti realizzabili con dipenderà dalla politica.

In ogni caso, i 3 giorni di valutazione sono stati per lo più divertenti e ho imparato molto, se trovi il tempo, ci vuole 1 giorno per Dart e 2 ore per TypeScript per esprimere la tua opinione. Provalo.

Aggiornamento ottobre 2014

È passato un po 'di tempo ed ex post sembra che l'ipotesi che Typescript sia la strada sicura e stabile da percorrere era assolutamente giusta. Ho appena trovato un'affermazione (molto) importante su Typescript, Dart e Closure:

Sono stato interessato alla sfida della programmazione Web in generale per un bel po 'di tempo. Credo che Google Closure sia attualmente l'opzione migliore per lo sviluppo di JavaScript / Web su larga scala, ma che alla fine verrà sostituito da qualcosa di meno prolisso. Sebbene Dart mostri notevoli promesse, sono ancora sgomento per le dimensioni del JavaScript che genera. In confronto, se TypeScript può essere tradotto direttamente in JavaScript che può essere compilato utilizzando la modalità avanzata del compilatore di chiusura, allora possiamo avere tutti i vantaggi di JavaScript ottimizzato da Chiusura senza la verbosità. Inoltre, poiché TypeScript è un superset di JavaScript, credo che le sue estensioni di sintassi abbiano la possibilità di trasformarlo nello standard ECMAScript a un certo punto,

http://blog.bolinfest.com/2013/01/generating-google-closure-javascript.html

Michael Bolin è da molto tempo (ex) google (ex) eroe front-end fb, coinvolto anche nella chiusura di google (ottieni il suo libro sulla chiusura).

Google Traceur

L'approccio di Google a vivere ECMA Script 6 oggi è il suo progetto Traceur: https://github.com/google/traceur-compiler

Rispetto a Typescript, il supporto degli strumenti è presumibilmente molto indietro rispetto ad oggi. Il lato positivo, tuttavia, è molto più veloce nell'adottare futuri futuri miglioramenti linguistici come iteratori o comprensioni.

Facebook Flow, Google AtScript

fornire funzionalità simili a TypeScript.

"Ci si potrebbe chiedere che cosa ci siano con queste diverse soluzioni di verifica del tipo JavaScript e cosa fare al riguardo. Una buona notizia è che Microsoft, Facebook e Google stanno collaborando su queste, secondo Jonathan Turner di Microsoft:

Il team di TypeScript sta lavorando con entrambi i team Flow e AtScript per garantire che le risorse che sono già state create dalla comunità di digitazione JavaScript possano essere utilizzate in questi strumenti. Ci sono molti progetti che possono imparare gli uni dagli altri e non vediamo l'ora di lavorare insieme per il futuro e creare i migliori strumenti possibili per la comunità JavaScript. A lungo termine, lavoreremo anche per piegare le migliori caratteristiche di questi strumenti in ECMAScript, lo standard dietro JavaScript. "

articolo infoq sul flusso fb

Citando Scott Hanselman:

Le persone hanno confrontato TypeScript con Dart. Questo sta confrontando le mele con i carburatori. TypeScript si basa su JavaScript, quindi non ci sono problemi di interoperabilità JS. Dart è una macchina virtuale nativa scritta da zero. Dart interops con JavaScript ... ma non è JS. Ad esempio, non utilizza nemmeno il tipo di numero JavaScript.

Da Perché TypeScript ha la risposta a qualcosa?

Ho dovuto avviare questa discussione con le mie scoperte di recente.

1 °: TypeScript

MS ha adottato un approccio gradevole nel fatto che puoi facilmente entrare e uscire da TS e JS. Utilizziamo principalmente AngularJS per il nostro sviluppo e abbiamo riscontrato che non esiste molta documentazione per la conversione di Angular in TypeScript. È stata una bella aggiunta per incorporare TypeScript nel nostro flusso di lavoro Dev.

2 °: Dardo

Dart è un passo un po 'ironico per Google. Forse non ricordano activeX e tutti gli incubi che provano a far funzionare un'applicazione in qualsiasi cosa tranne il temuto IE 5 o IE 6 del giorno. La SM ha impiegato molti anni per riprendersi da quei giorni.

Il dardo come linguaggio "concettualmente" sembra provare a combinare alcune belle funzionalità OOP. Annotazioni ecc. Sono un bel pensiero per Javascript.

Il problema, è difficile immaginare una larghezza di banda sufficiente per creare un nuovo editor, una nuova lingua, nuove vm attraverso i browser, plug-in per altri IDE, compilatore da convertire in javascript (senza dimensioni multiple di mega), convertire o creare nuove librerie di dardi in sostituisco le migliaia delle attuali librerie js, chiedi a qualcuno di decidere polimeri o direttive, converti il ​​sito di dartlang per usare il dardo, questo è quello che mi viene in mente dalla testa.

Il concetto di provare a usare Dart in tutto tranne che in un'app banale in questo momento è spaventoso.

Oltre a tutto questo ES6 non è lontano. ES6 offre molte funzionalità che Dart sta cercando di risolvere in ES5. Quale sarà la proposta di valore una volta che ES6 uscirà per strada? Almeno in questo momento l'unica modifica che devi apportare in TypeScript una volta uscito ES6 è forse quella di scegliere una compilazione diversa da target.

Giusto per chiarire, comunque, che io sono un professionista della SM. MS produce alcuni prodotti decenti e ha fatto passi da gigante per correggere gli errori del passato con la comunità OSS. Raramente continuo a usare raramente qualcosa di diverso da TypeScript di MS.