Note: Gren has managed effects, meaning that things like HTTP requests or writing to disk are all treated as data in Gren. When this data is given to the Gren runtime system, it can do some “query optimization” before actually performing the effect. Perhaps unexpectedly, this managed effects idea is the heart of why Gren is so nice for testing, reuse, reproducibility, etc.
Gren has two kinds of managed effects: commands and subscriptions.
A subscription is a way of telling Gren, “Hey, let me know if anything interesting happens over there!” So if you want to listen for messages on a web socket, you would tell Gren to create a subscription. If you want to get clock ticks, you would tell Gren to subscribe to that. The cool thing here is that this means Gren manages all the details of subscriptions instead of you. So if a web socket goes down, you do not need to manually reconnect with an exponential backoff strategy, Gren does this all for you behind the scenes!
Sub specifies (1) which effects you need access to and (2) the type of
messages that will come back into your application.
Note: Do not worry if this seems confusing at first! As with every Gren user ever, subscriptions will make more sense as you work through the Gren Architecture Tutorial and see how they fit into a real application!
Tell the runtime that there are no subscriptions.
When you need to subscribe to multiple things, you can create a
Sub.batch [ Sub.none, Sub.none ] and
Sub.batch  all do the same thing.