Hacker News Reader

Comment by zachrose | Hacker News Reader

I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers:

    Time.every second Tick

vs.

    Time.on('everySecond', tick)

Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?

View on HN

I don't know anything about Elm subscriptions yet. But there is a lot more to this stuff then just event emitters.

Things like:

* When an event/action/etc comes through, does it always call listeners synchronously? Can you change that and schedule events manually?

* How do you compose subscriptions/event handlers? This is usually the hardest part, and where simple event emitters really start breaking

* What about the lifecycle of the listener? What happens when it subscribes or unsubscribes? More importantly, what happens when the source that it subscribed to "shuts down"?

All of these things get pretty complicated and is the reason why various fields like FRP exist. Simple event emitters work immediately, yes, but they are a pretty terrible abstraction to build an app on.

Yeah the same questions popped up in my head. The natural end point to me looks more like Rx. Lifecycle and especially composition seem like big missing pieces.

Exactly these questions also came to my mind when I read the article. Subscriptions can get very tricky. Sometimes you want events to be synchronously fired, sometimes it's better when they are deferred into another eventloop tick. Unsubscription can also get quite tricky as you said.

I really wonder if Elm got a generic solution that fits all possible usage scenarios.

It looks like Subscriptions are just Signals with another name. I don't see any difference except that functions like map, foldp, etc. have been removed to discourage first-order use of them.

They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what?

So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.

> The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.

To be fair you can do this in javascript as well using a messaging pattern similar to elm. Many libraries like postal.js (synchronous) and msngr.js (asynchronous) support a messaging pattern where you can access resources without caring who owns them.

The fact that you can immediately imagine how it works and think that it is a very simple comncept, makes the changes in 0.17 even more awesome.

It turned something that is in real life difficult to manage, compose and scale, into something not just easy to grasp, but also simple to read and safe to execute.

Congrats on everyone involved in making this release happen.

`Time.every second Tick` returns a time-varying value it doesn't call a side-effecting callback. It generates a filtered event emitter if you will. Semantically it has almost no relation to your JS version, aside from both being function calls.

Ah, this explanation is the most cogent to me. So does the Elm runtime and/or compiler manage this as an event or callback under the hood?

First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/

> No runtime errors in practice. No null. No undefined is not a function.

> Friendly error messages that help you add features more quickly.

> Well-architected code that stays well-architected as your app grows.

> Automatically enforced semantic versioning for all Elm packages.

to be fair, all these things do not seem to be dependent on this new Subscriptions thing, as in fact they were there even before.

I am sure the new idea is good, but as grandparent said, the examples fail to convey why this is better than what we had before.

The "new Subscriptions" thing replaces signals, which is not what GP thinks is "what we had before".

Reply on news.ycombinator.com