Komentáře k článku

Proč se vyhnout Angularu

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ě.“

Zpět na článek

89 komentářů k článku Proč se vyhnout Angularu:

  1. Ondra Kučera

    Two way databinding
    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.

    1. steida

      Re: Two way databinding
      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.

  2. 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.

    (

    1. steida

      Re:
      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.

  3. 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í.

    1. steida

      Re:
      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.

      1. anon

        Re:
        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 ;-)

        1. Robert

          Re:
          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.

        2. daniel

          Re:
          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ý.

          1. anon

            Re:
            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 ;-)

              1. fis

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

                1. Mark1516

                  Re:
                  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 .-)

        3. jita

          Re:
          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….

          1. Mark1516

            Re:
            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“ :-)

            1. Mark1516

              Re:
              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.“

  4. MilanLempera

    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ě.

    1. steida

      Re:
      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.

    2. steida

      Re:
      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.

      1. MilanLempera

        Re:
        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é.

        1. steida

          Re:
          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.

        2. steida

          Re:
          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

        3. steida

          Re:
          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.

  5. Robert

    Dan je nejlepší
    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.

  6. 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 ?
    1. steida

      Re:

      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/
      1. Radek Miček

        Re:

        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.

  7. semorad

    God bless angular ;-)
    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í.

  8. 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.

      1. steida

        Re: Direktivy
        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í.

        1. Jan Kašpar

          Re: Direktivy
          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.

          1. steida

            Re: Direktivy
            Š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.

  9. 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)

    1. steida

      Re:
      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.

      1. Radim

        Re:
        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).

        1. alesroubicek

          Re:
          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.

  10. jiri.vrany

    Jsou to jen nástrojeq
    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?

    1. steida

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

  11. 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.

    1. jiri.vrany

      Re: Flux
      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?

      1. steida

        Re: Flux
        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.

        1. jiri.vrany

          Re: Flux
          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í.

      1. steida

        Re: Polymer
        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.

    1. steida

      Re: Polymer
      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ší.

      1. Yosef

        Re: Polymer
        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… ;-)

        1. steida

          Re: Polymer
          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.

    1. steida

      Re: Meteor
      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.

  12. czberg

    kral je mrtev, at zije kral
    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.

  13. 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.

    1. vskiper

      Re: Skvělé demo
      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.

      1. steida

        Re: Skvělé demo
        Komponenty. To je hlavní síla Reactu. Zkuste si napsat komponentu, porovnejte s direktivou, a uvidíte.

  14. semorad

    Proč je Angularjs skvělý
    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.

    1. steida

      Re: Proč je Angularjs skvělý
      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.

      1. semorad

        Re: Proč je Angularjs skvělý
        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 ;-)

  15. 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 :-)

  16. Richard Casar

    Angularu vdacime za vela
    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.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=14190