Różnice między TypeScript a Dart [zamknięte]

Firma Microsoft niedawno zaprezentowała Typescript, nowy język programowania podobny do JavaScript. Jakiś czas temu słyszałem o Dart, nowym języku programowania stworzonym przez Google w celu rozwiązania problemów związanych z Javascriptem, takich jak wydajność, skalowalność itp.

Cel obu nowych języków wydaje mi się taki sam. Co myślisz?

Czy cele języków są takie same?

Jakie są w nich prawdziwe różnice?

Cytując Boba Nystroma :

TypeScript wydaje się miły, jeśli lubisz semantykę JS lub masz dużą bazę kodu JS, w którą jesteś inwestowany, ale masz problemy z konserwacją na dużą skalę. Droga do sukcesu jest znacznie płynniejsza, ponieważ (głównie?) Jest wstecznie kompatybilny z JS.

Dart bierze bardziej ryzykowny zakład. Jest znacznie dalej od JS, co jest, moim zdaniem, dobre na co dzień jako programista Dart, ale podnosi barierę wejścia. Ale w zamian za tę wyższą barierę wejścia dostajesz:

• Drżenie drzewa
• Gettery i settery (choć przypuszczam, że w końcu je otrzymają TypeScript)
• Przeciążenie operatora
• Prawdziwy zakres bloku, nie podnoszący nie Iife s
• Natywna maszyna wirtualna
• Semantyka rozsądnej równości
• Żadnego dziwnego, domyślnego szaleństwa konwersji
• Leksykalnie związany this wszędzie
• Mixiny
• Adnotacje
• System importu
• Zdefiniowane przez użytkownika operatory indeksu dolnego
• Generyczne, z reifikacją
• Lustra
• Lepsze klasy zbiórki
• Czystszy DOM API

Pisze także w http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd :

Należę do zespołu Dart firmy Google, więc naturalnie patrzę na to z tego punktu widzenia. Oto kilka przypadkowych rzeczy, które przykuły moją uwagę, głównie w porównaniu do Dart. Spędziłem tylko kilka minut, więc nie bierz tego zbyt poważnie ...

Bez leków generycznych

Sądzę, że niektóre typy są lepsze niż żadne, ale naprawdę ciężko jest je stracić. TypeScript ma wbudowane typy tablic, a typy obiektów obejmują niektóre przypadki użycia typu „map”. Ale niemożność zdefiniowania własnych typów ogólnych jest trudna. Dokumenty mówią, że po dodaniu, generyczne będą działały przy użyciu kasowania typu, czego się spodziewałbym, biorąc pod uwagę, że jest to styl „kompilujący się do lekkiego JS”, ​​ale to też może być uciążliwe. Czasami miło jest robić rzeczy z argumentami typu.

Wszystkie typy są zerowalne

Dart jest taki sam. Zasmuca mnie w obu przypadkach.

Składnia adnotacji typu jest dobra

Prawie każdy język z opcjonalnymi adnotacjami typu (ML, Scala, F #, Kotlin itp.) Zawiera „postfiks po:. Dart próbuje użyć adnotacji typu C, co powoduje pewne nieprzyjemne przypadki narożników. Podoba mi się to, co ma tutaj TypeScript, zwłaszcza składnia dla typów funkcji:

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

Interfejsy są typowane strukturalnie, klasy są nominalnie typowane

Ma sens, biorąc pod uwagę, że jest to JavaScript, ale wydaje się całkiem fajny. Możliwość niejawnego wdrożenia interfejsu jest miła. Ale TypeScript nie pozwala ci iść w drugą stronę: biorąc pod uwagę klasę, nie możesz stworzyć nowego typu, który byłby z nim kompatybilny bez konkretnego rozszerzenia go ze względu na markę. W Dart dzięki niejawnym interfejsom możesz.

Najlepszy typ powszechny może zawieść

Oznacza to, że jest to błąd typu:

[1, true]

Można przeciążać interfejsy według podpisu parametru

Jest to naprawdę fajne, ponieważ pozwala uzyskać bardziej precyzyjny przepływ wnioskowania typu przez wywołanie funkcji, które powoduje dynamiczne przełączanie typów. Na przykład:

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

Dzięki temu, gdy kompilator zobaczy wezwanie do podwojenia, może poprawnie dać ci precyzyjny typ zwracany na podstawie wnioskowanego typu argumentu. Nie jestem pewien, jak faktycznie zaimplementować klasę, która implementuje ten interfejs i sprawia, że ​​moduł sprawdzania typu jest szczęśliwy. Nie można przeciążać konkretnych metod, a moja pięciominutowa próba uczynienia go szczęśliwym przez dynamiczne sprawdzanie typów nie działała.

Istnieje specjalna składnia dla typów tablic

Ma sens, ponieważ nie ma żadnych leków generycznych. Jest także miły i zwięzły, co jest dobre, ale ja osobiście wolę leki generyczne ogólnego przeznaczenia od jednorazowych kolekcji specjalnych przypadków.

Nie ma domyślnego downcastingu

Jedną z bardziej nietypowych cech systemu Dart jest to, że kompatybilność przypisań jest dwukierunkowa: możesz spuszczać bez ostrzeżenia. Oprócz typowego specjalnego przypadku przypisywania do / z dowolnego (dynamicznego w innych językach), TypeScript na to nie pozwala. Musisz wpisać aser. Osobiście podoba mi się tutaj podejście TypeScript.

Funkcje strzałek i leksykalne to

To tylko macierzyństwo i szarlotka. Lubię to. (Dart też to ma i zawsze jest to związane leksykalnie.)

Ogólnie rzecz biorąc, wygląda całkiem schludnie. Jeśli chcesz dokładnie taką samą semantykę JS (dobrą i złą), ale także chcesz rozproszyć typy, TypeScript wydaje się przyzwoity. To jest jak Closure Compiler, ale z lepszą składnią.

Jeśli chcesz czegoś bardziej agresywnego o krok od składni i semantyki JS, wygląda na to, że TypeScript tak nie jest.

Chociaż pytanie brzmiało: „Czy cele języków są takie same?”, Prawdziwe pytanie brzmi: „Jak możemy ulepszyć programowanie internetowe z miejsca, w którym się znajdujemy?” .

Oba projekty starają się to zrobić, biorąc pod uwagę

• język programowania (TypeScript robi mały, ale bardzo czysty krok, Dart wykonuje bardziej rewolucyjny ruch, który wciąż się porusza)

• współdziałanie z istniejącym kodem js (0 przejście w TypeScript, który kompiluje się do js, ​​skomplikowane w Dart, ponieważ 2 maszyny wirtualne rozmawiają ze sobą)

• praktyki inżynierii oprogramowania (tylko Dart, komponenty internetowe i shadow dom)

Przez ostatnie 3 dni nurkowałem głęboko w Dart, a potem w TypeScript. Moja baza kodów CoffeeScript zawierała wiersze kodu z 2000 roku, zbyt wiele, aby można było je obsłużyć pięknym, ale zbyt puszystym CoffeeScript. Problem, z którym się spotkałem, polegał na tym, że CoffeeScript nie posiada funkcji, które mają języki zaprojektowane do programowania na średnią i dużą skalę: interfejsów, modułów, bezpieczeństwa typu. Ale był jeden nawet znacznie bardziej poważny problem z kawą i JS: JS „ten wskaźnik” niesamowitość wpływ na moje zdrowie psychiczne i coffeescript nic nie pomoże tutaj.

Oto moje wyniki po 3 dniach ewaluacji i użytkowania:

Strzałka

Przejrzałem dokładnie samouczek, czytając 1 książkę, przeglądając drugą książkę i wypróbowałem wersje demo. I pomyślałem, Dart, że to przyszłość . Następnie próbowałem przenieść moją aplikację do Dart. Właśnie dlatego mój entuzjazm spadł ze 100 do 10. Oto dlaczego:

1. Dart Editor jest jedynym sposobem, aby zaprogramować DART. Chociaż istnieją wtyczki do Sublime Text, nie zapewniają one funkcji takich jak intellisense, uzupełnianie kodu (popraw mnie, jeśli się mylę). Edytor dartów jest jednak w wersji starszej niż alfa. Chociaż obsługuje supercool magiczne rzeczy, takie jak aktualizacja strony internetowej podczas edycji pliku CSS (! Naprawdę fajne), zawiesza się lub ulega awarii kilka razy na minutę. Więc wpisujesz 5 liter i 2 razy musisz zaczekać 2 sekundy lub 15 sekund między pisaniem. Miałem projekt z niektórymi wierszami kodu, więc nie chciałem czekać, co się stanie, gdy pojawią się wiersze 1000s. Przeniesienie pliku z jednego folderu do drugiego w Edytorze Dart, awaria. Debugowaniez Dart Editor jest na pierwszy rzut oka lepszy niż wszystkie narzędzia do debugowania js, które znam (chrom jest moim wyborem), ale wciąż brakuje zbyt wielu rzeczy: brak bezpośredniego okna (w tej chwili debugowanie js jest znacznie lepsze), brak zegarków.

2. Polityka i możliwości ucieczki : niektórzy twierdzą, że Apple, MS i Firefox nigdy nie zapewnią Dart VM. Cóż, nie jestem tego taki pewien, ale przynajmniej dla Apple wydaje się to w tej chwili bardzo pewne. Dla innych jest to bardziej prawdopodobne niż na odwrót. Więc nie ma problemu, możemy przekonwertować Dart do JavaScript. Sposób, w jaki ta integracja działa, jest naprawdę świetny, Dart utrzymuje kod js, który utrzymuje kod js podłączony do Dart Editor, więc print()w edytorze Dart nadal pojawia się komunikat, fajne. Ale nadchodzi ale: ślad takiego przekonwertowanego kodu jest wysoki. Około 150 kB (przed minimalizacją). Nie wkopałem się zbyt dokładnie w dokładny rozmiar, więc nie dręcz mnie tym.

3. Dojrzałość językowa . Poza zbyt poważnymi problemami z pojawieniem się mojej twarzy Edytora Dart 3 razy na minutę, uważam też za niedopuszczalne, że każde znalezione źródło kodu Dart używa innej Dart. Język zmienia się każdego dnia. Znajdziesz post sprzed 5 tygodni? To jest przestarzałe. Próbujesz próbek z samouczka Google? Co najmniej 1 próbka nie jest kompilowana od czasu zmiany interfejsu API. Nawet przyziemne rzeczy, takie jak dołączanie zdarzenia do elementu DOM, są w dobrym ruchu .

4. Trochę wymaga integracji z istniejącymi bibliotekami js. 2 maszyny wirtualne muszą się tutaj komunikować, to trudne.

Podsumowując, na dzień dzisiejszy nie możesz poważnie używać Dart, a nurkowanie w nim nie jest zbyt zabawne z powodu 1 i 3. Oba punkty znikną z czasem. Około 2 punktu Google opublikował kilka dni temu testy wydajności, które pokazują, że ich skompilowane pliki js są lepsze niż te pisane ręcznie. Moje komplementy, świetna robota. Jak już powiedziano, czas ładowania może być jeszcze opóźniony z powodu problemu ze śladami. Jednak jeśli kod śladu zostanie wykorzystany przez wiele witryn, może być dostępny w pamięci podręcznej i voila, również znika.

Tak więc: Uważam Dart za świetny projekt, jego użycie w tej chwili niesie ze sobą sporą część nieprzewidzianego ryzyka, a osiągnięcie tego stabilnego poziomu zajmie w tym roku.

Maszynopis

Ocena TypeScript jest bardzo łatwa, zajmuje 1 lub 2 godziny i wiesz wszystko. Czytając dokument ze specyfikacją języka i krótką książkę (ujawniono TypeScript), wiedziałem wszystko i zacząłem programować. Byłem zaskoczony, gdy zauważyłem, że dodatki TypeScript do JavaScript wypełniają każdą poważną potrzebę, jaką musiałem ulepszyć programowanie klienta . Oto najważniejsze informacje:

1. Interfejsy . Hermetyzacja i interfejsy umożliwiają mi łatwą strukturę kodu. Doskonały!

2. Stan klasy . TypeScript pozwala wyrazić stan jawnie przenoszony przez instancje klasy lub lepiej ją wymusza. Jest to duży krok lepiej w porównaniu z kawą js lub kawą.

3. thiszłagodzenie szaleństwa połączeń . Wewnątrz funkcji strzałek TypeScript sprawia, że thiswskaźnik jest jak każdy normalnie zachowujący się obywatel.

4. Redaktor, Intellisense . TypeScript jest wyposażony w 100% najwyższą idealną inteligencję, która reaguje w zakresie mikro- lub milisekund, tak jak w Visual Studio podczas programowania C #. Istnieją również nagłówki TypeScript dla wszystkich ważnych bibliotek js . Świetnie świetnie.

5. Doświadczenie i ryzyko . Korzystanie z TypeScript niesie ze sobą żadnego ryzyka, język jest jasno zdefiniowany, doskonale stabilny, to tylko js z cukrem, nic nieprzewidywalnego.

W rzeczywistości te ulepszenia dają mi wszystko, czego potrzebowałem. Jedyne, co chciałbym zobaczyć w przyszłości, to kolekcje ogólne. Ale to są orzeszki ziemne.

A co z wydajnością? Chociaż uważam się za maniaka wydajności, nie sądzę, aby istniał jakiś projekt, który dokonałby wyboru technologii na podstawie wydajności. Oba są w lidze js.

Jeśli interesuje Cię przyszłość programowania internetowego, oba są wielkim wysiłkiem, TypeScript jest teraz o wiele bardziej pragmatyczny i użyteczny, Dart to bardzo interesujący projekt laboratoryjny, który będzie użyteczny, gdy dojrzałe edytory i debuggery będą dostępne, a zakres projektów wykonalnych za pomocą będzie to zależeć od polityki.

W każdym razie 3 dni ewaluacji były głównie zabawne i wiele się nauczyłem, jeśli znajdziesz czas, 1 dzień zajmuje Dartowi i 2 godziny, aby TypeScript wydał własną opinię. Spróbuj.

Aktualizacja z października 2014 r

Minęło trochę czasu i ex post wydaje się, że założenie, że Maszynopis jest bezpieczną, stabilną drogą do przebycia, było całkiem słuszne. Właśnie znalazłem (bardzo) znaczącą wypowiedź na temat maszynopisu, dartu i zamknięcia:

Od dłuższego czasu interesuję się wyzwaniem programowania na dużą skalę. Uważam, że Google Closure jest obecnie najlepszą opcją do tworzenia dużych skryptów JavaScript / sieci, ale ostatecznie zostanie ona zastąpiona przez coś mniej gadatliwego. Mimo że Dart jest bardzo obiecujący, wciąż niepokoi mnie rozmiar generowanego JavaScript. Dla porównania, jeśli TypeScript można bezpośrednio przetłumaczyć na JavaScript, który można skompilować za pomocą zaawansowanego trybu kompilatora Closure, możemy uzyskać wszystkie zalety zoptymalizowanego JavaScript z Closure bez gadatliwości. Co więcej, ponieważ TypeScript jest nadzbiorem JavaScriptu, uważam, że jego rozszerzenia składniowe mają szansę przekształcić go w standard ECMAScript,

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

Michael Bolin jest od dawna bohaterem (ex) google (ex) fb, również zaangażowanym w zamykanie google (pobierz jego książkę o zamknięciu).

Google Traceur

Appraoch firmy Google do uruchomienia ECMA Script 6 dzisiaj to jej projekt Traceur: https://github.com/google/traceur-compiler

W porównaniu do maszynopisu obsługa narzędzi jest prawdopodobnie daleko w tyle na dzień dzisiejszy. Z drugiej jednak strony znacznie szybsze jest przyjmowanie zbyt fajnych przyszłych ulepszeń języka js, takich jak iteratory lub wyrażenia.

Facebook Flow, Google AtScript

zapewniają podobne funkcje jak TypeScript.

„Można się zastanawiać, co jest z tymi różnymi rozwiązaniami do sprawdzania typów JavaScript i co z tym zrobić. Dobra wiadomość jest taka, że ​​Microsoft, Facebook i Google współpracują nad nimi, według Jonathana Turnera:

Zespół TypeScript współpracuje zarówno z zespołami Flow, jak i AtScript, aby zapewnić, że zasoby, które zostały już utworzone przez społeczność pisania skryptów JavaScript, mogą być używane we wszystkich tych narzędziach. Wiele projektów można się od siebie nauczyć i nie możemy się doczekać wspólnej pracy i tworzenia najlepszych narzędzi dla społeczności JavaScript. W dłuższej perspektywie będziemy również pracować nad złożeniem najlepszych funkcji tych narzędzi w ECMAScript, standardzie JavaScript. „

artykuł infoq na temat przepływu FB

Cytując Scott Hanselman:

Ludzie porównali TypeScript do Dart. To porównuje jabłka do gaźników. TypeScript opiera się na JavaScript, więc nie ma problemów z interakcją JS. Dart to natywna maszyna wirtualna napisana od podstaw. Dart współpracuje z JavaScript ... ale to nie jest JS. Na przykład nawet nie używa typu numeru JavaScript.

Od Dlaczego TypeScript jest odpowiedzią na cokolwiek?

Musiałem ostatnio włączyć się do tej dyskusji z własnym odkryciem.

1st: TypeScript

MS przyjęło dobre podejście, ponieważ możesz łatwo wskakiwać i wyskakiwać z TS i JS. Używamy AngularJS do naszego rozwoju i znaleźliśmy, choć nie ma zbyt wiele dokumentacji do konwersji Angular na TypeScript. Przyjemnym dodatkiem było włączenie TypeScript do naszego przepływu pracy deweloperów.

2nd: Dart

Dart to ironiczny krok dla Google. Może nie pamiętają ActiveX i wszystkich koszmarów wokół, próbujących sprawić, by aplikacja działała w czymkolwiek innym niż przerażająca IE 5 lub IE 6 tego dnia. Minęło wiele lat, zanim stwardnienie rozsiane odzyskało zdrowie po tych dniach.

Dart jako język „koncepcyjnie” wydaje się próbować połączyć kilka fajnych funkcji OOP. Adnotacje itp. Są miłym pomysłem dla Javascript.

Problemem jest to, że trudno sobie wyobrazić wystarczającą przepustowość, aby utworzyć nowy edytor, nowy język, nowe maszyny wirtualne w przeglądarkach, wtyczki dla innych IDE, kompilator do konwersji na javascript (bez wielu megabajtów), konwersję lub tworzenie nowych bibliotek rzutek do wymień tysiące obecnych bibliotek js, poproś kogoś, aby zdecydował się na polimery lub dyrektywy, przekonwertuj stronę dartlang, aby używała rzutek, o tym myślę z góry.

Pomysł, aby w tej chwili używać Dart do niczego poza trywialną aplikacją, jest przerażający.

Co więcej, ES6 jest niedaleko. ES6 oferuje wiele funkcji, które Dart próbuje naprawić, które istnieją w ES5. Jaka będzie wartość oferty, gdy ES6 pojawi się na ulicach? Przynajmniej w tej chwili jedyną zmianą, którą musisz wprowadzić w TypeScript po pojawieniu się ES6, może być wybór innej kompilacji, na którą ma być skierowany cel.

Żeby wyjaśnić, że jestem profesjonalistą z MS. MS produkuje przyzwoite produkty i poczyniło wielkie postępy, aby naprawić wcześniejsze błędy ze społecznością OSS. Nadal się zmieniam, rzadko używam niczego innego niż TypeScript od MS.