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

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.