I don’t know if it’s just me, but I find Typescript written with Effect somewhat hard to grok.
It sounds like an interesting project but when I look at the Without Effect and With Effect code samples on https://effect.website, my immediate reaction is that I’ll take the Without Effect version.
From this post, it seems somewhat nice that the final “effect” of a chain of actions is hoisted up to the top and you can see what it returns if it succeeds or fails.
const success: Effect.Effect<number, never, never> = Effect.succeed(42)
const fail: Effect.Effect<never, Error, never> = Effect.fail(
new Error("Something went wrong")
)
But those chains of pipes… That doesn’t seem to be the most readable to me.
My ears definitely perk up at the mention of structured concurrency (I wrote a blog post about it in Rust).
From looking through the website a bit, I was missing some of the “why” for this approach though. This blog post explains it more, but I’m still not sure how big of an issue this is in TS/JS land: https://frontside.com/blog/2023-12-11-await-event-horizon/
For me, the problem reduces down to async flow control and structured concurrency is a fantastic way to manage it. This is why structured concurrency is such a great tool for TS since the node/browser is single-threaded and requires strong concurrent tooling. It’s a great fit.
I agree. The pitch of “the missing standard library for TypeScript” is extremely off-putting. I can imagine balls of spaghetti code because Effect is neither a standard nor a language. That positioning is going to mean that everybody invents best practices and it’ll be used either too much or too little.
I’d love to see an effect system in TS but it needs to be language level for it to be practical.
So I’ve been learning RxJS (in TypeScript). Effect looks interesting in that it seems to support async and promises better. In theory I like that it adds typing for errors and effects, but the code examples on that page are even more tangly than what I’ve been getting used to with RxJS, so the complexity might not be worth it for me.
I love functional programming, which is why I shared this article. I really wanted to like all kinds of FP things in JavaScript, which is my workaday language: Elm (which I started a local meetup for some years back), Ramda, Kefir, Bacon, PureScript, RxJS, and others. However, I think these frameworks, tools, and languages are usually working “against the grain” of the language, creating more work than eliminating it. Interop is usually not great, and that is often what writing JavaScript is all about. Unfortunately, like so many modern languages, JavaScript is perched firmly on the fence of multiparadigmaticism. That means there are a few FP things (like functions as values) and things that are decidedly not (mutability by default, prototypal inheritance, class inheritance sugar on top of prototypal inheritance, and a high degree of imperative code in most projects).
I would like to think Effect is some kind of exception. Although I’m saddened to hear you describe it as “tangly,” I’m not surprised. I think Zod is the only FP-heavy JavaScript library I’ve used and haven’t felt something similar, perhaps because it limits itself to parsing and schemas, which is a nice niche in TypeScript, particularly. Personally, I keep coming back to libraries like these because they’re an interesting way to better understand properly FP languages, ponder what I value in programming language design, and occasionally adapt some practical architectural patterns where I can.
For what it’s worth, if you want to build something complex in JavaScript that runs in the browser, you could do worse than Vue, particularly if you keep your state centralized (e.g. with Pinia). You can even use the reactivity without the framework (@vue/reactivity). Vue’s is the only reactivity model that hasn’t felt like it’s fighting against the underlying language. Even if the contents of one’s functions in Vue are imperative, they hang together relatively declaratively.
I’m hoping someone with more Svelte experience will jump in. In the absence of an expert, I would suggest not. This is kind of a hard-core functional programming library. One of the decisions it imposes on its users is immutable data structures. Whether that makes sense in JavaScript is debatable. I think this library could be really interesting—practical, even—in a context where there either is no existing reactivity model or where the reactivity model is built on immutability, such as React. Svelte has a (compile-time?) reactivity model that, in the past at least, was designed around mutable values. Things may have changed a bit with Svelte 5 and “runes,” but as far as I can tell, it’s still a mutable idiom. Bridging the gap between a mutable idiom and an immutable one is cumbersome and costly.
I don’t know if it’s just me, but I find Typescript written with Effect somewhat hard to grok.
It sounds like an interesting project but when I look at the Without Effect and With Effect code samples on https://effect.website, my immediate reaction is that I’ll take the Without Effect version.
From this post, it seems somewhat nice that the final “effect” of a chain of actions is hoisted up to the top and you can see what it returns if it succeeds or fails.
But those chains of pipes… That doesn’t seem to be the most readable to me.
You might be interested in effection which tries to accomplish similar goals but look like vanilla JS: https://frontside.com/effection/
There’s also https://starfx.bower.sh which builds off of it and is used in the FE.
Very interesting!
My ears definitely perk up at the mention of structured concurrency (I wrote a blog post about it in Rust).
From looking through the website a bit, I was missing some of the “why” for this approach though. This blog post explains it more, but I’m still not sure how big of an issue this is in TS/JS land: https://frontside.com/blog/2023-12-11-await-event-horizon/
Nevertheless, it does seem nice that it seems to be using slightly more built-in constructs: https://frontside.com/effection/docs/async-rosetta-stone
Great insight, I tried to answer that question here: https://bower.sh/why-structured-concurrency
For me, the problem reduces down to async flow control and structured concurrency is a fantastic way to manage it. This is why structured concurrency is such a great tool for TS since the node/browser is single-threaded and requires strong concurrent tooling. It’s a great fit.
That’s something that would need to be fixed on the language level. ts-effect can’t do much here.
I agree. The pitch of “the missing standard library for TypeScript” is extremely off-putting. I can imagine balls of spaghetti code because Effect is neither a standard nor a language. That positioning is going to mean that everybody invents best practices and it’ll be used either too much or too little.
I’d love to see an effect system in TS but it needs to be language level for it to be practical.
Yeah, I could barely get something written. No chance I’d get anybody else to read or write this stuff.
So I’ve been learning RxJS (in TypeScript). Effect looks interesting in that it seems to support async and promises better. In theory I like that it adds typing for errors and effects, but the code examples on that page are even more tangly than what I’ve been getting used to with RxJS, so the complexity might not be worth it for me.
I love functional programming, which is why I shared this article. I really wanted to like all kinds of FP things in JavaScript, which is my workaday language: Elm (which I started a local meetup for some years back), Ramda, Kefir, Bacon, PureScript, RxJS, and others. However, I think these frameworks, tools, and languages are usually working “against the grain” of the language, creating more work than eliminating it. Interop is usually not great, and that is often what writing JavaScript is all about. Unfortunately, like so many modern languages, JavaScript is perched firmly on the fence of multiparadigmaticism. That means there are a few FP things (like functions as values) and things that are decidedly not (mutability by default, prototypal inheritance, class inheritance sugar on top of prototypal inheritance, and a high degree of imperative code in most projects).
I would like to think Effect is some kind of exception. Although I’m saddened to hear you describe it as “tangly,” I’m not surprised. I think Zod is the only FP-heavy JavaScript library I’ve used and haven’t felt something similar, perhaps because it limits itself to parsing and schemas, which is a nice niche in TypeScript, particularly. Personally, I keep coming back to libraries like these because they’re an interesting way to better understand properly FP languages, ponder what I value in programming language design, and occasionally adapt some practical architectural patterns where I can.
For what it’s worth, if you want to build something complex in JavaScript that runs in the browser, you could do worse than Vue, particularly if you keep your state centralized (e.g. with Pinia). You can even use the reactivity without the framework (
@vue/reactivity). Vue’s is the only reactivity model that hasn’t felt like it’s fighting against the underlying language. Even if the contents of one’s functions in Vue are imperative, they hang together relatively declaratively.i wanted to understand if using something like https://tanstack.com/query/latest/docs/framework/svelte/overview (tanstack query) is useful when using something like effect. Some usecases seem overlapping, does it make sense in trying to make use of both?
I’m hoping someone with more Svelte experience will jump in. In the absence of an expert, I would suggest not. This is kind of a hard-core functional programming library. One of the decisions it imposes on its users is immutable data structures. Whether that makes sense in JavaScript is debatable. I think this library could be really interesting—practical, even—in a context where there either is no existing reactivity model or where the reactivity model is built on immutability, such as React. Svelte has a (compile-time?) reactivity model that, in the past at least, was designed around mutable values. Things may have changed a bit with Svelte 5 and “runes,” but as far as I can tell, it’s still a mutable idiom. Bridging the gap between a mutable idiom and an immutable one is cumbersome and costly.