Effection: structured concurrency for JavaScript without the ceremony

The problem is resources outliving the code that made them

Effection is described as structured concurrency and effects for JavaScript, and the argument for it is about leaks. The README says Effection leverages the idea of structured concurrency to ensure that you do not leak any resources and effects, and that cancellation is always properly handled. The idea comes from other languages: a child task cannot outlive the scope that spawned it, and when the scope ends, everything inside it is torn down. In JavaScript the equivalent failure is an event listener that outlives the component, a timer that fires after teardown, an abort signal nobody aborted, or a promise chain that keeps a request alive after the user has moved on. The pitch includes the claim that it helps you build concurrent code that feels rock solid at scale while feeling like normal JavaScript, and that last clause is the whole design constraint.

Effects are the unit, not promises

The word effects does the work in the library's name, and it is a specific concept rather than a vague one. An effect is a computation with a lifecycle: something that starts, may be interrupted, and has a defined cleanup. A promise is a value, and a promise has no notion of being cancelled or of releasing what it acquired. The repository's topic tags name algebraic-effects alongside async-await, concurrency, effects-management and structured-concurrency, so the framing is the algebraic one, where a program is a description of effects to be run rather than a sequence of side effects already performed. That is why the library presents itself as a layer rather than as a promise wrapper, and why the cancellation story is built into the primitive instead of bolted on through an abort signal convention.

One library, three runtimes, two package registries

Effection runs on all major JavaScript platforms including NodeJs, Browser and Deno, and it is published on both npm and deno.land. The dual publication is a deliberate choice rather than an accident of tooling, and it follows from the development setup: Deno is the primary tool used for development, testing and packaging. So the library is written and tested in one runtime and published to two ecosystems, which means the package you install through npm and the one you import from deno.land are the same code with different packaging. The practical consequence for a consumer is that you are not forced into Deno to use it, but you are using a Deno-first project if you fork it. The home page for the project is frontside.com/effection, and the repository is under the Frontside organisation, the consultancy that builds it.

Deno tasks for tests and for a development npm build

Running the tests is a single Deno task.

$ deno task test

Building a development version of the npm package, so you can link it locally, uses the build:npm script with a version number.

$ deno task build:npm 3.0.0-mydev-snapshot.0
Task build:npm deno run -A tasks/build-npm.ts "3.0.0-mydev-snapshot.0"
[dnt] Transforming...
[dnt] Running npm install...

up to date, audited 1 package in 162ms

found 0 vulnerabilities
[dnt] Building project...
[dnt] Emitting ESM package...
[dnt] Emitting script package...
[dnt] Complete!

The built npm package ends up in the build/npm directory. The output shows the packaging tool, dnt, transforming the Deno-style source into npm-compatible ESM and script packages, which is the step that makes a Deno-first library consumable by a normal Node project.

The repository shape and the version split

The top-level listing shows a Deno project: a deno.json at the root, a mod.ts as the entry point, a lib directory for the implementation, a test directory, a bench directory, a lint directory, tasks for the build scripts, and docs for the documentation. There is also an experimental.ts, which is the usual name for an entry point that exposes unstable APIs, and www for the website, with a separate section in the README for contributing to the website. The version story needs care. The default branch of the repository is v4, and the recent releases listed are effection-v3.0.2, effection-v3.0.1 and effection-v3.0.0, all published on the same day in February 2024. So the published 3.x line and the v4 branch are different things, and the README's build example passes a 3.0.0 prefixed version, which tells you which line the npm build task is geared towards.

Where Effection is the wrong choice

Four limits apply. It is an abstraction over concurrency, and an abstraction over concurrency has a cost in readability: a reader who does not know the library has to learn the effect model before they can follow the control flow, and the claim that it feels like normal JavaScript is the developer's claim rather than a property you can verify from the source. The versions are unsettled, with a v4 branch and published 3.0.x packages, so pinning a dependency means pinning a major line that may still move. The package is a single library rather than a set of small ones, so adopting it is adopting its whole opinion about effects. And the effect implementations it offers are the ones it ships, so if your effect is unusual, or if you need one from the ecosystem, the library may not cover it and you are back to managing lifetimes by hand.

Editorial conclusion

Use Effection when you have concurrent JavaScript where the lifetime of a resource, a subscription or a request does not match the lifetime of the function that created it, because the library gives you a scope that ties those together. Do not reach for it if your concurrency is a handful of promises you already understand, because the abstraction costs something in readability. Verify first which major version you are targeting, since the repository's default branch is v4 while the published packages on npm are the 3.0.x line, that your runtime can run the library, since Deno is the primary development tool but the packages are published for the others, and that the effect implementations you need exist in the right package, since the repository now names a family of EffectionX packages.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thefrontside/effection on GitHub