Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: newbie 15. 06. 2017, 01:02:08
-
Zdravim, zaujimalo by ma ako je to v sucasnosti s Angularom. Pokial sa clovek chce naucit vyvijat SPA, oplati sa snim vobec zacinat? Ako je to v praxy? 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?
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?
-
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.
-
Angular 2, 4, 5 se zas tak moc neliší
-
S Angularem je to nasledovne: Nejprve byla prvni verze oznacovana jako AngularJS, pak byl kompletne prepracovan a vznikl Angular2 resp. Angular4 (Angular4 je pokracovani Angular2, rekneme takovy angular 2.1) ktery uz ma zustat 'naporad' jen jako Angular.
Oznacovani je nasledujici: 'AngularJS' pro Angular1 a jednoduse 'Angular' pro 2,4,5,..
Ma cenu se ucit Angular2, oni (google) v podstate okopirovali dobre veci z Reactu a posunuli celou myslenku jeste o level dal. Angular2 se hodi tam, kde chces javascript pouzit na komplet frontend aplikaci (striktni oddeleni od backendu). Angular1 zase naopak muzes pouzit jen jako doplnek pro realizaci jedne komponenty na webu.
-
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).
-
Ucit se nekde neco z knizek "podle poptavky" je blbost. Jestli mas nejaky obecny zaklad tak je to prece uplne jedno - naskocis a za chvili jedes.
-
a ak nemam ? preto kladiem tu otazku .. chcem sa zacat ucit SPA, tak ci ma zmysel angular alebo skor nieco ine ... nevidim dovod preco sa neucit podla toho po com je poptavka, dany clovek zacina
-
Angular2+ nie je dobra volba pokial chces robit nieco sam (= jeden clovek) a ma to byt jednoduche.
Ak chces robit SPA a web componenty, pozri si radsej Polymer2 alebo Aurelia. Aurelia vznikla z frustracie z toho, akym smerom sa vybral Angular 2+. Treba si uvedomit, ze okrem nejakych zakladnych konceptov AngularJS (t.j. 1ka) s Angular 2+kou nema nic spolocne. Co sa dokumentacie tyka, vraj je na tom najlepsie React. Angular2+ je sice v Typescripte (co povazujem za najvacsie plus), ale typove definicie mas dnes uz pomaly pre vsetko. Po roku s Angular2+ si myslim, ze je to zbytocne prehypovany, silne opinionated, overengineered framework so zlou dokumentaciou, ktory ale funguje a v podstate robi to, co sa od neho ocakava.
Dufam, ze mi kolegovia sarkasticky pripomenu, aky som bol z Angularu2 pred rokom nadseny.
-
https://hackernoon.com/angular-vs-react-the-deal-breaker-7d76c04496bc
-
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).
dopyt teraz je, ale to neznamena, ze co je cool, je aj dobre a nastalo. ak bude nosenie ho*na na hlave cool, tiez tak zacneme robit? dnes je XYZ javascript frameworkov, ze orientovat sa v tom je zlozite a nie to este aj poriadne ovladat, resp. z takych su len nejaki rychlokvaseni "vyvojari". Ked vravis, ze je po tom dopyt, tak asi si si poriadne nepozrel ponuky, pretoze dopyt je po - Angular, React, Vue, Knockout, Ember, atd. Ktory z nich? Nehovoriac o tom, ze niektore spolocnosti maju v inzerate vymenovanych niekolko tychto frameworkov, cize zienka pre vsetko. O par rokov vyjde zas nieco nove, a "progresivne" spolocnosti to budu chciet, lebo to bude IN a COOL, az sa v tom clovek napokon strati. Predstav si udrziavat kod po 10 rokoch v angulary :)
Ja osobne tieto webove, hlavne front-endove veci nepreferujem a snazim sa im vyhybat pri hladani pracovnych ponuk. Tie nech si zoberu studenti...
-
Nevyplati, za rok to zase prepisou from scratch. Spis se nauc javascript jako takovy.
-
Ja myslim, ze se to urcite vyplati. Kdyz budes pouzivat mezery misto tabulatoru, tak te profit nemine ;D
-
inac, ked je po tom dopyt, tak vela ludi sa to bude ucit, co sposobi, ze firmy si budu moct vyberat a tym padom pojde dole aj cena prace.
Napriklad ja som pred rokom zacal robit s technologiou UWP od Microsoftu. Nova technologia, ktoru MS aktualne presadzuje a mozno to bude casom nahrada za WPF. Co myslis, kolko ludi ju ovlada? Dokonca ked som sa obzeral po novych pracovnych ponukach, tak jedna firma bola prekvapena, ze som robil s UWP technologiou. To znamena, ze si mozem aj zapytat viac :)
-
Trapit se s necim co me desne sere jen protoze "je dopyt"? Vem cokoliv co pouzijes na svuj vlastni miniprojektik a uvidis. Az trochu pochopis jak to funguje tak budes vedet co hledat nebo cemu se vyhnout.
-
Nejsem expert na weby, ale IMHO se vyplati naucit se trochu React uz jen kvuli jeho filozofii, a protoze byl "prvni". Mam za to, ze Angular 2 je trochu podobny, ale nejsem si jisty.
IMHO znalost te architektury (zpusobu navrhu aplikaci) je dulezitejsi nez konkretni framework.
-
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
-
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?
-
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
-
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.
-
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.
-
[...] 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.
-
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!?
-
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.
-
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?
-
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[].
-
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 ;)
-
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.
-
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.
-
Jn, a dopadne to jako typy pro pajpu v Ramde. Vse je zcela jasne na prvni pohled z typu ;D:
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. (https://github.com/Microsoft/TypeScript/issues/5929)), coz je pro funkcionalni programovani celkem dulezite (pokud tedy chcete nejake ty abstrakce a ne vse definovat nadesetkrat).
-
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
-
elektron framework a napr. M$ Visual Studio Code (a x dalsich) na Slovensko jeste nedorazily ?
-
hej, bezne vsetci vyvojari pouzivaju Visual Studio Code. Na normalne VS sa to nechyta. Kazdy, kto chce robi s Visual Studiom, tak si radsej stiahne Community ediciu, ktora je zadarmo a nebude si tahat VS Code ;).
A snad nechces povedat, ze VS Code je LOB aplikacia :D
-
co sa tyka vyuzitia MS technologie, tak WPF sa pouziva pri LOB aplikaciach. Apropo, naco potrebujem multiplatformovost, ked cely den budem sediet za pc s windowsom??? Stale ti nedochadza, ze naco mam brat technologie tretich stran, ked mozem pouzit nativnu technologiu?
-
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.
Hovadina. Jeden priklad za vsetky: reaktivne formulare. Ak je nieco TypeScript-first, tak v prvom rade to musi mat poriadne otypovane verejne API. Ak TypeScript riesi iba typy a nejaky projekt o sebe tvrdi, ze je TypeScript-first, ale vo svojom verejnom API pouziva any, tak to potom nie je TypeScript-first.
Citajte so mnou definiciu typu asynchronneho validatora AsyncValidatorFn z Angularu 2.0.1:
/**
* @stable
*/
export interface AsyncValidatorFn {
(c: AbstractControl): any;
}
Vidite tam to @stable? Ja ano. Vidite tam navratovy typ any? Ja ano. Je to verejne API? Je. Tak podme na API dokumentaciu AsyncValidatorFn pre verziu Angular 2 (https://v2.angular.io/docs/ts/latest/api/forms/index/AsyncValidatorFn-interface.html). Vidite tam vobec nejaky navratovy typ? Ja nie.
Aka to skoda, ze uz davno v tom case mohol byt navratovy typ iba Promise alebo Observable. A ako sa to dalo zistit? No jednoducho, pozreli ste si zdrojaky. Ako mne a mojmu IDEcku pomohol Anuglar2 TypeScript-first pristup v tomto pripade? Absolutne nijako.
Ale ano, mate pravdu, o zopaaaar verziiiii (a mesiacov) dalej sme dostali konecne typ (https://angular.io/api/forms/AsyncValidatorFn), ktory sice implementacia vyzadovala od zaciatku, ale TypeScript-first Angular2 to nepovazoval za podstatne...
A moralne ponaucenie? Ak je nieco v TypeScripte napisane, neznamena to, ze to ma poriadne zadefinovane typy vo svojom verejnom API. Aky je potm rozdiel medzi typovymi deklaraciami generovanymi z TypeScriptu voci retrofitovanym API pre kniznice, ktore v TypeScripte napisane neboli? Absolutne ziadny - odflaknut sa da oboje, breakovat sa bude oboje.
O tom, ze pri transpilacii sa typy zahodia a ze vyznam TypeScriptu je dokumentacny (a IDEcku napomahajuci) sa dufam bavit nemusime.
-
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!?
Hej, hej, preto ani v TypeScript-first Angular4 neexistuje metodika ake access modifiery pouzivat na komponentoch, ku ktorym pristupuju templaty. Ved na konci dna sa z toho aj tak kompiluje JavaScript, ktory ziadne access modifiery nema. Aha ono to potom nefunguje dobre s AOT kompilaciou, ked ludia pouzivaju restriktivne access modifiery (https://github.com/angular/angular/issues/11978). A to si dovolili na komponentoch, ktore sa kazdy snazi izolovat!? (ze by access modifiery boli integralnou sucastou TypeScript-u?).
Nuz, snad sa raz do tej dokumentacie dostane, ze komponenty sa sice pisu v TypeScripte, ale vlastne nemozete pouzivat plnohodnotny TypeScript (https://github.com/angular/angular/issues/15951), lebo veci prestanu fungovat...
Tomuto hovorim TypeScript-first Angular tm.
Nenapisal som, ze na typovom systeme TypeScriptu je nieco sofistikovane, napisal som, ze oproti ziadnemu typovemu systemu (JS, ES), je ten TypeScriptovy, dost sofistikovany... a tym som myslel, ze to mohlo dopadnut horsie.
-
Jn, a dopadne to jako typy pro pajpu v Ramde. Vse je zcela jasne na prvni pohled z typu ;D:
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. (https://github.com/Microsoft/TypeScript/issues/5929)), coz je pro funkcionalni programovani celkem dulezite (pokud tedy chcete nejake ty abstrakce a ne vse definovat nadesetkrat).
Ja to chapem tak, ze TypeScript sa snazi prepasovat aspon naznak klasickej enkapsulacie a "tradicneho" OOP z jazykov ako su C++, C# a Java do JavaScriptu. Robi tak preto, aby ludia s C++, C# a Java pozadim neboli uplne strateni v prototypovom nestabilnom svete s nazvom JavaScript. Tiez to robi preto, aby vam vedelo IDEcko pomahat. Na premostenie tychto dvoch svetov bol zvoleny typovy system, ktory dokaze "napodobnit tu Javu", ale zaroven si ako tak rozumie s JavaScriptom...
...a obe vase vytky boli v tom, ze TypeScript neumoznuje plnohodnotne funkcionalne programovanie?! Clovece, nezmylili ste si nahodou jazyk?
Ved Haskell sa da corsskompilovat aj do JavaScriptu, ci?
-
Ja nerikam, ze Angular ma dokonale typovani (par any nutne neznamena, ze je neco spatne, pokud ale any pouziva kazda druha nebo kazda definice [videl jsem takove "typove" soubory], tak je to nepouzitelne a TypeScript se ani nemusi pouzivat, protoze nepouzivame zadne typy).
Muj argument byl spise opacny - pokud to neni TypeScript-first, tak mam jistotu, ze typy tam jsou spise na okrasu, bude jich cast chybet uplne, nebudou sedet k aktualni verzi knihovny, pripadne k verzi knihovny, kterou chci pouzit (nebo uz to snad podporuje verzovani, ten typings nastroj?) atd.
Ja to chapem tak, ze TypeScript sa snazi prepasovat aspon naznak klasickej enkapsulacie a "tradicneho" OOP z jazykov ako su C++, C# a Java do JavaScriptu.
To uz dela JavaScript sam, ES2015 ma tridy, na to neni potreba TypeScript.
Robi tak preto, aby ludia s C++, C# a Java pozadim neboli uplne strateni v prototypovom nestabilnom svete s nazvom JavaScript.
Nevim, i dost "plnohodnotnych" (ve vyznamu znaji a umeji pouzivat prototypovou dedicnost) JavaScript vyvojaru nema prototypy rado. Ale jiste, je mozne, ze je nemaji rado proto, ze k JS prechazeli z klasickeho OOP.
Tiez to robi preto, aby vam vedelo IDEcko pomahat.
Ano, to je jeden z hlavnich duvodu, proc mam radsi TypeScript nez divoky JavaScript.
Na premostenie tychto dvoch svetov bol zvoleny typovy system, ktory dokaze "napodobnit tu Javu", ale zaroven si ako tak rozumie s JavaScriptom...
To je trosku problem, protoze rozumnet si s dynamickym JavaScriptem, kde kazda knihovna muze pouzivat specialni logiku - svuj typovy system, nevim jestli je dosazitelne. Osobne me spis pripada, ze Angular se snazi napodobit Javu (predepisuje celkem jasne strukturu, cileny na velke projekty), TypeScript samotny mi Javu nebo jeji pristup zase tolik nepripomina (ale urcite napomaha v enterprise svete, o tom zadna). Podobne mi Flow take nepripomina Javu, mit typy != je to Java.
...a obe vase vytky boli v tom, ze TypeScript neumoznuje plnohodnotne funkcionalne programovanie?! Clovece, nezmylili ste si nahodou jazyk?
Nespletl jste si vlakno? JavaScript JE funckionalni jazyk :D. A stejne tak knihovny v nem pouzivaji typovy system zalozeny na Haskellu - viz Ramda nebo Sanctuary. Sanctuary dokonce provadi i typovou kontrolu (volitelne v runtime).
TypeScript se snazi svym typovym systemem umoznit bezpecne pouzivani JavaScriptovych knihoven a zaroven Sanctuary je JS knihovna (ktera ale kvuli slabemu typovemu systemu TypeScriptu nemuze byt spravne natypovana) => TypeScript je problematicky pri pouzivani JS knihoven. Chcete to napsat jeste nejak jinak, nebo to staci takto?
Ved Haskell sa da corsskompilovat aj do JavaScriptu, ci?
Co vim, tak to nebylo moc slavne. Si to s sebou tahalo runtime Haskellu a moc podporovane to nebylo. To uz spise PureScript nebo mozna Elm (ale ten je pry hodne ochuzeny). Ale zadny z nich se jaksi bezne u nas nepouziva, takze pokud se tim chcete zivit v CR, tak TypeScript nebo mozna Scala jsou asi nejblize funkcionalnimu svetu.
-
Aky prinos maju pre dotycneho tie vase prispevky kde si rozoberate haskell? To urcite zaujima tazatela. Mozne len na rootu. :D
-
Ved Haskell sa da corsskompilovat aj do JavaScriptu, ci?
Da - akorat k tomu je dost velký runtime. Jinak to teda překvapivě funguje, ale mám pocit, že jediné rozumné řešení je používat "reflex"... což není špatné, akorát, že je to hodně work-in-progress... Asi bych to nedoporučil (a nějak mi nesednul ani purescript, bohužel moc už nevím, co je lepší varianta...).
-
Aky prinos maju pre dotycneho tie vase prispevky kde si rozoberate haskell? To urcite zaujima tazatela. Mozne len na rootu. :D
Rozebira se TypeScript, ktery s Angularem velmi uzce souvisi. Pokud si OP zvoli Angular a tim i TypeScript (ostatni verze [Dart a JS] na tom byly s dokumentaci a popularitou podstatne hure, nevim jak je to nyni), tak je dobre vedet, na co se v pripade TypeScriptu pripravit. Rozhodne to neni krasny svet statickeho typovani jako zname z Javy, C#, Scally nebo Haskellu.
Typovy system Haskellu (asi spise podmnozina) v JavaScriptove knihovne mel pouze ilustrovat znacna omezeni pri pouzivani JavaScriptovych knihoven v TypeScriptu. Zaver je, ze pokud se rozhodnete pouzivat TypeScript, tak cokoliv, co nebylo psane pro TypeScript, bude velmi obtizne pouzitelne bez obezlicek nebo vynechani typu a tim se ztraci vyhoda TypeScriptu.
Uz chapete, jak to souvisi s tematem?
-
Uz chapete, jak to souvisi s tematem?
Ono to s tématem souvisí i tak, že TypeScript byl na JS naroubovaný ex post a byl vymyšlený tak, aby pokryl (aspoň) většinu patternů, které se v praktickém JS skutečně používají. Čili když s ním chce někdo dělat, neměl by očekávat stejný komfort a čistotu jako u jazyků, kde byly typy od začátku a používané patterny se musely přizpůsobit jim, ne naopak. Proto srovnání s Haskellem nebo Elmem určitě má smysl, aby člověk věděl, co očekávat.
+ jak jsem psal vyse, TypeScript (co vim) neumi vyjadrit ani zakladni funktor
A to bych mu ani zas tak moc nevyčítal. Dovedu si představit (čistě laicky, nikdy jsem nic takového nepsal, ani tomu jinak zvlášť nerozumím), že higher-kinded types implementaci typového systému (a zvlášť inference) hodně zesložití a v kombinaci s jinými silnými featurami (třeba polymorfismus) se ztratí determinismus a celý to začne být chaos, který za ty higher-kinded types nestojí. Já osobně moc nemám rád, když mi občas překladač řekne, že neví, a musím ho ručně nakopnout. Většinou jsou ty hlášky totiž dost komplikované a člověk si musí zbytečně lámat hlavu nad tím, kam vlastně to nakopnutí dopsat... Nehledě na to, že to je velký prostor pro těžko debugovatelné chyby překladače.
-
Ono to s tématem souvisí i tak, že TypeScript byl na JS naroubovaný ex post a byl vymyšlený tak, aby pokryl (aspoň) většinu patternů, které se v praktickém JS skutečně používají. Čili když s ním chce někdo dělat, neměl by očekávat stejný komfort a čistotu jako u jazyků, kde byly typy od začátku a používané patterny se musely přizpůsobit jim, ne naopak. Proto srovnání s Haskellem nebo Elmem určitě má smysl, aby člověk věděl, co očekávat.
Ano, dekuji, tak jsem to presne myslel.
Myslim, ze na tech higher-kinded types delaji. Ale dovedu si predstavit, ze je to beh na dlouhou trat (uz ted podporuji zajimave veci jako union a intersection typy, n-tice pres pole, typ this u funkce, pretezovani, enumy [zajimave v kontrastu k JS]).
Inference celkove je bohuzel v TypeScriptu slaba :(. Jak jsem psal, treba generika u curried funkce (ihned volane) neodvodi a musi se otrocky vypisovat vsechny typove parametry. Videl jsem navrhy, jak to resit, pres nejaky "auto" typ a prekladaci podsunout jen ty typove parametry, ktere odvodit nevzladne. Neni to idealni, ale porad lepsi nez nynejsi stav. Mozna i defaultni typove parametry by tomu mohly pomoci, nevim.
TypeScriptu se musi nechat, ze jeho typovy system se rozsiruje s kazdou verzi a vyvoj je IMO rychly (oproti nejake Scale je TypeScript blesk; pravda, ve Scale se prepisuje cely prekladac a prekopova i jazyk, mozna nejsem fer).
-
Nespletl jste si vlakno? JavaScript JE funckionalni jazyk :D.
Iste, iste a preto ma prvotriednu podporu vynimiek a try/catch konstrukt pre imperativne riesenie side effectov... Noze este prilozte ako vyzera JavaScriptovy try/catch v Haskelli - nech si rozsirim obzor. Navyse si zelam, aby control flow pokracoval hned na riadku po odchyteni vynimky v tele presne tej istej funkcie, v ktorej vynimka nastala bez toho, aby ju runtime vobec opustil. Ved JavaScript JE funkcionalny jazyk, to predsa musi ist aj v Haskelli.
To uz dela JavaScript sam, ES2015 ma tridy, na to neni potreba TypeScript.
A kde ma triedy ES5?
Viete, ze aj Džava ma pvotriedne funkcie a monady? Je to podla vas funkcionalny jazyk?
Sanctuary je JS knihovna (ktera ale kvuli slabemu typovemu systemu TypeScriptu nemuze byt spravne natypovana) => TypeScript je problematicky pri pouzivani JS knihoven. Chcete to napsat jeste nejak jinak, nebo to staci takto?
Nie, nie, uz som pochopil. Vam vadi, ze vasa oblubena kniznica, inspirovana typovym systemom Haskellu a naimplementovana v JavaScripte, nie je otypovatelna TypeScriptom, ktory je inspirovany typovym systemom nominalne typovanych imperativnych jazykov ako C++ a Java, a ktory aby rozumne spolupracoval s JavaScriptom pouziva strukturalne subtypovanie a type erasure pri kompilacii. Vystihol som to presne?
Viete, tak nejak mam pocit, ze mozno keby ste zobrali kniznicu napisanu v JavaScripte, ktora sa inspirovala typovym systemom Javy, nebudete mat vobec problem ju ex post otypovat cez TypeScript. Nemyslite si to tiez? Ci toto nebude to, co tu nazyvate TypeScript-first....
Myslim, ze vas matie to Type v nazve TypeScriptu. Ale viete, firmy si vyberaju rozne nazvy produktov. Mozno by vam ulahodil HaskellTypedTypeScript, ktory ale zatial neexistuje.
-
Viete, ze aj Džava ma pvotriedne funkcie a monady? Je to podla vas funkcionalny jazyk?
Promatkuprirodu jenom prosim nezacinejte flame ohledne definice pojmu "funkcionalni jazyk" ::)
-
Noef:
Nie, neviem ako to suvisi s tematom. Tazatel sa zaujima, ci sa oplati ucit Angular. Ano/nie a preco. A nie to, co tu rozoberate vy ;)
-
Viete, ze aj Džava ma pvotriedne funkcie a monady? Je to podla vas funkcionalny jazyk?
Promatkuprirodu jenom prosim nezacinejte flame ohledne definice pojmu "funkcionalni jazyk" ::)
No to ste mali reagovat skorej, Mirek. Ja studoval jazyky jenom ti prirodzene, mohu v tom mit preci neporadek...
Noef:
Nie, neviem ako to suvisi s tematom. Tazatel sa zaujima, ci sa oplati ucit Angular. Ano/nie a preco. A nie to, co tu rozoberate vy ;)
Nakolko sa Angularove aplikacie pisu v TypeScripte, ktory je typovany (ale nie tak, ako by si zelali funkcionalny programatori), tazatel musi mat z nastolenej diskusie zasadny osoh.
Taktiez treba podciarknut, ze tym, ze Angular je priamo zavisli na RxJS5, tazatel bude vystaveny paradigme funkcionalneho reaktivneho programovania a samotna vedomost tohto faktu mu moze pomoct pri rozhodovani, ci Angular pouzit alebo nie.
-
No nic, svoje jsem si rekl, troly krmit dal (moc) nebudu. Angular s TypeScriptem souvisi (v nicem jinem se snad ani aplikace pro Angular nedelaji), problemy s typovym systemem TypeScriptu jsou take k tematu. Omezeni typoveho systemu a typove inference TypeScriptu se netykaji jen funkcionalniho programovani, jak jsem jiz nekolikrat napsal. S tim, jestli se ucit Angular zcela jiste souvisi fakt, ze se OP bude muset naucit i TypeScript, ktery ale neni takovy vselek, jak by se mohlo na prvni pohled zdat. Take stoji za to zminit, ze RxJS snad je funkcionalni programovani a Observable z teto knihovny s pri pouzivani Angularu nevyhnete. Na problemy s inferenci bezne narazim i u Observable - napr. v nemalo pripadech TS neni schopny bez explictniho uvedeni typu u parametru funkce predane metode map (a jinym) typ odvodit a placne si tam any.
A kde ma triedy ES5?
Nevim, proc zminujete starou verzi EcmaScriptu. Primo v ES5 se bezne front-endy nevyviji (bavime se o vaznem vyvoji - tema je o Angularu, ne lepeni par radek v jQuery), stejne jako se primo neposila nezkompilovany TypeScript prohlizeci. Ostatne neni duvod vyvijet v ES5, kdyz mate dobre transpilery (jinak by ani ten TypeScript nebyl pouzivany korporaty, kdyby nebyla dobra podpora).
type erasure pri kompilacii. Vystihol som to presne?
Ne, "type-erasure" (to se snad v kontextu TypeScriptu ani nepouziva) s tim nejak nesouvisi. Sanctuary pouziva runtime kontrolu typu jako svoje reseni typovani, protoze JS zadne rozumne nema. Kdyby TypeScript mel silny typovy system ala Scala (bezi take nad JVM jako Java, takze ocividne to jde, kdyz se chce), Haskell nebo Idris tak by stacilo napsat typove soubory pro knihovnu, vypnout runtime checky a vse by bylo dokonale - vse by se zkontrolovalo pri prekladu. Bohuzel to zatim v TS neni.
-
Z mojeho pohledu se to nevyplatí. Jednak jsou tady i lepší frameworky(čistě subjektivní názor) a hlavně to pak nemusíš smolit v nějakém okrajovém jazyce, který jinak víceméně nikdo nepoužívá(přenostnost kódů, hledání vývojářů, řešení problémů s transpilerem místo psaní skutečného kódu, ...).
-
Jednak jsou tady i lepší frameworky(čistě subjektivní názor).
Asi by teda stalo za to tazateli poradit, jake frameworky povazujes za lepsi, ne?
-
Mirek:
Nieco take, co ma uz nejaku historiu, a nevymrie tak rychlo. O 10 rokov po Angulary ani pes nestekne ;). Radsej C++, Javu, C#, Python.
-
Mirek:
Nieco take, co ma uz nejaku historiu, a nevymrie tak rychlo. O 10 rokov po Angulary ani pes nestekne ;). Radsej C++, Javu, C#, Python.
To su zas komentare na posratie ... vysvetli mi ako spravis v c++ alebo jave SPA ??
-
Aby som roztal kruh, uznavam, ze bola chyba, ze som napisal, ze TypeScript ma definicie pomaly pre vsetko.
Radsej som mal napisat: pre vsetko co ma zmysel. Ludia, ktori pisu typove definicie pre Sanctuary a Ramdu si evidente necitali, ze TypeScript nie je jazyk pre nich a nikdy nebude a to, ze vobec splodili nejake definicie je vacsia chyba ako keby ziadne neboli. Potom by tu ludia nenariekali, ze TypeScript nema taky silny typovy system, akeho su tieto kniznice hodne.
Nie, nie, uz som pochopil. Vam vadi, ze vasa oblubena kniznica, inspirovana typovym systemom Haskellu a naimplementovana v JavaScripte, nie je otypovatelna TypeScriptom, ktory je inspirovany typovym systemom nominalne typovanych imperativnych jazykov ako C++ a Java, a ktory aby rozumne spolupracoval s JavaScriptom pouziva strukturalne subtypovanie a type erasure pri kompilacii. Vystihol som to presne?
Ne, "type-erasure" (to se snad v kontextu TypeScriptu ani nepouziva) s tim nejak nesouvisi. Sanctuary pouziva runtime kontrolu typu jako svoje reseni typovani, protoze JS zadne rozumne nema. Kdyby TypeScript mel silny typovy system ala Scala (bezi take nad JVM jako Java, takze ocividne to jde, kdyz se chce), Haskell nebo Idris tak by stacilo napsat typove soubory pro knihovnu, vypnout runtime checky a vse by bylo dokonale - vse by se zkontrolovalo pri prekladu. Bohuzel to zatim v TS neni.
Cakat mozte donekonecna, lebo nic take v TypeScripte nikdy nebude, kedze je to explicitne zadeklarovane ako non-goal. Cas pre vas pohladat iny jazyk alebo vyvinut vlastny.
Taktiez, to ci TypeScript dokaze poskytnut kvalitne definicie nie je podmienene tym, ci je kod pisany v TypeScripte alebo v JavaScripte, ale tym, ci kod/kniznica operuje s typovym systemom podobnym ako ma C# alebo Java. Ak ano, nevidim dovod, preco by sa nedali urobit korektne ex post definicie v TypeScripte.
Naopak, ak je nieco v TypeScripte napisane, neznamena to automaticky, ze to poskytuje dobre typove definicie alebo inak nenarusuje semantiku TypeScriptu, vid. Angular2+ a jeho handlovanie access modifierov na komponentoch pri pristupe z templatov.
Specialne pre vas som zrekonstruoval nasledovnu konverzaciu:
Ja to chapem tak, ze TypeScript sa snazi prepasovat aspon naznak klasickej enkapsulacie a "tradicneho" OOP z jazykov ako su C++, C# a Java do JavaScriptu.
To uz dela JavaScript sam, ES2015 ma tridy, na to neni potreba TypeScript.
A kde ma triedy ES5?
Nevim, proc zminujete starou verzi EcmaScriptu. Primo v ES5 se bezne front-endy nevyviji (bavime se o vaznem vyvoji - tema je o Angularu, ne lepeni par radek v jQuery), stejne jako se primo neposila nezkompilovany TypeScript prohlizeci. Ostatne neni duvod vyvijet v ES5, kdyz mate dobre transpilery (jinak by ani ten TypeScript nebyl pouzivany korporaty, kdyby nebyla dobra podpora).
Kto napisal, ze vyvijam v ES5. Bavime sa o TypeScripte. Neverili by ste, ale jeden z dovodov preco TypeScript vznikol je aj to, aby bolo mozne vytvarat triedy zo specifikacie ES2015 uz v ES5. Kde je prosim vas napisane, ze TypeScript musite pouzivat pre pisanie frontendov v browseroch. Viete, ze stale umoznuje kompilovat do ES3? To ma TypeScript dropnut podporu ES3, lebo vacsina browserov podporuje skoro celu ES2015 sepcifikaciu? Co ak mate biznis logiku na backende napisanu v TypeScripte?
"type-erasure" [...] se snad v kontextu TypeScriptu ani nepouziva
No, to je ta zakladna vec, ktoru TypeScript kompiler robi, dokonca sa tak aj vola a je to by design.
-
Mirek:
Nieco take, co ma uz nejaku historiu, a nevymrie tak rychlo. O 10 rokov po Angulary ani pes nestekne ;). Radsej C++, Javu, C#, Python.
To su zas komentare na posratie ... vysvetli mi ako spravis v c++ alebo jave SPA ??
To netvrdim, ze to v tom urobi. Ja tvrdim, ze angular bude o par rokov pase, a bude jeden mnohych js frameworkov.
-
Ja tvrdim, ze angular bude o par rokov pase, a bude jeden mnohych js frameworkov.
To ale bude platit prakticky o čemkoli, to bys nemohl dělat nic. Flash, WebForms, Silverlight, JBoss Seam,... Technologie přichází a odchází, s tím nic nenaděláš.
-
Z MS technologii tu je WPF uz asi od roku 2007, WinForms este dlhsie a stale sa v tom vyvija. Technologie starsie ako 10 rokov. Samotny .Net je tu uz dlho. Java je tiez uz dlho na trhu.
-
Z MS technologii tu je WPF uz asi od roku 2007, WinForms este dlhsie a stale sa v tom vyvija. Technologie starsie ako 10 rokov. Samotny .Net je tu uz dlho. Java je tiez uz dlho na trhu.
Tazatel se ale ptá na webové technologie.
To je jako:
A: Mám si koupit Forda nebo Fiata?
B: Ford ani Fiat tady za deset let nebudou, kup si zlatou cihlu!