ALMAD: kdyz jsem tu videl prispevky o webpacku, tak jsem si dovolil zabrousit do JSPM. Ve skutecnosti je pacakge manager pro frontend, kterej se nejak snazi bejt co nejvic ES6 kompatibilni. Umi tahat veci z npm i rovnou z githubu a nasledne minifikovat, delat codemapy a podobne. Tady ma typek clanecek, jak to rozchodil s jasmine a istanbul: https://medium.com/...lium/es6-code-coverage-with-babel-jspm-karma-jasmine-and-istanbul-2c1918c5bb23

KALICOR: tl;dr je https://github.com/felixge/node-memory-leak-tutorial, taky https://hacks.mozilla.org/2012/11/tracking-down-memory-leaks-in-node-js-a-node-js-holiday-season/ bylo pekny.

Ad jspm...jaká je výhoda proti npm?

cau, pisu prvni apku v node.js s vyuzitim socket.io a poprve jsem v js narazil na problem s uvolnovanim pameti. tak jsem podle navodu nekde na strankach IBM obalil nektere casti (function(){ //kod })(); a pomohlo to, jen se mi to teda moc nelibi - ze jsem to tam nasekal a teda znalosti mi to o teto problematice moc nepridalo ;) narovinu - je to takova docana lamerina :D nevite o nejakem clanku/videu na toto tema? diky

Nekdo, kdo pouziva JSPM?

CYNIK: muze mi tohle nekdo vysvetlit ? Jeste vcera jsem si spokojene zil s verzi 0.12.x :) Ten vyvoj jde tak rychle, ze to nejak vubec nestiham :/. Samzorejme nastuduju, co jsem propasnul.

Má už někdo zkušenost s tim, jak připravenej je dependency chain na upgrade z 0.12?

StrongLoop | What the IBM Acquisition of StrongLoop Means for the Node.js Community
https://strongloop.com/strongblog/node-js-community-ibm-acquisition/

MARYO: muze dokonce vytvorit link s data uri, ve kterym budou ty komprimovany soubory, cimz se vyhne implementaci na serveru. Ale browser-side komprese nebude zrovna efektivni zalezitost :)

Ale může třeba poslat request na server, ten mu vrátí třeba zip a nabídne k uložení, resp. otevře se dialog kam to uložit.

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.