The front end framework for correctness: built on Effect, architected like Elm
Posted by plucafs 9 hours ago
Comments
Comment by Etheryte 9 hours ago
Comment by speedgoose 8 hours ago
Perhaps it makes sense for AI agents, but as a human, I will pass.
Comment by zdragnar 8 hours ago
Comment by devinjameson 4 hours ago
Comment by danfritz 9 hours ago
IMO the reset should fire regardless what happens after it.
Comment by airstrike 8 hours ago
Comment by horsawlarway 6 hours ago
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.
Comment by devinjameson 4 hours ago
Comment by devinjameson 4 hours ago
Comment by PaulHoule 5 hours ago
Comment by ivanjermakov 5 hours ago
Comment by curiouskoala 7 hours ago
Comment by devinjameson 4 hours ago
Comment by devinjameson 4 hours ago
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.
Comment by myk9001 5 hours ago
Comment by danfritz 9 hours ago
Comment by SinParadise 8 hours ago
Comment by WorldMaker 6 hours ago
Comment by typesafeJ 2 hours ago
Comment by 1-more 3 hours ago
Styling is all gross, sorry.
Comment by satvikpendem 8 hours ago
Comment by e1g 7 hours ago
Comment by arnejenssen 5 hours ago
Cons: The API surface is huge so there is a steep learning curve.
Comment by te_chris 6 hours ago
Comment by epolanski 8 hours ago
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...
Comment by chamomeal 6 hours ago
Comment by satvikpendem 5 hours ago
Comment by rramon 9 hours ago
Comment by hit8run 8 hours ago
Comment by yewenjie 7 hours ago
Comment by dflock 9 hours ago
Comment by LoganDark 3 hours ago
https://webcontainers.io/guides/browser-support
Is this using a different WebContainers?
Comment by lxe 8 hours ago
Comment by css_apologist 8 hours ago
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
Comment by 1-more 3 hours ago
- 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.
Comment by epolanski 8 hours ago
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.
Comment by Exoristos 3 hours ago
Comment by oofbey 9 hours ago
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.
Comment by dflock 9 hours ago
Comment by Multicomp 7 hours ago
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!)
Comment by triyambakam 8 hours ago
Comment by whattheheckheck 9 hours ago
Comment by hnsmomdpvp 8 hours ago
Comment by hey_lalit 6 hours ago