Co to jest TypeScript i dlaczego miałbym go używać zamiast JavaScript? [Zamknięte]


1694

Czy możesz opisać, jaki jest język TypeScript?

Co może zrobić, czego nie może zrobić JavaScript lub dostępne biblioteki, co dałoby mi powód do rozważenia?



Oto kilka przemyśleń na ten temat: blog.priceandcost.com/development/…
Jefim

Odpowiedzi:


1298

Oryginalnie napisałem tę odpowiedź, gdy TypeScript był jeszcze w gorącym stanie. Pięć lat później jest to w porządku przegląd, ale spójrz na odpowiedź Lodewijk poniżej, aby uzyskać więcej szczegółów

Widok 1000 stóp ...

TypeScript to nadzbiór JavaScript, który przede wszystkim zapewnia opcjonalne pisanie statyczne, klasy i interfejsy. Jedną z dużych zalet jest umożliwienie IDE zapewnienia bogatszego środowiska do wykrywania typowych błędów podczas pisania kodu .

Aby dowiedzieć się, co mam na myśli, obejrzyj film wprowadzający firmy Microsoft dotyczący tego języka.

W przypadku dużego projektu JavaScript przyjęcie TypeScript może spowodować, że oprogramowanie będzie bardziej niezawodne, a jednocześnie będzie można je wdrożyć tam, gdzie działałaby zwykła aplikacja JavaScript.

Jest to oprogramowanie typu open source, ale mądry Intellisense pojawia się tylko podczas pisania, jeśli używasz obsługiwanego IDE. Początkowo było to tylko Visual Studio Microsoftu (odnotowane również w poście na blogu Miguela de Icazy ). Obecnie inne środowiska IDE również oferują obsługę TypeScript .

Czy istnieją inne podobne technologie?

Istnieje CoffeeScript , ale tak naprawdę służy on innemu celowi. IMHO, CoffeeScript zapewnia czytelność dla ludzi, ale TypeScript zapewnia również głęboką czytelność narzędzi dzięki opcjonalnemu pisaniu statycznemu ( więcej krytyki znajduje się w ostatnim poście na blogu ). Jest też Dart, ale to w pełni zastępuje JavaScript (choć może produkować kod JavaScript )

Przykład

Jako przykład, oto niektóre TypeScript (możesz się z tym bawić na Playground TypeScript )

class Greeter {
    greeting: string;
    constructor (message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}  

A oto JavaScript, który by wyprodukował

var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();

Zwróć uwagę, w jaki sposób TypeScript definiuje typ zmiennych składowych i parametry metody klasy. Jest to usuwane podczas tłumaczenia na JavaScript, ale używane przez IDE i kompilator do wykrywania błędów, takich jak przekazywanie typu liczbowego do konstruktora.

Jest również w stanie wnioskować o typach, które nie zostały jawnie zadeklarowane, na przykład, by określić, że greet()metoda zwraca ciąg znaków.

Debugowanie TypeScript

Wiele przeglądarek i IDE oferuje bezpośrednią obsługę debugowania poprzez sourcemaps. Zobacz to pytanie dotyczące przepełnienia stosu, aby uzyskać więcej informacji: Debugowanie kodu TypeScript w programie Visual Studio

Chcieć wiedzieć więcej?

Oryginalnie napisałem tę odpowiedź, gdy TypeScript był jeszcze w gorącym stanie. Sprawdź odpowiedź Lodewijk na to pytanie, aby uzyskać bardziej aktualne informacje.


103
WebStorm oferuje teraz ładny IntelliSense na TypeScript i jest wieloplatformowy.
Radek

26
Problem z tymi narzędziami polega na tym, że nigdy nie można uzyskać pełnej wydajności z javascript. Tak, zapewnia dobrą czytelność, ale skompilowany kod bywa czasem bardzo niezręczny. Do pisania natywnego języka javascript korzystasz z narzędzia innej firmy. Myślę, że nie jest to właściwa droga, to jak transformacja języka na inny. Chcąc zmienić język, który nie jest innym językiem, aby zachowywał się tak, jak lubisz, to głupie i głupie. ...... (koniec części 1) ......
Codebeat

56
@Erwinus: Czy nadal programowałeś w asemblerze?
VikciaR

11
@Erwinus Zakładasz, jak działa TypeScript. Możesz pisać zwykły JavaScript jako TypeScript, a kompilator może sprawdzać tylko typ czasu kompilacji. Dzięki temu nie ma utraty wydajności.
thinkrepo,

41
@Erwinus Celem TypeScript jest zapewnienie sprawdzania typu czasu kompilacji. Jeśli nie widzisz w tym wartości, to w porządku. TypeScript jest określany jako „twój pierwszy test jednostkowy”. Istnieje wiele zasobów, które omawiają, czy opcjonalne sprawdzanie typu ma wartość, i są bardziej szczegółowe niż to, co możemy tutaj zrobić. Nie próbuję cię o niczym przekonywać, tylko koryguję nieporozumienie.
thinkrepo,

1052

Relacja TypeScript do JavaScript

TypeScript to typowy nadzbiór JavaScript, który kompiluje się do zwykłego JavaScript - typescriptlang.org .

JavaScript to język programowania opracowany przez Komitet Techniczny EMCA 39 , który jest grupą ludzi złożoną z wielu różnych interesariuszy. TC39 jest komitetem organizowanym przez ECMA : wewnętrzną organizację normalizacyjną. JavaScript ma wiele różnych implementacji przez wielu różnych dostawców (np. Google, Microsoft, Oracle itp.). Celem JavaScript jest bycie lingua franca w sieci.

TypeScript jest nadzbiorem języka JavaScript, który ma jeden kompilator typu open source i jest rozwijany głównie przez jednego dostawcę: Microsoft. Celem TypeScript jest wczesne wykrywanie błędów w systemie typów i zwiększenie wydajności programowania JavaScript.

Zasadniczo TypeScript osiąga swoje cele na trzy sposoby:

  1. Obsługa nowoczesnych funkcji JavaScript - Język JavaScript (nie środowisko wykonawcze) jest znormalizowany zgodnie ze standardami ECMAScript . Nie wszystkie przeglądarki i środowiska wykonawcze JavaScript obsługują wszystkie funkcje wszystkich standardów ECMAScript (zobacz to omówienie ). TypeScript pozwala na użycie wielu najnowszych funkcji ECMAScript i tłumaczy je na starsze wybrane cele ECMAScript (patrz lista celów kompilacji pod --targetopcją kompilatora). Oznacza to, że możesz bezpiecznie korzystać z nowych funkcji, takich jak moduły, funkcje lambda, klasy, operator rozprzestrzeniania i destrukcja, pozostając jednocześnie kompatybilnym wstecz ze starszymi przeglądarkami i środowiskiem wykonawczym JavaScript.

  2. Zaawansowany system typów - obsługa typów nie jest częścią standardu ECMAScript i prawdopodobnie nigdy nie będzie wynikać z interpretowanej natury zamiast skompilowanej natury JavaScript. System typów TypeScript jest niezwykle bogaty i obejmuje: interfejsy, wyliczenia, typy hybrydowe, generyczne, typy sum / skrzyżowań, modyfikatory dostępu i wiele więcej. Oficjalna strona maszynopisu zawiera przegląd tych cech. System typów maszynopisu jest na równi z większością innych języków maszynowych, aw niektórych przypadkach prawdopodobnie bardziej wydajny.

  3. Obsługa narzędzi programistycznych - kompilator TypeScript może działać jako proces w tle, obsługujący zarówno kompilację przyrostową, jak i integrację IDE, dzięki czemu można łatwiej nawigować, identyfikować problemy, sprawdzać możliwości i refaktoryzować bazę kodu.

Relacja TypeScript z innymi językami docelowymi JavaScript

TypeScript ma unikalną filozofię w porównaniu do innych języków, które kompilują się w JavaScript. Kod JavaScript jest prawidłowym kodem TypeScript; TypeScript jest nadzbiorem JavaScript. Możesz prawie zmienić nazwy .jsplików na .tspliki i zacząć korzystać z TypeScript (patrz „Współdziałanie JavaScript” poniżej). Pliki TypeScript są kompilowane do czytelnego kodu JavaScript, dzięki czemu migracja jest możliwa, a zrozumienie skompilowanego TypeScript wcale nie jest trudne. TypeScript opiera się na sukcesach JavaScript, jednocześnie poprawiając jego słabości.

Z jednej strony masz narzędzia przyszłości, które przyjmują nowoczesne standardy ECMAScript i kompilują je do starszych wersji JavaScript, przy czym najpopularniejszym jest Babel. Z drugiej strony masz języki, które mogą się całkowicie różnić od JavaScript, które są ukierunkowane na JavaScript, takie jak CoffeeScript, Clojure, Dart, Elm, Haxe, Scala.js i wiele innych hostów (zobacz tę listę). Języki te, chociaż mogą być lepsze niż te, które mogłyby prowadzić do przyszłości JavaScript, wiążą się z większym ryzykiem braku wystarczającej adaptacji, aby zagwarantować ich przyszłość. Możesz również mieć więcej problemów ze znalezieniem doświadczonych programistów dla niektórych z tych języków, chociaż te, które znajdziesz, często są bardziej entuzjastyczne. Interakcja z JavaScript może być również nieco bardziej zaangażowana, ponieważ są one dalej usuwane z tego, czym faktycznie jest JavaScript.

TypeScript znajduje się pomiędzy tymi dwoma skrajnościami, równoważąc ryzyko. TypeScript nie jest żadnym ryzykownym wyborem. Przyzwyczajenie się do JavaScriptu wymaga bardzo niewielkiego wysiłku, ponieważ nie jest to zupełnie inny język, ma doskonałą obsługę interoperacyjności JavaScript i ostatnio wiele razy go przyjęto.

Opcjonalnie pisanie statyczne i wnioskowanie o typie

JavaScript jest wpisywany dynamicznie. Oznacza to, że JavaScript nie wie, jakiego typu jest zmienna, dopóki nie zostanie faktycznie utworzona w czasie wykonywania. Oznacza to również, że może być za późno. TypeScript dodaje obsługę typów do JavaScript. Błędy spowodowane przez fałszywe założenia, że ​​jakaś zmienna jest określonego typu, mogą zostać całkowicie wyeliminowane, jeśli dobrze zagrasz kartami (jak ścisłe wpisujesz kod lub jeśli w ogóle wpisujesz kod, zależy od ciebie).

TypeScript sprawia, że ​​pisanie jest nieco łatwiejsze i znacznie mniej wyraźne dzięki zastosowaniu wnioskowania o typie. Na przykład: var x = "hello"w TypeScript jest taki sam jak var x : string = "hello". Typ jest po prostu wywnioskowany z jego użycia. Nawet jeśli nie wpisujesz wyraźnie tych typów, nadal są one dostępne, aby uchronić cię przed zrobieniem czegoś, co w przeciwnym razie spowodowałoby błąd w czasie wykonywania.

TypeScript jest domyślnie wpisywany opcjonalnie. Na przykład function divideByTwo(x) { return x / 2 }jest poprawną funkcją w TypeScript, którą można wywołać za pomocą dowolnego parametru, nawet jeśli wywołanie jej ciągiem spowoduje oczywiście błąd w czasie wykonywania . Tak jak zwykle w JavaScript. Działa to, ponieważ gdy jawnie nie przypisano żadnego typu i nie można było wywnioskować typu, jak w przykładzie divideByTwo, TypeScript domyślnie przypisze ten typ any. Oznacza to, że podpis funkcji divideByTwo automatycznie staje się function divideByTwo(x : any) : any. Jest flag kompilatora, aby nie pozwolić na to zachowanie: --noImplicitAny. Włączenie tej flagi zapewnia większy stopień bezpieczeństwa, ale także oznacza, że ​​będziesz musiał częściej pisać.

Z typami wiąże się koszt. Po pierwsze, istnieje krzywa uczenia się, a po drugie, oczywiście, będzie trzeba trochę więcej czasu, aby skonfigurować bazę kodów przy użyciu odpowiedniego ścisłego pisania. Z mojego doświadczenia wynika, że ​​te koszty są całkowicie warte każdej poważnej bazy kodu, którą udostępniasz innym. Wielkoskalowe studium języków programowania i jakości kodu w Github sugeruje, że „języki o typie statycznym są generalnie mniej podatne na defekty niż typy dynamiczne i że pod tym samym względem lepsze pisanie jest lepsze niż pisanie słabe”.

Warto zauważyć, że ten sam artykuł stwierdza, że ​​TypeScript jest mniej podatny na błędy niż JavaScript:

Dla osób z dodatnimi współczynnikami możemy spodziewać się, że język jest związany z większą liczbą poprawek błędów. Te języki to C, C ++, JavaScript , Objective-C, Php i Python. Wszystkie języki Clojure, Haskell, Ruby, Scala i TypeScript mają ujemne współczynniki, co oznacza, że ​​prawdopodobieństwo, że te języki będą mniejsze niż średnia, spowoduje zatwierdzenie naprawy błędów.

Ulepszona obsługa IDE

Programowanie w TypeScript jest świetnym ulepszeniem w stosunku do JavaScript. IDE jest informowany w czasie rzeczywistym przez kompilator TypeScript o swoich bogatych typach informacji. Daje to kilka głównych zalet. Na przykład za pomocą TypeScript można bezpiecznie dokonywać refaktoryzacji, takich jak zmiany nazw w całej bazie kodu. Dzięki uzupełnianiu kodu możesz uzyskać bezpośrednią pomoc dotyczącą wszystkich funkcji, które może oferować biblioteka. Nie musisz już ich zapamiętywać ani szukać w referencjach online. Błędy kompilacji są zgłaszane bezpośrednio w IDE za pomocą czerwonej, kwadratowej linii, gdy jesteś zajęty kodowaniem. Podsumowując, pozwala to na znaczny wzrost wydajności w porównaniu do pracy z JavaScript. Można poświęcić więcej czasu na kodowanie, a mniej na debugowanie.

Istnieje wiele różnych IDE, które mają doskonałą obsługę TypeScript, takich jak Visual Studio Code, WebStorm, Atom i Sublime.

Ścisłe kontrole zerowe

Błędy czasu wykonania formularza cannot read property 'x' of undefinedlub undefined is not a functionsą bardzo często spowodowane błędami w kodzie JavaScript. Po wyjęciu z pudełka TypeScript już zmniejsza prawdopodobieństwo wystąpienia tego rodzaju błędów, ponieważ nie można użyć zmiennej, która nie jest znana kompilatorowi TypeScript (z wyjątkiem właściwości anyzmiennych typowanych). Nadal jednak można błędnie wykorzystać zmienną, która jest ustawiona na undefined. Jednak w wersji 2.0 TypeScript można razem wyeliminować tego rodzaju błędy poprzez użycie typów, które nie mają wartości zerowej. Działa to w następujący sposób:

Przy włączonej ścisłej kontroli zerowej ( --strictNullChecksflaga kompilatora) kompilator TypeScript nie zezwoli undefinedna przypisanie do zmiennej, chyba że jawnie zadeklarujesz, że jest typu zerowalnego. Na przykład let x : number = undefinedspowoduje błąd kompilacji. To doskonale pasuje do teorii typów, ponieważ undefinednie jest liczbą. Można określić xjako rodzaj suma numberi undefinedpoprawić w ten sposób: let x : number | undefined = undefined.

Gdy wiadomo, że typ jest zerowalny, co oznacza, że ​​może on również mieć wartość, nulllub undefinedkompilator TypeScript może określić poprzez analizę typu opartą na przepływie kontroli, czy kod może bezpiecznie używać zmiennej, czy nie. Innymi słowy, kiedy sprawdzasz, że zmienna przechodzi undefinedprzez, na przykład, ifkompilator TypeScript wywnioskuje, że typ w tej gałęzi przepływu sterowania twojego kodu nie jest już zerowalny i dlatego można go bezpiecznie używać. Oto prosty przykład:

let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.

Podczas kompilacji współtwórca konferencji TypeScript Anders Hejlsberg w 2016 r. Szczegółowo wyjaśnił i zademonstrował tę funkcję: wideo (od 44:30 do 56:30).

Kompilacja

Aby użyć TypeScript, potrzebujesz procesu kompilacji w celu skompilowania do kodu JavaScript. Proces kompilacji zwykle zajmuje tylko kilka sekund, w zależności od wielkości projektu. Kompilator TypeScript obsługuje kompilację przyrostową ( --watchflaga kompilatora), dzięki czemu wszystkie kolejne zmiany mogą być kompilowane z większą prędkością.

Kompilator TypeScript może wstawiać informacje o mapie źródłowej do generowanych plików .js lub tworzyć osobne pliki .map. Informacje o mapie źródłowej mogą być wykorzystywane przez narzędzia do debugowania, takie jak Chrome DevTools i inne środowiska IDE, w celu powiązania linii w JavaScript z liniami, które je wygenerowały w TypeScript. Umożliwia to ustawianie punktów przerwania i sprawdzanie zmiennych podczas działania bezpośrednio na kodzie TypeScript. Informacje o mapie źródłowej działają całkiem nieźle, istniały na długo przed TypeScript, ale debugowanie TypeScript na ogół nie jest tak świetne, jak w przypadku bezpośredniego używania JavaScript. Weźmy thisna przykład słowo kluczowe. Ze względu na zmienioną semantykę thissłowa kluczowego wokół zamknięć od ES2015, thismoże faktycznie istnieć w czasie wykonywania jako zmienna o nazwie _this(patrz ta odpowiedź). Może to dezorientować Cię podczas debugowania, ale ogólnie nie stanowi problemu, jeśli wiesz o tym lub sprawdzasz kod JavaScript. Należy zauważyć, że Babel ma dokładnie ten sam problem.

Kompilator TypeScript może wykonać kilka innych sztuczek, takich jak generowanie kodu przechwytującego na podstawie dekoratorów , generowanie kodu ładowania modułu dla różnych systemów modułów i analizowanie JSX . Prawdopodobnie jednak będziesz potrzebować narzędzia kompilacji oprócz kompilatora maszynopisu. Na przykład, jeśli chcesz skompresować kod, musisz dodać inne narzędzia do procesu kompilacji, aby to zrobić.

Dostępne są wtyczki kompilacji TypeScript do Webpack , Gulp , Grunt i praktycznie każdego innego narzędzia do budowania JavaScript. Dokumentacja TypeScript zawiera sekcję dotyczącą integracji z narzędziami do budowania obejmującymi je wszystkie. Linter dostępny jest również w przypadku chcesz jeszcze więcej kontroli czasu kompilacji. Istnieje również wiele projektów początkowych, które pomogą Ci rozpocząć pracę z TypeScript w połączeniu z szeregiem innych technologii, takich jak Angular 2, React, Ember, SystemJS, Webpack, Gulp itp.

Współdziałanie JavaScript

Ponieważ TypeScript jest tak blisko związany z JavaScriptem, ma świetne możliwości współdziałania, ale do pracy z bibliotekami JavaScript w TypeScript wymagana jest dodatkowa praca. Maszynopis definicje są potrzebne tak, że kompilator maszynopis rozumie, że wywołania funkcji, takich jak _.groupBylub angular.copyczy $.fadeOutnie są w rzeczywistości nielegalnych wypowiedzi. Definicje tych funkcji są umieszczone w .d.tsplikach.

Najprostszą formą, jaką może przyjąć definicja, jest dowolne użycie identyfikatora. Na przykład, gdy korzystasz z Lodash , plik definicji z jedną linią declare var _ : anypozwala na wywołanie dowolnej funkcji, którą chcesz _, ale oczywiście nadal możesz popełniać błędy: _.foobar()byłoby to legalne wywołanie TypeScript, ale oczywiście , nielegalne połączenie w czasie wykonywania. Jeśli chcesz mieć poprawną obsługę typów i uzupełnianie kodu, twój plik definicji musi być dokładniejszy (patrz definicje lodash na przykład).

Moduły Npm dostarczane fabrycznie z własnymi definicjami typów są automatycznie rozumiane przez kompilator TypeScript (patrz dokumentacja ). W przypadku prawie każdej innej, mało popularnej biblioteki JavaScript, która nie zawiera własnych definicji, ktoś już udostępnił definicje typów za pośrednictwem innego modułu npm. Moduły te mają przedrostek „@ types /” i pochodzą z repozytorium Github o nazwie DefinitelyTyped .

Jest jedno zastrzeżenie: definicje typów muszą być zgodne z wersją biblioteki używanej w czasie wykonywania. Jeśli nie, TypeScript może uniemożliwić Ci wywołanie funkcji lub odwołanie się do zmiennej, która istnieje, lub pozwolić na wywołanie funkcji lub odwołanie się do zmiennej, która nie istnieje, po prostu dlatego, że typy nie pasują do czasu wykonywania w czasie kompilacji . Upewnij się więc, że załadowałeś odpowiednią wersję definicji typów dla odpowiedniej wersji używanej biblioteki.

Szczerze mówiąc, jest to trochę kłopotliwe i może to być jeden z powodów, dla których nie wybrałeś TypeScript, ale zamiast tego wybrałeś coś takiego jak Babel, który wcale nie cierpi z powodu konieczności korzystania z definicji typów. Z drugiej strony, jeśli wiesz, co robisz, możesz łatwo rozwiązać wszelkie problemy spowodowane przez nieprawidłowe lub brakujące pliki definicji.

Konwersja JavaScript z TypeScript

Każdy .jsplik można zmienić nazwę na .tsplik i uruchomić przez kompilator TypeScript, aby uzyskać składniowo ten sam kod JavaScript, co wynik (jeśli był poprawny pod względem składniowym). Nawet jeśli kompilator TypeScript otrzyma błędy kompilacji, nadal będzie generować .jsplik. Może nawet akceptować .jspliki jako dane wejściowe z --allowJsflagą. Pozwala to od razu zacząć od TypeScript. Niestety błędy kompilacji mogą wystąpić na początku. Trzeba pamiętać, że nie są to błędy zatrzymujące wyświetlanie, jak w przypadku innych kompilatorów.

Błędy kompilacji, które pojawiają się na początku podczas konwersji projektu JavaScript na projekt TypeScript, są nieuniknione ze względu na charakter TypeScript. TypeScript sprawdza poprawność całego kodu, dlatego musi wiedzieć o wszystkich używanych funkcjach i zmiennych. Dlatego dla każdego z nich należy wprowadzić definicje typów, w przeciwnym razie z pewnością wystąpią błędy kompilacji. Jak wspomniano w powyższym rozdziale, dla praktycznie każdego frameworka JavaScript istnieją .d.tspliki, które można łatwo uzyskać dzięki instalacji pakietów DefinitelyTyped. Może się jednak zdarzyć, że użyłeś niejasnej biblioteki, dla której nie są dostępne definicje TypeScript lub że wypełniłeś niektóre prymitywy JavaScript. W takim przypadku musisz podać definicje typów tych bitów, aby błędy kompilacji zniknęły. Po prostu utwórz .d.tsplik i dołącz go do filestablicy tsconfig.json , aby zawsze był uwzględniany przez kompilator TypeScript. Zadeklaruj w nim te bity, o których TypeScript nie wie jako typ any. Po wyeliminowaniu wszystkich błędów możesz stopniowo wprowadzać pisanie w tych częściach zgodnie z własnymi potrzebami.

Konieczne będą także pewne prace nad (re) konfiguracją potoku kompilacji, aby wprowadzić TypeScript do potoku kompilacji. Jak wspomniano w rozdziale na temat kompilacji, istnieje wiele dobrych zasobów i zachęcam do szukania projektów początkowych, które wykorzystują kombinację narzędzi, z którymi chcesz pracować.

Największą przeszkodą jest krzywa uczenia się. Na początku zachęcam do zabawy przy małym projekcie. Zobacz, jak to działa, jak buduje, jakie pliki używa, jak jest skonfigurowany, jak działa w twoim IDE, jak jest zorganizowany, jakie narzędzia używa itp. Konwersja dużej bazy kodu JavaScript na TypeScript jest możliwa, gdy wiesz, że co robisz. Przeczytaj ten blog, na przykład na temat konwersji 600 000 wierszy na maszynopis w ciągu 72 godzin ). Upewnij się, że dobrze znasz język, zanim wykonasz skok.

Adopcja

TypeScript jest oprogramowaniem typu open source (licencja Apache 2, patrz GitHub ) i wspierana przez Microsoft. Anders Hejlsberg , główny architekt C # kieruje projektem. To bardzo aktywny projekt; Zespół TypeScript wypuścił wiele nowych funkcji w ciągu ostatnich kilku lat, a wiele z nich jest nadal planowanych (patrz mapa ).

Kilka faktów na temat adopcji i popularności:

  • W ankiecie dla programistów StackOverflow w 2017 r. TypeScript był najpopularniejszym transpilatorem JavaScript (9 miejsce w ogóle) i zdobył trzecie miejsce w najbardziej lubianej kategorii języków programowania.
  • W badaniu stanu js w 2018 r. TypeScript został ogłoszony jednym z dwóch dużych zwycięzców w kategorii smaków JavaScript (drugim jest ES6).
  • W ankiecie deverloper StackOverlow z 2019 roku TypeScript zajął 9 miejsce wśród najpopularniejszych języków wśród profesjonalnych programistów, wyprzedzając zarówno C, jak i C ++. Znów zajął trzecie miejsce wśród najbardziej lubianych języków.

25
„Kod JavaScript jest prawidłowym kodem TypeScript” - tak naprawdę nie zawsze jest to prawda. Mam na myśli kod, taki jak jeśli (1 === '1') {} daje błąd w TS i JS nie. Ale przez większość czasu, jeśli kod JS jest dobrze napisany, to prawda.
Maciej Bukowski

3
Jeśli straciłeś swój cenny produktywny czas na przejmowanie się brakującym średnikiem, pisanie na maszynie byłoby ratowaniem życia.
SoSufi

3
Pisanie jest przestarzałe, a obecnie najlepszą praktyką jest po prostu npm(lub yarn) install @types/foo. Czy potrafisz zaktualizować swoją odpowiedź?
Jed Fox

13
TL; DR oszczędziłoby w tej odpowiedzi;)
Qback

8
@MaciejBukowski Nawet jeśli TypeScript faktycznie narzeka w tym przypadku, nadal otrzymujesz prawidłowy wynik JS (który będzie kodem JS skompilowanym / transpilowanym za pomocą TypeScript). Jest to więc „kompilacja z błędem”, a nie niepoprawny TypeScript. W specyfikacji TypeScript zapisano, że każdy poprawny kod JS musi być prawidłowym kodem TS.
Pac0,

83

TypeScript robi coś podobnego do tego, co mniej lub sass robi dla CSS. Są to jego super zestawy, co oznacza, że ​​każdy kod JS, który piszesz, jest poprawnym kodem TypeScript. Dodatkowo możesz użyć innych dodatków dodanych do języka, a transpilowany kod będzie prawidłowym js. Możesz nawet ustawić wersję JS, na której chcesz uzyskać wynikowy kod.

Obecnie TypeScript jest super zestawem ES2015, więc może być dobrym wyborem, aby rozpocząć naukę nowych funkcji js i transponować je do wymaganego standardu dla twojego projektu.


4
Najlepsza TL; DR to strona TS: „TypeScript to typowy nadzbiór JavaScript, który kompiluje się w zwykły JavaScript”.
Juan Mendes,

1
Nie odpowiada jednak na pytanie „dlaczego powinienem go używać”. Tutaj tl; dr będzie: 1) Aby dodać opcjonalne typy statyczne do JavaScript. Typy mogą pomóc wykryć błędy w czasie kompilacji i lepiej udokumentować program. 2) Możesz napisać nowy JavaScript (ES6 / ES7 / ESnext) i skompilować go z powrotem do ES5, który jest niezbędny do obsługi starszych przeglądarek; Opracowałem trochę więcej na stronie tsmean.com/articles/vs/typescript-vs-javascript dla osób zainteresowanych więcej niż tl; dr
bersling

1
„Przeszczepiony kod będzie prawidłowy JS” - i to jest pięta achillesowa TypeScript, jeśli mnie o to poprosisz. Oznacza to, że nie mogą dodać kilku bardzo przydatnych funkcji do JS; przede wszystkim sprawdzanie typu środowiska wykonawczego . Trochę denerwujące jest posiadanie bezpieczeństwa typu kompilatora tylko po to, aby go utracić dla danych wykonawczych odczytywanych z I / O lub za każdym razem, gdy twój transpilowany kod jest wywoływany niezgodnie z innymi JS.
Jez

44

TypeScript Fundamentals ” - kurs wideo Pluralsight prowadzony przez Dana Wahlina i Johna Papę jest bardzo dobrym, obecnie (25 marca 2016 r.) Zaktualizowanym, aby odzwierciedlić TypeScript 1.8, wprowadzenie do maszynopisu.

Dla mnie naprawdę dobrymi funkcjami, oprócz fajnych możliwości inteligencji, są klasy , interfejsy , moduły , łatwość implementacji AMD oraz możliwość korzystania z debugera Visual Studio Typescript po wywołaniu z IE.

Podsumowując : Używany zgodnie z przeznaczeniem, Maszynopis może sprawić, że programowanie JavaScript będzie bardziej niezawodne i łatwiejsze. Może znacznie zwiększyć wydajność programisty JavaScript w porównaniu z pełnym SDLC.


9
jakie są SDLC? AMD?
Oooogi,

15
@Oooogi, SDLC == Cykl życia oprogramowania. AMD == Definicja modułu asynchronicznego. Ten drugi jest specyficzny dla JavaScript, podczas gdy ten drugi ma raczej ogólny zakres.
Dimitre Novatchev

2
„Łatwość implementacji AMD, ...” - przeczytałem to i pomyślałem, że to jakaś optymalizacja Threadrippera czy coś takiego.
jrh

15

Skrypt Ecma 5 (ES5), który obsługuje wszystkie przeglądarki i jest wstępnie skompilowany. ES6 / ES2015 i ES / 2016 przyszły w tym roku z dużą ilością zmian, więc aby je wyskoczyć, jest coś, co powinno zadbać o to, aby TypeScript.

• TypeScript to Typy -> Oznacza, że ​​musimy zdefiniować typ danych każdej właściwości i metody. Jeśli znasz C #, to Maszynopis jest łatwy do zrozumienia.

• Dużą zaletą TypeScript jest to, że problemy związane z typem tożsamości mamy na wczesnym etapie przed rozpoczęciem produkcji. Pozwala to na niepowodzenie testów jednostkowych, jeśli występuje niezgodność typu.


2
To nie jest co roku, kolego! .. zmienili specyfikację po bardzo długim oczekiwaniu
Subham Tripathi

... i te zmiany, które możesz skorelować z tym, że Microsoft ma w tym swoje palce. ;-)
Trober

2
@SubhamTripathi To bardzo jest co roku. ES2015, ES2016, ES2017 i tak dalej, aż język umrze. Nie było to co roku, przed 2015 rokiem, ale teraz jest. Wyszukaj „Proces TC39”, aby dowiedzieć się więcej.
daemonexmachina

1
czy było duże zapotrzebowanie na sprawdzanie typów w społeczności javascript? Po prostu nie miałem wielu błędów związanych ze sprawdzaniem typu.
Box and Cox
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.