Effect fixes your TypeScript · Part 12
When you should NOT use Effect
The honest one. For a 50-line script, plain TypeScript wins. Effect pays for itself when you have errors to handle, concurrency to limit, resources to close or services to swap. Adopt it at the edges first.
Comment below: Would you use Effect at work? Tell me why, or why not.
Effect fixes your TypeScript: a series on the bugs you already ship, and how Effect makes them impossible. All code is real Effect v4 and was compiled before it went on screen. https://effect.website
Transcript
Don't use Effect. Sometimes. 11 parts in, here's the honest one. A 50-line script, plain TypeScript wins. Effect has a learning curve. Generators, services, layers, schedules. Your whole team has to read it, not just you. And on a tiny front end, it's one more dependency to justify. Where it wins. Errors you need to handle. Concurrency you need to limit. Resources you need to close. Services you need to swap. If your code does two of those, Effect pays for itself, and you don't need to rewrite anything. Effect and promises work both ways. Best practice. Adopt it at the edges first. One service, one boundary. That's the series. Would you use Effect at work? Tell me why, or why not.
