[lhorie]

Disclaimer: I wrote Mithril (one of the vdom frameworks mentioned in the presentation)

I like the idea of reactive programming, but it tends to add a lot of indirection. This is theoretically desirable, but not necessarily pragmatic in reality. A lot of frontend code in the wild is of the throw-away-in-a-few-years nature and it's hard to get mindshare among developers if they're required to learn stuff that feels academic when all they really care about is getting stuff shipped the next day. Being able (forced?) to tightly couple a controller and a view in Angular is one reason a lot of people like it.

I was giving a workshop on FP recently, and you'd be surprised at the number of people who still don't grok `filter`. FRP is still way over a lot of people's heads. Hopefully the industry will warm up more to the concept as React, Mithril, Meteor, etc get more popular.

@staltz WRT Cycle.js itself:

I took a look at the TodoMVC example and was surprised to see intents reading data from DOM element data attributes (e.g. https://github.com/staltz/todomvc-cycle/blob/master/js/inten... ). How does one go about doing non-string parameterized intents? For example, I often need to reference an entity from an event handler and searching for it in a collection by ID seems wasteful. In Mithril, for example, handlers can receive parameters as inputs either via closures from the view or via partial application (i.e. Function::bind). This is especially useful for event handlers that deal with relationships between two or more different entities. Is there a similar mechanism in Cycle.js?

[staltz]

> How does one go about doing non-string parameterized intents?

From yesterday, it's now possible to have stateful custom elements, as if they were Web Components: https://github.com/staltz/cycle/blob/fbae9c6610043ef6e46941a... This brings Cycle a bit closer to React, in that a "component" can handle its own events. The overall approach is still different than React, because in React you are encouraged to use components for anything, while custom elements exist in Cycle only when a pure component (i.e. a function returning a virtual DOM element, in React terms, props-only component) is not enough. Hence TodoMVC could be rewritten to use <todo> custom elements.

Using DOM attributes to register IDs is just one technique. Things are evolving fast, and I haven't myself tried to publish/share Cycle just yet, because it's not ready.

PS: I have a lot of respect for Mithril. Unfortunately not reactive as I would appreciate, but Mithril is very fast and very simple to understand.

[discreteevent]

If they don't grok filter then they cannot even interact with a relational database at the simplest level (a select, where). I think there is a certain level below which you are not obliged to dumb it down further.

[lhorie]

Sure there are those who get by w/ Google/StackOverflow/copy+paste (and hey, everyone has to start somewhere), but also remember that not everyone is a full stack dev. Lots of people make a living programming exclusively on the frontend.

There are also those that understand the concept of filtering at a basic level when reading tutorials about it, but still write for/if loops when it comes to producing actual code and it doesn't occur to them that it's possible to take the anonymous function out of the filter() call and give it a name to start building up a compositional foundation in their codebases.

My point though is that the benefits of FRP are somewhat out of line with the types of problems that people face in the real world.

[staltz]

I use a simple example of how Rx (not FRP, that's something completely different) benefits in programming: the traditional use case of analytics events is to spread Analytics.sendEvent() calls in many places of your codebase. Using Rx to solve this problem, things get inverted: you have all analytics events defined in one module, they are listening to events happening throughout the codebase. Sometimes the platform (mobile or whatnot, think beyond JS) provides convenient lifecycle events for this. In conclusion: the only place you see analytics events in your codebase is in the Analytics module.

To me, it's about separation of concerns most of the times, and about handy event operators sometimes (e.g. https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...).