Jaka jest motywacja TypeScript?

Mieliśmy JavaScript, potem Flash, potem Silverlight, a potem HTML5 - wszystkie.

Jaka jest zatem motywacja TypeScript? Jakie problemy zostaną rozwiązane i jakie ulepszenia uzyskamy dzięki TypeScript?

http://www.typescriptlang.org/

Wygląda mi na to, że jest to statycznie wpisany, oparty na klasach język, który kompiluje się do JavaScript. To dobry pomysł, który inni też mieli.

Korzyści powinny być oczywiste dla każdego, kto opracował zarówno w statycznie typowanych językach opartych na klasach, jak iw JavaScript:

• Przede wszystkim kompilator. Możliwość sprawdzenia pod kątem oczywistych problemów z poprawnością spowodowanych literówkami lub nieostrożnością przed wdrożeniem jest czymś, co większość programistów bierze za pewnik, dopóki nie będzie musiała zajmować się tworzeniem stron internetowych, a następnie nagle wyrywa się spod ich stóp. Przeglądarki zostały zaprojektowane tak, aby przeglądanie było przyjemne kosztem odpowiednich narzędzi do testowania i debugowania, a standardowe rozwiązanie, JSLint, nie zastąpi prawdziwego kompilatora, ponieważ pomija pewne oczywiste problemy z poprawnością i łączy wiele skarg sprawdzających styl w z jego raportami. Posiadanie prawdziwego kompilatora to ogromny krok naprzód.
• I wzdłuż podobnych linii system typów . Systemy typów poprawiają kod, ułatwiając czytanie (dokładnie wiesz, co jest przekazywane do funkcji i co może zrobić, po prostu patrząc na listę parametrów, na przykład) oraz wymuszając pewien stopień poprawności podczas kompilacji czas. (Jeśli spodziewasz się określonego typu obiektu, podanie liczby całkowitej jest błędem. JavaScript pozwoli ci to zrobić, a następnie wybuchnie, gdy spróbujesz go uruchomić; kompilator z systemem typów złapie go i zgłosi błąd dla ty.)

Jak widzimy, podstawowy pomysł jest bardzo dobry. Powiedziawszy to, nie mogę nic powiedzieć o samym języku, ponieważ nie mam z nim doświadczenia. Ale użyłem Smart (link powyżej) i okazało się, że jest to niezwykle potężne i przydatne narzędzie do tworzenia stron internetowych.

O ile wiem, istnieje kilka dobrych powodów, aby używać TypeScript. Przede wszystkim, jak powiedział Mason Wheeler, kompilator . A raczej cała kontrola wykonywana przez kompilator. JSLint i inne narzędzia są przydatne, ale brakuje niektórych problemów i czasami są po prostu błędne. Z pewnością z zadowoleniem przyjmuję tę „innowację”.

Następnie istnieje prawdziwy system typów , poprawiający czytelność i egzekwujący prawidłowe typy. W końcu zwiększa to szybkość rozwoju.

Dla mnie jedną z wielkich rzeczy jest wsparcie narzędziowe . To prawdopodobnie efekt uboczny systemu typów, ale mimo to świetny. I naprawdę konieczne, ponieważ obecna obsługa narzędzi JavaScript jest bardzo przydatna.

TypeScript próbuje rozszerzyć JavaScript . Kompilator generuje naprawdę niezły JavaScript. Poza tym jest zgodny z propozycjami ECMAScript 6 . (Na przykład składnia funkcji strzałki , wartości domyślne parametrów , moduły i tak dalej.

Ułatwia to pracę z modułami i klasami . W rzeczywistości jest możliwa i dość powszechna praca z klasami i modułami w JavaScript, ale wymaga to pewnej ilości kodu z podstawowymi informacjami. I nie jest to łatwe do odczytania. TypeScript pozwala na pisanie instrukcji klas, interfejsów i modułów, tak jak w Javie lub C #, co jest o wiele łatwiejsze, jeśli mnie o to poprosisz.

Ale w końcu jest to po prostu JavaScript . Nie ma potrzeby uczenia się nowego języka lub składni. Jedyne, co dodaje, to opcjonalny system pisma (który jest świetny i spóźniony).

Jest też „biblioteka definicji” , co oznacza, że ​​mogę używać wszystkich moich bibliotek JavaScript bez przepisywania, a nawet łatania ich. Jednak teraz mam dodatkowy system typów.

Na pewno spróbuję!

I ostatnia rzecz, nie ma konkurencji między HTML5 a TypeScript. Ale to inna historia.

Mieliśmy JavaScript, potem Flash, potem Silverlight, a potem HTML5 - wszystkie.

To po prostu NIE jest prawdą . HTML5 nie jest ich właścicielem, wprowadza nowe znaczniki, które upraszczają korzystanie z multimediów i odkrywa zalety przeglądarek nowej ery (takich jak przyspieszenie sprzętowe podczas renderowania html).

Jaka jest zatem motywacja TypeScript?

Motywacje mogą wynikać z powodów, dla których warto z nich korzystać. Wszystkie funkcje TypeScript, takie jak: sprawdzanie statyczne, nawigacja oparta na symbolach, uzupełnianie instrukcji i refaktoryzacja kodu są bardzo silnymi powodami, aby to rozważyć.

Ponadto oferuje klasy, moduły i interfejsy, które pomagają w budowaniu niezawodnych komponentów. Funkcje te są dostępne w czasie programowania do tworzenia aplikacji o wysokim poziomie zaufania, ale są skompilowane w prosty JavaScript.

Może być traktowane jako narzędzie do zarządzania rozwojem javascript, a nie jako zupełnie nowy język, który kompiluje się w JS. Nie chce być językiem programowania po stronie serwera, takim jak Dart, i nie może mieć innej składni, jak CoffeeScript. Nie chciał brać popularnego języka (i jego podstawowej biblioteki) i kompilować go do JS, takiego jak GWT lub skrypt nr. TypeScript ma nawet tę samą składnię „klasy”, którą zaproponowano dla następnej wersji JS.

Myślę, że większość tworzenia stron internetowych odbywa się dzisiaj przy użyciu prawdziwego języka JavaScript, tylko po stronie klienta. Języki lub frameworki, takie jak Dart, GWT nie są do tego odpowiednie. Jeśli wybierzesz coffeescript, pojawi się nowa składnia. Musisz zrozumieć zarówno coffeescript, jak i JS. Podczas gdy TypeScript dodaje tylko kilka dodatkowych funkcji zorientowanych na typ, połączonych w JS, które chronią programistów przed błędami specyficznymi dla typu (co stanowi dużą część błędów JS) i daje narzędziom programistycznym więcej informacji na temat zamiarów programistów.

To podejście nie jest nowe. Przejdź do sekcji „Pisanie statyczne” w

Ten artykuł dotyczy twojego zapytania- http://www.eweek.com/developer/microsoft-delivers-typescript-a-better-javascript-for-big-apps/

Myślę, że wysiłek polega na przekształceniu wspólnego, niewiarygodnego badziewia (javascript) w zastrzeżony język, który w rzeczywistości można wykorzystać do dużych projektów.

Należy go porównać do GWT, który ma podobny zestaw celów, ale przyjął czystsze podejście, nie czyniąc javascript częścią języka; oraz z apletami Java lub Flash, które przyjmują bardzo czyste podejście do definiowania pełnego środowiska wykonawczego niezależnego od przeglądarki.

Twoja opinia może się różnić, ale myślę, że jest ona skazana na niepowodzenie, o ile zależy ona od przeglądarek natywnie dostarczających (różne, niespójne) implementacje javascript i modele DOM.