7 ms·

Thanks for the thoughtful response. It is interesting. In normal Js applications there is tremendous gravity towards having mutable application state because t

Thanks for the thoughtful response. It is interesting. In normal Js applications there is tremendous gravity towards having mutable application state because the callbacks need a handle of some sort (normally some instance of something). So I am wondering what you mean by saying that the callback pattern is more functional? In addition to mutable application state we have another global mutable state, one that's even harder to opt out of: The Dom. Regardless wether we use channels or callbacks this is going to be a problem whenever we have more than one actor changing it, whether that is done at the same time or sequentially. To me the place for core.async or the newish yield operator is that blocking will allow us to wire together complex event behavior in some fairly sophisticated ways. How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? So we can handle the wiring of events and when we get to the right state we do our functional application state transition. Then as long as we are driving the Dom off of our application state then we should be good right? * waiving my hands a bunch

ricardobeat 13y ago
> How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? Those are not hard problems, really. Doesn't core.async solve bigger issues?
- swannodette 13y ago
  Do you not consider managing complexity a "big" problem? I'm certainly tired of writing code like this http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.autocomplete.js http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui....
  - brucehauman 13y ago
    Wow, that looks a lot easier than I thought it would be.
- brucehauman 13y ago
  Wether they are hard or not. They seem to confound developers as the edge cases of shared mutable state stack up. Core.async is offering another way to express solutions to complex behavior and is certainly worth investigating. I would say that is the bigger issue 'expression'. I have to say though I am not advocating the creation of huge systems this way but I am very interested in this as a different approach and I am going to see how far it takes me.
drcode 13y ago
> what you mean by saying that the callback pattern is more functional? I agree that the callback approach is not functional, and that the channel approach is certainly much better than this status quo approach. I'm comparing instead against an approach where you break down all relevant events into JSON, and then push those into a global fully-functional "event handler" function that translates events (along the "world state") into a set of DOM manipulation primitives. With that type of approach, no channels are necessary. I agree this approach has difficulties with time-sensitive operations (such as responsive autocomplete, etc) and that channels offer advantages for this. I'm not yet sure which approach leads to the least tradeoffs or whether there is a third approach that combines the best of both worlds that I don't quite comprehend yet. > another global mutable state, one that's even harder to opt out of: The Dom Well, I think the success of angular.js shows that it's possible (and probably desirable) to completely isolate DOM state changes from other program code... though the OP program doesn't do this, this is clearly just a simplified example, so I want to see what is possible once someone builds a client-side framework that is built on channels...
- brucehauman 13y ago
  Well a really interesting thing is that the channels approach helped me "discover" the queue approach that you are mentioning. As I worked on the channel examples I kept seeing the equivalent Js patterns that would make a more functional approach possible. The decoupled queue approach seems to be rare in practice and obviously superior. Wish I had thought about it long ago. I just followed the examples available to me. I really believe the channel approach lifts this notion (values on queues) to the forefront with the addition of blocking sequential semantics. Yeah my examples were a bit simplified, but I did try to make the DOM state a function of the application state. There will be more examples coming in the near future :)
- gruseom 13y ago
  I'm comparing instead against an approach where you break down all relevant events into JSON, and then push those into a global fully-functional "event handler" function that translates events (along the "world state") into a set of DOM manipulation primitives How common is this approach? I'd be very interested to hear people's experiences with it. It's what we do, except we run the global event processor on a JS timer so that it works like a game loop picking items off a queue. Our DOM event handlers (the things you call addEventListener with) are all trivial stubs that simply create JSON descriptions of events as they happen and append them to that queue. We tried many different approaches before we hit on this, and it works surprisingly well in the two hardest areas: managing complexity and keeping the UI snappy. You can also create perceived concurrency this way: you do a little work on an item in the queue and then, if it's not done, put it back at the back of the line. That's how we do the "time-sensitive operations" you mention. I'm not sure what to call this design. I think of it as a state machine, but that's a metaphor rather than a precise description.

ricardobeat 13y ago

> How long does it take to get a slideshow to really work well in callback land? Or responsive autocomplete with correct lower and upper bound timeout thresholds? Those are not hard problems, really. Doesn't core.async solve bigger issues?

swannodette 13y ago
Do you not consider managing complexity a "big" problem? I'm certainly tired of writing code like this http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.autocomplete.js http://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui....
- brucehauman 13y ago
  Wow, that looks a lot easier than I thought it would be.
brucehauman 13y ago
Wether they are hard or not. They seem to confound developers as the edge cases of shared mutable state stack up. Core.async is offering another way to express solutions to complex behavior and is certainly worth investigating. I would say that is the bigger issue 'expression'. I have to say though I am not advocating the creation of huge systems this way but I am very interested in this as a different approach and I am going to see how far it takes me.

drcode 13y ago

> what you mean by saying that the callback pattern is more functional? I agree that the callback approach is not functional, and that the channel approach is certainly much better than this status quo approach. I'm comparing instead against an approach where you break down all relevant events into JSON, and then push those into a global fully-functional "event handler" function that translates events (along the "world state") into a set of DOM manipulation primitives. With that type of approach, no channels are necessary. I agree this approach has difficulties with time-sensitive operations (such as responsive autocomplete, etc) and that channels offer advantages for this. I'm not yet sure which approach leads to the least tradeoffs or whether there is a third approach that combines the best of both worlds that I don't quite comprehend yet. > another global mutable state, one that's even harder to opt out of: The Dom Well, I think the success of angular.js shows that it's possible (and probably desirable) to completely isolate DOM state changes from other program code... though the OP program doesn't do this, this is clearly just a simplified example, so I want to see what is possible once someone builds a client-side framework that is built on channels...

brucehauman 13y ago
Well a really interesting thing is that the channels approach helped me "discover" the queue approach that you are mentioning. As I worked on the channel examples I kept seeing the equivalent Js patterns that would make a more functional approach possible. The decoupled queue approach seems to be rare in practice and obviously superior. Wish I had thought about it long ago. I just followed the examples available to me. I really believe the channel approach lifts this notion (values on queues) to the forefront with the addition of blocking sequential semantics. Yeah my examples were a bit simplified, but I did try to make the DOM state a function of the application state. There will be more examples coming in the near future :)
gruseom 13y ago
I'm comparing instead against an approach where you break down all relevant events into JSON, and then push those into a global fully-functional "event handler" function that translates events (along the "world state") into a set of DOM manipulation primitives How common is this approach? I'd be very interested to hear people's experiences with it. It's what we do, except we run the global event processor on a JS timer so that it works like a game loop picking items off a queue. Our DOM event handlers (the things you call addEventListener with) are all trivial stubs that simply create JSON descriptions of events as they happen and append them to that queue. We tried many different approaches before we hit on this, and it works surprisingly well in the two hardest areas: managing complexity and keeping the UI snappy. You can also create perceived concurrency this way: you do a little work on an item in the queue and then, if it's not done, put it back at the back of the line. That's how we do the "time-sensitive operations" you mention. I'm not sure what to call this design. I think of it as a state machine, but that's a metaphor rather than a precise description.