Angular2 vs React

[Ivan Nový]

React umožňuje renderování provádět na serveru, i na serveru může udržovat kopii DOMu.

To je pravda, ale řekl bych, že výhody reactu se projevý hlavně při malých změnách. Při změně stránky tabulky vyjde vygenerování nového těla minimálně nastejno jako určení rozdílu a překreslení jen změněných částí.

Ano, ale ruku v ruce s tím musí přijít i změna konceptu zobrazování a především vyhledávání informací, ne už listování v dlouhých stránkovaných seznamech, ale zobrazení přímo toho, co vás zajímá na základě kontextu a zadaných parametrů. A toje právě koncept, na jaký vede tlustý klient. Takže, když si otevřete například fakturu, ihned máte po ruce, odkaz na dodavatele, související objednávku, platební příkaz nějaké, účtování a ne odkaz do obecného seznamu, který manuálně procházíte.

V podstatě seznam potřebujete zobrazit jen tehdy, když hledáte něco a nevíte co. A takovému stavu v aplikaci je se potřeba vyhnout, vždy to co máte po ruce pomocí odkazů, má převyšovat vaše požadavky. No a nějaké hledání mimo běžnou práci už může být pomalejší a méně optimalizované.

Zcela přírozeně toto vzniklo v eshopech, kde se záhy vynořily filtry omezující výběr. Otevření detailu v seznamu nemusí znamenat jeho načtení, ale mohl být už načtem spolu se seznamem a ve vhodné chvíli se jen zobrazí. Supervizorem aplikace už není server, ale klient. Což odpovídá i přirozené logice.

[Reklama]

[reaktor]

Angular nepoznam, React pouzivam uz cca rok a je to pecka. Oproti angularu je vraj jednoduchsi na pochopenie (neviem porovnat) ale spolu s reactom sa musis naucit aj redux alebo flux pretoze bez toho si pri vacsich projektoch nevystacis.

React spaja viacero pristupov. Od komponetoveho pristupu ala delphi, cez funkcionalne programovanie, az po skladanie komponent na styl WPF. Daju sa v tom robit velmi pekne aplikacie ktore su po funkcnej stranke rovnako interaktívne ako desktopove. Taktiez ma velmi pozitivne prekvapil vykon reactu (hlavne ked porovnam nase aplikacie s rovnako komplexnými aplikáciami konkurencie).

[TT]

Pouzivame Angular 2 na obrovsky system. Je to parada, hlavne pro backend vyvojare, kteri maji zkusenosti s desktopovym vyvojem (wpf, winforms).

Ucici krivka je brutalne nizka, s malyma znalostma lze hned vytvorit neco pouzitelneho.
Infrastrukturu za tebe vyresi Angular CLI, kdy staci dva prikazy k rozjeti aplikace (automaticky to vsechno nakonfiguruje - webpack, typescript, sass, atd) a spusti. Konecne vyvojovy proces podobny Visual Studio a .NET platforme, kde si stahnes projekt, zmacknes F5 a vsechno funguje. Zadne zbytecne konfigurace a trapeni navic.

Kód: [Vybrat]

ng new my-app
ng serve

Dalsi obrovska vyhoda je defaultni podpora Typescriptu, staticky typovane jazyky jsou proste pro vetsi systemy prinosnejsi. Kdyz jsem se minule snazil nejak rozumne rozjet typescript + react, tak jsem u toho stravil prebytecne mnozstvi hodin.

Ta znovupouzitelnost komponent (zapouzdreni/shadowing) je bozi.

[kimec]

Angular2 ma jednoznacne buducnost. Trackujeme ho od bety cez RC verzie a momentalne sme par tyzdnov na stabilnom release. Medzi jednotlivymi RC sa rozbijalo kopec veci.
Samozrejme treba sa mentalne pirpravit na lahky uvod do Haskellu, teda pardon na FRP v podani RxJS. Veskera komunikacia s backendom sa implementuje pomocou monad, takze si o tom treba nieco pozriet. Kedze su monadicke API v imperativnych jazykoch infekcne, je nutne designovat kod tak, aby bol monad friendly, t.j. v pripade RxJS aby ste spristupnovali Observable a zaclenili si ho do API.
Synchronnym volniam a imperativnemu programovaniu mozete dat zbohom.

[Tomáš Roll]

Angular 2 má budoucnost do vydání Angular 3, kdy bude dvojka zatracena a opuštěna.

[Reklama]

[kimec]

Co bude niekedy na jar 2017. V pripade, ze kvoli 3 budu nejake API verzie 2 urcene na deprecation, tie budu vyhodene az v vo verzii 4, ktora by mala vyjst niekedy v druhej polovici 2017.

[Tomáš Roll]

Jako minule, kdy v Angluaru nezůstal kámen na kameni a aplikace v jedničce se mohly vyhodit?

[noef]

Pokud vim, tak Angular presel na semver a verze 3 bude znamenat jen dalsi update 2ky s nejakymi breaking changes, zadny prepis od piky jako 2. Takoveto updaty se dely s Angularem 1 bezne, akorat se kvuli tomu nezvedala hlavni verze.

Ke komponente a sablone - mozna to neni presne, ale v Angularu 2 je Component dekorator (anotace) tridy kontroleru (component =?= controller) a sablona je retezec nebo html soubor, coz snad odpovida view. Takze v ramci nejake knihovny to muze znamenat neco jineho.

S Angular 2 velmi pomalu zacinam, ale pokud vim, tak ma server-side rendering a jako dalsi optimalizaci i predkompilovani sablon (AOT).

Take by mne zajimalo, co je spatneho na pouzivani Angularu a Reduxu? Jednu mensi aplikaci jsem v ng 1 + Redux psal a prislo me to dobre - diky loggeru stavu se velmi pohodlne debugovalo ve srovnani s ng 1 bez Reduxu.

Ptam se, protoze dalsi projekt mame delat v Angularu 2 a ngrx/store (vychazi z Reduxu), tak by me zajimalo, co je na tom tak sileneho.

Jinak me prijde, ze Angular 2 vs React zustava klasicke "vse pripravene v jednom" vs. "poskladej si sam" a k Angularu 2 oproti 1 jeste pribyla dobra podpora TypeScriptu, ktera pro nekoho (treba me) je velke plus. Cetl jsem, ze pro zacatecnika muze byt Angular lepsi, protoze jasne udava mantinely a vse ma clovek pripravene (ale osobne srovnat s Reactem nemuzu, zkusenosti s nim nemam).

[čumil]

ani jedno

v práci ale potkáš angular nebo react (spíš ten angular)

takže se uč angular a nějakej další jen pro sebe (třeba vue, nebo ember)

[pr]

Angular2 +redux může a nemusí být ok,
záleží na implementaci - protože React dělá diff, Angular nic takového neumí

samozřejmě máme li čistě funkcionální konponenty a vhodnou implementaci flux architektury, tak je to OK (tuším, že pro angular 1 to splňuje https://github.com/christianalfoni/flux-angular)

hlavně jde ale o to, že angular je plný oop komplikací: controller, service, factory...

react + redux je spíše funkcionální a IMHO jednodušší...

[tichopopesine]

To, že šablony nejsou oddělené od kódu je výhoda.

Šablony samy o sobě jsou zlo. Reálně jsou to data pro univerzální builder, ale tváří se jako program, je to mix deklarativního a procedurálního přístupu, což je samo o sobě špatné.

Neoddělení šablon od kódu způsob nevede na iluzorní šablonovou modularitu, ale na modularitu kódu. Oddělení vede na dvoukoljenou modularitu, což znesnadňuje následnou údržbu, musíte dvakrát hledat místo, které je třeba upravit. Vznikají neúmyslné vazby mezi logicky nesouvisejícími moduly.

Z praktického hlediska údržby není dobré sdílet šablony napříč aplikací, mnohem lepší je aplikaci skládat z funkčních komponent (šablona + chování a tyto aspekty komponenty držet na jednom místě pohromadě).

Sdílení šablon komponentami je porušení principu zapouzdření. Vede na vedlejší zobrazovací efekty při úpravách.

Doporučuji si nastudovat, co znamená Model-View-Controller a proč ho každý druhý UI framework znovu a znovu vynalézá už čtyřicet let (což je v IT neuvěřitelně dlouhá doba).

Šablony (views) se mezi komponentami (controller) nesdílí. Smysl rozdělení je přesně opačný. Sdílí se jedna komponenta pro více šablon. Třeba jednu šablonu generující HTML a druhou JSON.

View != Šablona, View lze realizovat i bez šablony.
A znáte framework, který zakazuje použít šablonu v komponentě, jiným komponentám?

Nevim jestli jsem vas pochopil uplne spravne, rikate ze pouzit view v controlleru jinym controllererem je vporadku? Jsem trochu zmateny co tim vlastne myslite. Obecne nacpat kus view do controlleru je hloupost, stejne tak volat controller ve view, pouziti sablony jinym kontrolerem je normalni (notice, error a jine helpery napr.). Jinak v ruby on rails vam to 100% nedovoli, je workaround, ale to je proste mimo logiku a smysl celeho MCV (MVC je hloupost protoze neopovida poradi dle meho nazoru). To ze v Javascriptu, kde si odkudkoliv muzu prepsat cokoliv a kdyz mi to nepujde procpu to pres DOM je totiz celej kamen urazu. Takze to, jestli vy pak pisete "prasokod", protoze to je jednodussi nebo rychlejsi nebo z jakehokoliv jineho duvodu, jeste neznamena, ze neporusujete koncepci. Takze je to podobna situace asi jako s coding standards. Bohuzel v pripade porusovani koncepce vytvarite diry a pochybne/nezname situace/chovani aplikace. Nicmene jsem vas jenom mozna spatne pochopil tak si to neberte za zle. A ano view samotne neni definovano jako "HTML", ale muze to byt json, xml nebo i neco jineho klidne i CSS, obrazek.... proc ne. Me prijde, ze Angular se hodne inspiroval RoR, stejne tak Laravel. V Djangu je to trochu jine chapani/koncept/interpretace MCV oproti zminenym.