it-swarm.com.de

Unterschiede zwischen TypeScript und Dart

Microsoft hat kürzlich TypeScript vorgestellt, eine neue JavaScript-ähnliche Programmiersprache. Vor einiger Zeit hörte ich von Dart, einer neuen Programmiersprache, die von Google entwickelt wurde, um Probleme im Zusammenhang mit Javascript wie Leistung, Skalierbarkeit usw. zu lösen.

Der Zweck beider neuer Sprachen scheint mir der gleiche zu sein. Was denkst du?

Sind die Zwecke der Sprachen gleich?

Was sind die wirklichen Unterschiede an ihnen?

90
margabit

Zitat Bob Nystrom :

TypeScript scheint gut zu sein, wenn Sie JS-Semantik mögen oder eine große JS-Codebasis haben, in die Sie investiert haben, aber bei der Skalierung Wartungsprobleme haben. Der Weg zum Erfolg ist viel reibungsloser, da er (meistens?) Abwärtskompatibel mit JS ist.

Dart geht eine riskantere Wette ein. Es ist in vielerlei Hinsicht weiter von JS entfernt, was meiner Meinung nach vor allem als alltäglicher Dart-Programmierer gut ist, aber es erhöht die Eintrittsbarriere. Aber als Gegenleistung für diese höhere Eintrittsbarriere erhalten Sie:

  • Baum zittern
  • Getter und Setter (obwohl ich davon ausgehe, dass TypeScript diese irgendwann bekommen wird)
  • Überlastung des Bedieners
  • Realer Blockumfang, kein Heben, kein IIFE s
  • Eine native VM
  • Vernünftige Gleichheitssemantik
  • Keine seltsame implizite Konversionsverrücktheit
  • lexikalisch gebundenthis überall
  • Mixins
  • Anmerkungen
  • Ein Importsystem
  • Benutzerdefinierte Indexoperatoren
  • Generika, mit Verdinglichung
  • Spiegel
  • Bessere Sammelklassen
  • Eine sauberere DOM-API

Außerdem schreibt er in http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_TypeScript/c6g37xd :

Ich bin im Dart-Team von Google, daher betrachte ich es natürlich aus diesem Blickwinkel. Hier sind einige zufällige Dinge, die mir aufgefallen sind und die ich hauptsächlich mit Dart verglichen habe. Ich habe nur ein paar Minuten damit verbracht, zu überfliegen, also nimm nichts davon zu ernst ...

Keine Generika

Ich denke, einige Typen sind besser als gar keine, aber es ist wirklich schwierig, diese zu verlieren. TypeScript verfügt über integrierte Array-Typen, und Objekttypen decken einige Anwendungsfälle vom Typ "Map" ab. Es ist jedoch ein Problem, keine eigenen generischen Typen definieren zu können. Die Dokumente sagen, wenn sie hinzugefügt werden, funktionieren Generika mit Typlöschung, was ich erwarten würde, wenn man bedenkt, dass es sich um einen "Compile to Lightweight JS" -Stil handelt, aber das kann auch schmerzhaft sein. Es ist schön, manchmal zur Laufzeit mit Ihren Typargumenten arbeiten zu können.

Alle Typen sind nullbar

Dart ist der gleiche Weg. Macht mich in beiden Fällen traurig.

Die Syntax für Typanmerkungen lautet Nice

Fast jede Sprache mit optionalen Typanmerkungen (ML, Scala, F #, Kotlin usw.) wird mit "postfix nach a :. Dart versucht, Typanmerkungen im C-Stil zu verwenden, was einige unangenehme Eckfälle verursacht. Ich mag, was TypeScript hier hat. insbesondere die Syntax für Funktionstypen:

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

Schnittstellen sind strukturell typisiert, Klassen sind nominell typisiert

Sinnvoll, da es sich um JavaScript handelt, aber es scheint ziemlich ordentlich zu sein. Eine Schnittstelle implizit implementieren zu können, ist schön. Aber TypeScript scheint Sie nicht in die andere Richtung gehen zu lassen: Bei einer bestimmten Klasse können Sie keinen neuen Typ erstellen, der mit ihm kompatibel ist, ohne ihn aufgrund des Markenmaterials konkret zu erweitern. In Dart können Sie dank impliziter Schnittstellen.

Bester allgemeiner Typ kann fehlschlagen

Das heißt, dies ist ein Typfehler:

[1, true]

Sie können Schnittstellen durch Parametersignatur überladen.

Dies ist wirklich cool, da Sie so einen genaueren Typinferenzfluss durch einen Funktionsaufruf erhalten, der eine dynamische Typumschaltung durchführt. Zum Beispiel:

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

Wenn der Compiler einen Aufruf zum Verdoppeln sieht, kann er Ihnen einen genauen Rückgabetyp basierend auf dem abgeleiteten Argumenttyp korrekt geben. Ich bin mir nicht sicher, wie ich eine Klasse implementieren soll, die diese Schnittstelle implementiert und die Typprüfung glücklich macht. Sie können konkrete Methoden nicht wirklich überladen, und mein fünfminütiger Versuch, sie durch dynamische Typprüfung glücklich zu machen, schien nicht zu funktionieren.

Es gibt eine dedizierte Syntax für Array-Typen

Sinnvoll, da es keine Generika gibt. Es ist auch schön und knapp, was gut ist, aber ich persönlich bevorzuge Allzweck-Generika gegenüber einmaligen Spezialkoffersammlungen.

Es gibt kein implizites Downcasting

Eine der ungewöhnlicheren Systemfunktionen von Dart ist, dass die Zuweisungskompatibilität bidirektional ist: Sie können ohne Vorwarnung einen Downcast durchführen. Abgesehen von dem typischen Sonderfall der Zuweisung zu/von einem (dynamisch in anderen Sprachen) erlaubt TypeScript dies nicht. Sie müssen assert eingeben. Persönlich mag ich den Ansatz von TypeScript hier.

Pfeilfunktionen und lexikalisch dies

Dies ist nur Mutterschaft und Apple pie. Ich mag es. (Dart hat das auch, und das ist immer lexikalisch gebunden.)

Insgesamt sieht es ziemlich ordentlich aus. Wenn Sie genau die gleiche JS-Semantik (gut und schlecht), aber auch ein paar Typen wünschen, scheint TypeScript anständig zu sein. Es ist wie Closure Compiler, aber mit einer besseren Syntax.

Wenn Sie etwas wollen, das aggressiver von JS 'Syntax und Semantik abweicht, dann scheint TypeScript das nicht zu sein.

61
Seth Ladd

Während die Frage lautete: "Sind die Zwecke der Sprachen gleich?", Lautet die eigentliche Frage: "Wie können wir die Webprogrammierung von unserem Standort aus verbessern?" .

Beide Projekte versuchen dies unter Berücksichtigung

  • Programmiersprache (TypeScript macht einen kleinen, aber sehr sauberen Schritt, Dart macht den revolutionäreren Schritt, der sich noch bewegt)

  • Interoperabilität mit vorhandenem js-Code (0 Übergang in TypeScript, der zu js kompiliert wird, kompliziert in Dart, da 2 VMs miteinander kommunizieren)

  • Software-Engineering-Praktiken (nur Dart, Webkomponenten und Shadow Dom)

In den letzten 3 Tagen habe ich mich intensiv mit Dart und dann mit TypeScript befasst. Meine CoffeeScript-Codebasis umfasste Codezeilen aus den 2000er Jahren, zu viel, um mit schönem, aber zu flauschigem CoffeeScript verarbeitet zu werden. Die Probleme, mit denen ich konfrontiert war, waren, dass CoffeeScript nicht über die Funktionen verfügt, die Sprachen für die Programmierung in mittlerem bis großem Maßstab bieten: Schnittstellen, Module, Typensicherheit. Aber es gab ein noch viel schwerwiegenderes Problem mit Kaffee und js: Die Verrücktheit von js "this pointer" hat meine geistige Gesundheit beeinträchtigt und CoffeeScript hilft hier nichts.

Also hier meine Ergebnisse nach 3 Tagen Auswertung und Nutzung:

Pfeil

Ging gründlich durch das Tutorial, las 1 Buch, überflog das 2. Buch und probierte die Demos aus. Ich dachte, Dart das ist die Zukunft . Dann habe ich versucht, meine App auf Dart zu migrieren . Dort ging meine Begeisterung von 100 auf 10 zurück. Hier ist der Grund:

  1. Der Dart Editor ist die einzige Möglichkeit, Dart zu programmieren. Es gibt zwar Plugins für Sublime Text, diese bieten jedoch keine Funktionen wie Intellisense oder Code-Vervollständigung (korrigieren Sie mich, wenn ich falsch liege). Der Dart Editor ist jedoch in Pre-Alpha-Qualität. Während es supercoole magische Dinge wie das Aktualisieren der Webseite beim Bearbeiten der CSS-Datei unterstützt (! Wirklich cool), hängt es mehrmals pro Minute oder stürzt ab. Sie geben also 5 Buchstaben ein und müssen 2 Mal 2 Sekunden oder 15 Sekunden zwischen der Eingabe warten. Und ich hatte ein Projekt mit einigen Codezeilen, wollte also nicht warten, was passiert, wenn 1000 Zeilen enthalten sind. Eine Datei wurde im Dart Editor von einem Ordner in den anderen verschoben, Absturz. Das Debuggen mit dem Dart-Editor ist auf den ersten Blick besser als alle mir bekannten Debugging-Tools von js (Chrome ist meine Wahl), aber es fehlen immer noch zu viele Dinge : Kein unmittelbares Fenster (dies macht das Debuggen im Moment viel besser), keine Uhren.

  2. Politik und Fluchtmöglichkeiten : Einige sagen, dass Apple, MS und Firefox niemals Dart-VMs bereitstellen werden. Nun, ich bin mir nicht so sicher, aber zumindest für Apple erscheint dies im Moment sehr sicher. Für die anderen ist es wahrscheinlicher als das Gegenteil. Also kein Problem, wir können Dart in JavaScript konvertieren Die Art und Weise, wie diese Integration funktioniert, ist wirklich großartig. Dart unterhält einen js-Stub, der den js-Code mit dem Dart-Editor verbunden hält, sodass im Dart-Editor immer noch eine print() - Anweisung angezeigt wird, cool. Aber hier kommt das aber: Der Footprint eines solchen konvertierten Codes ist hoch. 150 KB oder so (vor der Minimierung). Ich habe nicht zu viel in die exakte Größe gegraben, also nageln Sie mich nicht darauf fest.

  3. Sprachreife . Abgesehen von den viel zu ernsten Problemen mit dem Dart Editor, die mir dreimal pro Minute ins Gesicht tauchten, fand ich es auch inakzeptabel, dass jede Quelle über Dart-Code, die Sie finden, einen anderen Dart verwendet. Die Sprache ändert sich jeden Tag. Sie finden einen Beitrag von vor 5 Wochen? Es ist veraltet. Sie probieren die Beispiele aus dem Google-Tutorial aus? Mindestens 1 Beispiel wird nicht kompiliert, da eine API geändert wurde. Sogar alltägliche Dinge wie das Anhängen eines Ereignisses an ein DOM-Element sind in gutem Zug .

  4. Die Integration in vorhandene js-Bibliotheken ist etwas aufwendig. 2 VMs müssen hier kommunizieren, es ist schwierig.

Zusammenfassend lässt sich sagen, dass Sie Dart ab heute nicht mehr ernsthaft verwenden können und das Eintauchen aufgrund von 1 und 3 nicht allzu viel Spaß macht. Beide Punkte verschwinden mit der Zeit. Über den 2-Punkte-Punkt hat Google vor einigen Tagen Leistungsbenchmarks veröffentlicht, die zeigen, dass ihre kompilierten js besser sind als handgeschriebene js. Mein Kompliment, tolle Arbeit. Die Ladezeit kann aufgrund des genannten Footprint-Problems immer noch zurückbleiben. Wenn der Footprint-Code jedoch von vielen, vielen Websites verwendet wird, ist er möglicherweise zwischengespeichert verfügbar, und voila verschwindet ebenfalls.

Also: Ich halte Dart für ein großartiges Projekt, da die Verwendung im Moment einen großen Teil des unvorhersehbaren Risikos birgt und es dieses Jahr dauern wird, bis es ein gutes stabiles Niveau erreicht.

Typoskript

Das Auswerten von TypeScript ist sehr einfach, dauert 1 oder 2 Stunden und Sie wissen alles. Als ich das Sprachspezifikationsdokument und ein kurzes Buch (TypeScript enthüllt) las, wusste ich alles und begann zu programmieren. Ich war dann überrascht, dass die Ergänzungen von TypeScript zu JavaScript nur alle ernsthaften Anforderungen erfüllen, die ich zur Verbesserung meiner Client-Programmierung hatte . Hier die Highlights:

  1. Schnittstellen . Kapselung und Schnittstellen ermöglichen es mir, meinen Code einfach zu strukturieren. Perfekt!

  2. Klassenstatus. . Mit TypeScript können Sie den Status ausdrücken, den Instanzen einer Klasse explizit tragen, oder erzwingen ihn besser. Dies ist ein großer Schritt besser als bei js oder Kaffee.

  3. this Verrücktheit mildern . Innerhalb der Pfeilfunktionen macht TypeScript den Zeiger this wie jeden Bürger, der sich normal verhält.

  4. Editor, Intellisense . TypeScript wird mit 100% perfekter Intelligenz geliefert, die im Mikro- oder Millisekundenbereich reagiert, wie er von Visual Studio beim Programmieren von C # verwendet wird. TypeScript-Header für alle wichtigen js-Bibliotheken gibt es auch . Großartig großartig großartig.

  5. Erfahrung und Risiko . Die Verwendung von TypeScript birgt kein Risiko, die Sprache ist klar definiert, perfekt stabil, es ist nur js mit Zucker, nichts Unvorhersehbares.

Eigentlich geben mir diese Verbesserungen alles, was ich brauchte. Das einzige, was ich in Zukunft gerne sehen würde, sind generische Sammlungen. Aber das sind Erdnüsse.

Was ist also mit der Leistung? Obwohl ich mich als Leistungsfreak betrachte, glaube ich nicht, dass es ein Projekt gibt, bei dem die Wahl der Technologie hier auf der Grundlage der Leistung getroffen wird. Beide sind in der js liga.

Wenn Sie an der Zukunft der Webprogrammierung interessiert sind, sind beide große Anstrengungen, TypeScript ist jetzt viel pragmatischer und verwendbarer. Dart ist ein sehr interessantes Laborprojekt, das verwendet werden kann, sobald ausgereifte Editoren und Debugger verfügbar sind und der Umfang der Projekte damit machbar ist es wird von der Politik abhängen.

Auf jeden Fall haben die 3 Bewertungstage meistens Spaß gemacht und ich habe viel gelernt. Wenn Sie die Zeit finden, dauert es 1 Tag für Dart und 2 Stunden für TypeScript, um Ihre eigene Meinung zu bilden. Versuch es.

Update Oktober 2014

Es ist eine Weile her und nachträglich scheint die Annahme, dass TypeScript der sichere stabile Weg ist, ganz richtig zu sein. Ich habe gerade eine (sehr) prominente Aussage zu TypeScript, Dart und Closure gefunden:

Ich habe mich schon seit einiger Zeit für die Herausforderung der Webprogrammierung im Großen interessiert. Ich glaube, dass Google Closure derzeit noch die beste Option für die groß angelegte JavaScript-/Webentwicklung ist, aber letztendlich durch etwas ersetzt wird, das weniger ausführlich ist. Obwohl Dart vielversprechend ist, bin ich immer noch bestürzt über die Größe des JavaScript, das es generiert. Wenn TypeScript im Vergleich direkt in JavaScript übersetzt werden kann, das im erweiterten Modus des Closure Compilers kompiliert werden kann, können wir alle Vorteile von optimiertem JavaScript aus Closure ohne Ausführlichkeit nutzen. Da TypeScript eine Obermenge von JavaScript ist, glaube ich, dass seine Syntaxerweiterungen irgendwann in den ECMAScript-Standard aufgenommen werden können, während die Wahrscheinlichkeit, dass Dart in allen gängigen Browsern nativ unterstützt wird, ziemlich gering ist.

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

Michael Bolin ist ein langjähriger (ex) google (ex) fb Front-End-Held, der auch an der Schließung von Google beteiligt ist (siehe sein Buch über Closure).

Google Traceur

Googles Ansatz, ECMA Script 6 heute zu leben, ist das Traceur-Projekt: https://github.com/google/traceur-compiler

Im Vergleich zu TypeScript liegt die Werkzeugunterstützung bis heute vermutlich weit zurück. Auf der anderen Seite ist es jedoch viel schneller, übermäßig coole zukünftige js-Sprachverbesserungen wie Iteratoren oder Verständnis zu übernehmen.

Facebook Flow, Google AtScript

bieten ähnliche Funktionen wie TypeScript.

"Man könnte sich fragen, was mit diesen verschiedenen JavaScript-Typprüfungslösungen zu tun ist und was dagegen zu tun ist. Eine gute Nachricht ist, dass Microsoft, Facebook und Google bei diesen zusammenarbeiten, so Jonathan Turner von Microsoft:

Das TypeScript-Team arbeitet sowohl mit dem Flow- als auch mit dem AtScript-Team zusammen, um sicherzustellen, dass Ressourcen, die bereits von der JavaScript-Typisierungs-Community erstellt wurden, für diese Tools verwendet werden können. Diese Projekte können viel voneinander lernen, und wir freuen uns darauf, in Zukunft zusammenzuarbeiten und die besten Tools für die JavaScript-Community zu entwickeln. Langfristig werden wir auch daran arbeiten, die besten Funktionen dieser Tools in ECMAScript, dem Standard hinter JavaScript, zu integrieren. "

infoq Artikel über fb flow

61
citykid

Zitat von Scott Hanselman:

Die Leute haben TypeScript mit Dart verglichen. Das vergleicht Äpfel mit Vergasern. TypeScript baut auf JavaScript auf, sodass keine JS-Interop-Probleme auftreten. Dart ist eine native virtuelle Maschine, die von Grund auf neu geschrieben wurde. Dart Interops mit JavaScript ... aber es ist nicht JS. Es wird beispielsweise nicht einmal der JavaScript-Nummerntyp verwendet.

Von Warum ist TypeScript die Antwort auf irgendetwas?

17
M. Dudley

Musste mich in letzter Zeit mit meiner eigenen Erkenntnis in diese Diskussion einmischen.

1. TypeScript

MS hat einen guten Ansatz gewählt, da Sie problemlos in TS und JS ein- und aussteigen können. Wir verwenden AngularJS hauptsächlich für unsere Entwicklung und haben festgestellt, dass für die Konvertierung von Angular in TypeScript) nicht viel Dokumentation vorhanden ist. Es war eine nette Ergänzung, TypeScript in unseren Dev-Workflow zu integrieren.

2. Dart

Dart ist für Google ein ironischer Schritt. Vielleicht erinnern sie sich nicht an activeX und all die Albträume, in denen versucht wurde, eine Anwendung in etwas anderem als dem gefürchteten IE 5 oder IE 6 des Tages) zum Laufen zu bringen MS hat viele Jahre gebraucht, um sich von diesen Tagen zu erholen.

Dart als Sprache "konzeptuell" scheint zu versuchen, einige Nice OOP - Funktionen zu kombinieren. Anmerkungen usw. sind ein guter Gedanke für Javascript.

Das Problem ist, dass es kaum vorstellbar ist, dass genügend Bandbreite vorhanden ist, um einen neuen Editor, eine neue Sprache, neue VMs in verschiedenen Browsern, Plugins für andere IDEs und einen Compiler zum Konvertieren in Javascript (ohne mehrere Megabyte groß), zum Konvertieren oder Erstellen neuer Dart-Bibliotheken zu erstellen Ersetzen Sie die Tausenden von aktuellen js-Bibliotheken, lassen Sie jemanden über Polymere oder Direktiven entscheiden, konvertieren Sie die Dartlang-Site in Dart, das ist es, woran ich denken kann.

Das Konzept, Dart derzeit in einer anderen als einer trivialen App zu verwenden, ist beängstigend.

Darüber hinaus ist ES6 nicht weit entfernt. ES6 bietet viele Funktionen, die Dart zu beheben versucht und die in ES5 vorhanden sind. Was wird das Wertversprechen sein, wenn ES6 auf die Straße kommt? Zumindest zu diesem Zeitpunkt besteht die einzige Änderung, die Sie in TypeScript vornehmen müssen, sobald ES6 herauskommt, darin, möglicherweise eine andere Kompilierung als Ziel auszuwählen.

Nur um zu klären, dass ich eine Pro-MS-Person bin. MS stellt einige anständige Produkte her und hat große Fortschritte gemacht, um frühere Fehler in der OSS-Community zu beheben. Ich verwende immer noch selten etwas anderes als TypeScript von MS.

3
code