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

SH_PANDA: zkus a uvidíš :) React je hodně o tom, že má úplně jinej přístup než všechno ostatní, který, zdá se, funguje a asi taky fungovat bude. Viz. airbnb.com nebo facebook - výborný weby, co svištěj.

CYNIK: Ja tomu zase az tak moc nerozumiem, ale jak sa lisi Node + React od Node + Nejaky iny frontend framwork a Nejaky iny backend + React?

Takže zkušenosti s Node + React, máme, nemáme?

3108: Tak jasny ;)

Duvod proc jsme u CS je mj. ten, ze je to proste jenom "tesnopis" pro JS. To co generuje je citelny a nebojim se toho kdyztak vsechno proste zkompilovat do JS a pokracovat v EC6.

Coffee uz rozhodne neni cool, ale to nam tak nejak nevadi ;) Ja jsem prave zvedavej, co vypadne z tech typovejch js...ale pockam, zatim se mi nic moc nezda dostatecne dobry...(plus z nejakyho duvodu u me codebase psany v OCamlu budi pochyby ohledne OSS ekosysteu).

ALMAD: mne sa totiz ten cs paci aj vsetko akruat, neviem ako to bude v 2015 v javacripte vlastne vyzerat ;)

Zo vsade sa momentalne vali bud:
a) typovy javascript (typescript, flow, atscript)
b) ES6 fetatures (transpiled or native)

A nejak na coffee ako keby sa uz nekladol doraz, ale to bola len taka prakticka otazka (vcera som zrovna pozeral na DREDD a zaujala ma statistika CoffeeScript 98.2% :)

3108: Ad vymena backendu, proto dost firem pouziva cross-language, stateless templates...handlebar a podobne.

Sice kdyz ma clovek napsat nektery sablony, tak by si vypichal oci, ale tu kompatibilitu to ma...

3108: Nevim.

V CS je ~100% naseho JS. Verim taky, ze CS se uzpusobi tomu, jak bude ES6 vypadat.

Nicmene vic nez ES6 IMHO zalezi, jak se chytne promises ekosystem a jak to bude dohromady vypadat (CS+Promises proste vypada skoro stejne jako JS+Promises, takze na co ten overhead...)

Spis jdem ted tou cestou, ze z naseho monolitu vytrhavame services, takze se mozna stane, ze ruzne kusy budou v nahodnych jazycich. Ale ta spolecna platform a to ze je kazdej schopnej hrabout do cehokoli ma dost vyhod...

ALMAD: vdaka za ten tip na eco.
Zaujimalo by ma, ako ste natom u vas vo firme co sa tyka coffee to ES6 transition. Viem ze v coffee je vela syntakticky podobnych konstruktorov, ale zas aj par odlisnosti.

Budete to riesit nejako, ked mate kus logiky (vacsinu js kodu) v coffee a ked pride ES6 tak budete pokracovat v coffee alebo nove zdojaky pisat v ES6?

CYNIK: Mno ten isomorphic app development ma potencial a urcite tam bude kus dobrych myslienok, ale pride mi to velky zavazok previazat klienta konkretnou implementaciou backendu (co ked sa vymeni javascript (express) za railsy, alebo djangoo, alebo nieco dalsie? Co ak o rok uz nebude isomoprhic v mode? :) btw ako je v isomporhic dizajne definovane abstraktne API?