Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The front end framework for correctness: built on Effect, architected like Elm

foldkit.dev

Post reply on HN
Print view View original

41–50 of 53 posts

Re: The front end framework for correctness: built on Effect, architected like Elm

#41

Post by devinjameson »

zdragnar wrote: post #16
speedgoose wrote: post #15

Earlier quoted context omitted.

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 :)

Re: The front end framework for correctness: built on Effect, architected like Elm

#44

Post by 1-more »

css_apologist wrote: post #20
lxe wrote: post #14

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.

Re: The front end framework for correctness: built on Effect, architected like Elm

#45

Post by Exoristos »

epolanski wrote: post #18

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.

Re: The front end framework for correctness: built on Effect, architected like Elm

#49

Post by Franzkier »

chamomeal wrote: post #27
epolanski wrote: post #19

Earlier quoted context omitted.

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'v…

T3? Isn’t T3 just a TRPC boilerplate kinda thing?

T3Code* (and it's FLOSS)

Re: The front end framework for correctness: built on Effect, architected like Elm

#50

Post by dalmo3 »

devinjameson wrote: post #39
curiouskoala wrote: post #22

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 be…

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.

Post reply on HN