Gdy JavaScript się rozwinął, okazało się, że nie jest w stanie unieść złożonych projektów. Trzeba było wymyślić język, dzięki któremu utrzymanie systemów będzie prostsze, tańsze i bardziej przewidywalne. Tak powstał TypeScript! W sto szesnastym odcinku DevTalk bierzemy na tapetę JS i TS. Poznamy trochę historii, kilka wad i zalet oraz perspektywy rozwoju. O wszystkim opowie Tomasz Ducin.
Tomek to niezależny konsultant, architekt i programista, przewodnik po świecie JavaScriptu. Udziela się jako spiker na konferencjach w Polsce i Europie. Jako trener tłumaczy z pasją jak co działa oraz uczy unikania przekomplikowanych rozwiązań i podejmowania zbędnych decyzji. Nie cierpi buzzwordów i wciskania ludziom kitu. Jest skoncentrowany na rozwiązywaniu technicznych i organizacyjnych bolączek projektów. Uwielbia pracę z ludźmi. Dwie ciekawostki: jest ex-aktorem teatralnym i pije cztery espresso dziennie. :)
Z tego odcinka dowiesz się:
- Czym się charakteryzuje JavaScript?
- Czy jest sens uczyć się samego JS?
- Po co komu TypeScript?
- Na czym polega kompilacja TSa?
- Na co możemy się nadziać w TS?
- Jakie są narzędzia i wsparcie TS na rok 2020?
- Gdzie warto się uczyć i w jakich projektach używać TypeScript?
- Przyszłość TypeScript i JavaScript – czy będzie merge?
PS Podoba Ci się ten odcinek? Zostaw gwiazdki i opinię na na iTunes. To BARDZO pomaga. Dzięki!
A teraz… PLAY!
Montaż odcinka: Krzysztof Śmigiel.
Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki:
- DevTalk
- DevTalk #96 – O Nauce Frontendu z Maciejem Korsanem
- DevTalk #92 – O błędach w tworzeniu WWW z Tomaszem “Comandeer” Jakutem
Tomasz Ducin
- blog Tomasza
- Tomek na Twitterze
- State of JS – ankieta o stanie javascript z 2019 roku
- Coffeescript.org
- Anders Hejlsberg
- Flow
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Nie żebym się czepiał, ponieważ rozmowy są zazwyczaj ciekawe, ale fakt, że spora ilość rozmówców jest w mniejszym lub większym stopniu powiązana z firmą Bottega sprawia, że podcast zaczyna wyglądać trochę jak reklama tejże firmy. Tymczasem w Polsce istnieją setki, jeśli nie tysiące organizacji zajmujących się w większym lub mniejszym stopniu wytwarzaniem rozmaitego oprogramowania. Więcej różnorodności! Odmiennych spojrzeń na praktyki tworzenia oprogramowania. Chętnie wysłuchałbym rozmowy z kimś o odmienych poglądach i sensownych argumentach na temat będących obecnie na topie dogmatów (przykład: “DDD się nie sprawdza”, “testy jednostkowe nie dają oczekiwanej jakości w porównaniu do nakładu pracy”, “SharePoint to najlepsza platforma dla developerów!” ;)), tudzież zajmujących się zupełnie innymi obszarami branży (był już np. SAP, programowanie mikro-kontrolerów, albo GameDev, prośba o więcej!)
Pozdrawiam.
Na tapet, nie tapetę.
Blazorjest kompilowany do WebAssembly czyli tego samego środowiska co Javascript (a w zasadzie jego gorące punkty).
Technologia ta może zniknąć ponieważ się nie spodoba programistom, ale nie ze względu na niekompatybilność rantajmu.
Ok. 31m — testy etwe? Hanselman zrobiłby przerywnik na tłumaczenie co to jest.
Testy E2E, end-to-end.
Ach ten Hanselman, też go <3 :)
Jako Python fan muszę wspomnieć o tym że typy w Pythonie są już od dawna i nikt już nie pisze testów na to. Np mypy robi to za nas. :)
Fajnie się słuchało, jednak mam dwa “ale”:
1. Typescript to nie jedynie JS + typy. Jest to faktycznie podstawowa funkcja, ale nie mniej istotna jest kompilacja w dół do starszych wersji JS. Mogę pisać kod z użyciem najnowszych elementów JS takich jak choćby klasy,,a kompilator TS skompiluje mi to w dół np. do ES5, dzięki czemu kod uruchomi się też przykładowo w IE. Jak dla mnie to bardzo istotna cecha. Przy czym pada argument o tym, że wynikowy JS równa się TS minus typy. Będzie sporo różnic, chociaż esencja będzie oczywiście zachowana.
2. Blazor nie ma nic wspólnego z Flashem, czy appletami Javy. Nie jest to plugin. W trybie “client side” Odpalany jest zoptymalizowany runtime .NET (Mono) skompilowany do WASM, którego wspierają wszystkie przeglądarki z wyjątkiem IE. W trybie “server side” uruchamiane jest połączenie z serwerem, które przesyła delty interfejsu użytkownika. Obie technologie nie wymagają żadnych dodatkowych elementów od przeglądarek.