3 ms·

Can someone explain the benefits of channels vs event handlers for frontend development in a non-abstract way like I'm five?

by gfodor 13y ago

cgag 13y ago
A more detailed explanation on how those IoC threads work would be awesome too if someone's going to be explaining things to children would be great.
- snprbob86 13y ago
  The IoC threads work by converting park-able functions into Single-Static Assignment (SSA) form [1] and then compiled to a state machine. Essentially, each time a function is "parked", it returns a value indicating where to resume from. These little state machine functions are basically big switch statements that you don't need to write by hand. This design is inspired by C#'s async compilation strategy. See the EduAsync Series [2] on John Skeet's blog, and the compilation post [3] in particular. Once you have these little state machines, you just need some external code to turn the crank. [1]: http://en.wikipedia.org/wiki/Static_single_assignment_form http://en.wikipedia.org/wiki/Static_single_assignment_form [2]: http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/default.aspx http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/defa... [3]: http://msmvps.com/blogs/jon_skeet/archive/2011/05/20/eduasync-part-7-generated-code-from-a-simple-async-method.aspx http://msmvps.com/blogs/jon_skeet/archive/2011/05/20/eduasyn...
  - cgag 13y ago
    These are all excellent, that wiki page is surprisingly easy to understand. Thanks.
- ufo 13y ago
  My impression is that the IOC threads spare you from needing to write continuation-passing-style code by hand and let you program in a more idiomatic style instead. This would be specially useful if you have lots of jumps in your control flow such as loops, return and break statements.
snprbob86 13y ago
It's not quite clear what patterns will emerge with respect to UI event handlers, so there really isn't an ELI5 answer yet in the View layer. The backend advantages are well covered by the Go language community, so check out Rob Pike's talk [1]. As for other parts of the frontend, like the model layer, channels can lead to a major simplification for the callback hell involving multiple coordinated network requests or for transforming and processing events off a message socket, like that of Socket.io. [1]: http://talks.golang.org/2012/concurrency.slide#1 http://talks.golang.org/2012/concurrency.slide#1
nwjsmith 13y ago
Channels allow you to write code that "pulls" events off of a stream or enumerate-like structure. This can dramatically simplify event-heavy front end code. Bacon.js is a library that exposes a similar technique (FRP), and their readme outlines the benefits in tangible terms https://github.com/raimohanska/bacon.js https://github.com/raimohanska/bacon.js

Can someone explain the benefits of channels vs event handlers for frontend development in a non-abstract way like I'm five?

by gfodor 13y ago

Can someone explain the benefits of channels vs event handlers for frontend development in a non-abstract way like I'm five?

cgag 13y ago

A more detailed explanation on how those IoC threads work would be awesome too if someone's going to be explaining things to children would be great.

snprbob86 13y ago
The IoC threads work by converting park-able functions into Single-Static Assignment (SSA) form [1] and then compiled to a state machine. Essentially, each time a function is "parked", it returns a value indicating where to resume from. These little state machine functions are basically big switch statements that you don't need to write by hand. This design is inspired by C#'s async compilation strategy. See the EduAsync Series [2] on John Skeet's blog, and the compilation post [3] in particular. Once you have these little state machines, you just need some external code to turn the crank. [1]: http://en.wikipedia.org/wiki/Static_single_assignment_form http://en.wikipedia.org/wiki/Static_single_assignment_form [2]: http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/default.aspx http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/defa... [3]: http://msmvps.com/blogs/jon_skeet/archive/2011/05/20/eduasync-part-7-generated-code-from-a-simple-async-method.aspx http://msmvps.com/blogs/jon_skeet/archive/2011/05/20/eduasyn...
- cgag 13y ago
  These are all excellent, that wiki page is surprisingly easy to understand. Thanks.
ufo 13y ago
My impression is that the IOC threads spare you from needing to write continuation-passing-style code by hand and let you program in a more idiomatic style instead. This would be specially useful if you have lots of jumps in your control flow such as loops, return and break statements.

snprbob86 13y ago

It's not quite clear what patterns will emerge with respect to UI event handlers, so there really isn't an ELI5 answer yet in the View layer. The backend advantages are well covered by the Go language community, so check out Rob Pike's talk [1]. As for other parts of the frontend, like the model layer, channels can lead to a major simplification for the callback hell involving multiple coordinated network requests or for transforming and processing events off a message socket, like that of Socket.io. [1]: http://talks.golang.org/2012/concurrency.slide#1 http://talks.golang.org/2012/concurrency.slide#1

nwjsmith 13y ago

Channels allow you to write code that "pulls" events off of a stream or enumerate-like structure. This can dramatically simplify event-heavy front end code. Bacon.js is a library that exposes a similar technique (FRP), and their readme outlines the benefits in tangible terms https://github.com/raimohanska/bacon.js https://github.com/raimohanska/bacon.js