Hacker News Reader

Comment by gfodor | Hacker News Reader

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

View on HN

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

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

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.

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

[2]: http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/defa...

[3]: http://msmvps.com/blogs/jon_skeet/archive/2011/05/20/eduasyn...

These are all excellent, that wiki page is surprisingly easy to understand. Thanks.

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.

Reply on news.ycombinator.com