00:09:49  * kazuponquit (Remote host closed the connection)
00:11:22  * Foxandxssquit (Remote host closed the connection)
00:18:10  * l4u-joined
00:21:13  * TheAceOfHeartsquit (Quit: Leaving.)
00:51:18  * corbanbquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:55:34  * TheAceOfHeartsjoined
01:16:35  * kazuponjoined
01:31:48  * kazuponquit (Remote host closed the connection)
01:33:10  * kazupon_joined
02:43:12  * kazupon_quit (Remote host closed the connection)
03:24:30  * kazuponjoined
03:30:10  * kazuponquit (Ping timeout: 272 seconds)
03:37:52  * kazuponjoined
03:46:08  * kazuponquit (Remote host closed the connection)
04:35:57  * basicdaysquit (Quit: I'm out)
04:43:19  * kazuponjoined
05:39:11  * joshonthewebjoined
05:48:15  * TheThingquit (Remote host closed the connection)
05:55:19  * joshonthewebquit (Quit: Computer has gone to sleep.)
05:58:56  * joshonthewebjoined
05:59:04  <TheAceOfHearts>oh
05:59:13  <TheAceOfHearts>I could've totally helped IvanSB
06:42:21  * TheAceOfHeartsquit (Quit: Leaving.)
07:41:30  * joshonthewebquit (Quit: Computer has gone to sleep.)
08:00:15  * l4u-quit (Quit: Connection closed for inactivity)
08:02:31  * mhernandez1quit (Remote host closed the connection)
08:04:30  * mhernandez1joined
08:09:36  * kazuponquit (Remote host closed the connection)
08:30:35  * kazuponjoined
09:31:04  * Foxandxssjoined
09:49:07  * TheThingjoined
09:53:49  * TheThingquit (Ping timeout: 264 seconds)
10:23:18  * IvanSBjoined
10:32:24  * fsalgojoined
10:32:36  * fsalgopart
10:39:20  * IvanSBquit (Remote host closed the connection)
10:42:19  * IvanSBjoined
11:07:58  * kazuponquit (Remote host closed the connection)
11:16:37  * kazuponjoined
11:26:13  * mhernandez1quit (Remote host closed the connection)
11:37:20  * joshonthewebjoined
12:04:31  * kazuponquit (Remote host closed the connection)
12:04:59  * kazuponjoined
12:09:11  * kazuponquit (Ping timeout: 246 seconds)
12:14:51  * IvanSBquit (Quit: Konversation terminated!)
12:35:38  * mhernandez1joined
13:12:08  * TheAceOfHeartsjoined
13:53:38  * mhernandez1quit (Remote host closed the connection)
14:23:46  * joshonthewebquit (Quit: Computer has gone to sleep.)
14:35:15  * kazuponjoined
15:04:12  * IvanSBjoined
15:10:13  * IvanSBquit (Remote host closed the connection)
15:13:11  * IvanSBjoined
15:21:00  * kazuponquit (Remote host closed the connection)
15:21:26  * kazuponjoined
15:25:59  * kazuponquit (Ping timeout: 265 seconds)
15:53:24  <IvanSB>I'm trying to "port" fluxible-router to koa. I've something very similar to: https://github.com/yahoo/flux-examples/blob/master/fluxible-router/server.js The problem is that executeAction is asyncronous and while express use send(), koa just modify body and pass execution to the next middleware.
15:54:22  <IvanSB>If I move renderToStaticMarkup() outside executeAction it doesn't have the right context. Any suggestion?
16:15:53  * shesekjoined
16:20:50  * kazuponjoined
17:22:57  <TheAceOfHearts>IvanSB: hi
17:24:02  * mhernandez1joined
17:24:08  <TheAceOfHearts>koa middleware is based on generators
17:24:46  <TheAceOfHearts>and "context.executeAction" will return a promise, so you could just yield that and render afterwards
17:24:59  <TheAceOfHearts>I use async/await, but it's still basically the same thing
17:25:00  <TheAceOfHearts>see here:
17:25:40  <TheAceOfHearts>https://gist.github.com/cesarandreu/03f6c584a40c62812deb
17:26:08  <TheAceOfHearts>since executeAction returns a promise you can just yield or await that
17:29:34  <IvanSB>TheAceOfHearts: thanks, that's exactly what I was looking for. I've been missing the last 15 years of JS development after looking at it in disgust. I'm trying to catch up by trial and errors ;)
17:29:53  <TheAceOfHearts>lol
17:30:30  <TheAceOfHearts>I've used fluxible a bit
17:32:47  <IvanSB>TheAceOfHearts: well I'm really new to node and I was looking around to see what people are using today to do web stuff. Well with the exception of repeating the errors that have been made 20 years ago...
17:33:35  <IvanSB>TheAceOfHearts: so I started to look at tools even before being able to program in JS (at least not without shame)
17:34:27  <TheAceOfHearts>ah well, gotta start somewhere :P
17:35:05  <TheAceOfHearts>I'm setting up a scaffold for isomorphic apps
17:35:16  <TheAceOfHearts>github.com/cesarandreu/web-app I made this front pure frontend apps
17:35:17  <IvanSB>TheAceOfHearts: I'd be very happy to avoid to use fluxible... but that's the only tool that seems to have a reasonable isomorphic router. I feel all the stuff about stores, actions etc... is overengineered
17:35:50  <TheAceOfHearts>it just scales well for complicated UI's
17:35:58  <TheAceOfHearts>but I do think for basic CRUD stuff it's way overkill
17:36:04  <TheAceOfHearts>but e.g. if you're making some like a web IDE
17:36:09  <TheAceOfHearts>it makes it a LOT simpler
17:37:33  <TheAceOfHearts>there's react-router, as well, which you can use with fluxible
17:38:58  <IvanSB>TheAceOfHearts: I still have to convince myself it's true. It doesn't seem to borrow anything from classical GUI programming and considering web developers discovered they were missing URL just a couple of years ago and came up with all this iso stuff, I'm a bit suspicious about flux
17:39:51  <TheAceOfHearts>isomorphic apps have been around since backbone though :D
17:39:52  <IvanSB>TheAceOfHearts: react-router seems too simple for the server side part. It doesn't support methods up to my knowledge.
17:40:31  <TheAceOfHearts>what I do is I just mount the frontend app as a middleware
17:40:51  <TheAceOfHearts>and I use koa-router under /api/
17:41:33  <IvanSB>TheAceOfHearts: yeah... I thought the same... but I'm doing this for fun, it has to be nice to be fun and having 2 routers is not nice for me
17:41:48  <TheAceOfHearts>lol
17:42:01  <TheAceOfHearts>having the same router for API and client-side code doesn't make sense, tbh
17:42:29  <IvanSB>and I've to admit again my ignorance about browsers and JS... and I don't want to rewrite the part that manage history
17:42:47  <IvanSB>TheAceOfHearts: why?
17:43:18  <TheAceOfHearts>because API routes are short lived and they'll usually handle authentication, authorization, and fetching some stuff from the database
17:43:27  * kazuponquit (Remote host closed the connection)
17:43:40  <TheAceOfHearts>but client-side routes are more stateful, since you move between em
17:43:53  <TheAceOfHearts>and your code can just hit the API endpoints to fetch data
17:43:59  <TheAceOfHearts>that's the only way it can work as an isomorphic app
17:44:06  <TheAceOfHearts>so you have API endpoints
17:44:12  <TheAceOfHearts>and when you run the client-side code on the server
17:44:19  <TheAceOfHearts>it'll just make requests to the API
17:44:32  <TheAceOfHearts>you could abstract it away so it doesn't actually make requests or something
17:44:47  <TheAceOfHearts>but that's what people typically do, they jsut do requests to the API
17:44:51  <IvanSB>TheAceOfHearts: still parsing...
17:44:51  <TheAceOfHearts>they're handling different things
17:45:02  <TheAceOfHearts>a lot of people don't even write their APIs in node
17:45:10  * kazuponjoined
17:45:23  <TheAceOfHearts>but they'll use node as a frontend server
17:45:55  <TheAceOfHearts>the responsibilities of a client-side router and a server router are just too different
17:46:10  <TheAceOfHearts>I've done a few things with koa+isomorphic flux
17:46:16  <IvanSB>TheAceOfHearts: well infact I was planning to write just the frontend in node... and API in bottle/flask let me finish to fully understand what you wrote
17:46:44  <TheAceOfHearts>I just mount my koa API app under /api/, and below that I mount the client-side renderer
17:47:02  <TheAceOfHearts>sure
17:47:23  <TheAceOfHearts>if anything isn't clear, feel free to ask
17:50:17  <IvanSB>TheAceOfHearts: I was thinking for example to validating forms and recycle the code on client and server... yeah I could still do it "outside" fluxible-router but well I just feel it would be nice...
17:51:13  <TheAceOfHearts>uhhh
17:51:34  <TheAceOfHearts>if you're doing regular forms *and* ajax forms, it'll be REALLY difficult
17:51:39  <TheAceOfHearts>it's doable, sure… but not pleasant
17:51:53  <TheAceOfHearts>if you're doing regular forms, I'm not sure why you'd make it into an isomorphic apps
17:52:09  <TheAceOfHearts>I only do server-side validation of forms
17:52:21  <TheAceOfHearts>https://blog.cesarandreu.com/posts/form_validation_with_angularjs_and_rails this is an old blog post
17:52:24  <TheAceOfHearts>but the strategy is the same
17:52:30  <TheAceOfHearts>I do it with flux and react
17:52:48  <TheAceOfHearts>I just post whatever and the server responds with a 422 and a validation object, and I just iterate each key and set the validation error on each field
17:52:52  <IvanSB>TheAceOfHearts: well validating on the client may improve user experience...
17:53:39  <TheAceOfHearts>eh
17:53:50  <TheAceOfHearts>I don't think it's doable for any non-trivial system
17:54:08  <TheAceOfHearts>one approach is to use JSON schema and validate on the client-side first
17:54:20  <TheAceOfHearts>but then you need to write JSON schema for everything
17:54:29  <TheAceOfHearts>and it still won't cover all your validation needs
17:55:10  <TheAceOfHearts>there's a framework called meteor.js
17:55:20  <TheAceOfHearts>they claim to let you share models between server and client
17:55:22  <IvanSB>TheAceOfHearts: it is nearly doable with python eg. WTForms... I thought it could be easier if you used the same language both sides...
17:56:46  <TheAceOfHearts>well, I dunno, I haven't seen anyone pull that off nicely
17:57:46  <IvanSB>same problem with ORM and DB... It would be enough to avoid most of the duplication and add some lines here and there
17:58:13  <TheAceOfHearts>I've seen nice ORMs, and I've seen nice server-side forms
17:58:22  <TheAceOfHearts>but I haven't seen anything that ties em all nicely
17:59:20  <TheAceOfHearts>if you use an ORM that works on the client-side code it's doable
17:59:28  <TheAceOfHearts>then your server is just a small layer in front of your data store o w/e
18:00:08  <IvanSB>TheAceOfHearts: one step at a time... now you'd concentrate on convincing me that 1 router is not a good idea ;)
18:00:28  <TheAceOfHearts>well, client-side routes and API routes are just totally different
18:00:34  <TheAceOfHearts>they have COMPLETELY different concerns
18:01:17  <TheAceOfHearts>with API routes you don't have a bunch of application state to worry about, but on the client you *do* have all that state, and you need to handle errors and such
18:01:34  <TheAceOfHearts>or well, maybe application state isn't the right term
18:02:25  <IvanSB>but the concerns are in the handlers... not in the router... I can make handlers very different and keep the same router.
18:04:08  <TheAceOfHearts>but why?
18:04:46  <TheAceOfHearts>your router needs to worry about a lot of concerns
18:04:52  <IvanSB>TheAceOfHearts: and yeah... reading koa-router features I can see I'll miss "Named routes with URL generation" for example... but nothing more
18:05:55  <TheAceOfHearts>w/e
18:06:07  <TheAceOfHearts>good luck
18:06:21  <IvanSB>TheAceOfHearts: for example? In my naive view it just have to parse a request and pass it to the correct handler with some syntactic sugar
18:06:26  <IvanSB>TheAceOfHearts: thanks
18:06:49  <IvanSB>TheAceOfHearts: really thanks for your time
18:06:56  <IvanSB>and your example
18:07:03  <TheAceOfHearts>error handling?
18:07:05  <TheAceOfHearts>authentication?
18:07:06  <TheAceOfHearts>atuhorization?
18:07:20  <TheAceOfHearts>responding?
18:08:13  <TheAceOfHearts>modeling these problems as middleware is a lot simpler than modeling it with something like fluxible-router
18:08:33  <TheAceOfHearts>you'll otherwise end up building your own middleware layer on top of koa and fluxible-router or whatever router you use
18:09:39  <IvanSB>TheAceOfHearts: but why I can't continue to delegate auth to middleware even if I use fluxible-router (any)?
18:09:48  <TheAceOfHearts>and the behavior of an API route is very different from a client-side route
18:10:34  <TheAceOfHearts>sure, if all your routes need to check auth then you can place it in front of fluxible-router
18:10:56  <TheAceOfHearts>but let's say you have /foo and /bar
18:11:15  <TheAceOfHearts>and one requires an auth check, the other is public
18:12:55  <IvanSB>TheAceOfHearts: yeah... I can still think of a way to deal with this scenario... and avoid duplication... but let my hands get dirtier a little bit more with what koa has to offer ;)
18:14:00  <TheAceOfHearts>you're going to end up building your own framework on top of all these abstraction layers
18:15:15  <TheAceOfHearts>have you even considered how you're gonna send down the code to the client-side?
18:15:52  <IvanSB>TheAceOfHearts: auth code on the client side?
18:16:15  <TheAceOfHearts>well, if you're using the same code in both places
18:16:48  <IvanSB>I'd like to use as much code as *possible*...
18:17:20  <TheAceOfHearts>how are you gonna use the same router in both places, though?
18:18:13  <TheAceOfHearts>IMO… there's even better separation of concerns when you use separate routers
18:18:21  <TheAceOfHearts>I treat API and Client as separate apps
18:18:29  <TheAceOfHearts>API gets mounted on /api/ and client on /
18:19:21  <TheAceOfHearts>client just hits api endpoints
18:19:30  <IvanSB>TheAceOfHearts: I totally get your point, I'll try to experiment a bit with auth and fluxible-router to see if it is worth the assle
18:19:41  <TheAceOfHearts>maybe isomorphic models might be a bit more worthwhile
18:20:01  <TheAceOfHearts>but even then… the kind of validation you can do on the client-side is usually trivial
18:20:26  <TheAceOfHearts>you can't do any sort of relational constraints on the client
18:20:38  <IvanSB>TheAceOfHearts: but VERY boring to rewrite
18:21:11  <TheAceOfHearts>why not define your validation as pure functions and just pull those in…?
18:21:32  <TheAceOfHearts>on the server you pass the body to that function and then create model instances
18:21:46  <TheAceOfHearts>on the client you pass the current form to the function and update errors
18:26:57  <IvanSB>TheAceOfHearts: I'll see. I've just started to play with this... my first working example has no more than 4days...
18:27:29  <TheAceOfHearts>you should check out Relay
18:27:31  <TheAceOfHearts>it's not out yet :(
18:27:37  <IvanSB>TheAceOfHearts: just speculating... using the same router is just a child desire
18:27:38  <TheAceOfHearts>but it makes the isomorphic dream come true
18:27:57  <TheAceOfHearts>cuz even with what you mention
18:28:02  <TheAceOfHearts>whenever you change something
18:28:05  <IvanSB>there are too many things on the net that are called Relay...
18:28:10  <TheAceOfHearts>you need to update an API route
18:28:16  <TheAceOfHearts>and then you need to update your client-side code
18:28:27  <TheAceOfHearts>Relay and GraphQL
18:29:00  <IvanSB>I can't keep up LOL
18:29:50  <TheAceOfHearts>https://www.youtube.com/watch?v=X6YbAKiLCLU they show it off here
18:29:59  <TheAceOfHearts>jump to 39:45
18:30:56  <TheAceOfHearts>the thing is that this… it exists. I've tried it out. It's real.
18:31:12  <TheAceOfHearts>it handles stuff like optimistic updates and caching very elegantly
18:31:51  <IvanSB>TheAceOfHearts: I'm not that sure I want something more to learn ;)
18:32:03  <TheAceOfHearts>it's not out yet
18:32:12  <TheAceOfHearts>but it changes the playing field for apps...
18:34:49  <IvanSB>TheAceOfHearts: I was thinking to use Baobab... this is just one more piece I'll have to think about
18:35:13  <TheAceOfHearts>Relay isn't out et anyway, so it can't be used lol
18:35:17  <TheAceOfHearts>I saw Baobab
18:35:22  <TheAceOfHearts>not being maintained though, is it?
18:35:38  * kazuponquit (Remote host closed the connection)
18:35:56  <IvanSB>TheAceOfHearts: I'm still looking around... I didn't check
18:36:19  <TheAceOfHearts>you should check out meteor.js
18:36:25  <TheAceOfHearts>that sounds like something closer to what you want
18:36:30  <TheAceOfHearts>same router, same models, etc.
18:36:31  <TheAceOfHearts>I think
18:37:33  <IvanSB>I think I need to go out and have some fun
18:38:18  <IvanSB>TheAceOfHearts: thanks...
18:41:57  <IvanSB>TheAceOfHearts: no I stumbled on meteor too and it is not what I was looking for... but yeah nice
18:53:04  * IvanSBquit (Quit: Konversation terminated!)
19:47:35  * IvanSBjoined
19:59:16  * mhernandez1quit (Remote host closed the connection)
20:06:36  * IvanSBquit (Remote host closed the connection)
20:09:35  * IvanSBjoined
20:19:49  <IvanSB>TheAceOfHearts: I thought await was part of node. It seems it isn't or should I have to enable some node/io flag?
20:20:54  * mhernandez1joined
20:22:39  <TheAceOfHearts>nope, it's part of ES7, I use babel.js to transpile my code :D
20:22:48  <TheAceOfHearts>but you can use generators instead
20:23:06  <TheAceOfHearts>co lets you yield promises
20:23:11  <TheAceOfHearts>and executeAction is a promise
20:27:30  <IvanSB>TheAceOfHearts: FUUU I was on the right path. I tried to yield the promise but being new to JS I thought the error I got was related to the fact I was yielding inside a nested function
20:28:09  <TheAceOfHearts>well, generators aren't really meant to be used this way lol, it's kinda a hack with co
20:32:55  * mhernandez1quit (Remote host closed the connection)
20:34:01  * mhernandez1joined
20:34:48  * mhernandez1quit (Remote host closed the connection)
20:35:45  <IvanSB>TheAceOfHearts: well JS is a hack. If it wasn't its most exciting concurrency model wouldn't be based on generators. Right now it's enough I can see it can work. Then I'll plug it back in the main webpack project and consider transpiling server code too.
20:36:21  <TheAceOfHearts>I transpile server code with wepback~
20:36:35  <TheAceOfHearts>I'm in process of publishing a scaffold for that too
20:37:44  * felixjetquit (Read error: Connection reset by peer)
20:39:31  <IvanSB>yep... but well I didn't know about the existence of webpack till a week ago. And I was not planning to invest too much in infrastructure before getting an idea of how things work. webpack is very client oriented and I still have to understand how to avoid bundling server code. Infact I used gulp to translate jsxfor the server.
20:40:37  * felixjetjoined
20:45:31  * mhernandez1joined
20:48:59  <TheAceOfHearts>you can just use babel for the server
20:49:02  <TheAceOfHearts>it's better
20:49:07  <TheAceOfHearts>it does ES6 and jsx
20:49:12  <TheAceOfHearts>there's node-babel or babel-node
20:49:23  <TheAceOfHearts>if you're using iojs you can just use the -r flag
20:55:44  <IvanSB>TheAceOfHearts: if we keep compiling scripting languages we rather go back to CGI in C
20:56:25  <TheAceOfHearts>lol
20:56:26  <TheAceOfHearts>oh well
20:57:20  <IvanSB>I've seen wonderous things written in JS and I actually wonder
20:57:41  <TheAceOfHearts>JS is great, it's basically a LISP :D
20:58:19  * Ineenthojoined
21:02:01  <IvanSB>TheAceOfHearts: LISP is a wonderful language used by no one that was anticipating its time, JS is a terrible language used by everybody that it's moving its first step out of the '90 just now
21:02:15  <TheAceOfHearts>oh well
21:02:23  <TheAceOfHearts>bitching about it sure doesn't help :p
21:15:11  * kazuponjoined
21:20:00  * kazuponquit (Ping timeout: 252 seconds)
21:45:04  * morbitjoined
22:21:56  * mhernandez1quit (Remote host closed the connection)
22:22:14  * mhernandez1joined
22:22:46  * mhernandez1quit (Remote host closed the connection)
22:24:13  <IvanSB>TheAceOfHearts: GraphQL and Relay seems a way to write SQL bottom up. It really doesn't explain how a graph get converted to something you can actually use to query a DB. What it is all about?
22:24:35  <TheAceOfHearts>you need a compatible backend
22:24:52  <TheAceOfHearts>that can handle graphql => whatever :D
22:24:59  <TheAceOfHearts>they're gonna open source it soon~~
22:25:36  <IvanSB>TheAceOfHearts: Relay or the graphql => ???
22:25:58  <TheAceOfHearts>Relay is just a consumer of GraphQL
22:27:59  <IvanSB>TheAceOfHearts: still... it is nice I've a mmm sort of optimized query... but that's far from having a real query to a real DB
22:28:54  <TheAceOfHearts>sure
22:29:03  <TheAceOfHearts>you have model definitions in the graphql server
22:30:55  <IvanSB>TheAceOfHearts: anyway looking at the speed of how this framework get trown away... I think I'm not going to get trapped by fluxible-router
22:31:05  <TheAceOfHearts>lol
22:31:25  <TheAceOfHearts>need to use smaller more composable parts
22:32:48  <IvanSB>TheAceOfHearts: before having this tour with JS I just had a tour in python microframeworks exactly for the same reason...
22:58:00  * IvanSB_joined
22:58:28  * IvanSBquit (Ping timeout: 255 seconds)
23:21:28  * IvanSB_quit (Read error: Connection reset by peer)
23:22:31  * IvanSB_joined
23:31:07  * kazuponjoined
23:39:12  * kazuponquit (Ping timeout: 272 seconds)
23:47:03  * joshonthewebjoined