Choosing Between PureScript's Aff and Effect Monads for Asynchronous Code

Decision and Constraints

When writing PureScript code that interacts with a JavaScript environment (browser or Node), you must decide whether to model asynchronous operations with the Aff monad or keep them in the simpler Effect monad. The choice hinges on whether you need built‑in support for composing async actions, parallel execution, and error propagation.

Constraints

• Target platform: JavaScript (browser or Node).
• PureScript version: 0.15.x (where Aff lives in Effect.Aff).
• Dependencies: Aff requires the purescript-aff package (and its transitive deps purescript-either, purescript-transformers). Effect is provided by the core purescript-effect package and needs no extra installation.

Comparison Table

Aspect	Aff	Effect
Async support	Native (forkAff, awaitAff, Affjax)	Requires manual callbacks or JS FFI
Composition	Monadic bind, parallel via Aff.parallel	Sequential only (do‑notation)
Error handling	Either‑like semantics (EitherT, tryEither)	Manual propagation
Runtime overhead	Minimal (few closures)	Zero extra cost
Learning curve	Moderate (understand transformers)	Low (direct effect)
JS interop	Easy via Aff.fromPromise, Affjax	Direct foreign imports

Trade‑offs Explanation

Aff gives you a monad that models asynchronous, potentially failing computations. Its Bind instance lets you chain actions sequentially, while Aff.parallel lets you run independent async effects concurrently. Errors are captured in an Either-like structure, so a single tryEither can convert a computation to Either Error a.

The downside is a small runtime cost due to the underlying free‑monad implementation and a modest increase in cognitive load because you must understand concepts like EitherT and Affjax. For purely synchronous side‑effects—such as mutating the DOM, writing to console.log, or reading a synchronous config—Effect is sufficient and incurs no extra overhead.

Concrete Implementation

Using Aff for an AJAX request

module Main where

import Effect (Effect)
import Effect.Aff (Aff, launchAff_, mapEffect)
import Effect.Class.Console (logError, logShow)
import Effect.Ajax (ajax, AjaxError)
import Data.Either (Either(..))

main :: Effect Unit
main = launchAff_ $ do
  result <- ajax { url: "/api/data", method: "GET", responseType: "json" }
  case result of
    Left err -> logError $ "Request failed: " <> show err
    Right resp -> logShow resp

This snippet shows the typical workflow: launchAff_ starts the computation in the JavaScript event loop, ajax returns an Aff (Either AjaxError a), and the do‑notation binds the result while preserving error information.

Using Effect for a simple console log

module Main where

import Effect (Effect)
import Effect.Class.Console (log)

main :: Effect Unit
main = log "Hello from Effect"

Here no asynchronous behavior is needed; the Effect monad directly performs the side‑effect.

Verification Steps

1. Create a minimal project: spago init.
2. Add dependencies: spago install purescript-aff purescript-dom purescript-ajax (for the Aff example) and ensure purescript-effect is present.
3. Place the Aff example in src/Main.purs, compile with spago build, and open the generated index.js in a browser. Verify that a network request is made and the response appears in the console.
4. Replace src/Main.purs with the Effect example, rebuild, and run. Confirm that the string "Hello from Effect" is printed without any async machinery.
5. Optionally, write a unit test using purescript-affjax and spago test to assert that an Aff computation yields a Right value on success.

Limitations and Practical Checks

• Aff computations are cold: they do nothing until launched with launchAff_ (or similar). Forgetting this results in a silent no‑op.
• When mixing Aff with raw JavaScript promises, convert via Aff.fromPromise or Aff.tryEither to avoid unhandled rejections.
• Parallel combinators assume commutative effects; using them with non‑commutative DOM writes can cause race conditions.
• To check that an Aff computation actually ran, attach a side‑effect (e.g., a console log) inside the do block and verify its output.