Ahoj, amaterskej dotaz: jde nejak udelat to, ze user na strance klikne na 1 cudlik a stranka posle requesty na nekolik souboru, ktery stahne, zalozi na disku adresar, a vsechny je do nej nasoupe?

Trošku si hraju s Djangem a Reactem a zkoušim nějaké, aby mi Django rovnou renderovalo React, koho by to zajímalo, tak: https://github.com/vojtatranta/Django-react/tree/master

Aha, stary este vubec neznam asi ;)

Ale kdyz na landing page najdes So you decided to give a chance to this web stack, but where is documentation? Code is documentation itself as it illustrates various patterns -- pak je to IMHO to co pise, tzn. ukazka toho, jake principy se daji pouzit. V tom je taky IMHO to este-todomvc super.

Potom je to ale na "podivej se na to jak se tyhle veci pouzivaj dohromady v este", ale v momente kdy cloveka odkazes na este.dom.isRoutingEvent, tak jsi imho mimo, protoze pak proste mas nezdokumentovanou metodu.

CYNIK: tak ono to nebola z mojej strany kritika niekoho konkretneho, ja si dokonca myslim,ze to esteTODO MVC je rozhodne dobra demonstracia urciteho pristupu a prichadza v spravnom case (ked sa vyvojari viacmenej zoznamuju s reactom, fluxom, ES6 a pod).

To co som pisal sa tykalo viacmenej generickeho OSS projektu, ze by mal byt zdokumentovany .)

3108: pardon, abych to dal do kontext Maryo mluvil o starém Este, což je fakt jenom grunt task na převod Coffee do Closure.

Nové Este opravdu je framework a měl by být dokumentován https://github.com/steida/este-todomvc.
Nicméně steida tam fakt nepoužil prakticky žádný svůj kód. Všechno je poskládané dohromady prakticky jen díky package.json a takle to teď asi prostě funguje.
Tudíž, pokud se s tím chceš seznámit, doporučuju se podívat na několik implementací Fluxu a na immutable.js a samozřejmě na Express s Reactem, pak to v poho pochopíš, jako jsem to pochopil já.

3108: ale tak se na to mrkněte, to vůbec takle není :-D, este není framework a ani to není knihovna.
Tam prakticky nenajdete steigerwaldův kód. Este, jak spráně psal Maryo je hlavně o kompileru Coffee do closure a jenom tam je kus kódu, kterej není dokumentovanej a hádal bych se o to, jeslti je potřeba ho dokumentovat, protože tam jde o tři příkazy grunt dist, grunt build a grunt. Což jsou gruntový příkazy a tudíž byste se měli kouknout na to, jak funguje grunt / gulp, protože se všechno konfiguruje přes grunt/gulpfile.

Něco jiného je nové Este, to by zasloužilo dokumentaci, to už je programovací rámec.
Steigerwalda nemám rád, ale v tomhle se ho musim zastat.

CYNIK: Jak rikal jeden moudry Djangista, "cim mensi je tvoje knihovna, tim vic dokumentace musi mit, protoze jinak je jednodussi si to napsat nez to studovat" ;)

Jinak je mi to celkem jedno -- steida by se na to moh vysrat, misto toho neco sdili, takze palec nahoru. Jenom je to podle me nevyuzita prilezitost.

CYNIK: to co pises trosku zavana lakatosom - banalni vec ktera..

co sa tyka absencie testov a dokumentacie pri OSS projekte, tak u mna nogo.

Ked cekujem github nejakeho projektu zaujimaju ma 3 veci:

1) dokumentacia/wiki/readme whatever kde pri 0 znalosti za 5 min nasajem gro a nejake how-to
2) testy - v urcitych pripadoch to moze byt brane ako doc ku kodu
3) stav issues (frequency, open vs closed) - rust je pekna ukazka, rovnako ako hocijaky major projekt kde to aktivne zije

fail pri jednom z vyssie uvedenych obodov mi raisne v invisible logu WARN, ze autor knihovny/frameworku/stacku to s potencialnymi uzivatelmi mozno nemysli velmi zavazne a vacsinou tam koncim.

To este-todomvc je pre mna ako cloveka ktory tie technologie denne nesleduje a nepouizva rozhodne zaujimavy a mozem sa tam cosi naucit, ale ked som si cekol gitter tak sa tam riesia dost koncepty, ktore by sa dali lahko zodpovedat nejakym API docom.

verim v tom, ze cas insvestovany do tvorby dokumentacie bude vzdy(!) mensi ako cas potrebny na zodpovedanie (hoci aj trivialnych) otazok ktore plynu s chybajucej dokumentacie :)

ALMAD: tak vono to je tak dělaný, není to framework, kterej by ses musel učit.

MARYO: Jo, to je fakt, to jsem přesřelil.
Jenom šlo o to, že Songary je hrozná aplikace.
Je to spíš o té architektuře, když tam není flux.

CYNIK: To, jak se Steida prezentuje je jedna věc, ostatně to byla "jen" integrace Closure Compileru, Closure Library, coffeescriptu (kterej se jinak s Closure Compilerem bez jeho hacků zas tak moc nekamarádí), nějakejch knihoven z Polymeru, jeho DI container a pár dalších věcí. Closure Compiler je super tool, Closure Library vynikající knihovna a tak dál... Zkrátka se snažil/snaží sledovat co je in a brát si z toho to z jeho pohledu nejlepší. Ne každýmu to musí sedět, ale za nepoužitelnou mrdku bych předchozí Este rozhodně nenazýval, to je docela silný slovo.

CYNIK: Nojo, on se asi fakt lepší. Už to má i README kde je něco jinýho, než že je to nejlepší! ;)

AREX: tady je Gulp v pozadí ve prospěch Webpacku.
Gulp je lepší než Grunt v konfigurace, u které člověk tak netrpí - podle mě, makám s obouma.

CYNIK: Jo, sice React zatím teprve poznávám, ale celé to dává docela smysl. Moc nechápu to hurá kolem gulpu. Sice streamy ok, ale zrovna v tomhle repu bych řek, že je to spíš nepřehledný. Na tohle si vystačím s gruntem.

UETOYO: JN, jeho předchozí srandy (předchozí Este, Songary) (až na coffee2closure) byly celkem nepoužitelný mrdky, ale tohle je fakt supr, nejdál, co jsem zatim viděl.

3108: supr nidky jsem zatim neslyšel o nějaké konkurenci :)
Mrknu na to.

CYNIK: skus sa mrknut na tuto prezentaciu http://staltz.com/dont-react

z moje strany to nie je hejt proti reactu, skor zaujimavy protinazor.

SH_PANDA: z mojho pohladu najviac asi v tom, v ktorej casti stacku a akym sposobom pracujes s prezentacnou vrstvou/logikou. Zaroven je to o odlisnom pristupe ku cross-cutting concerns. Tzn. react je dalsi evolucny stupen, alebo od plain-textovych templat ku virtual/shadow DOMu.

existuje aj ina implementacia ako react https://github.com/Raynos/mercury