Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

TypeScript czyli typowana wersja JavaScript

JavaScript powoli staje się najpopularniejszym językiem programowania. Nie posiada on składni, która górowałaby nad innymi językami. Maszyny wirtualne JavaScriptu są mniej wydajne niż JVM, a tym bardziej kod natywny. A jednak zastosowanie JavaScript z roku na rok zwiększa się. Już nie tylko stanowi jedyny język działający w przeglądarkach, ale również możemy używać go wszędzie tam gdzie nie potrzebna jest super wydajność. Frameworki takie jak NodeJS umożliwiają jego wykorzystanie po stronie serwera. Coraz częściej aplikacje wyglądające podobnie do natywnych są w rzeczywistości napisane w JavaScript. Przykładowo aplikacje Qt5 możemy oprogramować używając wyłącznie JS, podczas gdy wygląd opisujemy w formacie JSON. Microsoft również bardzo dobrze wspiera pisanie aplikacji w tym języku. Dość szybko zaczyna się spełniać interpretacja programistycznej zasady najmniejszej energii (Rule of least power) Jeffa Atwooda, mówiąca, że wszystko co da się napisać w JavaScript zostanie w nim napisane.

Dart od Google

Mimo to trudno znaleźć wielu programistów, którzy zachwycaliby się składnią JavaScript. Język ten jest bardzo ekspresyjny, jednak jego składnia, a w szczególności paradygmat obiektowy, odbiega od tego do czego jesteśmy przyzwyczajeni w najbardziej popularnych językach. Innym problemem jest brak typowania, które pozwala na wykrywanie wielu błędów już na poziomie kompilacji, bez konieczności pisania olbrzymiej ilości testów jednostkowych. Te i inne problemy są widoczne dla większości osób i firm zaangażowanych w rozwój standardów webowych. Dlatego też prace nad nowym standardem ECMAScript 6 stanowiących podstawę implementacji JavaScript w silnikach przeglądarek były bardzo długie (ostateczne zakończenie ich planuje się na czerwiec br.). Debatujący nie mogli zgodzić się co do kierunku w jakim powinny pójść zmiany. Google chciało bardzo poważnych zmian, jednak wiele innych firm wolało nie robić rewolucji, tak aby dawna wersja JavaScript była kompatybilna wstecznie z nową. Wynikiem niezadowolenia Google było opracowanie języka Dart będącego wizją tego czym powinien być JavaScript. Dart miał pojawić się w Chrome jako drugi język skryptowy. Obecnie wiemy, że plany te zostały zmienione i wycofano zupełnie się z tego pomysłu. Język ma niby być rozwijany dalej, ale już wiadomo, że Google ma zupełnie inny pomysł na JavaScript i można się obawiać o dalszy rozwój Darta.

Microsoft ma dobre pomysły?!

Swoją wizję co do przyszłości JavaScriptu przedstawił też Microsoft. Nie chciał on zbyt dużych rewolucji w samym języku, ale równocześnie widział jego mankamenty. Inżynierowie tej firmy, wpadli na bardzo ciekawy pomysł. Założyli, że napiszą kompilator do języka, który będzie kompilowany do JavaScript. Język ten nazwali TypeScriptem i jak sama nazwa wskazuje miał dostarczyć opcjonalne typowanie. Dart posiada tę samą możliwość jednak jako dodatek i cecha przejściowa, ponieważ docelowo miał być interpretowany bezpośrednio w przeglądarce. Microsoft nic takiego nie planował. Najważniejsze jednak w tym wszystkim (sam pomysł kompilacji to nic nowego, bo tak działa chociażby lubiany przez wielu CoffeeScript), że ma on działać w ten sposób, że każdy kod TypeScripta może zawierać kod czystego JavaScript. Możemy więc nie tylko dopisywać do kodu tego pierwszego kod tego drugiego, ale możemy też z założenia korzystać ze wszystkich bibliotek JavaScript. W drugą stronę bez problemu możemy korzystać z wszystkich plików napisanych w TypeScript, ale oczywiście po skompilowaniu. Konieczność kompilacji wydaje się dużym utrudnieniem, ale mając odpowiednie narzędzia nie stanowi, żadnego problemu. Najlepszym rozwiązaniem w tym przypadku jest kompilacja do JS przy każdym zapisie pliku.
Pomysł tego projektu od razu wydawał się świetny, ale jego realizacja mogła być trudna. Microsoft od razu zaplanował otwartość tego projektu. Kod jest dostępny na licencji Apache 2, posiadającej klauzulę mówiącą o tym, że piszący zrzeka się wszelkich własnych licencji w stosunku kodu, który napisał, a które ten kod mógłby naruszać. Nie ma więc mowy, że miałby to być tzw. prezent na gumce. Również realizacja pomysłu okazała się bardzo dobra. Wystarczy porównać kod kompilowany przez TypeScript Compiler (tsc) do tego z Darta, aby przekonać się, że efekt jest niesamowicie dobry. Kod po skompilowaniu bez problemu można czytać i nie zawiera, żadnych nadmiarowych elementów. Kod jaki wypluwa Dart jest zaś ciężkim do zrozumienia blobem. Nie wynika to tylko z jakości pracy inżynierów, ale przede wszystkim z przyjętych założeń projektowych. Efekt jest taki, że do pomysłu przekonało się Google. Zamierza ono bardzo intensywnie korzystać z TypeScripta. Zapowiedziano przepisanie niektórych bibliotek na ten język, w tym super popularnego ostatnio frameworka AngularJS. Wiele pomysłów Microsoftu skończyło się tragicznie (zapewne nie więcej niż w innych korporacjach - wystarczy porównać do Google), często zdarzało się, że forsował on własne standardy próbując zdominować inne firmy. Jednak w tym przypadku firma pokazała na prawdę wysoką klasę, dając społeczności świetne narzędzie, a równocześnie nie zamykając go dla swojej konkurencji. Co za czasy nastały!

Składnia TypeScript

Język ten dostarcza programiście typowanie zmiennych, argumentów i funkcji, klasyczny sposób tworzenia obiektów wraz z dziedziczeniem i interfejsami, moduły i typ wyliczeniowy oraz szereg innych udoskonaleń.
Przykładowy kod: class Zespolona { im : number; re : number; constructor ( im: number, re: number) { this.im = im; this.re = re; } getMod() : number { return Math.sqrt(this.im*this.im + this.re*this.re ); } add(zes : Zespolona): Zespolona { this.im += zes.im; this.re += zes.re; return this; } sub = (zes : Zespolona) : Zespolona => { this.im -= zes.im; this.re -= zes.re; return this; } toString() { return "Zespolona: rzeczywista " + this.re + " urojona " + this.im; } } var z1 = new Zespolona(23.34, 34.43); var z2 = new Zespolona(12.34, -34.43); console.log("zespolona moduł z sumy: " + z1.add(z2).getMod()); console.log("Różnica " + z1.sub(z2)); Typowanie jak widać odbywa się podobnie do Pascala i Scali po dwukropku i jest opcjonalne. Możemy przeładowywać metody i nadpisywać je. Metoda sub jest przykładem cukru syntaktycznego umożliwiającego uproszczenie zapisu funkcji, a w zasadzie jest zapisem funkcji anonimowej.

Edycja, kompilacja kodu i uruchomienie.

Obecnie chyba najlepszym narzędziem do pisania w TypeScript jest Visual Studio. Jednak inne firmy jak np. JetBrains również podjęły się zapewnieniu wsparcia dla tego języka. Sam do pisania w TypeScript użyłem Atom IDE, który potrafi całkiem nieźle podpowiadać składnie. W Ubuntu wystarczy dodać repozytorium webupd8 i zainstalować go za pomocą apt-get. Warto upewnić się czy mamy zainstalowane nodejs, nodejs-legacy i npm. Następnie za pomocą apm (menadżer instalacji wtyczek Atoma) doinstalowujemy pakiet typescript:apm install atom-typescriptJeśli nie chcemy również kompilować w konsoli ściągamy kompilator poprzez npm:npm install typescriptjest to również konieczne, aby utworzyć plik konfiguracyjny tsconfig.js.
Jeśli uruchomimy z sudo i flagą -g damy dostęp również innym użytkownikom, a my nie będziemy musieli podawać ścieżki do kompilatora.
Kompilacja odbywa się poprzez użycie programu tsc:tsc plik.ts(gdy nie zainstalowaliśmy globalnie, podajemy ścieżkę do tsc - w katalogu node_modules) i uruchamiamy za pomocą nodejs:node plik.jsWtyczka atom-typescript automatycznie kompiluje pliki ts jeśli do plku konfiguracyjnego dodamy linię:"disableCompileOnSave": false,Niestety często zdarza się, że nie chce kompilować świeżo dodanego pliku, aż do restartu.

Podsumowanie

O powstaniu projektu TypeScript wiedziałem już niedługo po jego powstaniu. Od razu wydawał mi się dużo sensowniejszym podejściem do problemu niż to co prezentowało Google. Nie od razu jednak wyglądało na to, że język i jego narzędzia spopularyzują się gdzieś indziej niż tylko jako dodatek do Visual Studio. Teraz jednak wydaje się, że przed tym językiem rysuje się wielka kariera. Dla programistów to dobre rozwiązanie eliminujące szereg słabości JavaScriptu, a przy tym niewymuszające na nikim jego stosowanie. Koszmar programistów nie kochających JavaScript coraz bardziej się spełnia, ale za to JavaScript może mieć, jak się okazuje bardziej ludzką twarz ;)

PS. Wygląd kodu z przykładu po kompilacji: var Zespolona = (function () { function Zespolona(im, re) { var _this = this; this.sub = function (zes) { _this.im -= zes.im; _this.re -= zes.re; return _this; }; this.im = im; this.re = re; } Zespolona.prototype.getMod = function () { return Math.sqrt(this.im * this.im + this.re * this.re); }; Zespolona.prototype.add = function (zes) { this.im += zes.im; this.re += zes.re; return this; }; Zespolona.prototype.toString = function () { return "Zespolona: rzeczywista " + this.re + " urojona " + this.im; }; return Zespolona; })(); var z1 = new Zespolona(23.34, 34.43); var z2 = new Zespolona(12.34, -34.43); console.log("zespolona moduł z sumy: " + z1.add(z2).getMod()); console.log("Różnica " + z1.sub(z2)); 

internet programowanie

Komentarze

0 nowych
Frankfurterium   9 #1 01.05.2015 23:57

Jeszcze niedawno płakałem, kiedy zmuszano mnie do pisania w JS-ie, a ostatnio, dzięki coraz ciekawszym narzędziom, sam do niego siadam. Niestety lub stety - za jakiś czas innego frontendu webowego/mobilnego niemal nie będzie.


Btn. trochę załamała mnie informacja o tym, że Atom też ma własny manager pakietów. Już wcześniej można było się zgubić: NVM do zarządzania instancjami Node'a; npm do modułów Node'a, Bower do zarządzania bibliotekami; gem Rubiego, żeby mieć Compassa, apm do Atoma...
Łatwiej ściągnąć odpowiedni box vagrantowy, niż to wszystko po kolei instalować.

gowain   18 #2 02.05.2015 00:06

Bardzo dobry wpis, coś tam bawiłem się jakiś czas temu z TypeScriptem i powiem, że fajnie to wygląda.

mikolaj_s   13 #3 02.05.2015 00:16

@Frankfurterium
"Już wcześniej można było się zgubić: NVM do zarządzania instancjami Node'a; npm do modułów Node'a, Bower do zarządzania bibliotekami; gem Rubiego, żeby mieć Compassa, apm do Atoma... "

To chyba kwestia automatyzacji. Przykładowo angular-seed po sklonowaniu wymaga tylko kilku komend. Po prostu narzędzia JS szybko się rozwijają i narzędzia automatyzacji jeszcze nie nadążają za nowościami. ;)

  #4 02.05.2015 22:12

O JavaScripcie nie powinno się myśleć, jako o języku, w którym pisze się kod, a raczej jako o języku pośrednim, pewnej abstrakcji, na kształt assemblera. Istnieje bardzo wiele narzędzi kompilowanych do JavaScriptu, oprócz wspomnianego TypeScriptu i Darta polecić mogę też C# (duocode!) oraz HaXe.
Do grona fajnych narzędzi teraz zaliczyć możemy też Visual Studio Code działające na OSX!
A sam JavaScript? No cóż... Jest jaki jest. Przyszło mi pisać interpreter tego języka, gdyż zaistniała tak potrzeba w projekcie i można powiedzieć, że dzięki byłem zmuszony przebyć tą samą drogę co Brendan Eich wiele lat temu i patrzę na tą konstrukcję trochę bardziej wyrozumiale.

kowgli   6 #5 02.05.2015 22:43

Fajnie byłoby moim zdaniem jeszcze pokazać jaki podany TS generuje JS, bo w tym cała istota.

  #6 02.05.2015 22:59

Ciekawi mnie jak rozumiesz super wydajność?

aPoCoMiLogin   7 #7 02.05.2015 23:15

Webstorm korzysta z jednego repo: https://github.com/borisyankov/DefinitelyTyped gdzie znajduje się ogromna liczba definicji w typescript dla wielu popularnych libów.

Jusko   12 #8 02.05.2015 23:54

JavaScript - troszkę mierzi mnie, gdy pomyślę o kodowaniu czegokolwiek w tym języku. Szybciej zdążyłem opanować w wystarczającym dla mnie stopniu technologie webowe, Javę, a przy okazji zbudować w międzyczasie parę javowych aplikacji z GUI.

Wyparcie JS jest u mnie tak duże, że mimo nieustannych szlifów - moja głowa po prostu go nie przyjmuje :-P

Autor edytował komentarz.
ra-v   12 #9 03.05.2015 00:06

Myślę, że można to przyrównać w ten sposób - jeśli TypeScript jest tym, czym C++ w oprogramowaniu niewebowym, to JavaScript jest ASMem. Czyli jest dylemat - łatwość programowania vs wydajność.
A co będzie, gdy w TS zostanie znaleziony kiks na miarę OpenSSLa?

mikolaj_s   13 #10 03.05.2015 00:22

@Jusko: "zdążyłem opanować w wystarczającym dla mnie stopniu technologie webowe"
Nie ma technologii webowych bez JS :) Co do języka to idzie się przyzwyczaić, a jak ciężko to warto wypróbować TypeScript.

@@ra-v "Czyli jest dylemat - łatwość programowania vs wydajność."
Nie ma dylematu. TypeScript daje kod równie wydajny, no chyba, że ma problemy w jakimś bardziej złożonym kodem, ale wątpię bo w zasadzie kod łatwo się tlumaczy z TS na JS.

"A co będzie, gdy w TS zostanie znaleziony kiks na miarę OpenSSLa?"
To i w JS może być bug. Tak to niczego nie można by spokojnie tknąć. ;)

Pablo_Wawa   9 #11 03.05.2015 01:40

Popraw kod metody sub klasy Zespolona, ponieważ nie realizuje ona odejmowania liczb, a dodawanie (tak to bywa, jak się na szybko kopiuje jakiś kod).

  #12 03.05.2015 06:33

Żeby być jeszcze całkowicie grammar nazi dorzucę, że metoda getModulo(), powinna nazywać się getModulus(), bo ona liczy moduł liczby, a nie resztę z dzielenia.

mikolaj_s   13 #13 03.05.2015 13:23

@Pablo_Wawa: Dzięki za czujność. Zapomniałem poprawić po skopiowaniu metody add ;) Tak to jest jak się nie pisze testów jednostkowych.

  #14 03.05.2015 13:27

@ra-v: Założeniem TS jest to, że kod wynikowy ma wyglądać tak ładnie jakbyś sam go napisał.

W odróżnieniu od ASM.js gdzie zmienne trzeba trzymać w typowanych tablicach i emulować stos i stertę języka C.

nintyfan   10 #15 03.05.2015 14:00

Szacun dla firmy MS. Sam mógłbym wpaść kiedyś na tak dobre pomysły. Należy jednak zwrócić uwagę, że Makefile to taki shell z dodatkową składnią.

Jak rozwiązano dziedziczenie atrybutów/metod prywatnych? W JavaScripcie ciężko coś takiego zrealizować, jeśli w ogóle jest możliwe.

Taka mała uwaga: czy przypadkiem ASMJS nie dostarcza typowania?

Autor edytował komentarz.
mikolaj_s   13 #16 03.05.2015 14:53

@nintyfan: "Jak rozwiązano dziedziczenie atrybutów/metod prywatnych? W JavaScripcie ciężko coś takiego zrealizować, jeśli w ogóle jest możliwe "

Nie testowałem tego zbytnio, ale jak najbardziej to jest. W kodzie JS nic z tego nie widać. Po prostu pisząc TS kompilator i IDE podpowiada Ci, że nie możesz użyć danego pola klasy bo jest prywatne. W asemblerze też przecież nie ma pól prywatnych ;)

"Taka mała uwaga: czy przypadkiem ASMJS nie dostarcza typowania?"
Owszem dostarcza, ale raczej nie jest zastępstwem TypeScript. Chociaż może dobrym pomysłem byłby kompilator z TS do asm.js. ;)

kostek135   8 #17 03.05.2015 18:33

@nintyfan: "Jak rozwiązano dziedziczenie atrybutów/metod prywatnych? W JavaScripcie ciężko coś takiego zrealizować, jeśli w ogóle jest możliwe."
Ciężko? Jak się nie zna słowa kluczowego var, to może i tak: http://stackoverflow.com/a/2803378

Autor edytował komentarz.
mikolaj_s   13 #18 03.05.2015 19:31

@kostek135: To nie do końca to samo. Spróbuj w przykładzie kodu w artykule po skompilowaniu użyć zmiennej _this, w którejś metodzie dodawanej przez prototype. W rzeczywistości ten sposób, który podajesz wykorzystuje zasięg zmiennej i domknięcia. Efekt jest podobny, ale jak widać nie do końca.

Mad.   3 #19 03.05.2015 22:27

Jeśli chcecie pobawić się TypeScript-em, to wystarczy wejść tutaj: http://www.typescriptlang.org/Playground
Dziedziczenie w TS i JS: wybierzcie z listy Walkthrough: Inheritance.

Autor edytował komentarz.
molexor   6 #20 03.05.2015 22:52

Och! Ach! TypesScript! Biegnę po książkę i się uczę bo przecież ten JS jest taaaaki trudny. No nie da się go zrozumieć! podobnie jak c++! toż to nie dla ludzi!
I już zmieniam wszystkie toole żeby móc z tego korzystać. Instaluje VisualStudio żeby se móc debugować! Jak ja mogłem bez tego żyć do tej pory! :P
Powoli...
ECMA 6 wyjdzie, przegladarki zaktualizują- sytuacja wróci do normy.
Mam pytanie po tym sarkaźmie lciutkim ;)
Co ma Typescript czego nie będzie w Ecma 6?

  #21 04.05.2015 00:31

@nintyfan: Pola prywatne, const i część typów nie są informacją dla programu, tylko dla programisty. Kompilator analizując kod zgłasza błąd, że gdzieś użyłeś tego czego nie powinieneś i tyle. Kod wynikowy metod prywatnych to normalne funkcje.

ASMJS nie dostarcza typowania. Wprowadzono jedynie typowane tablice w JS wraz z WebGL. Ułatwiają komunikację i zwiększają wydajność.
ASMJS to tylko ich wykorzystanie w celu emulowania pamięci komputera dla języka C.

  #22 04.05.2015 00:32

@molexor: To ma, że działa dzisiaj. A w przyszłości stanie się standardem ECMA.

ra-v   12 #23 04.05.2015 01:06

@mikolaj_s: #10
"no chyba, że ma problemy w jakimś bardziej złożonym kodem"
Czyli są wątpliwości ;-)

"To i w JS może być bug. "
Oczywiście, ale jeśli w czystym JS po testach nie ma błędu, w TS też nie, ale po roku okazuje się, że któryś z miliona testerów coś wykrył, to wtedy TS leży, JS nie (często nie "leży" ze względu na swoją unikalność).

ra-v   12 #24 04.05.2015 01:08

@Anonim (niezalogowany): #14
Założenia i efekty często nie leżą obok siebie.

Kamatori   6 #25 04.05.2015 07:44

@molexor: sprawdzanie typów, ciut inne podejście do klas i w sumie tyle. Gdy ECMA6 oficjalnie wyjdzie na produkcyjny kod to 'języki' pokroju TypeScripta, CoffieScripta, ClojureScripta etc. będą musiały przejść spore zmiany by utrzymać się na rynku.

mikolaj_s   13 #26 04.05.2015 14:34

@ra-v: "Czyli są wątpliwości ;-) "
Nie da się udowodnić, że krasnoludki nie istnieją. ;) Sam za bardzo tego nie testowałem, ale nie słyszałem o jakiś problemach.

" ale po roku okazuje się, że któryś z miliona testerów coś wykrył, to wtedy TS leży,"
Widziałeś kiedyś jakiś software bez błędów? To może żyjesz w jakimś innym lepszym świecie. :D Jak znajdą błąd to zawsze można go naprawić, tak się robi zazwyczaj ;)

mikolaj_s   13 #27 04.05.2015 14:40

@molexor: "Biegnę po książkę i się uczę bo przecież ten JS jest taaaaki trudny. "
Języki programowania są jak szczoteczki do zębów. Są użyteczne, ale kto by chciał czytać książkę o szczoteczce? :) TS daje po prostu możliwość szybszego tworzenia aplikacji. Niektórzy lubią chodzić, ale inny się spieszy i wsiadają do samochodu.

awangardowy   7 #28 05.05.2015 11:35

Google od dluzszego czasu ma ochote na stworzenie swojego, kompleksowego j. programowania,
Przykładem jest język GO , którego nikt oprócz Googli i kilku powiązanych z nimi korporacji nie uzywa.
Akurat język GO jest fajny, przejrzałem składnie, to naprawdę czysty i elegancki. Natknąłem się w praktyce, jak zauważyłem jakiś skrypt w tym języku i tutaj nagle pojawiło się jakieś "GO"... w sumie fajnie im to wyszło ;)
Zresztą oni mają też strategię skupowania programistów, którzy mieli duże osiągnięcia w tworzeniu natywnych bibliotek/języków (głównie to pierwsze: stworzyłeś dobrą i znaną, uniwersalną bbibliotekę do języka X? Google może się tobą zainteresować...).
Przykład:
http://en.wikipedia.org/wiki/Guido_van_Rossum
Guido van Rossum
twórca Pythona długo pracował dla Googli.

Google konkuruje z javą od Oracle, która zawładnęła ich Anroidem (sytuacja paradoksalna, bo Google nie ma pełnej kontroli nad eko-systemem, bo przecież java w Androidzie jest standardem).
No i dlatego kolejną próbą jest np. ten język Dart (oczywiście javaScript a java to coś innego). Chodzi żeby wytworzyć jakąś swoją technologię, która stanie się popularna i która de facto da kontrolę nad jakimś skrawkiem programistycznego tortu...

co do TypeScriptu, to nie dla mnie, bo Windows i VS nie są mi potrzebne. ;)
Nawet hello world nie będzie.

Autor edytował komentarz.
  #29 05.05.2015 13:05

@awangardowy: Tak, ale samo Google produkuje jedne z najgorszych bibliotek na świecie. Wiele bibliotek Androida i Pythona zostało za takie uznane. Wspomniany przez ciebie Guido wiele razy musiał się tłumaczyć, że on za nie nie odpowiada. Z resztą uciekł do Dropboxa.

Jeśli chodzi o Go, to teoretyzujesz. Sądząc po wypowiedziach na Rededicie, wielu programistów G. jest do niego zmuszanych. Sam język nie jest jakiś wspaniały. Jak chcesz fajny hipsterski język to zainteresuj się Rust. A jak chcesz fajny, ale normalny to nowe C# z async jest świetne.

mikolaj_s   13 #30 05.05.2015 14:55

@awangardowy: Osobiście bardziej niż Go podoba mi się Rust. Tyle, źe,to ciągłe wymyślenie nowych języków i proba ich forsowania, przeoisywania tych samych bibliotek od nowa jest męcząca. A jeśli język ma służyć jakieś dominacji to szkoda nim sobie zawracać głowy.

Co do TypeScriptu to nie ma co kojarzyć go tylko z Microsoftem. JetBrains juź pracuje nad wsparciem i jak zwykle WebStorm będzie pewnie najlepszy również do niego. Sam pisałem w Atomie IDE i całkiem fajnie działa. Projektem i tak zarządza się najlepiej z konsoli.

ra-v   12 #31 06.05.2015 19:16

@mikolaj_s:
Ale w przypadku gdy błąd jest w "kompilatorze", to wszystko leży. A kto będzie naprawiał stare, wygenerowane JSy :) ?