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?

3108: Mě láká extrémně možnost sdílet šablony a modely tak, že se mi stránky načítaj hezky ajaxově a krásně to všechno sviští, tam jsem se zatim zasek, nevim, zatim, jak donutit react renderovat jenom část stránky bez layout hell (všechny komponenty na jednou layoutu)

CYNIK: imho zatial hype :D dam este par mesiacov inkubacie, kym vznikne rozmuny devstack.

Ale musim dodat ze ember + ember-cli umoznuje pomocou browserify addonu zdielat nejaku logiku, validaciu a pod. Ale rovnako uvitam nejake postrehy ;)

CYNIK: V Apiary sdílíme kód mezi serverem a klientem, ale isomorphismem bych to úplně nenazýval.

Už v tom vlastně někdo napsal něco produkčního? :)

Děláte už někdo nějaké isomorphy?
Máte nějaký devstack (Este.js se mi nelíbí), nevíte někdo o jobu, kde by se dalo něco přiučit o isomorphismu?

Díky

Ahoj, používáte někdo Web Starter Kit od Google?

Výchozí `gulp styles` je neskutečně pomalý, u mně trvá 31 s. I kdyby to bylo 5 s, tak je to moc. Ok, pokud by se jednalo o součást buildu, ale includují to i do `gulp serve`, který je určený na vývoj. Uniká mi něco?

WENCA:
Dobrej napad, zkusim to.

COLBEN: tak eshopu v php, pythonu, ruby mas celkem dost, argument je steny (tzn. kazdemu co jeho jest ;))

COLBEN: eshop by som sa nebal.

ahoj, libi se mi node.js tak si s nim trosku hraju a trosku vic jsem se zacal zajimat o javascript taky. chtel jsem se zeptat zda mate zkusenost s vyvojem cele business logiky v javascriptu (treba nejake aplikace typu eshop) ? trosku se bojim, ze javascript je sice super flexibilni, ale na vyvoj nejakyho backendu se preci jen spis hodi nejaky staticky typovany jazyk

coffescript 1.7 vonku, made my day:

"Leading . now closes all open calls, allowing for simpler chaining syntax."

SUCZKER: Diky, to by taky asi slo. Kazdopadne jsem to vyresil tak, ze jsem to napsal v jinym jazyce a neni problem :) Jinak pokud jsem v tom scriptu pouzival HTTPS spojeni, tak to zralo cca o 100% vic pameti nez HTTP.

KEEPER: Uz to asi neni aktualni, ale mozna bych na to zkusil nejakej spawn / fork a cist si to pomoci sprosty pajpy, to by ti melo zajistit, ze ten hlavni proces neporoste.

ALMAD: Tak jsem to prepsal do eventu. Bohuzel je to stejny. Nechal jsem ten script par hodin bezet a nakonec se narust pameti teda zastavil. Zkousel jsem to monitorovat pres Nodetime, roste hlavne RSS, ale po pravde nevim, co presne to pro me znamena :) Kazdopadne stejnej script napsanej v Ruby zabere max 25MB pameti a vic ani tuk.

KEEPER: Ted si vybavuju, ze kdyz sem neco takovyho resil posledne, tak jsem skoncil u toho, ze jsem to prepsal na event emittery...to zabralo, protoze tam stoprocentne kontext nedrzis. U nas se to pak zvrhlo a konci to takhle, ale u tebe by to melo zustat nekomplikovany, protoze kdyz neprojde podminka, tak das setTimeout(function(){ emitter.emit('resume'); }, time);, coz uz by kontext fakt drzet nemelo.

ALMAD: Diky, presne to jsem zkousel. V ty else vetvi jsem mel: process.nextTick(run). Pokud jsi tohle mel na mysli? Mozna ze jenom node je zravy a nekde se to nakonec zastavi? Zatim teda, co jsem to nechal bezet, tak spotreba pameti neustale rostla a to me prekvapilo, proto patram, jestli nekde neni chyba v kodu. Chtel jsem takovych scriptu poustet vic na slabym VPSku s malo RAM a jeste u toho mit Redis, ale takhle to moc nevypada, ze by to bylo realizovatelny :)