Přejít k navigační liště

Zdroják » JavaScript » Proč se vyhnout Angularu

Proč se vyhnout Angularu

Články JavaScript

Před nějakou dobou jsem dostal do schránky mail zhruba tohoto znění: „Dobrý den, používáme Angular, máme v něm rozepsanou aplikaci, ale máme problémy s výkonem, a programátoři si stěžují, že se jim struktura aplikace zkomplikovala. Implementace nových funkcí trvá déle, než bychom očekávali. Našel byste si chvilku? Třeba děláme něco špatně.“

Nálepky:

Autor článku pořádá školení, která si můžete objednat na Javascript-skoleni.cz.

Nebyl to první mail tohoto typu. Abyste rozuměli, posledních pět let se živím tím, že pomáhám firmám i jednotlivcům s jejich webovými projekty. Jak psát testy, jak ladit výkon, jak navrhnout architekturu a mnohé další. Jelikož se mi nechtělo zas a znova všechno sepisovat zvlášť, publikoval jsem stručný článek What’s wrong with Angular.js. Odezva byla nečekaná, k dnešnímu dni skoro 60 tisíc shlédnutí. Článek je citován, naposledy na legendárním webu Quirksmode „The Angular criticism that resonates most with me comes from the What’s wrong with Angular.js article by Daniel Steigerwald“ – The problem with Angular.

Dva dny jsem strávil s firmou nad jejím projektem. Ti z vás co znají Angular, asi tuší. Angular nijak nenaznačuje, jak v aplikaci implementovat business model. Ne, scope není business model. Programátoři, kterých na projektu pracovalo několik, zamořili celý zdrojový kód watch(), $digest() and $apply() metodami. Všechno poslouchalo všechno a nikdo si nebyl jist, odkud změny přicházejí. Celá aplikace se zle debugovala. Další problém byly direktivy, všechny je psala externí firma. Záměr byl asi takový: nakoupit hotové komponenty a nechat je vlastní programátory využívat.

Výsledkem bylo, že programátoři nemohli pružně reagovat na změny zadání a komponenty začali hackovat. Je třeba říct, že nešlo o nijak složitou aplikaci. Možná vás překvapí, že jsem nenavrhoval kompletní přepis. Aplikace byla již v produkci, na přepsání tak nebyl čas ani prostředky. A především, programátoři nejdříve museli pochopit v čem je problém, a že webové aplikace se dají psát jinak a lépe.

Tento článek však není case study, takže jen stručně. Jako první bylo třeba postupně aplikaci dodat business model, a to skrze Facebook Flux. Tento pattern není vázán na konkrétní implementaci, lze jej použít i s Angularem. Hezký článek jak na to je How can React and Flux help us create better Angular applications?

Co je tedy tak špatného na Angularu, že doporučuji se mu vyhnout?

Skoro všechno. Opravdu. Ačkoliv ne vše. Modularizace kódu a dependency injection, které Angular nabízí, jsou skvělé praktiky a držte se jich. Také důraz na testovatelnost kódu. Autor Angularu Miško Hevery psal kdysi skvělý blog, který stojí za to si přečíst i dnes. Vřele doporučuji. Pokud však chcete detailně popis toho, co vše je špatného na Angularu, přečtěte si můj anglický článek. Nemá smysl, abych jej zde překládal. Pokud však nesouhlasíte, máte prostor k diskuzi v komentářích tady zde na zdrojáku, rád vše dovysvětlím. Než však napíšete rozhorčený komentář, vemte prosím na vědomí, že Angular 2 je hodně jiný. Proč asi?

Angular 2

V roce 2014 uvolnil Facebook React, později Flux. A způsobil tak revoluci. Možná krčíte rameny a říkáte si, proč by mě mělo zajímat, jak programují programátoři nějaké sociální sítě? Třeba proto, že Facebook je nyní největší open source firmou. Týmy Angularu a Emberu, dvou asi největších frameworků pro vývoj webových SPA aplikací, se mohutně od Reactu a Fluxu inspirují. Ember zavádí virtual dom a server side rendering, Angular zavádí one way data flow. To vše je v Reactu a Fluxu už od začátku elegentně vyřešené. Správným a čistým návrhem.

Dan a Igor

„I don’t always agree with him, but I love this guy.“ https://plus.google.com/+IgorMinar/posts/a3ePEKy3mm6

Měl jsem s Igorem, hlavním vývojářem Angularu, dlouhou debatu. Snažil jsem se mu vysvětlit, že Angular tím, že vsadil na HTML, vsadil špatně. Igorův hlavní argument byl, že kodeři potřebují především HTML. Možná, ale problém leží v tom, že v Angularu se píší aplikace, ne weby. Angular 2 bude velmi jiný, a jeho popis je super obsáhlý „My phone battery ran out while I was reading it“ https://twitter.com/swannodette/status/552150238455431168.

Autor článku týden po jeho napsání, team Angularu opustil. Mnohé bylo opraveno, tak snad třeba, při vhodném použití, čistě pro obohacené statické weby, poslouží Angular 2 dobře. Problém však je ten, že Angular 2 zatím neexistuje a dlouho existovat nebude, a investovat do Angularu 1 už nemá cenu.

Co s tím?

Pokud máte existující aplikaci v Angularu 1, dále ji udržujte, a v mezičase se zkuste poučit z How can React and Flux help us create better Angular applications? Pokud budete tápat, napište mi. Pokud chystáte aplikaci novou, kterou nebudete chtít za pár let komplet přepisovat, přečtěte si můj článek.

Záměrem toho článku opravdu není přeložit to, co už jsem napsal a bylo okomentováno jinde, ale vyvolat diskuzi. Pište do komentářů, ptejte se, ale prosím až poté, co prostudujete odkazy. Velmi rád vše vysvětlím.

Komentáře

Subscribe
Upozornit na
guest
89 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ivan

Cely clanok by sa dal zhrnut do jednej spravicky…

Ondra Kučera

Rovnou přiznám, že Angular jako takový neznám (z praktického použití), ale překvapilo mě, že v jeho kritice zmiňuješ jako problematický two way databinding obecně, dokonce, že je to anti-pattern. Mně osobně se třeba two way databinding tak, jak je například v JSF, líbí dost (vůbec tu ale nechci rozbíhat debatu o tom, co všechno je dobře nebo špatně na JSF), a naopak je pro mě představa, že když uživatel něco změní ve view, musím se sám nějak postarat, abych každé takové políčko propagoval do správné části modelu, děsivá. Ale možná přehlížím nějakou třetí možnost, takže bych se chtěl zeptat, jak se tedy domníváš, že by se tohle mělo správně řešit.

steida

Binding z modelu do view je přímočarý, ale binding z view do modelu už ne. Chceš model updatovat na každou změnu, nebo na submit, nebo na blur, nebo jak? Zároveň chceš hodnoty z view určitě omezit, třeba i validovat, idealne lazy a eager jak je třeba. Dost možná máš jeden model závislej na druhým, třeba dropdown s výběrem země, a následně dropdown s výběrem města. React a Flux identifikovat a vyřešil dva problémy:

1) Sebelepší two way binding abstrakce je zase jenom abstrakce. React prosazuje explicit over smart kód. onChange na field inputu je to neexplicitnější, co máš a pro začátek stačí. Můžeš použít linkTo mixin, který už two way binding hodně připomíná, osobně jej nepoužívám. Můžeš si napsat nějaký super helper sám, ale vždy v rámci jedné komponenty, viz bod 2.

2) Druhý bod je mnohem podstatnější. Unidirectional data flow. Co to znamená? Místo toho, aby jedno view měnilo druhé view a to měnilo třetí view, a možná jeste nějakej jinej view model, všechno se má točit v kruhu :-) Změna UI vyvolá akci, akce je handlována v příslušných storech, story vyvolají update view. Prostě Flux. Jaká je toho výhoda? Obrovská. Pokud jdou všechny akce přes jeden dispatcher, můžeš logovat všechny akce, můžeš nechat čekat jednu akci na druhou, to vše explicitně přímo ve storech, které jsou za změny odpovědné. Představ si, že přijdeš k projektu, který neznáš. Jak zjistíš, co závisí na čem? Jedině tak, že projdeš řádek po řádku každé view, dost možná v celé aplikaci, a budeš hledat bindingy. Hodně štěstí, až to celé budeš držet v hlavě. Pokud se budeš držet unidirectional flow, tak se prostě koukneš do příslušných storů, a je to.

Ne náhodou spousta Angular vývojářů na tento model přechází, a i kvůli Reactu a Fluxu, Angular začal nabízel optional one way data flow.

Majo

Dat za priklad firmu, ktora hackuje cudzie direktivy len aby dosiahla workaround a zasype kod digest a apply volaniami… A na tomto postavit (aj ked s odkazmi inam) postulat, ze je angular zly, to mi pride smiesne.

Ako keby som uviedol, ze na androide je zle vsetko, lebo moja mama s nim nevie pracovat a uz jej kopu veci nejde, lebo ma stale verziu 2.3.6.

Ked sa s angularom robi podla best practices a na to, na co nema podporu sa robi inou vecou zase podla best practices (flux) tak je to jeden bajecny framework s ktorym sa da spravit vela. Dobry developer bude robit dobry kod, zly developer, zly kod. A namyslim si, ze angular navadza ten mainstream na zly kod o nic viac ako cokolvek ine, co mame k dispozicii.

(

steida

A četl jste můj článek? Rád bych slyšel reakci na jeden z deseti bodů. Angular má best practices neuvěřitelně moc, asi proč? Protože je v něm velmi snadné napsat špatný kód. A to, že je to obří HTML string tag soup parser, vývoji moc nepomůže, protože to se opravdu velmi zle debuguje.

anon

přečtěte si můj anglický článek. Nemá smysl, abych jej zde překládal.

Možná bys to, Dane, měl zvážit :-) Číst tu angličtinu fakt bolí.

Robert

Hloupost. Naprosto čitelná angličtina.

steida

Jsem rád, že jste se ozval. Vím, že moje angličtina by mohla být lepší. Naštěstí tady na zdrojáku vládne spousta komentujících angličtinou mnohem lepší, takže předem děkuji za všechny chyby, na které mne jistě upozorníte, protože jinak byste ten komentář nepsal.

anon

S radostí. Začneme hezky od začátku, tedy nadpisem a konkrétně slovosledem.

What I would recommend

je samozřejmě špatně. Správný slovosled je

What would I recommend

To je dost do očí bijící. Také byste si měl doplnit znalosti užití interpunkčních znamének. Ono totiž dělat čárky tam, kde je děláme v češtině, je špatně. Tím narážím na vaše větné konstrukce or,or,or,or.

Slovo nor se ve větě

you don’t need Angular nor jQuery.

používá v konjunkci se slovem neither. To je taky dost známá fráze. Tedy mezi angličtináři ;-) Názorně:

you don’t need neither Angular nor jQuery.

Zdá se, že nerozumíte významu slova Me. Totiž spojení

Me bad :-)

není v pořádku, tohle by mohl říct jen nějaký anglosaský školáček. Správně je pochopitelně

My bad :-)

Osvěžit si užití členů určitých by taky neuškodilo

Of course decision is up to you.

špatně, chybí člen určitý. Správně:

Of course the decision is up to you.

Mám pokračovat? Já jen, aby se to zdrojak.cz vešlo do databáze ;-)

Robert

Katastrofa. Všechny ty konstrukce zásadně mění smysl sdělení a bez vašich oprav nikdo jejich význam nepochopil. Danům článek masivně odkazují hlavně kvůli tomu, aby se každý návštěvník té angličtině vysmál.

anon

Dane, nemusíte postovat pod více účty ;-) Spíš zkuste přijmout kritiku a obohatit sám sebe.

steida

Na to teda fakt mám čas, abych postoval pod více učty. Omg.

vaclav.sir

Je to akronym, takže správně je to OMG. :-)))

daniel

No samozřejmě. Díky, něco jsem přehlédl, něco nevěděl, něco je sporné, tak jen houšť. Nechte tu pak číslo účtu, nezůstanu dlužný.

anon

Dneska to máte zadara, když mi slíbíte, že si trochu sklepnete ego a nebudete dělat ramena, když máte článek plný chyb ;-)

steida

Tak já neučím angličtinu, že.

fis

At ucis, co ucis, nemusis se chovat namistrovane, jako kdybys sezral vsechnu moudrost sveta. Jde to napsat i uplne normalne.

Mark1516

to snad … stejně jako jazykoví velmistři snad nemají automatický nárok, aby se před nimi každý klaněl a preventivně líbal nohy .-)

NoxArt

Když už tak sebevědomě kritizujete angličtinu… co to „don’t neither“? Dvojitý zápor v angličtině? (http://english.stackexchange.com/questions/60840/neither-and-either-usage-in-negative-sentence)

Lamicz

Pink Floyd – We don`t need no education

jita

Tak nimrat se v gramatice dokáže kde kdo. Proč my se musíme takhle patlat, když běžná anglicky mluvící osoba to hodnotí úplně jinak. To je tragédie. Zatímco anglicky mluvící presona, to prostě přejde, čech hodnotí, kde kdo jak špatně použil předložku, slovosled, tvar slovesa….

Mark1516

ono je to v pořádku být puntičkář ale přál bych si aby pod články, zvlášť těmi českými existovala dvojí diskuse, jedna příhodně nadepsaná „k věci“ a druhá „o prdu a interpunkci“ :-)

Mark1516

nebo alespoň pod formulářem pro vložení komentáře zřetelně uvést hlášku „UPOZORNENI PRO KOREKTORY Z RAD CTENARU: pouzijte prosim zvlastni formular pro hlaseni jazykovych chyb, tento formular vam umizni zadat sve cislo uctu a odmena vas nemine. Tato odmena bude pochopitelne strzena z premii naseho vlasniho korektora :-) Pokud zaplevelite vecnou diskusi jazykovymi korekturami, odmena vam nebude priznana zadna.“

Milan Lempera

Ahoj Dane,
jako někdo kdo píše v angularu a školí ho se nemůžu nevyjádřit.

Ano, obecný princip “použili jsme něco, čemu nerozumím a teď máme problém” platí i pro angular, ale důvod nepoužít ho to nebude.
Pro nás v angular.cz je to naopak důvod vysvětlovat lidem na školeních dopodrobna jak angular funguje a jaké to při chybném použití může mít následky. Mimo jiné v části o $digest rozebíráme přístup ostatních frameworků a zmiňujeme tvůj článek a Facebook Flux.

Je pravda, že některý kód napsaný v angularu je strašný, ale často je to proto, že se lidé angular nenaučí a přenáši si do něj špatné návyky odjinut (práce s DOM všude, špageti kód,…). Poslední dobou se situace (alespoň podle článků a publikovaného kódu) hodně zlepšuje, ale primárně to není o angularu, ale o čistém kódu, lepším návrhu a testování. Je dobře, pokud k tomu Flux, nebo jiná technologie dokáže inspirovat.

Na závěr ještě dotaz. Píšeš

Pokud chystáte aplikaci novou, kterou nebudete chtít za pár let
komplet přepisovat, přečtěte se si můj článek

Jaká je životnost frontendové technologie?

Mám aplikaci psanou na tvém este těsně předtím, než přišel React. Jsem s ní spokojený, funguje dobře, ale pokud bych chtěl velké úpravy, musím jí přepsat.
Dneska je in React a Flux, ale nepřijde zítra něco, co je předčí?

Neměly bychim si zvyknout, že (tak jako na serveru) budou starší aplikace používat starší frameworky a novější aplikace ty novější.
Fragmentace závislostí (kterou doporučuješ v odkazovaném článku) povede k tomu, že místo jednoho frameworku budu záviset na 10-ti komponentách, takže budu aplikaci přepisovat po menších částech, zato častěji.
Proč ne, je to taky možnost, ale (a tady se vracím na začátek) musíš dobře znát co používáš, protože pokud nevíš jak framework/komponenty fungují uvnitř, dřív nebo později přijdou problémy…

Takže je to zase (obecné) dilema:

  • použít framework, který řeší spoustu věcí, naučit se ho, ale mít na paměti, že nemohu překročit jeho hranice
  • nebo si svůj “framework” poskládat sám, sledovat dění v oboru, aktualizovat ho, vylepšovat, měnit technologie na kterých běží?

Oba přístupy jsou v pohodě, jen je potřeba vědět kdy který dává smysl (časově, ekonomicky, …).

Spíš jsem se od tebe těšil na článek, ve kterém představíš své songary, ukážeš v čem se liší od stylu stávajících aplikací, kde jsou jeho silné a slabé stránky. Tak snad někdy příště.

steida

Ad životnost technologie

Ač to tak nevypadá, technologii měním jednou za mnoho let. Posledních 5 let používám Closure Tools, a staré Este nebylo nic jiného, než přepsanej Backbone, který sám je docela maličký. Když se koukneš na todomvc, zjistíš, že většina frameworků, se liší jen v api, ale principy mají v zásadě stejné.

No a pak přišel React a Flux, a nebyl to nový hráč, ale celé nové hřiště :-) Nevidím důvod, proč by se následujících několik let mělo něco zásadního měnit. Angular se změnil totálně. React se mění kosmeticky, maličko, a nenech se zmást tím, že je venku teprve rok a něco, ve Facebooku ho používají už mnoho let.

To neznamená, že se vývoj zastavil. V současné době „frčí“ immutability, a projekt na kterém teď dělám postupně na immutable.js asi přejde. Možná, že nějakou důležitou core logiku naprogramuji v http://www.purescript.org, ale nebudu kvůli tomu přepisovat appku. Důležité je, že jsou to všechno drobné inkrementální změny. V jedné bance dokonce používají moje Este a jako view používají React. Časem mohou Este-backbone nahradit Fluxem, opět bez komplet přepisu.

steida

Ad obecné dilema.

V celém světě se ustupuje od monolitických frameworků ve prospěch „skládaček“. Důvod je ten, že můžeš časteji iterovat, máš větší kontrolu, vybereš si co chceš, a máš menší bus factor. Mimochodem, Angular 2 bude také celý komplet modulární.

S Angularem je jiný problém, který asi není zcela patrný, a proto jej zde zopakuji: Angular vytváří zbytečné abstraktní vrstvy které nepotřebuješ, a které tě ve výsledku pouze brzdí. A je to v zakódované v jeho genetickém kódu, což se bohužel zle projevilo i na Angularu 2, jehož specifikace je obří. At script, wtf? Proč má mít Angular vlastní jazyk? Ne, generování runtime checků a anotace všude v kódu, za to nestojí.

Angular vsadil na obohacené HTML, a byla a je to design chyba. Angular musí parsovat DOM, Angular musí parsovat html stringy, obojí se blbě debuguje a blbě debugovat bude, protože nedebuguješ kód, ale Angular. Angular ti neřekne řádek kódu a soubor, ve kterém je chyba, ne bez obřích workaroundů. Angular neumí server rendering, a já už bych si bez toho nedovedl představit psát appku. Ano, můžete namítnout, že pro nějakou administraci to není třeba. Ale já chci psát kompletní aplikace, a nepřemýšlet o tom, jaký server framework zvolím pro server side rendering. Angular se server side renderingem nepočítá, Ember už ano, vědí proč. React je tak dobře navržen, že umožňuje rendering i ve web workeru, což skýtá netušené možnosti, především pro mobilní zařízení a hry. S Angularem budeš navždy řešit chicken-egg problem, HMTL nebo kód? Co má přednost? Jistě vše lze nějak ošetřit, ale za jakou cenu? Není lepší, dělat to správně od začátku? S Reactem můžeš renderovat dokonce canvas, SVG, využít immutability a reference check pro neskutečně rychlej render. Angular tohle nikdy nedožene a umět nebude, protože to je prostě HTML first framework. Mohl bych pokračovat ještě dál, ale jen bych opakoval teze svého článku.

Milan Lempera

Díky za reakce.

Zvláštní, pocit že něco “vytváří zbytečné abstraktní vrstvy které nepotřebuješ” jsem měl když jsem viděl kód ukázky fluxu. Ale v podstatě to můžeš na psat o každém pokročilejším frameworku, ne?

Zajímavé je, že to co ty vnímáš jako chybu (obohacení HTML) je pro pro spoustu lídí důvod proč se jim Angular líbí. Troufnu si dokonce tvrdit, že je to jeden z důvodů vysoké popularity.
Na druhou stranu souhlasím s tím, že to má následky, které zmiňuješ. Ale nenarazil jsem sám na nějaký problém, kde bych se trápil debugováním Angularu. Většinou dostaneš velmi slušnou chybovou hlášku.

Ad server rendering – ano, neumí. Ve světě ve kterém žiji existuje mnoho aplikací, kterým to nevadí – možná žijeme každý ve světě jiných aplikací :-) Třeba věci, které dřív používali wicket, nebo jiný server-side framework, který se snaží tvrdit javistům, že nepotřebují vědět co je frontend se dnes dají s daleko menší režijí a větší uživatelskou přívětivostí psát v angularu a požadavky serverového rendrování tam neřešíme.

Ad dilema HTML vs kód – asi se na věci díváme jinak, ale já tohle nikdy neřešil.
Bussines logika, výpočty jsou v kódu, když chci něco skrýt, zobrazit, zopakovat, je to v šabloně. Nějak s tím nemám problém.

Chápu tvé argumenty, nemyslím si, že Angular je absolutně nejlepší framework od teď až na věčné časy, ale je to velmi slušné řešení, které dobře pokrývá požadavky mnoha aplikací. Kromě toho na školeních často vidím, že Angular posouvá lidi v tom jak programují (granularizace kódu díky DI, testování, protože je to snadné,…) a to je důvod proč se mi líbí.

Někdy mám pocit, že právě díky těmhle diskuzím se část vývojářů bojí rozhodnout pro Angular, tvorba vlastního frameworku s Reactem, Fluxem, Backbonem, gulpem,… jim přijde složitá (protože to opravdu vyžaduje dost znalostí) a tak zůstávají u jQuery, modelu v DOM, server-side frameworků a podobných řešení. A to je docela smutné.

steida

Nejdříve jsem Flux také moc nechápal, pak pochopil :-) Zkusím tě nasměrovat.

Proč dispatcher? Není to nějaký zjednodušený event systém nebo bus?
Je, a to z dobrého důvodu. Když může vše poslouchat vše, velmi rychle tím můžeš vytvořit nečitelný a obtížně udržovatelný kód. A poslouchá B to poslouchá C atd. Facebook si tím prošel, zkoušel, a nakonec došel k závěru, že takhle ne. Musím souhlasit.

„We found that two-way data bindings led to cascading updates, where changing one object led to another object changing, which could also trigger more updates. As applications grew, these cascading updates made it very difficult to predict what would change as the result of one user interaction. When updates can only change data within a single round, the system as a whole becomes more predictable.“ https://github.com/facebook/flux

Ve Fluxu výš přesně co se stane na akci send-foo. Jak? Dáš vyhledat všechny app.Actions.SEARCH_SONG v kódu.

Tohle je taky dobrej článek btw:
https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99

Proč akce?
Jakmile přejdeš na akce, které jsou mimochodem jen stringovou konstantou plus custom metoda pro vyvolání akce, získáváš lineární přehled o tom, co se v appce děje, neocenitelné. Zároveň může UI aplikace s těmito pending akcemi pracovat velmi elegantně, třeba takhle: https://github.com/steida/songary/blob/f4d60519d8e77b2e896c0771f9f865ca0279148b/app/client/js/users/react/login.coffee#L20 A pokud dojde k chybě, můžeš před jejím odesláním na server připojit posledních x akcí, které uživatel provedl i aktuálními hodnotamy.

steida

Ad dilema HTML vs kód – asi se na věci díváme jinak, ale já tohle nikdy neřešil.
Bussines logika, výpočty jsou v kódu, když chci něco skrýt, zobrazit, zopakovat, je to v šabloně. Nějak s tím nemám problém.

A nejsi sám. V zásadě všechny frameworky z todomvc šli podobným směrem, a Angular i Polymer to dotáhli do extrému. Proto je React tak revoluční. Převrátil best practices naruby :-) Doporučuji tyhle slides: http://www.slideshare.net/floydophone/react-preso-v2

steida

Někdy mám pocit, že právě díky těmhle diskuzím se část vývojářů bojí rozhodnout pro Angular, tvorba vlastního frameworku s Reactem, Fluxem, Backbonem, gulpem,… jim přijde složitá (protože to opravdu vyžaduje dost znalostí) a tak zůstávají u jQuery, modelu v DOM, server-side frameworků a podobných řešení. A to je docela smutné.

Ano, to je daň za vývoj. Nejprve si každý psal vše sám (V Seznamu to tak dělají dodnes, viz JAK), pak zkusil jQuery, pak Angular, no a teď je tu React a Flux.

Milan Lempera

Díky za odpovědi a odkazy, prostuduji to.

Robert

Problémem českého rybníčku je, že jsou tu milováni Grudlové, zatímco na Steigerwaldy se plive.

Pak ti nejlepší utečou do světa a zůstane tu jen odpad. Díky Dane, žes ještě na místní nezanevřel a stále se snažíš o osvětu.

vaclav.sir

Jakože David je odpad? Chápu to správně? :-)

Majo

Budem reagovat na povodny clanok:

  1. Deklarativne programovanie je podla mna jedna z velkych vyhod Angularu. Staci sa pozriet na Html a hned viem, ze co dana aplikacia robi. Custom html tagy vo forme directiv su potom nieco ako http://webcomponents.org/ uz dnes.
  2. Two-way data binding anti pattern?? WTF. Je to jedna z veci pre ktore som zacal pouzivat AngularJS. Dokaze nenormalne zredukovat mnozstvo potrebneho kodu. A vsetci vieme, ze menej kodu = menej bugov.
  3. Dirty checking, accessors… mobilne aplikacie… Este ze chalani z http://ionicframework.com/ maju na to iny nazor
  4. ng-module – nikto nikoho nenuti to pouzivat. Kludne moze byt aj cela aplikacia jeden modul (niekedy tisickrat lepsie ako niekolko nelogicky vytvorenych modulov).
  5. Angular is slow. Neviem kedy si skusal naposledy ale od verzie 1.3 sa vela veci zlepsilo vo vseobecnosti + nove veci ako one time binding. Ak chcem performance tak si to cele napisem v pure javascript, 99% aplikacii to podla mna nepotrebuje. Nie kazdy programuje gmail:)
  6. k tomuto sa neviem vyjadrit
  7. Angular is hard to learn . Skor by som povedal ze tam je par veci ktore trocha trvaju dokial ich clovek pochopi ale spokojnost so sebou je potom o to vacsia:) BTW jednoduchy hello world sa da napisat bez ciarky javascriptu – dokaze toto iny framework?:)
  8. Google does not use Angular in production for their flag apps like Gmail or Gplus. – to dava zmysel tieto aplikacie maju obrovsku navstevnost, tu sa uz casto pise vsetko od piky ale ako som uz povedal, tak 99% aplikacii nie je Gmail a tak s radostou siahnem po efektivnosti a produktovite Angularu. BTW: vypocujte si tento podcast http://devchat.tv/adventures-in-angular/016-aia-ng-1-3-and-2-0-with-brad-green-igor-minar-and-mi-ko-hevery hovori sa tam ze google pouziva AngularJS na 600 svojich aplikacii.
  9. Will be rewriten entirely soon. Preto sa planuje 1.4 a ked sa vyda 2.0 tak este dva roky support pre 1.x ?
steida
  1. Ano i ne. Nicméně, to se můžete podívat i na React, a vidíte tam komponenty a custom attributy. Akorád to není HTML, ale kód.
  2. Viz. předchozí komentář. Kdyby to bylo tak krásné, jak píšete, tak proč Angular přišel s one way data flow? Protože React (nebudu teď hledat link, kde to autoři potvrzují). Dále jsem odkazoval článek (a zdaleka není jediný), kde uživatel Angularu ukazuje, jak se inspirovat Reactem a Fluxem.
  3. Ať mají.
  4. Modularizace je dobrá věc, ng modul je akorád zastaralej.
    1. Zase, inspirují se Reactem a Fluxem, ale stále budou narážet na limity Angularu. http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/
Radek Miček

Kdyby to bylo tak krásné, jak píšete, tak proč Angular přišel s one way data flow?

Protože je to zrovna v kurzu. Je jen otázkou času, než se uchytí nějaký nový framework, který se vrátí k two-way data-bindingu.

semorad

Pro ty, kdo nemáte čas mám tento obrázek…
Pro ty, kdo nemáte čas mám tento obrázek…
Pro ty, které zajímá celý obrázek…
Jak vidíte, co jsem architektonicky potřeboval, to jsem si dodělal. Na obrázku je jen část toho všeho, co jsem si dodělal. Ale nebýt Angularu makal bych jako otrok, díky Angularu byly architektonické nadstavby pošušňáníčko, radost, konečně je tvorba sw lahoda… Příklad: V jiných frameworcích je zavolání modálního okna spousta kódu a vyšívání, díky Angularu je to jen jeden řádek kódu s pár parametry – adresou view, modelem a transactionpointem. Undo a podobné věci? To jsou architektonické detaily, o které se vůbec nemusím starat ;-) Jinými slovy, co jde, to univerzálně automatizuji do frameworku. Viz příklad modálního okna. Vlastní aplikace je jen opravdu byznys logika. Prostě višeň. A to nemluvím o procesním modelování. S Angularem hračka. Možná BPM půjde dodělat i v React/Flux. Nakouknul jsem – ale pro začátek dost složité a málo heroické. Nuda. S Angularem se rychle pracuje. ZaplaťPánBůh za Angular. Že tam není všechno? A někde snad je? Že není blbuvzdorný? A k čemu asi tak můžete blbce pustit? Jakoukoliv věc Vám někdo zešvejkuje ;-) Hlavní důvod, proč jsem šel do Angularu bylo, že mi ho nikdo nemůže vzít. Tak jako mi některé velké firmy vzaly (zatraceně) draho koupené technologie tím, že prostě přestaly fungovat. Ty technologie. Ne ty firmy. Koupíte úžasné špičkové technologie a nástroje. Nevydrží ani pět let. Za jak dlouho naučíte dobře programátory technologii? Za jak dlouho napíšete kvalitně aplikaci, větší projekt? Velká firma Vám zablokuje to, co jste si koupili a jste v háji. Velká firma mi řekla, že si to máme znova přeložit. A co s DLL od třetích stran? A co s DLL od Velké firmy? Všechno vyhodíte. Většina projektů se nedodělá, ty ostatní vyhodíte z právě uvedeného důvodu. Takže s Angularem jsem v pohodě – a to je pro mne to hlavní.

Miroslav Král

Tak já Vám nevím, ale kdyby se článek jmenoval, proč Telata nemají používat AngularJS, bylo by vše v pořádku. Kdyby článek obsahoval onen úsměvný začátek a pak to skončilo, tak bych to vzal jako moc povedené. Věděl ten tým o něčem jako je například:

https://github.com/johnpapa/angularjs-styleguide

Reakce na Váš původní bulvární článek byla dobře shrnuta zde:

http://www.johnpapa.net/why-does-there-have-to-be-something-wrong-with-angularjs/

Prasit se dá v každé technologii, ale povím Vám, že tak nadšený z učení a programování jako s Angularem jsem už dlouho nebyl.

Kolemjdouci

Fakt je, ze direktivy jsou fakt prasarna

semorad

Škoda, že jste nenapsal proč. Takhle je to jenom spam, fire, bulvar, emoce, populistika…

Kolemjdouci

Zkousel jsi to nekdy testovat?

steida

Komentář jsem nepsal já, ale když už se ptáte, odpovdím. Z mého pohledu jsou direktivy zlo, protože abych mohl mít vlastní HTML, musím mít JS direktivu, a v ní HTML jako string. Prostě meta meta meta. Plus ta konfigurace je monstrózní.

Jan Kašpar

Vzdyt direktiva muze mit vlastni html sablonu a klidne i svuj controller. Je to proste znovu pouzitelna komponenta. Co je na tom tak spatne? Naopak se da pomoci direktiv aplikace dobre strukturovat. Zajimavy pohled na direktivy vs controllery – http://teropa.info/blog/2014/10/24/how-ive-improved-my-angular-apps-by-banning-ng-controller.html, directivy lze skladat stejnym zpusobem jako komponenty v pripade Reactu.

Angular poskytuje velmi dobre pouzitelnou View vrstvu a genialni DI framework. Mam pocit ze ale nevede programatora tolik k dalsimu strukturovani aplikace. Controller v pojeti angularu se scope by imho měl obsahovat jen prezentacni logiku (tady je pak i ten 2-way data binding velmi uzitecny). Business logika(Model) by ale mela byt oddelena z controlleru do dalsi vrstvy services. Tady Vam nikdo nebrani treba i pouzit ten Flux :), a rikat tomu stores.

steida

Špatné je na tom to, že to lze dělat lépe, v Reactu. Kdyby existoval jen Angular a nic jiného, pak ano, pak by Angular byl nejlepší. Jenže vývoj jde dál, a Angular zaspal.

1) HTML je dobré jen pro kodéra, který nechce přijít do styku s JavaScriptem. Jakmile vzdáte HTML tag string, a píšete komponenty rovnou v JavaScriptu, vše je jednoduší a rychlejší.

2) Geniální není framework, ale samotné DI. Mimochodem, v Angularu 2 bude DI komplet přepsané, a použitelné kdekoliv, i bez Angularu. Do té doby můžete DI psát ručně, pure DI se tomu říká. Až přijde nové Angulaří DI, stačí smazat kompozitní root.

3) A ano, Flux se s Angularem kombinuje, viz. odkazy v mém článku.

Radim

V Angularu jsem dělal dva roky poměrně velkou aplikaci. S částí kritiky určitě nelze než souhlasit. Nicméně je třeba si uvědomit, že v době nástupu Angularu v něm často začínaly aplikace serverside vývojáři a jim jeho model opravdu přišel přívětivý proti tehdejším alternativám (Backbone, Ember, Knockout). Pokud by takový nebyl, vznikla by spousta SPA té doby v čistém jquery. Prostě to byl krok kupředu jak u vývojářů, tak u technologie jako takové.

Pak se objevil React a virtuální DOM. Osobně to beru jako další generaci js frameworků a tak mi ta módní vlna kritiky Angularu přijde poměrně zbytečná (nebo je takový problém na nových projektech React obhájit?) – srovnává nesrovnatelné. Přestože se mi myšlenka virtálního DOMu moc líbí, myslím, že výsledkem hypování Reactu bude spousta špatného softwaru. Celá řada technologií od PHP, přes Servlety až k JSP prokázaly, že dovolit vývojářům míchat kód se šablonou končí špatně. Udržoval jsem takového softwaru spoustu a upřímně lituju ty, co dostanou důsledky React hypu na starosti.

Osobně věřím v kombinaci handlebars (nebo jiné logic-less šablony) a Virtual-domu (resp. diffu)

steida

Ad „výsledkem hypování Reactu bude spousta špatného softwaru. Celá řada technologií od PHP, přes Servlety až k JSP prokázaly, že dovolit vývojářům míchat kód se šablonou končí špatně.“

Rozdíl mezi PHP, servlety, JSP a Reactem je tento: Serverové technologie vezmou data, nalijou je do šablony, a výsledný HTML string odešlou na server, konec. JS aplikace mají řádově složitější logiku, a hlavně, žijí v čase a drží stav. Proto se tvoří komponenty, a ne šablony. Oddělení HTML a JS není separation of concerns, ale separation of technologies. React šablona ve skutečnosti není HTML s JS, ale čisté JS. Stavový automat, který pro každý stav view modelu popisuje odpovídající stav v HTML. JSX je pouze tenký transpiler pro kodery, aby jim to vypadalo jako HTML, ve skutečnosti jsou tagy normální metody a attributy object literal. Pokud používáte CoffeeScript, JSX vůbec nepotřebujete. Příklad: https://gist.github.com/steida/b975439378980911ee4d

Používal jsem oddělené šablony, nejrůznější meta jazyky, a nic z toho se s Reactem nedá srovnávat. Vzhledem k tomu, že jde o kód a používám Closure Compiler, jsou mé view „šablony“ staticky kompilované s dead code removal. Tohle Angulaří HTML tag soup nikdy umět nemůže a nebude.

Radim

Nerozumíme si. Ten rozdíl o kterém mluvíš nijak neřeší problém o kterém mluvím já – to co mají tyhle technologie společné – smíchání aplikační logiky a view. Pokud to jde (a to jde právě díky tomu, že reactí „šablona“ je opravdu jen javascript), vývojáři to udělají. Takový software se špatně udržuje, dekódovat, co ta komponenta renderuje znamená daleko větší zátěž, hlavně pro člověka, co přímo ten kus kódu nepsal. A to platí kdekoliv, ať už na serveru, nebo v browseru.

Chápu, že třeba ty to tak nevidíš (s tím nemám problém). Je mi jen líto těch, co se na hype vlně toho, že už máme ten „silver bullet“ užijí spoustu srandy při údržbe takové aplikace (udržoval jsem takových mraky).

steida

Ale ono ono to je oddělené. Co se renderuje je v render metodě, vše ostatní mimo.

alesroubicek

Zato dekódování Angulařích šablon, kde se kód s markupem „vůbec nemíchá“, to je slast…

Pokud čtu správně, tak nikdo netvrdí, že React je „silver bullet“ nebo jediné správné řešení. Aktuálně je React velice slušná knihovna na tvorbu views. Za tu slušnost považuju rychlost renderování, a efektivní práci s DOM (úspora energie u mobilních zařízení), jasnou strukturu a snadnost pochopení, jak takový systém funguje. Pokud se vám nelíbí zbytečná ukecanost React komponent, můžete použít víc funkcionálně zaměřený Omniscient.

jiri.vrany

React i Angular jsou jen nástroje. Záleží kdo v tom píše a co v tom píše…

Ale React mi postavil řadu tradičních konceptů na hlavu a přinutil mě o aplikacích začít myset trochu jinak. Takže momentálně mě hodně baví. Doporučuju dát tomu 5 minut a až pak začít soudit.

Jako View je to perfektní, trochu ale tápu nad zbytkem aplikace. Flux mi připadá (a i ho tak na webu propagují) jako architektura, bez konkrétní implementace. Použít třeba JQuery kvůli AJAX requestům (jako to mají v oficiálním tutoriálu k Reactu) mi přijde jako zhovadilost.

Momentálně zkomám Fluxxor. Nějaké další tipy?

steida

jQuery na AJAX requesty je ok. A to říkám jako někdo, kdo jQuery v životě použil tak 5x.

steida

Flux má konkrétní implementaci od Facebooku zde: https://github.com/facebook/flux/blob/master/src/Dispatcher.js
A zde máš dvě mini aplikace, ze kterých bys měl pochopit co a jak: https://github.com/facebook/flux/tree/master/examples

Varuji přes Fluxxorem a ostatními, bacha na vendor lock a Flux napodobeniny. I když už jsem viděl hodně zajímavé implementace, třeba tuhle: https://github.com/goatslacker/alt, začátečníkovi doporučuji pouze originální implementaci.

jiri.vrany

Jo jo, ty examples už jsem prošel. TodoMVC je pěkné, ale neřeší to co bych chtěl řešit já, protože tam není žádná komunikace na server API. Budu muset detailněji rozpitvat ten chat.

Ale tomu vendor locku nerozumím – jak fluxxor tak ten alt jsou opensource s kódem na githubu. Myslíš to tak, že to původního autora může časem přestat bavit udržovat a mě zůstane v aplikaci knihovna plná chyb?

steida

Komunikace se serverem je nastřelená právě v tom chatu, také jsem to původně přehlédl.

Ano, přestane ho to bavit, nebo Flux třeba ne zcela pochopil, i to se může stát.

jiri.vrany

To je pravda. Na druhou stranu vzhledem k tomu, jak vypadá oficiální dokumentace k Fluxu se to nepochopení může přihodit kde komu, nejen autorům knihoven :-)

React je prostě hotové řešení. Kdyby vypadal jako Flux bylo by to asi tak nějak ve stylu „hele vymysleli jsme virtuální DOM a takhle by se to asi dalo napsat, dobrý ne?“. Je to zkrátka spíš koncept k zamyšlení.

Asi i proto je tolik různých Flux implementací. Některé budou dobré, jiné méně. Ale řeší to spousta chytrých lidí, pro které to není první program, tak si myslím že nějaké dobrá časem přijde. Naposled dneska proletěl twittrem martyjs.org, když Bill Fischer napsal, že je to celkem dobrá implementace.

A asi zatím nejlepší intro do Fluxu které jsem četl, je článek Flux for stupid people. Hlavně kapitola Unanswered Questions pobaví.

Yosef

A jaky nazor mate na Polymer? Kde hlavnim interfacem je HTML. A kompozice je na prvnim miste.

Google mu hodne veri, viz
https://github.com/Polymer
https://github.com/GoogleWebComponents
https://github.com/dart-lang/chromedeveditor

Zajimava videa z Chrome Dev Summitu…
http://youtu.be/6vcQlD-jadk?list=PLmccrGoe3AUABlLmrZn4ukY8kxLIPRcOb

http://webcomponents.org
Podporuje Chromium(Chrome, Opera) od verze 36
Firefox na tom maka

steida

Se Sebastianem (jeden z hlavních vývojářů ve Facebooku) jsme se shodli, že Polymer neřeší ani jeden z problémů co máme, a ani nepřináší (pro nás) nic zajímavého a podnětného.

steida

Web Components technologie je ok. Polymer má svůj smysl jako integrační point. Tedy, napíšu svou aplikaci nebo komponentu (s Reactem jak jinak), a Polymer custom element může být jedním ze způsobů distribuce, pokud si chce holčina na svůj blogísek přidat nějakej můj kód. Je jasné, že do ničeho jiného, než je HTML, šahat nebude.

Bohužel Google Polymer „prodává“ jako nějakou super architekturu pro psaní aplikací, což je samozřejmě zcela špatně. To Polymer opravdu není. A ano, bavil jsem se o tom s autory. Jsou to normální mladí kluci (a holky) žádné božstvo, patent na rozum nemají. Některé věci v Polymeru vypadají jako užitečný polyfil, ale to je tak všechno. Jejich imlementace pointer events je tragédie. Nejdříve napsali jednu knihovnu, pak jí odpískali s tím, že to byl omyl. Pak se rozhodli psát druhou knihovnu polymer-gestures, a je to opět tragédie… nikdo nereaguje na issues ani na PR, prostě ostuda.

Je třeba si uvědomit, že Google je obří firma, kde levá ruka neví co dělá pravá. Angular má vlastní píseček, Polymer má vlasntí píseček, Dart má vlastní píseček… a zbytek firmy prostě vyvíjí až na výjimka aplikace v Google Closure Tools, které nemají žádnou vyhajpovanou marketingovou podporu, ale přesto (a nebo právě proto) jsou nejlepší, a v Googlu nejpoužívanější.

Yosef

Ja jim verim, ze verze 1.0 bude funkcni a rychla. Nyni 0.8 je uz zajimava.

Libi se mi prehlednost diky kompozici, kdy element si drzi vlastni JS a CSS.

Libi se mi jak bali googli API do Polymer elementu. Firebase API.

Libi se mi jak vytvorili elementy pro Material Design.

Ja jim verim… ;-)

Yosef

PS: makam na projektu Start Polymer ;-)
https://github.com/StartPolymer

Yosef

Chapu, ze React ma sve misto, treba viz http://blog.atom.io/2014/07/02/moving-atom-to-react.html

Ale klasicka Single Page App bude jen tezit z Polymeru. Zde je videt, ze v jednoduchosti je sila.
https://www.polymer-project.org/articles/spa.html

steida

Však i Polymer má své místo. Obohacení webových stránek, rychle mashupy, jednoduchoučké appky. A pak se stane co? Tvoje jednoduchá appka se změní v obří string HTML tag soup konfigurační file/fail. Před programováním není úniku.

snakeyyy

A co Meteor jako budoucnost SP a izomorfních aplikací? Bude hrát roli nebo nebude?

steida

Toť otázka. Určitou roli asi hrát bude, a na určité projekty se také hodit bude. Jen bych se obával přilišného vendor locku. Meteor chce všechno po svém, proč ne. Ale já rád vidím pod povrch a mám možnost si vybrat. Pokud Vám Meteor vyhovuje, klidně do něj jděte.

steida

Užitečnej článek zodpovídající některé dotazy zde položené.

https://medium.com/@joaomilho/arguing-for-reactjs-7b80aafc6493

czberg

Proste angular lidi si musi utrit slzicky a smirit se s tim, ze dalsi vyvijeni v nem je pouze posmrtna krec. Jinak kdo hleda implementaci fluxu, tak doporucuji reflux.

petrjiricka

Když je tedy na Angularu všechno špatně, zajímalo by mě, co si myslíte o Aurelii: http://blog.durandal.io/2015/01/26/introducing-aurelia/ – od bývavého člena Anguar týmu. Dík.

steida

Ron makal na Angularu, team opustil přesně týden po svém obřím blogspotu o Angularu 2. Asi pochopil, že tudy cesta nevede, nebo se mu nechtělo čekat celý rok, než bude Angular 2 hotový, takže se vrátil zpět k Durandalu. Dle mého, nic zajímavého tam není, prostě variace na Angular.

steida

Teď se koukám úplně roztrhl pytel s články o úspěšné migraci z Angularu na React. Každý den mám v Twitteru aspoň jeden nový – https://www.airpair.com/angularjs/posts/angular-vs-react-the-tie-breaker

steida

A další: https://javascriptkicks.com/stories/3718 why-junior-developers-are-learning-bad-habits-from-angular Konce to nemá…

steida

No a tady to Tom Occhino skvěle vysvětluje https://www.youtube.com/watch?v=KVZ-P-ZI6W4&feature=youtu.be
Oni měli něco jako Angular už před lety, ale sralo je to.

semorad

Learn once, write anywhere. Tahle hláška se mi líbila.

steida

Myslím, že po shlédnutí toho sedmiminutového videa každý pochopí, že oddělovat HTML a JS pro view logiku je anti-pattern.
https://egghead.io/lessons/react-react-in-7-minutes

vskiper

Takze tady John Papa (excelentni developer takze v nem chyba neni) behem 8mi minut napsal ng-repeat? A kdyz bude chtit zobrazit jinou collection tak si to cele zase zopakuje? No tak to je vazne super :)) Tak to uz jsem uplne presvedcenej, ze mam u Angularu zustat !!!
Angular podle me vnasi do Javascriptu logiku a rad deskotopovych programovacich jazyku. Business logika se pocita nekde na pozadi a jakmile je hotovo DOM vysledek zobrazi. JS (vcetne jQuery) nedava zapomenout, ze jako jazyk vznikl za 8dnu. Programovani v podstate advanced funkci ala vyssi programovaci jazyky nad daty ulozenzmi v DOMu (aka v display memory)? No jasne ze to lide nenavideli. ReactJS (alespon z toho co ukazuje toto demo) se k teto nedobre metode vraci. Pripada mi jednoduzsi opravit pomale direktivy (coz se ostatne deje) nez se kvuli par nostalgikum, kteri ziji z nejakeho nejakeho jQuery smirbuchu z roku 2002 vracet v case.

steida

Komponenty. To je hlavní síla Reactu. Zkuste si napsat komponentu, porovnejte s direktivou, a uvidíte.

steida

Přesné: composition, unidirectional data flow, freedom from DSLs, explicit mutation and static mental model.

semorad

Toto je sice odpověď na článek, ale hlavní důvod je jiný. Na konferenci ng-europe bylo k vidění pár náhrobků. Vzhledem k tomu, kdo je prezentoval, zanechalo mi to klidným. Angularjs přece vznikl z nedočkavosti a nedohlednosti webcomponents ;-) – s tím, že se k nim připojí! Takže takové věci nebyly neočekávané.
Článek se tváří, že ví více. Nehledal jsem hodiny, hledal jsem celé dny. I autorova videa jsem shlédl. Nic jsem nenašel.

Angularjs vznikl za účelem psaní účinnějšího a přehlednějšího kódu. To se mi splnilo super.
To, co se v článku uvádí jako problematické, mi úžasně slouží:

HTML – direktivy. Naprosto skvělá komunikace se zadavateli, uživateli, grafiky…
V odezvě na článek najdete: react templates: http://wix.github.io/react-templates/
A tam se dočtete: Why not use JSX?
Some love JSX, some don’t. We don’t. More specifically, it seems to us that JSX is only a good fit for components with very little HTML inside. And this can be accomplished by creating DOM elements in code. Also, we like to separate code and HTML because it just feels right.

Two way databinding – používám ho tam, KDE je ho potřeba. Je to snadné, přímočaré, rychlé, přehledné… Rozhodně by mi chyběl.

Dirty checking – Nejenže využívám, přímo zneužívám. Umožňuje mi elegantně používat komponenty z jiných frameworků. S přehledem kombinuji JQuery UI, Bootstrap, Kendo UI, CodeMirror a další… Model a Controller je přece můj…
Pro mne je Angularjs dobrý sluha. Jestli je pro někoho zlý pán nemohu posoudit. Autor článku uvádí jakýsi pokleslý projekt. Za žádný pokleslý projekt nemůže (jakákoliv) technologie, ale lidé. V takových projektech se běžně neví, co se (vlastně) chce a technologie rovněž neznají. V obráceném případě totiž nemůžete projekt pokazit. Buď ho uděláte nebo do něj vůbec nepůjdete. Do projektu se chodí se znalostí, ne s vírou (v někoho, něco, cosi…). Svádět to pak na technologie je samozřejmě snadné a hlavně oblíbené a vděčné.

V běžných firemních projektech je největší slabinou komunikace mezi lidmi. Takže každý framework, který tuto komunikaci usnadní, každé DSL je vítáno. Úplně zásadní je popis byznys procesů. Proto první, co jsem si do Angularjs dodělal bylo procesní řízení a transactionpointy . To ale není chyba Angularjs, naopak, Angularjs mi poskytuje solidní základ, na kterém mohu postupovat dál. Angularjs mi dává svobodu. Takhle to chápu od začátku – že mi šetří práci.

Nadstaveb nad Angularjs mám celou řadu, ale žádná není proto, že by mi Angularjs něco dlužil nebo bych ho musel obcházet, hekovat. Všechno jsou to „high-level“ komponenty za účelem „easy-to-use“ a Angularjs je pro mne jen skvělý assembler a dsl maker.

steida

To je tak, když někdo honem honem komentuje, aniž by četl komentáře a odkazy.

To je pak marná práce tu něco psát. Třeba „Also, we like to separate code and HTML because it just feels right.“ Ano, tak jsme to dělali všichni sto let. V odkazech máte dobré důvody, proč je lepší přístup Reactu. Vy ale nechce polemizovat, chcete jen celému světu říct „já, já, já mám pravdu.“

Ano, Angular je lepší než nic. Ano, lepší než samotné jQuery. Přesto všechno, Angulaří přistup přináší celou řadu problému. Jde to dělat jednodušeji, rychleji, s menším vendor lockem, moderněji. A tak dále, jen bych se opakoval. Používejte si co chcete. Hezký den.

semorad

To je tak, když autor článku nečte příspěvky ke svému článku. Jinak by zjistil, že jsem tématu článku věnoval celé dny a také by se dozvěděl proč.

Co autoři Angularjs slíbili, to splnili. Tedy nejedná se o nějaký omyl.
Šlo o usnadnění návrhu webových aplikací tak, aby práce byla (proti jiným frameworkům) ještě snazší. A to se stalo. Bez javascriptu můžete pomocí direktiv realizovat rychle, snadno a přehledně části aplikace. Pro mne je Angularjs něco jako HTML++ . Autorovi HTML vadí, není to jeho šálek čaje. Uvedl to i v jednom videu, tuším z roku 2012, našel jsem ho na youtube. Chápu ho do té míry, že pokud rozšíření HTML začnou vypadat jako jakési XSLT, tak už se to začíná míjet účinkem. A ten hlavní účinek spatřuji v tom, že HTML je user friendly pro analytiky, „odborné“ uživatele, grafiky a vůbec lidi kolem zadání a užívání. A na to jsou direktivy super.

Dirty checking vznikl proto, aby model zůstal svobodný. Pokud si přečtete záměry autorů Angularjs, tak je k tomu vedlo to, že v praxi se dívá uživatel na obrazovku, která je omezená a vidí na ní omezenou (lehce spočetnou) množinu informací. A proto – světe div se – v běžném provozu je dirty checking dokonce rychlejší. Pokud chce pomocí základních principů angularu někdo zpracovávat video pixel po pixlu, tak na to najde asi lepší způsoby ;-) . Pro běžné byznys aplikace ale nevím o ničem lepším. U těch se zadání rodí těžko a postupně. A právě na tyhle „top management“ korouhvičky je angular vyložená spása.

Jako autora článku nebaví HTML++, tak mne zase nebaví rozřezávat html předlohy a cpát je do js. I jednou je to (pro mne) otrava, natož pak ty korouhvičky. S templates může dělat každý grafik. Já s nimi (takřka ;-) ) vůbec nepřijdu do styku. Na to mám parsery a compilery. Psal jsem si je v r. 2009 na serveru a vůbec se mi nechtělo to přepisovat na klienta. Ne proto, že by se to neosvědčilo – ale správný programátor má být líný – osvědčilo se to skvěle, když zadavatel zjistí, že si korouhvičkami přidělá práci jenom sobě, korouhviček ubude ;-) . No a v tom přišel Angularjs a já zjistil, že úplně na zavolanou. Nic jsem přepisovat nemusel. Angularjs je „wash&go“ super dílko.

Zkuste chvíli uvažovat: model je váš, controller je váš a view je html. Co tedy vlastně je ten Angularjs?! Zkuste nad tím chvilku zameditovat, stojí to za to.

Kromě virtual DOM nevidím na Reactjs nic převratného. Chytristika virtual DOM mi připomíná chytristiku dirty checking. Prostě se takové „brutal force“ ;-) věci kupodivu někdy hodí. Ano, klobouk dolů. Jak jsem již uvedl, běžné byznys aplikace tímhle netrpí, takže si nepomůžu. A když přece jenom nastane ta potřeba, mohu dát Reactjs komponentu do Angularu. Pořád nevidím nějaký důvod k tomu, abych se mu (apriori) vyhnul.

Co se Fluxu týče, tam není nového vůbec nic. Přečetl jse spoustu článků a videí. Je to normální MVC. Není to MVVM. To je celé. Actions jsou lepší než vůbec nic. Ale jako důvod k vyhnutí se Angularjs je to málo.

Když se podíváte na obrázek mého příspěvku (a všimněte si i datumu) (=před rokem), tak nejenže tam všechno najdete, ale najdete tam toho více. Proto stále nevidím na Angularjs problém.

Na obrázku vidíte hned tři modely. Hlavní doménový dataModel. DataModelCopy je jeho kopií, která je rozšířena o potřeby controlleru. ViewModel je zase poplatný view. Kdybych musel jít do Flux-Store, tak musím do Store nacpat (aspoň) své dva modely. To je krok zpátky. Komunikace je úplně stejná jako u Flux, ale říkám tomu MVC. Nic jiného to není. Prostě M nebo V nebo C může být sofistikovanější, ale princip zůstává. V mém obrázku je napsáno, že view můžu měnit. Ono view může být třeba právě i komponenta Reactjs.

To, co je pro mne ale zásadní je, že view může být jakákoliv komponenta – KENDO, JQUERY, BOOTSTRAP…
Protože model a controller je váš a view je html. Kupříkladu jsem hledat „html very friendly“ data table. Zkoušel jsem jich moc, ale jediná DataTables obstála. Proto chválím JQUERY. Takovéhle věci jsou ověřené/vyzkoušené časem. To je pro úspěšné dokončení byznys projektů zásadní. Komponenty ne v rámci jedné platformy, ale skutečně univerzální. Protože model a controller je váš a view je html.

A to nejlepší nakonec. Všimli jste si transactionpointu? O tom přece všechny firemní byznys aplikace jsou – o transakcích. Pro mne je Flux hodně málo, já chci (a mám) process engine. Angularjs mi v tom nebrání.

Když porovnáte Angularjs s desítkami jiných frameworků, tak toho mnohé umí (kvantitativně) více. Ale o tom to je. Angularjs dělá to, co jinde není a vybízí vás to kombinovat s tím, co jinde je. To je přece konečně komponentnost! Prostě děláte úplně normnálně v html, css a js. A když chcete, můžete si odskočit do Angularjs. Nebo se z něj zase vrátit. Nebo ho kombinovat s něčím jiným. Nebo začít psát direktivy, komponenty, nadstavby. Takhle to vypadá i všude kolem. Podívejte se, kolik udělátorů, variant a vylepšení vzniká kolem Reactjs a Flux. To je v pořádku, to není vada Reactjs nebo Flux.

Prostě lidé se to snaží zjednodušit. Zjednodušení je ale u mne plná komponentnost a procesní engine.
Zatím si programátoři snaží ulehčit práci sobě. Promise nevznikla z potřeby domluvit se se zadavatelem projektu, ale kvůli callback hell apod. Stejně tak ostatní věci kolem Reactjs A Flux.

Až budete chtít opravdu ulehčit práci všem, přejdete k procesním enginům, modelům a skutečně spolupracujícím komponentám. Konečně luxusní debug. Je to programování jako každé jiné, ale z hlediska úspěšnosti projektů zásadní. Mluví se o tom desítky let. Mluví. Proto God bless angular ;-)

steida

To psal Jiří Hrebenář? #psycho

bronek.krystalin

Myslím, že u většiny aplikací více než na zvoleném frameworku záleží na tom jak ho lidé kteří s ním pracují znají a vědí co si můžou dovlit a co ne. S článkem vesměs souhlasím, ale nemyslím si že React a Flux je univerzální lék na všechny bolístky :-)

Richard Casar

Vsetko ma svoje nevyhody. Viac zalezi aky framework posadite do akej architektury a ako vyvojarov s nim naucite pracovat nez malo vyznamne a niektore trochu absurdne argumenty ktore autor popisuje v oboch clankoch. Angular je bezpochyby vynikajuci framework a pre siroke spektrum aplikacii moze byt najlepsie volba, staci si pozriet google trends a napriklad si to dat do porovnania s inymi – aj Reactom a Fluxom. Angular ma samozrejme slabe stranky ale netreba ich pliest so slabymi strankami javascriptu. Cely clanok nabada na to ze jazyk alebo framework by mal naucit programatora robit dobry kod. Toto sa mozno da v nejakych novsich a pokrocilejsich jazykoch ako Scala, ale urcite nie JavaScripte bez toho aby prisiel o svoje dobre casti.

Fotr

Mne to spis pripada jako promo pro React a Flux ;-)

Michal Vávra

Nemyslím si, že je to takhle jednostranné, já na angularu shledávám poměrně dost výhody, až tak, že jsem se o tom rozepsal, viz. http://pixelfield.cz/proc-milovat-angularjs/

Josef Polymer Ninja

Kdo nema rad tluste frameworky, ktere se tezko ladi, tak at vyzkousi Polymer. Na tema Polymer budu mit prednasku, viz https://www.meetup.com/GDG-%C4%8CVUT-Prague/events/234920012/

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.