KRkreyenborgi·Dec 29, 2025
Apparently no relation to the functional reactive web framework https://github.com/obsidiansystems/obelisk
In Obelisk 0.32: Cancellation, WebAPI, Postgresobsidiansystems
obelisk
Haskell2018–2025
obsidiansystems / obelisk
obelisk
Functional reactive web and mobile applications, with batteries included.
4Distinct people
12Mentions
1Explicit recommenders
1KGitHub stars
What to know before exploring
What it is
Functional reactive web and mobile applications, with batteries included.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
Sure. So I've spent a lot of time working with FRP things, e.g. with https://hackage.haskell.org/package/reflex with the github.com/obsidiansystems/obelisk/ web framework.…
Ericson2314 used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year12 dated mentions
Observed mentions: 2018-06-06 03:27:53 UTC to 2025-12-29 22:27:54 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
12 sourcesThe problem with this is this is that it assumes the programming language is the last world in the developer experience.
I am certainly a language person, and you cannot get anywhere with a bad language, but merely having a good language is not enough.
Working on github.com/obsidiansystems/obelisk/ we have very very many things we would like to work on, but not super much of it involves "adding new features" to Haskell. And yet the libraries are so richly layered e.g. the frontend feels more different from regular effectful code in Haskell, than regular effectful code in Haskell feels different from that in other languages.
The one feature we would like in Haskell is arguably a "removing the weaknesses and restrictions that make additional features appear necessary" thing, which is something like https://github.com/conal/concat and https:
Read the rest
//arxiv.org/abs/1007.2885. This would be a way to make some categorical DSL stuff less annoying to write because you have to make it point-free.
Sure. So I've spent a lot of time working with FRP things, e.g. with https://hackage.haskell.org/package/reflex with the github.com/obsidiansystems/obelisk/ web framework. While FRP was sort of deemed to hard / a dead end in the early 2020s, it works well for me, and I still consider it viable.
I dislike effects because superficially they are about similar problems ("My whole-program needs side effects") but no amount of effects system stuff is going to ever get you to anything like FRP. In particular, the eeffects mind seems to be pretty narrow, something like:
"I have a bunch of regular-seeming code that does some 'extra stuff', and I need to manage those extra capabilities in a modular way that respects the principle of least authority."
By contrast, the FRP approach rejects the premise that:
- The programs basically look more or less
Read the rest
"normal", but with (good) restrictions on what you can do
- The effects are something "side" or "extra".
It's hard to say exactly what it is about instead, but some guidelines might be:
- Don't just decompose a program into terminating parts (like terminating callbacks + magic event look). Embrase non-termination (well, co-termination), and think of new ways to be modular that don't carry over from terminating whole programs.
- Think in terms of "flows", be like a plumber. Try to directory program the steady state in terms of the large scale architecture, and not a regular functional--imperative program that "carries out" out the flows as a spec.
- - Actor-model-type stuff is wrong for focusing on the "nodes not edges". We should have simple components but rich networks.
- Try to find structure not in the effects themselves, but how you intended to use them. If the effects form sinks/sources, then have them be pipeline end pieces that compose just like the the pure middle pieces.
- Calculus is good for programming, after all. Time derivatives / time integrals are at very least good metaphors. We should all go learn more Control Theory for more things than "memory pressure".
I hope this helps.
No ...but
I use github.com/obsidiansystems/obelisk/ at work (I work at the place that makes it). It does it's own thing for user-visible routes (for frontend and backend because automatic prerendering). It does a different thing for requests and live queries all of which are over websockets for simplicity.
Our routes stuff should be pulled out as a generic dual parsing-prettyprinting library (it and https://hackage.haskell.org/package/tomland are the same basic ideal, just need to remove the concrete HTTP / TOML specifics to get to the commonality).
I once started throwing together like servant but using data kinds in https://github.com/ericson2314/matrix-client
In Real World HaskellAt work we make and use https://github.com/obsidiansystems/obelisk . While they're are certain framework-y things going on (we recommend our build system, our `ob` swift army knife command, etc.) nothing is obligatory and all the functionality is in separately libraries, and put effort to "bud off" ideas into separate repos etc.
I bring this is up as I think it's a good example of firstly absolutely not compromising on the end developer experience to compete with the monolithic framework, but secondly trying to beat them without stooping to their dirty tricks wherever possible.
In Prologue: Full-Stack Web Framework Written in NimReading stuff like this gets me hopeful that https://github.com/obsidiansystems/obelisk/ (from where I work) will be able to reach a wider audience. The author is right that the React ecosystem doesn't deliver what it claims to, but I think is overly pessimistic that the use-cases he describes are too diverse to be solved by a single solution.
In Second-Guessing the Modern WebYes it certainly does https://github.com/obsidiansystems/obelisk
[Disclaimer, I work at the company behind this.]
In Developing GHC for a LivingSo I'm sure lots of people will think that this definitely doesn't qualify as "Best language to share code...", but Haskell has stuff for getting web, desktop, iOS, and Android out of one code base. It's called Obelisk (https://github.com/obsidiansystems/obelisk) and it's actually getting to be a pretty good development experience.
In Ask HN: Best language to share code between an Android and iOS app?The "we" is I work at the company founded by the creator of reflex. I have no idea what is a good Beginning Haskell resource, honestly. I don't really remember but I think I mainly googled random bits of information on an as-needed / as-curious basis.
Most people use reflex for writing web frontends, and for that we have the very "batteries included" https://github.com/obsidiansystems/obelisk/ . If you want to dive into a well-blazed trail, I recommend that.
In The Incremental MachineGHCJS is mature enough to write production frontend apps in Haskell. JavaScript is not required.
Try: https://github.com/obsidiansystems/obelisk
Example app: https://github.com/srid/Taut
In Flutter and Chrome OSYou can use Haskell to do the things Elm does (and more, like deploying to mobile). Checkout reflex and obelisk:
http://docs.reflex-frp.org/en/latest/
https://github.com/obsidiansystems/obelisk
In Advice for Haskell beginners (2017)Miso is great. Also checkout reflex; and the recently open-sourced https://github.com/obsidiansystems/obelisk
In Ask HN: Are you working on interesting technical problems?