Typescript - konieczność?

Jak tak patrzę, to jest ogromny hype na Typescript. Co chwilę trafiam na jakieś artykuły w stylu Why TypeScript is the best way to write Front-end. Jak to jest w polskim biznesie? Wyparł już JS? Są nowe projekty w React/Vue w zwykłym JS?

nobody01 napisał(a):

Jak tak patrzę, to jest ogromny hype na Typescript. Co chwilę trafiam na jakieś artykuły w stylu Why TypeScript is the best way to write Front-end. Jak to jest w polskim biznesie? Wyparł już JS? Są nowe projekty w React/Vue w zwykłym JS?

U nas raczej migrujemy z czystego JS do TS. Pomaga utrzymać porządek w kodzie również na froncie

Znacie jakiś javowski transpiler do tego?

EDIT: Na C# też się nie pogniewam

W obecnych projektach jak i poprzednich też migrujemy JS -> TS, a wszystko nowe powstaje już w TS.

Pracuje z TS od wersji 2.1 - jeżeli byłby kompilator TS -> .net, to bym z C# zrezygnował :D
Jak pracuje z .net core to TS + NSwag TS Generator/AutoGen TS to taki standard sie robi - i dobrze, śmierć ręcznym klientom do api1

Cześć. Również potwierdzam zwiększoną popularność wyboru TypeScript'a w projektach komercyjnych.

Gdzieś słyszałem, że (chyba) 40% błędów w JSie jest związanych z zmiennymi (błędy typu: Cannot read property of undefined/null). Do Reacta jest nawet biblioteka która miała pomóc w typowaniu (oraz chyba autopodpowiadanie), więc było widać zapotrzebowanie na typowanie. Typescript zapewnia to z pudełka, nie widzę przyczyny do tworzenia nowych projektów w "czystym" JSie.

Edit: Ja na codzień pisze w Angularze, więc z automatu korzystam z Typescripta. Miałem krótką przygodę ucząc się Reacta, ale tam też uważam że nie ma sensu pisania w czystym JSie.

Zgadza się, jest ogromny hype na TypeScript i wiele osób idzie w tym kierunku. Jest to spowodowane przez cztery rzeczy: 1. sporo programistów przesiada się z języków typowanych (Java umiera) i nie potrafią pisać w JS i Pythonie bez typów, 2. ludzie gardzą JS-em, uważając go za g**no język, a TypeScript to coś nieco innego (choć tak naprawdę nadal JS), 3. w wielu firmach "nie ma czasu" na testy i/lub programiści nie chcą ich pisać, 4. moda.

Gdzieś słyszałem, że (chyba) 40% błędów w JSie jest związanych z zmiennymi (błędy typu: Cannot read property of undefined/null).

Nie wiem ile, ale fakt, często. Tylko co z tego? Takie błędy są akurat łatwo wykrywane i łatwo naprawialne. Przeglądarka rzuca ci błędem, łatwo dojść po nitce do kłębka, gdzie nastąpił błąd. Dla mnie to nie jest żaden specjalnie dobry argument za TypeScriptem. Prędzej za optional chaining, który to może złagodzić w niektórych sytuacjach: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining

Moim zdaniem od tego typu błędów bardziej trudne są wszelakie race condition, gdzie masz asynchroniczny kod, który w różny sposób się zachowuje w zależności od tego, co się stało wcześniej. Gdyby ten problem rozwiązać (np. za pomocą jakichś dobrych narzędzi debuggerskich), to by to wniosło więcej niż TypeScript.

A pisać w TypeScript nie lubię, bo mnie spowalnia. Lubię prototypować i zmieniać kod w miarę potrzeb, a potem dopiero definiować konkretne interfejsy czy wymyślać nazwy. Tak samo jak robię komponenty React, to jeśli chcę dodać jakąś testową albo dodatkową właściwość do komponentu, to błędy TypeScripta o tym, że nie ma takiej właściwości, tylko wkurzają.

Ale zastanawiam się, czy nie dodać TypeScriptu do swojego prywatnego projektu, bo używam wiele luźnych struktur danych, które chciałbym jakoś usystematyzować, żeby móc łatwiej śledzić zależności w projekcie. A są to zależności typu "jakaś funkcja przekazuje do drugiej funkcji obiekt o danych właściwościach i muszę pamiętać, która funkcja co przyjmuje". W TS byłby interfejs Foo czy Bar i jawne importowanie. I kontrola typów jako bonus.

W sumie... może lepsze użycie TypeScriptu to dodawanie go na jakimś etapie dopiero do projektu albo do konkretnych modułów? Dopiero na etapie, kiedy kod będzie dość stabilny i gdzie nie będzie potrzeba robienia wielkich eksperymentów?

Haskell napisał(a):

1. w wielu firmach "nie ma czasu" na testy i/lub programiści nie chcą ich pisać

Trochę offtop, ale jak to jest z testowaniem reacta w polskim biznesie? Tak samo popularne jak na backendzie, czy raczej przeważa widzę, że działa, więc po co testować? Ktoś tu chyba kiedyś pisał, że raczej to drugie.

LukeJL napisał(a):

Gdzieś słyszałem, że (chyba) 40% błędów w JSie jest związanych z zmiennymi (błędy typu: Cannot read property of undefined/null).

Nie wiem ile, ale fakt, często. Tylko co z tego? Takie błędy są akurat łatwo wykrywane i łatwo naprawialne. Przeglądarka rzuca ci błędem, łatwo dojść po nitce do kłębka, gdzie nastąpił błąd. Dla mnie to nie jest żaden specjalnie dobry argument za TypeScriptem. Prędzej za optional chaining, który to może złagodzić w niektórych sytuacjach: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining

Mnie jako backendowca z powołania wkurza to, że przeglądarka mi coś rzuca i muszę dochodzić - wolę dostać errora podczas kompilacji - co prawda w TS errory kiedyś były mega nieprzyjazne, szczególnie w react + generyki, ale jest coraz lepiej.

Pixello napisał(a):

Mnie jako backendowca z powołania wkurza to, że przeglądarka mi coś rzuca i muszę dochodzić - wolę dostać errora podczas kompilacji

To już było. W 1995 rozwiązali ten "problem internetów" dając ludzkości Javę.
Compile once. Run everywhere.

Pomysł genialny - jak komunizm - gorzej z realizacją. 25 lat a "pokrycie javą internetów" na poziomie Kim'owskiej Korei w proporcji do reszty świata.

Aisekai napisał(a):

Gdzieś słyszałem, że (chyba) 40% błędów w JSie jest związanych z zmiennymi (błędy typu: Cannot read property of undefined/null).

I jak niby TS cię od tego uchroni jak taki błąd dostajesz po kompilacji gdzie po TS nie ma śladu.

Oczywiście, że są przypadki gdy TS uchroni mnie przed błędami związanymi z nullem/undefined. Dodanie pola mandatory do interfejsu z automatu spowoduje, że w miejscu przypisania do zmiennej jakiejś wartości dostajesz wyjątek o niezgodności typów. Zmiana nazwy pola (bo np na backendzie zmieni się struktura DTO), jest banalnie prosta wykorzystując do tego np Intellij. W tych dwóch przypadkacj, rzuci Ci błąd kompilacji. Dodatkowo, wolałbym przychodząc do nowego projektu wiedzieć czego można się spodziewać "po zmiennej" patrząc na kod, niż bawić się debugerem.

Poza tym, w przeglądarkach masz "ślad" po TS w postaci source map (czy jakoś tak), gdzie korzystając ze stacktrace, bezpośrednio jesteś przenoszony do miejsca błędu w kodzie TS.

W przypadku gdy błąd związany z nullem/undefined nie wynika ze struktury danych, to fakt przed tym Cię to nie uchroni, ale też nie będzie przeszkadzać w debugowaniu. Imo - sytuacja w której jedynie można zyskać.

Panowie i panie, czy można się uczyć TS nie znając JS lub znając go pobieżnie? Jak będzie popularny ten nowy silnik - kompilator Deno, to zastąpi on silnik V-8 od Google na backendzie, czyli tam gdzie teraz jest Node? Więc będę mógł pisać w czystym TS po stronie serwera bez utraty wydajności, jak to obecnie jest przy konwersji TS do JS?

Nie da się, bo potem nie wiesz jak jest bindowane this, co to closure, jak działa itd.

sinatra napisał(a):

Panowie i panie, czy można się uczyć TS nie znając JS lub znając go pobieżnie?

TS to jest w zasadzie JS + seria adnotacji.

Więc i tak będzie ci potrzebna wiedza o JS, żeby pisać w TS.

Ew. tak jak niektórzy - możesz uczyć się mimowolnie JS przy okazji nauki TS - ale to ma taką wadę, że potem ludzie nie wiedzą, co im daje TS - i potem głoszą herezje typu, że "TS wrzuca OOP do JavaScriptu", co nie jest prawdą - obiektowość w JS od lat jest, tyle, że oparta na prototypach. Inna herezja to np. "TS dodaje klasy do JS", co też jest nieprawdą, bo w czystym JS też można już pisać klasy (chociaż TS dodaje np. interfejsy).

I ogólnie czasem widzę w internetach, jak ktoś się uczy od razu TS, to potem ma problemy z tym, że nie wie nawet co mu ten TS daje, nie widzi tej różnicy między TS, a JS. A potem traci czas na rozwiązywanie problemów z JSem, które ominął w nauce.

sinatra napisał(a):

Panowie i panie, czy można się uczyć TS nie znając JS lub znając go pobieżnie? Jak będzie popularny ten nowy silnik - kompilator Deno, to zastąpi on silnik V-8 od Google na backendzie, czyli tam gdzie teraz jest Node? Więc będę mógł pisać w czystym TS po stronie serwera bez utraty wydajności, jak to obecnie jest przy konwersji TS do JS?

Deno działa podobnie jak node. W dalszym ciągu do uruchomiania kodu jsowego służy V8.

Równie dobrze każdy (kto czuje się na siłach technicznie) może sobie użyć V8 i zrobić własnego Node'a.

Tylko i tak potem się okazuje, że rozbija się to o pakiety i ciągłe afery z nimi (przecież NPM miało ileś afer z tymi pakietami, że jakieś malware ktoś wrzucił, albo afera left pad itp.). Tutaj jest inne podejście:
Deno does not use npm It uses modules referenced as URLs or file paths
Ale czy lepsze? Poza tym inni muszą używać tego systemu pakietów. Bo inaczej to wymrze jak bower (to było takie coś jak npm, ale do frontendu - bo kiedyś npm się głównie do Node korzystało, dopiero potem powstała moda, żeby korzystać z npm do frontendu. pojawiły się narzędzia typu Browserify itp. bower poszedł w odstawkę. Chociaż ja nawet nie używałem bowera, tylko pamiętam, że był modny zanim npm stało się standardem)

LukeJL napisał(a):

Równie dobrze każdy (kto czuje się na siłach technicznie) może sobie użyć V8 i zrobić własnego Node'a.

Warto dodać, że twórca Deno nie tylko ma odpowiednie 'siły techniczne', ale ma również potężne doświadczenie jako twórca Node.js, w którym dostrzegł wady w założeniach i rozwiązaniach.

Ryzyko, że Deno się nie przyjmie jest spore, Node.js ma ugruntowaną pozycję, dużo napisanego kodu, bibliotek, dyskusji, tutoriali, jest wbudowane nawet w Phothoshopa czy After Effects (pamiętam swoje zabawy sprzed kilku lat z uruchamianiem wtyczki pozwalającej w Photoshopie na sterowanie głosem).