Vyplatí se učit Angular?

[Daniel Kozák]

Prijde mi jako kravina se na neco takovyho ptat. Jak se to chces ucit? Pokud mas realny projekt tak pouzij neco co je ti blizke a hotovo.

Nemam realny projekt, myslim to vseobecne ze je po Angular programatoroch celkom dopyt (zda sa mi ze o trocha vacsi ako po React), preto sa pytam ci ti angularisti len udrzuju uz hotove projekty, alebo sa v nom aj zakladaju nove(konkretne v novsich verziach angularu).

Tak napriklad u nas v praci v tom delame novy projekt.  Teda presneji receno delame novy frontend pro jiz existujici projekt. A stavime na novem angularu

[Reklama]

[jpu]

mna vzdy fascinuje, ako sa vsetko ma byt pristupne odvsadial, multiplatformove. Vacsina ludi a vela firiem vyuziva windows. Clovek v praci sedi za pc na ktorom ma windows. Naco mam robit nejaku webovu appku? Mam technologie ako WPF, WinForms, UWP, Qt, Java frameworky. Odinakial nebudem na to pristupovat, len v praci z pc. Mobil? To nie je zariadenie na pracu. Kopa webu sa rozsype na mobile alebo sa to seka. Preco teda nepouzit nativnu technologiu pre konkretnu platformu?

[to_je_jedno]

Na konzumaci obsahu je tablet vice nez dobry. To same mobil na urcite prehledy dat. U nas mame tipuju tak 50/40/10 win/mac/lin. Telefony tak zhruba 50/50

[newbie]

Ked vravis, ze je po tom dopyt, tak asi si si poriadne nepozrel ponuky, pretoze dopyt je po - Angular, React, Vue, Knockout, Ember, atd.

To si nemyslim, pozrel som vsetky vyvojarske pozicie ci uz java, alebo .net, a robil si na papier ciarky angular vs react vs ine ... vacsina z nich ma poziadavok na angular alebo react, alebo len angular (pomer 5:1 cca), obcas sa objavil nejaky iny fw.

[noef]

Nedavno vysiel Angular 4 nad ktorym rozmyslam ci sa oplati zacat ucit, pretoze na september uz sa chysta Angular 5. Kym clovek poriadne ovladne jednu technologiu hned je tu nova ... ale to uz je na inu debatu. Co teda poviete na tu 4rku?

Pouzivaji semver - jak pisi ostatni: Angular 2 a Angular 50 budou na stejne brdo, o zadny kompletni prepis nepujde.

Viem ze je v nom napisanych mnoho aplikacii, takze z hladiska ich udrzby sa to zrejme oplati, ale co nove projekty? Zakladaju sa v nom aj nove projekty?

Ted nevim, o jakem "Angularu" pisete. Protoze co jsem tak sledoval, tak v Angularu 2 zase tolik aplikaci neni. Naopak je dost mlady a tedy snad ani nemuze byt pouzity na stare projekty, kdyz v te dobe neexistoval. Pokud mate na mysli AngularJS (1kova rada), tak tam opravdu je hodne projektu, ale nove v tom IMO moc uz nevznikaji. Budto se pouzije Angular (2+) nebo jiny FW. AngularJS (1) rozhodne NEdoporucuji se ucit. Pokud neco, tak budto Angular (tzn. 2+), nebo si zkusit na vlastni kuzi vice frameworku/knihoven a vybrat si, ktery vam sedi nejlepe.

Poznamka k tomu, ze neco "ma typove soubory" - je propastny rozdil mezi tim, kdyz knihovna/framework byl vyvijeny v a pro TypeScript vs. kdyz se jen dolepi typove soubory. Zrovna ted v praci resim, ze sice knihovny maji nejake typove soubory, ale protoze typovy system TypeScriptu neni tak sofistikovany jako typovy system ze ktereho ty knihovny vychazeji (Haskell), tak se to tam hemzi chybejicimi definicemi, definicemi, ktere neodpovidaji realnemu typu (at jednim nebo druhym smerem, tzn. jsou prilis obecne nebo prilis omezene) a take se casto rozchazi typove soubory s kodem knihovny. (O problemech s typovou inferenci radeji pomlcim, nechutne mi to pripomina Javu.) Pokud pouzivate TypeScript, tak urcite prednostne berte takove knihovny/frameworky, ktere byly pro TypeScript tvorene.

[Reklama]

[kimec]

[...] Zrovna ted v praci resim, ze sice knihovny maji nejake typove soubory, ale protoze typovy system TypeScriptu neni tak sofistikovany jako typovy system ze ktereho ty knihovny vychazeji (Haskell)  [...]

Bavime sa po a) o SPA, po b) o javacriptovych frontendovych frameworkoch... ako sme sa dostali k Haskellu, preboha? Mohli ste rovno napisat, ze pri volani Haskellu z C++ typove deklaracie nie vzdy sedia a ze mnohe typy vasej kniznice sa v C++ nedaju ani vyjadrit. Ci to nebude tym, ze kazdy iny jazyk ma problem s Haskellom? Dovolim si tvrdit, Typescriptovy typovy system je dost sofistikovany voci ziadnemu a odost lepsi ako typovy system nominalne typovanych jazykov.

[Mirek Prýmek]

Bavime sa po a) o SPA, po b) o javacriptovych frontendovych frameworkoch... ako sme sa dostali k Haskellu, preboha? Mohli ste rovno napisat, ze pri volani Haskellu z C++ typove deklaracie nie vzdy sedia a ze mnohe typy vasej kniznice sa v C++ nedaju ani vyjadrit. Ci to nebude tym, ze kazdy iny jazyk ma problem s Haskellom? Dovolim si tvrdit, Typescriptovy typovy system je dost sofistikovany voci ziadnemu a odost lepsi ako typovy system nominalne typovanych jazykov.

Řeknu ti to jednodušeji: máš existující JS knihovnu, která z nějaké fce vrací pole [1,'ahoj'].

Plain JS je tak volný, že se rozumným typovým systémem dá dost těžko postihnout všechny možné finty. Čili je lepší mít zbrusu novou knihovnu, která je celou dobu psaná tak, aby do TypeScriptu sedla, než zcela volně napsanou Plain JS knihovnu, která sem tam do TypeScriptu nesedne.

P.S. Co je na typovém systému TypeScriptu sofistikovaného!?

[hurvajs]

mna vzdy fascinuje, ako sa vsetko ma byt pristupne odvsadial, multiplatformove. Vacsina ludi a vela firiem vyuziva windows. Clovek v praci sedi za pc na ktorom ma windows. Naco mam robit nejaku webovu appku? Mam technologie ako WPF, WinForms, UWP, Qt, Java frameworky. Odinakial nebudem na to pristupovat, len v praci z pc. Mobil? To nie je zariadenie na pracu. Kopa webu sa rozsype na mobile alebo sa to seka. Preco teda nepouzit nativnu technologiu pre konkretnu platformu?

jo, to možná takhle funguje na slovensku, protože tam nemáte internet. Všude jinde (v progresivních zemích) se právě snaží používat weboví technologie. BTW, Java = moloch a hrozný přežitea, nebýt bankovní sféry, dávno by byla mrtvá, WebForm = obsolete, dobré možná před 10 lety, UWP - možná v podání .NET Core, Qt je strašný paskvil... Asi tak :-D

To, že autora webové aplikace nezajímá responsivita a funguje mu web jen v IE a na desktopu je špatně. Dobře napsaný web, bude fungovat jak na mobilu, tak na 4k monitoru.

[kimec]

Bavime sa po a) o SPA, po b) o javacriptovych frontendovych frameworkoch... ako sme sa dostali k Haskellu, preboha? Mohli ste rovno napisat, ze pri volani Haskellu z C++ typove deklaracie nie vzdy sedia a ze mnohe typy vasej kniznice sa v C++ nedaju ani vyjadrit. Ci to nebude tym, ze kazdy iny jazyk ma problem s Haskellom? Dovolim si tvrdit, Typescriptovy typovy system je dost sofistikovany voci ziadnemu a odost lepsi ako typovy system nominalne typovanych jazykov.

Řeknu ti to jednodušeji: máš existující JS knihovnu, která z nějaké fce vrací pole [1,'ahoj'].

Ehm, no, zrovna toto sa v Typescripte vyjadruje uplne primitivne: [number, string]

Ze by to bolo tym, ze Typescript kontroluje typy strukturalne po uroven jednotlivych elementov tuplov?

[Mirek Prýmek]

Ehm, no, zrovna toto sa v Typescripte vyjadruje uplne primitivne: [number, string]

Ze by to bolo tym, ze Typescript kontroluje typy strukturalne po uroven jednotlivych elementov tuplov?

Ah, sorry, špatný příklad, myslel jsem, že má jenom number[].

[Mirek Prýmek]

Tak první hodnota je number a pak následuje libovolné množství stringů. To už by snad (doufám) měl být správný příklad

[noef]

Ten originalni priklad neni tak spatny. Staci mit pretizenou variantu te metody/funkce a hned je veselo - TypeScript totiz magicky obcas odvodi [number, string] a jindy any[] a tak musite hezky rucne mu to nutit (pretypovavat) na miste pouziti.

Ale obecne je to velky problem, pouzivat JS knihovnu v TS. I kdyz je trivialni, tak casto typy nesedi (nejsou aktualni). Kdyz je netrivialni, tak vyjadrit napr. funktor je snad nemozne, takze se musi otrocky vypisovat vsechny typy, pro ktere to muze platit (z jednoho radku se to rozpadne na nekolik pretizeni fce a samozrejme to, ktere potrebujete, chybi). Jsou i problemy s mnohem jednodussimi vecmi - napr. s inferenci generik u castecne aplikovanych funkci. Musi se otrocky vypisovat vsechny typove parametry a kod znacne utrpi na elegantnosti a casto i citelnosti. Prestoze jsem v Haskellu narazil na problemy (records a stejne pojmenovana pole, nedotazene a spatne dokumentovane knihovny), tak jeho typovou inferenci mu muze zavidet kdejaky main-stream jazyk. Tam se typy pisou jen pro programatora, protoze prekladac si je spravne odvodi z pouziti.

A pro toho cloveka, co nevidi, jak to souvisi s tematem: dotaz byl na Angular, aktualni Angular je TypeScript-first a argument, ze "pro vsechny frameworky/knihovny stejne existuji typove soubory, takze neni treba resit, zda to podporuje primo TypeScript" je spatny. Sice je pravdivy, typove soubory existuji pro skoro vse, ale casto byvaji plne any (tzn. v podstate vypnuti typove kontroly), neuplne nebo i spatne. Takze pouzivat takovou knihovnu/framework je velmi nepohodlne a casto skoncim s tim, ze si budto upravim/vytvorim typove soubory sam, nebo si napisu spravne typovane wrappery.

[kimec]

Tak první hodnota je number a pak následuje libovolné množství stringů. To už by snad (doufám) měl být správný příklad

Tak první hodnota je number a pak následuje libovolné množství stringů. To už by snad (doufám) měl být správný příklad

predstavujem si, ze povedzme do 10  elemntoveho tuple sa to v pohode da vyjadrit cez union typy a vyssie potom cez user defined type guard mozete paranoidne testovat kazdy prvok pola dle libosti - nie ze by na tom zalezalo. Ked budem mat cas napisem vam ako, alebo to napisete vy.

[noef]

Jn, a dopadne to jako typy pro pajpu v Ramde. Vse je zcela jasne na prvni pohled z typu :

Kód: [Vybrat]

        pipe<V0, T1>(fn0: (x0: V0) => T1): (x0: V0) => T1;
        pipe<V0, V1, T1>(fn0: (x0: V0, x1: V1) => T1): (x0: V0, x1: V1) => T1;
        pipe<V0, V1, V2, T1>(fn0: (x0: V0, x1: V1, x2: V2) => T1): (x0: V0, x1: V1, x2: V2) => T1;

        pipe<V0, T1, T2>(fn0: (x0: V0) => T1, fn1: (x: T1) => T2): (x0: V0) => T2;
        pipe<V0, V1, T1, T2>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2): (x0: V0, x1: V1) => T2;
        pipe<V0, V1, V2, T1, T2>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2): (x0: V0, x1: V1, x2: V2) => T2;

        pipe<V0, T1, T2, T3>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3): (x: V0) => T3;
        pipe<V0, V1, T1, T2, T3>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3): (x0: V0, x1: V1) => T3;
        pipe<V0, V1, V2, T1, T2, T3>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3): (x0: V0, x1: V1, x2: V2) => T3;

        pipe<V0, T1, T2, T3, T4>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4): (x: V0) => T4;
        pipe<V0, V1, T1, T2, T3, T4>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4): (x0: V0, x1: V1) => T4;
        pipe<V0, V1, V2, T1, T2, T3, T4>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4): (x0: V0, x1: V1, x2: V2) => T4;

        pipe<V0, T1, T2, T3, T4, T5>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5): (x: V0) => T5;
        pipe<V0, V1, T1, T2, T3, T4, T5>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5): (x0: V0, x1: V1) => T5;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5): (x0: V0, x1: V1, x2: V2) => T5;

        pipe<V0, T1, T2, T3, T4, T5, T6>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6): (x: V0) => T6;
        pipe<V0, V1, T1, T2, T3, T4, T5, T6>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6): (x0: V0, x1: V1) => T6;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5, T6>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6): (x0: V0, x1: V1, x2: V2) => T6;

        pipe<V0, T1, T2, T3, T4, T5, T6, T7>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn: (x: T6) => T7): (x: V0) => T7;
        pipe<V0, V1, T1, T2, T3, T4, T5, T6, T7>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T6) => T7): (x0: V0, x1: V1) => T7;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5, T6, T7>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T6) => T7): (x0: V0, x1: V1, x2: V2) => T7;

        pipe<V0, T1, T2, T3, T4, T5, T6, T7, T8>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T6) => T7, fn: (x: T7) => T8): (x: V0) => T8;
        pipe<V0, V1, T1, T2, T3, T4, T5, T6, T7, T8>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T5) => T6, fn7: (x: T7) => T8): (x0: V0, x1: V1) => T8;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5, T6, T7, T8>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T5) => T6, fn7: (x: T7) => T8): (x0: V0, x1: V1, x2: V2) => T8;

A abych nezapomnel, tak od urcite hranice (tusim 5 nebo 6?) pretizeni to zacina solidne zpomalovat preklad cele aplikace.

+ jak jsem psal vyse, TypeScript (co vim) neumi vyjadrit ani zakladni funktor (genericky parametr nemuze vystupovat jako typ, ktery sam je parametrizovany; napr.), coz je pro funkcionalni programovani celkem dulezite (pokud tedy chcete nejake ty abstrakce a ne vse definovat nadesetkrat).

[jpu]

mna vzdy fascinuje, ako sa vsetko ma byt pristupne odvsadial, multiplatformove. Vacsina ludi a vela firiem vyuziva windows. Clovek v praci sedi za pc na ktorom ma windows. Naco mam robit nejaku webovu appku? Mam technologie ako WPF, WinForms, UWP, Qt, Java frameworky. Odinakial nebudem na to pristupovat, len v praci z pc. Mobil? To nie je zariadenie na pracu. Kopa webu sa rozsype na mobile alebo sa to seka. Preco teda nepouzit nativnu technologiu pre konkretnu platformu?

jo, to možná takhle funguje na slovensku, protože tam nemáte internet. Všude jinde (v progresivních zemích) se právě snaží používat weboví technologie. BTW, Java = moloch a hrozný přežitea, nebýt bankovní sféry, dávno by byla mrtvá, WebForm = obsolete, dobré možná před 10 lety, UWP - možná v podání .NET Core, Qt je strašný paskvil... Asi tak :-D

To, že autora webové aplikace nezajímá responsivita a funguje mu web jen v IE a na desktopu je špatně. Dobře napsaný web, bude fungovat jak na mobilu, tak na 4k monitoru.

Vravim, naco sa budem srat s nejakymi webovymi technologiami, rozbiehat to na nejakom servery, ked mozem pouzit priamo nativnu technologiu? Si nepochopil. Neviem si predstavit take LOB aplikacie pisane webovou technologiou. Zatial som sa s takymi nestretol. Nevraviac o tom , ze nativnou tenchnologiou ziskam lepsiu odozvu a aj rychlost