I don't know, as far as I can tell the demo on the homepage is bugged? Or maybe I misunderstand how it's supposed to work? If I click reset after 2 seconds and then click add 1 right after it, the reset never fires. What's up with that, that's not what I expected to happen?
I guess it comes from the `tagsExhaustive` keyword. But I tried to search what it does in the documentation, and it doesn't return any hit. I then searched in the git repository and found it in some examples and CLAUDE.md but it doesn't really seem straightforward.
Perhaps it makes sense for AI agents, but as a human, I will pass.
Yeah, I can see how some scenarios might want that behavior, but it sort of defeats the purpose of the demo. It wouldn't hurt to have the reset be cancelable too if you wanted to really showcase how it should work
The project seems super interesting and I've been following since the creator went on an effect podcast I listened to. My only gripe/concern is the fact that the docs are so glaringly AI (likely claude) generated which is something I've come to not expect from technical documentation writing specifically. All in all though, the verbosity tradeoff for explicit design choice here is the right one and I think it does better than elm by remaining in javascript land rather than building a nicer abstraction layer on top that often needs to reach in to do interesting things with the web apis.
It took me 3 months to go from “I will never use it” to “I will never not use it”. Plus it’s always fun to watch the creators of Effect get confused about which brackets to where. The syntax is archaic, luckily we don’t write syntax by hand any more.
I use it from years, it's the only sane way to write typescript.
The learning curve is steep tho.
In any case it's a hard technology to sell, you don't appreciate it from hello worlds. In fact you hate it for trivial programs.
It shows it's benefits at scale.
Lots of tools like T3 and opencode use it at their core because they solve non trivial problems made of queues, retries, dependency injection, schemas, etc.
Just wondering how a matching backend framework for correctness would look like. Ideally something that doesn't repeat the React mess with two routers but fits right in Inertia style.
Maybe a bit late to ask but how would an EffectTS backend integrate seamlessly? Im looking for a full stack agent driven workflow including domain modeling, designing state machines (with Xstate or SCXML?) etc.
Is it just me? But every time I use a paradigm of global immutable state, almost always I run into edge cases where practically it falls apart either semantically (mental model explosion) or creates performance issues, whether they stem from architectural problems with the framework itself, or just the way computers operate.
- Elm CSS and even then, it was on a page with I think hundreds of accordions. We had to use Css.Global to create class based states, then toggle classes.
- Loading a massive library of data and leaving it in the state to make navigation within that library's pages faster. It was a classic tradeoff of upfront vs incremental load time, and we'd just over indexed in one direction.
I love both effect and elm, but I cannot swallow yet another Vue/React crap even if it adds effect niceties.
Especially after having used ruby and elixir extensively after years of react/Vue, it feels so backwards (and LLM unfriendly) to split front and backend unless you have gargantuan reactivity needs (you don't).
I wish JS offered just one proper server side focused frontend solution.
Given their heads, most clients / product owners drift toward not just major reactivity but real-time. A lot of us work for others, under barrages of feature requests, and Effect and other tools (which may seem like overkill) can reveal themselves as a very practical lifeline.
As agentic coding matures, this kind of project is the right direction. The mechanics of writing the code become less important. But having a language framework that naturally resists mistakes will become increasingly useful and important.
Similar to how Rust is obviously a better choice today than C++. Who cares if the language is “more difficult” to code in, if the agents are doing the coding. What we need is building blocks that make it harder to author bugs.
That's an interesting - and maybe correct - point. Looking at the examples, it seems very long winded and not something I would want to write myself - but maybe I don't need to care about that anymore, as you say!
This time around in the pre-covid days, F# had a surge of popularity, there was Fable and Giraffe and an elm-style set of frontends (the generic pattern is called MVU - Model View Update), it didn't take off because A) we are still a trend/fad-driven industry and B) there was no AI to help hold your hand in refactoring all of your apps.
These days? Doing this FE SPA framework for Effect/typescript familiarity or Fable for F# familiarity and a model-view update pattern can help one do CQRS better, force you to think about stronger Hexagonal Architecture patterns, and overall help your application care about long term correctness more without you having to hand code every discriminated union as such.
The LLM can't replace you, but it can be an enzyme that lowers the activation energy required to switch from bad old MVC mutable tag soup to MVU frontends with strong data interface designs held in sqlite-dbs-per-aggregate (if you are of a DDD or event sourcing taste, which this pattern does not require!)
I was thinking about agentic coding as well and a few years ago I probably would have really been interested in this project. But now it sits at a lower abstraction where I care less since the agent is the one managing it. It's strange
I don't know, as far as I can tell the demo on the homepage is bugged? Or maybe I misunderstand how it's supposed to work? If I click reset after 2 seconds and then click add 1 right after it, the reset never fires. What's up with that, that's not what I expected to happen?
I guess it comes from the `tagsExhaustive` keyword. But I tried to search what it does in the documentation, and it doesn't return any hit. I then searched in the git repository and found it in some examples and CLAUDE.md but it doesn't really seem straightforward.
Perhaps it makes sense for AI agents, but as a human, I will pass.
The whole setup reminded me of the mess people would make with RxJS, and this comment chain seems to indicate it's got the same drawbacks.
Will do my best to make sure that doesn’t happen :)
Yep, it seems that if you hammer messages things get easily dropped or the async behavior is not executed.
IMO the reset should fire regardless what happens after it.
Yeah, I can see how some scenarios might want that behavior, but it sort of defeats the purpose of the demo. It wouldn't hurt to have the reset be cancelable too if you wanted to really showcase how it should work
Agreed - I hit "Reset after 2 seconds", I hit "Add 1", and sure - it adds one, but it also unexpectedly cancels the reset.
Which I don't expect from the description, and I also don't expect from the code.
---
So outside of the simple "This is broken..." feedback, I want to further pick on this example:
Don't fucking hide the imports.
Especially don't fucking hide the imports if you're showing example code, and you're doing things like
```
import { Match as M, Schema as S } from 'effect'
import { m } from 'foldkit/message'
```
Which I only know because I bothered to dig through the example playground counter (which is a different example entirely!)
It's a huge issue to show demo code where concepts magically appear, and it's just bad manners to use shorthand at the same time.
Thanks for the feedback, that’s helpful.
The code didn't look that clear to me. Like bad smell city.
Will take a look at this tonight thanks for the feedback.
It's a framework for correctness, after all :)
The project seems super interesting and I've been following since the creator went on an effect podcast I listened to. My only gripe/concern is the fact that the docs are so glaringly AI (likely claude) generated which is something I've come to not expect from technical documentation writing specifically. All in all though, the verbosity tradeoff for explicit design choice here is the right one and I think it does better than elm by remaining in javascript land rather than building a nicer abstraction layer on top that often needs to reach in to do interesting things with the web apis.
I don’t like it either. Because I have a day job and like sleeping, I have two choices:
a) Actually ship docs, and use AI to help (I also do a ton of hand editing and review cycles)
b) Have poor docs coverage because I’m handwriting everything
I’ve chosen A, but plan to do a few weeks of docs rewrites before I ship 1.0.0. I would rather it sound like me.
I must say that, Claudeisms aside, the flow of the docs is excellent.
I also found the "Counter example" page title amusing.
I’m open about my process.
https://x.com/devinjameson/status/2073452791843131675?s=46
This feels a lot like sagas and redux sagas. Anyone else got that vibe?
Its the same "solved" pattern, but with the pattern being more deeply rooted in a project.
I was feeling similarly: epics with redux-observable but swapping RxJS for Effect.
Oh wow, a new frontend framework! Has nature finally begun healing or something?
How is Effect, for those who have used it? It's good that algebraic effects are becoming more mainstream.
It took me 3 months to go from “I will never use it” to “I will never not use it”. Plus it’s always fun to watch the creators of Effect get confused about which brackets to where. The syntax is archaic, luckily we don’t write syntax by hand any more.
Pros: Effect has explicit errors, and dependency management that gives an awesome DX. I also like the two-way Schemas.
Cons: The API surface is huge so there is a steep learning curve.
I use it from years, it's the only sane way to write typescript.
The learning curve is steep tho.
In any case it's a hard technology to sell, you don't appreciate it from hello worlds. In fact you hate it for trivial programs.
It shows it's benefits at scale.
Lots of tools like T3 and opencode use it at their core because they solve non trivial problems made of queues, retries, dependency injection, schemas, etc.
I've written a vscode extension with it:
https://github.com/dearhuman/effect-decorate/blob/main/src/e...
T3? Isn’t T3 just a TRPC boilerplate kinda thing?
T3Code* (and it's FLOSS)
T3 chat
It’s great and the deep compiler integration means with a skill the agents write it well
The front page example rewritten in Elm, in case you want to compare apples to apples https://ellie-app.com/zqnVHwRJSGpa1
Styling is all gross, sorry.
- i ll take another new frontend AI framework over the AI / LLM chatter anyday
- please more of you start doing this and flood HN with frontend frameworks please
Just wondering how a matching backend framework for correctness would look like. Ideally something that doesn't repeat the React mess with two routers but fits right in Inertia style.
Maybe a bit late to ask but how would an EffectTS backend integrate seamlessly? Im looking for a full stack agent driven workflow including domain modeling, designing state machines (with Xstate or SCXML?) etc.
That is a fair question. Probably one could inspiration by https://github.com/lustre-labs/lustre
Thanks, looks interesting!
This looks interesting, and I've been keeping an eye on this for a while - but does anyone have experience from actually using this for real?
If only I could have the syntactic beauty and brevity of Svelte 4 with the correctness of this <3
Yeah, I think the Effect team tried building a compiler for once (TS++ or something) but they abandoned it, as it was too much work.
Reminds me of Mint Lang https://mint-lang.com/. (The programming language for writing single page applications)
Is it just me? But every time I use a paradigm of global immutable state, almost always I run into edge cases where practically it falls apart either semantically (mental model explosion) or creates performance issues, whether they stem from architectural problems with the framework itself, or just the way computers operate.
its a trade off for sure
but my experience working with elm is that things just work almost always the first time
if they can bring that over, many will take that trade off
yes somethings are harder to express, but its subjective if its a bad thing given the correctness guarantees
i haven't firmly run into the perf ceiling myself, but yes it is obviously there for more interactive apps
My perf ceiling in Elm has been in two places:
- Elm CSS and even then, it was on a page with I think hundreds of accordions. We had to use Css.Global to create class based states, then toggle classes.
- Loading a massive library of data and leaving it in the state to make navigation within that library's pages faster. It was a classic tradeoff of upfront vs incremental load time, and we'd just over indexed in one direction.
Been keeping a close eye on foldkit. Devin is solid and his thinking behind foldkit solid
WebContainers have been available in Safari and Firefox for years. Why does it say I need Chrome?
https://webcontainers.io/guides/browser-support
Is this using a different WebContainers?
I love both effect and elm, but I cannot swallow yet another Vue/React crap even if it adds effect niceties.
Especially after having used ruby and elixir extensively after years of react/Vue, it feels so backwards (and LLM unfriendly) to split front and backend unless you have gargantuan reactivity needs (you don't).
I wish JS offered just one proper server side focused frontend solution.
Given their heads, most clients / product owners drift toward not just major reactivity but real-time. A lot of us work for others, under barrages of feature requests, and Effect and other tools (which may seem like overkill) can reveal themselves as a very practical lifeline.
As agentic coding matures, this kind of project is the right direction. The mechanics of writing the code become less important. But having a language framework that naturally resists mistakes will become increasingly useful and important.
Similar to how Rust is obviously a better choice today than C++. Who cares if the language is “more difficult” to code in, if the agents are doing the coding. What we need is building blocks that make it harder to author bugs.
That's an interesting - and maybe correct - point. Looking at the examples, it seems very long winded and not something I would want to write myself - but maybe I don't need to care about that anymore, as you say!
This time around in the pre-covid days, F# had a surge of popularity, there was Fable and Giraffe and an elm-style set of frontends (the generic pattern is called MVU - Model View Update), it didn't take off because A) we are still a trend/fad-driven industry and B) there was no AI to help hold your hand in refactoring all of your apps.
These days? Doing this FE SPA framework for Effect/typescript familiarity or Fable for F# familiarity and a model-view update pattern can help one do CQRS better, force you to think about stronger Hexagonal Architecture patterns, and overall help your application care about long term correctness more without you having to hand code every discriminated union as such.
The LLM can't replace you, but it can be an enzyme that lowers the activation energy required to switch from bad old MVC mutable tag soup to MVU frontends with strong data interface designs held in sqlite-dbs-per-aggregate (if you are of a DDD or event sourcing taste, which this pattern does not require!)
I was thinking about agentic coding as well and a few years ago I probably would have really been interested in this project. But now it sits at a lower abstraction where I care less since the agent is the one managing it. It's strange
And tla+ / sequence diagram / user flow diagrams / data models all in one "thing"
Finally someone said it