Unterschiede zwischen TypeScript und Dart [closed]

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 der beiden neuen Sprachen scheint mir der gleiche zu sein. Was denkst du?

Sind die Zwecke der Sprachen gleich?

Was sind die wirklichen Unterschiede an ihnen?

Zitat von Bob Nystrom :

TypeScript scheint gut zu sein, wenn Sie JS-Semantik mögen oder eine große JS-Codebasis haben, in die Sie investiert sind, bei der Skalierung jedoch Wartungsprobleme auftreten. 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 für einen täglichen Dart-Programmierer am besten ist, aber die Eintrittsbarriere erhöht sich. Aber als Gegenleistung für diese höhere Eintrittsbarriere erhalten Sie:

• Baum zittert
• Getter und Setter (obwohl ich davon ausgehe, dass TypeScript diese irgendwann bekommt)
• Bedienerüberladung
• Real Block Umfang, kein Heben, kein IIFE s
• Eine native VM
• Gesunde Gleichheitssemantik
• Keine seltsame implizite Conversion-Verrücktheit
• thisÜberall lexikalisch gebunden
• 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 sehe ich das 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 mit Überfliegen verbracht, 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 der Anwendungsfälle des Typs "Map" ab. Es ist jedoch schwierig, eigene generische Typen zu definieren. In den Dokumenten heißt es, dass Generika mit der Löschung von Datentypen funktionieren. Dies ist, wie ich es erwartet hätte, der Fall, wenn sie im "Kompilieren mit leichtem JS" -Stil vorliegen, aber das kann auch ein Problem sein. Es ist schön, zur Laufzeit manchmal Dinge mit Ihren Typargumenten zu tun.

Alle Typen sind nullfähig

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

Die Syntax der Typanmerkungen ist gut

Fast jede Sprache mit optionalen Typanmerkungen (ML, Scala, F #, Kotlin, etc.) geht mit "postfix after a:. Dart versucht, C-Typanmerkungen 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 nominal typisiert

Sinnvoll, da es sich um JavaScript handelt, aber es scheint ziemlich ordentlich zu sein. Es ist schön, eine Schnittstelle implizit implementieren zu können. TypeScript scheint Sie jedoch nicht in die andere Richtung zu führen: Wenn Sie eine Klasse angeben, können Sie keinen neuen Typ erstellen, der mit ihr kompatibel ist, ohne ihn aufgrund des Markenmaterials konkret zu erweitern. In Dart ist dies dank impliziter Schnittstellen möglich.

Bester gebräuchlicher Typ kann fehlschlagen

Das heißt, dies ist ein Tippfehler:

[1, true]

Sie können Schnittstellen durch Parametersignatur überladen

Dies ist wirklich cool, da Sie auf diese Weise einen genaueren Typinferenzfluss durch einen Funktionsaufruf erhalten, der eine dynamische Typumschaltung ausführt. Zum Beispiel:

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

Wenn der Compiler einen Aufruf von double sieht, kann er Ihnen auf der Grundlage des abgeleiteten Argumenttyps einen genauen Rückgabetyp geben. Was ich nicht sicher bin, ist, wie man tatsächlich eine Klasse implementiert, die diese Schnittstelle implementiert und die Typprüfung glücklich macht. Konkrete Methoden lassen sich 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 spezielle 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 Spezialkoffer-Sammlungen.

Es gibt kein implizites Downcasting

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

Pfeilfunktionen und lexikalisch dazu

Dies ist nur Mutterschaft und Apfelkuchen. Ich mag das. (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) wollen, aber auch ein bisschen mehr Typen wollen, scheint TypeScript anständig zu sein. Es ist wie Closure Compiler, aber mit einer besseren Syntax.

Wenn Sie etwas wollen, das aggressiver ist als die Syntax und Semantik von JS, dann scheint TypeScript das nicht zu sein.

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

Beide Projekte versuchen dies in Betracht zu ziehen

• 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 sprechen)

• Praktiken der Softwareentwicklung (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 bestand aus 2000er-Codezeilen, zu viel, um mit schönem, aber zu flauschigem CoffeeScript fertig zu werden. Die Probleme, mit denen ich konfrontiert war, waren, dass es in CoffeeScript an Funktionen mangelt, die für mittelgroße bis große Programmiersprachen entwickelt wurden: Schnittstellen, Module, Typensicherheit. Aber es gab ein noch viel ernsteres Problem mit Kaffee und js: Die Verrücktheit js "dieses Zeigers" wirkte sich auf meine geistige Gesundheit aus und CoffeeScript hilft hier nichts.

Also hier meine Ergebnisse nach 3 Tagen Auswertung und Nutzung:

Pfeil

Wir haben das Tutorial gründlich durchgearbeitet, 1 Buch gelesen, das 2. Buch überflogen und die Demos ausprobiert. 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. Plugins für Sublime Text sind zwar vorhanden, bieten jedoch keine Funktionen wie Intellisense oder Code-Vervollständigung (korrigieren Sie mich, wenn ich mich irre). Der Dart Editor ist jedoch in Pre-Alpha-Qualität. Obwohl es supercoole magische Dinge wie das Aktualisieren der Webseite unterstützt, wenn Sie die CSS-Datei bearbeiten (! Wirklich cool), bleibt es mehrmals pro Minute hängen oder stürzt ab. Sie tippen also 5 Buchstaben und müssen zwischen dem Tippen 2 Sekunden oder 15 Sekunden warten. Und ich hatte ein Projekt mit einigen Codezeilen, also wollte ich nicht warten, was passiert, wenn 1000 Zeilen eingegeben werden. Verschob eine Datei innerhalb des Dart Editors von einem Ordner in den anderen, stürzte ab. Debuggenmit dem dart editor ist auf den ersten blick besser als alle js debugging tools, die ich kenne (chrome ist meine wahl), aber es fehlen immer noch zu viele dinge: kein sofortiges fenster (das macht js debugging im moment viel besser), keine uhren.

2. Politik und Fluchtmöglichkeiten : Einige sagen, dass Apple, MS und Firefox niemals Dart-VMs anbieten werden. Nun, ich bin mir nicht so sicher, aber zumindest für Apple scheint dies im Moment sehr sicher zu sein. Für die anderen ist es wahrscheinlicher als das Gegenteil. Also kein Problem, wir können Dart nach 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 verbindet, sodass eine print()Anweisung im Dart-Editor weiterhin cool angezeigt wird. Aber hier kommt das Aber: Der Platzbedarf eines solchen konvertierten Codes ist hoch. 150kB oder so (vor der Minimierung). Ich habe nicht zu viel in die exakte Größe gegraben, also nagle mich nicht darauf fest.

3. Sprachreife . Abgesehen von den viel zu ernsten Problemen mit dem Dart Editor, die mir dreimal in der Minute ins Gesicht sprangen, fand ich es auch inakzeptabel, dass jede Quelle über Dart-Code, die Sie finden, einen anderen Dart verwendet. Die Sprache ändert sich jeden Tag. Du findest 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. Selbst alltägliche Dinge wie das Anhängen eines Ereignisses an ein DOM-Element sind in Ordnung .

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

Als Fazit kann man Dart ab heute nicht mehr ernsthaft einsetzen, und das Eintauchen macht aufgrund von 1 und 3 nicht allzu viel Spaß. Beide Punkte werden mit der Zeit verschwinden. In Bezug auf die 2 Punkte hat Google vor einigen Tagen Performance-Benchmarks veröffentlicht, die zeigen, dass ihre kompilierten js besser sind als handgeschriebene js. Mein Kompliment, tolle Arbeit. Die Ladezeit kann aufgrund des genannten Problems mit dem Platzbedarf immer noch zurückliegen. Wenn der Footprint-Code jedoch von vielen Sites verwendet wird, ist er möglicherweise im Cache verfügbar, und voila verschwindet ebenfalls.

Also: Ich halte Dart für ein großartiges Projekt, dessen Nutzung im Moment einen großen Teil des unvorhersehbaren Risikos birgt, und es wird dieses Jahr dauern, 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 Dokument mit den Sprachspezifikationen las und ein kurzes Buch (TypeScript enthüllt) enthüllte, wusste ich alles und begann zu programmieren. Ich war dann überrascht zu sehen, dass die Ergänzungen von TypeScript zu JavaScript einfach jeden ernsthaften Bedarf erfüllen, den ich zur Verbesserung meiner Client-Programmierung hatte . Hier die Highlights:

1. Schnittstellen . Durch Kapselung und Schnittstellen kann ich meinen Code einfach strukturieren. Perfekt!

2. Class State. . Mit TypeScript können Sie den Status von Instanzen einer Klasse explizit ausdrücken oder besser erzwingen. Dies ist ein großer Schritt besser als js oder Kaffee.

3. thisWahnsinn gemildert . Innerhalb von Pfeilfunktionen macht TypeScript den thisZeiger zu einem Bürger, der sich normal verhält.

4. Herausgeber, Intellisense . TypeScript wird mit 100% perfekter Intellisense ausgeliefert, die im Mikro- oder Millisekundenbereich reagiert, wie er in Visual Studio beim Programmieren von C # verwendet wird. TypeScript-Header für alle wichtigen js-Bibliotheken sind ebenfalls vorhanden . 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 mit der Leistung? Obwohl ich mich selbst als Leistungsfreak betrachte, glaube ich nicht, dass es ein Projekt gibt, das die Wahl der Technologie hier auf der Grundlage der Leistung treffen würde. Beide sind in der js liga.

Wenn Sie sich für die Zukunft der Webprogrammierung interessieren, sind beide sehr aufwändig. TypeScript ist jetzt viel pragmatischer und benutzerfreundlicher. Dart ist ein sehr interessantes Laborprojekt, das verwendet werden kann, sobald ausgereifte Editoren und Debugger verfügbar sind und der Umfang der Projekte mit denen gearbeitet werden kann es wird von der Politik abhängen.

Auf jeden Fall haben die 3 Testtage meistens Spaß gemacht und ich habe viel gelernt. Wenn Sie die Zeit gefunden haben, dauert es 1 Tag, bis Dart und 2 Stunden, bis TypeScript Ihre eigene Meinung geäußert hat. Versuch es.

Update Oktober 2014

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

Die Herausforderung der Webprogrammierung im großen und ganzen interessiert mich schon seit geraumer Zeit. Ich bin der Meinung, dass Google Closure derzeit noch die beste Option für die groß angelegte JavaScript / Web-Entwicklung ist, dass es jedoch letztendlich durch etwas weniger ausführliches ersetzt wird. Obwohl Dart vielversprechend ist, bin ich immer noch bestürzt über die Größe des erzeugten JavaScript. Zum Vergleich: Wenn TypeScript direkt in JavaScript übersetzt werden kann, das im erweiterten Modus des Closure-Compilers kompiliert werden kann, können wir alle Vorteile des optimierten JavaScript von Closure ohne die Ausführlichkeit nutzen. Da TypeScript eine Obermenge von JavaScript ist, haben die Syntaxerweiterungen meines Erachtens die Chance, dass es irgendwann zum ECMAScript-Standard wird.

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

Michael Bolin ist ein langjähriger (Ex-) Google- (Ex-) FB-Frontend-Held, der auch an Google Closure beteiligt ist (siehe sein Buch über Closure).

Google Traceur

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

Im Vergleich zu Typescript ist die Unterstützung von Werkzeugen ab heute vermutlich weit zurückgegangen. Auf der anderen Seite ist es jedoch viel schneller, übermäßig coole zukünftige Sprachverbesserungen wie Iteratoren oder Verstehen zu übernehmen.

Facebook Flow, Google AtScript

bieten ähnliche Funktionen wie TypeScript.

"Man könnte sich fragen, was mit diesen verschiedenen JavaScript-Lösungen für die Typprüfung 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. Es gibt eine Menge, die diese Projekte voneinander lernen können, und wir freuen uns darauf, gemeinsam die besten Tools für die JavaScript-Community zu entwickeln. Langfristig werden wir auch daran arbeiten, die besten Funktionen dieser Tools in ECMAScript zu integrieren, dem Standard hinter JavaScript. "

infoq artikel über fb flow

Zitat von Scott Hanselman:

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

Von Warum hat Typoskript die Antwort auf alles sein?

Musste in letzter Zeit mit meinen eigenen Erkenntnissen 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 hauptsächlich AngularJS für unsere Entwicklung und haben festgestellt, dass für die Konvertierung von Angular nach TypeScript nicht viel Dokumentation vorhanden ist. Es war eine schöne Ergänzung, TypeScript in unseren Entwicklungsworkflow 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 sie versuchten, eine Anwendung zum Laufen zu bringen, außer in dem gefürchteten IE 5 oder IE 6 des Tages. MS hat viele Jahre gebraucht, um sich von diesen Tagen zu erholen.

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

Das Problem ist, dass man sich kaum genug Bandbreite vorstellen kann, um einen neuen Editor, eine neue Sprache, neue VMs in verschiedenen Browsern, Plugins für andere IDEs, einen Compiler, der in Javascript konvertiert werden kann (ohne mehrere Megabyte groß zu sein), um neue Dart-Bibliotheken zu erstellen oder zu konvertieren Tausenden von js-Bibliotheken ersetzen, jemanden über Polymere oder Richtlinien entscheiden lassen, die Dartlang-Site für die Verwendung von Dart konvertieren.

Das Konzept, Dart derzeit nur in einer einfachen App zu verwenden, ist beängstigend.

Darüber hinaus ist ES6 nicht weit entfernt. ES6 enthält viele Funktionen, die Dart in ES5 zu beheben versucht. Was wird das Wertversprechen sein, wenn ES6 auf die Straße geht? Zumindest zu diesem Zeitpunkt müssen Sie in TypeScript nach dem Erscheinen von ES6 nur noch eine andere Kompilierung als Ziel auswählen.

Nur um aufzuklären, dass ich eine Pro-MS-Person bin. MS stellt einige anständige Produkte her und hat große Anstrengungen unternommen, um Fehler in der Vergangenheit mit der OSS-Community zu beheben. Ich benutze immer noch selten etwas anderes als TypeScript von MS.