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: 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?

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.