6 ms·

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)

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?

vvanders 10y ago
First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/ 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.
- riffraff 10y ago
  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.
  - masklinn 10y ago
    The "new Subscriptions" thing replaces signals, which is not what GP thinks is "what we had before".
wheatBread 10y ago
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.
- BinaryIdiot 10y ago
  > 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.
jlongster 10y ago
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.
- smrtinsert 10y ago
  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.
- Matthias247 10y ago
  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.
- dreamdu5t 10y ago
  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.
jose_zap 10y ago
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.
masklinn 10y ago
`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.
- zachrose 10y ago
  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?

vvanders 10y ago

First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/ 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.

riffraff 10y ago
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.
- masklinn 10y ago
  The "new Subscriptions" thing replaces signals, which is not what GP thinks is "what we had before".

wheatBread 10y ago

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.

BinaryIdiot 10y ago
> 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.

jlongster 10y ago

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.

smrtinsert 10y ago
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.
Matthias247 10y ago
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.
dreamdu5t 10y ago
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.

jose_zap 10y ago

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.

masklinn 10y ago

`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.

zachrose 10y ago
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?