Effect.ts: Absence as First-Class

Philosophy • Lesson 24 of 51

24. Frontend Reality Check

Why Effect might be overkill for most frontend code

Code Example

// Typical frontend code:
async function handleSubmit() {
  setLoading(true);
  try {
    const result = await api.submitForm(data);
    showSuccess(result);
  } catch (error) {
    showError(error);
  } finally {
    setLoading(false);
  }
}

// This is fine! The HOW is simple:
// - Just wait for the network
// - Show success or error
// - Done

// Effect version would add ceremony
// without much benefit:
const handleSubmit = Effect.gen(function* () {
  // ... more code for same thing
});

Interactive Example

const output: string[] = [];
output.push('Frontend: Simple async is often enough');
output.push('');
output.push(' Use Effect when:');
output.push('  • Complex error handling');
output.push('  • Multiple retry strategies');
output.push('  • Dependency injection needed');
output.push('  • Backend/CLI apps');
output.push('');
output.push(' Skip Effect when:');
output.push('  • Single API call');
output.push('  • Simple try/catch is fine');
output.push('  • UI framework handles complexity');
output.push('');
output.push(' Don't cargo-cult!');
return output.join('
');

Explanation

Frontend: when absence-first is overkill.

Most frontend code:

Simple unavailability (one API call)
One HOW (fetch, handle error, done)
UI framework manages the complexity
Making assumptions is OKAY here

Effect shines when:

Complex absence (many services)
Multiple HOWs (retry, timeout, fallback, parallel)
Backend/CLI (no UI to hide complexity)

Don't cargo-cult! Absence-first is powerful but not always needed.

Part 24 of 51 in the Effect.ts Absence Modeling series

←→