Newest at the top
| 2025-03-01 01:06:16 +0100 | <haskellbridge> | <Liamzee> also this is basically what i was looking for, oh well |
| 2025-03-01 01:06:10 +0100 | <haskellbridge> | <Liamzee> https://en.wikipedia.org/wiki/Isomorphic_JavaScript |
| 2025-03-01 01:02:43 +0100 | <haskellbridge> | <Liamzee> tbh with CPP, you don't actually need Haskell |
| 2025-03-01 01:02:15 +0100 | <haskellbridge> | <Liamzee> but the entire point is so that you're building full stack in one module, one module at a time |
| 2025-03-01 01:02:05 +0100 | <c_wraith> | But it involves a lot of manual work, and a good platform would have a better abstraction for that. |
| 2025-03-01 01:01:42 +0100 | <c_wraith> | You can put platform-specific stuff in separate trees and conditionally include those trees depending on platform in cabal |
| 2025-03-01 01:01:14 +0100 | <c_wraith> | You can do better than that |
| 2025-03-01 01:01:07 +0100 | <haskellbridge> | <Liamzee> you could hack it with CPP, i suppose |
| 2025-03-01 01:00:18 +0100 | ell | (~ellie@user/ellie) ellie |
| 2025-03-01 00:59:44 +0100 | <c_wraith> | They have to have built before that. |
| 2025-03-01 00:59:36 +0100 | <c_wraith> | Only at link time |
| 2025-03-01 00:59:26 +0100 | <haskellbridge> | <Liamzee> no, but if the functions aren't used at all, shouldn't they be excluded from the binary? |
| 2025-03-01 00:58:48 +0100 | <haskellbridge> | <Liamzee> ah, yes, i see what you mean |
| 2025-03-01 00:58:45 +0100 | <c_wraith> | so... different dependencies on each target? |
| 2025-03-01 00:58:33 +0100 | <haskellbridge> | <Liamzee> libraries |
| 2025-03-01 00:58:21 +0100 | <c_wraith> | Well then, you need to have different dependencies on each target |
| 2025-03-01 00:58:07 +0100 | <c_wraith> | No? |
| 2025-03-01 00:58:03 +0100 | yegorc | (~yegorc@user/yegorc) () |
| 2025-03-01 00:58:00 +0100 | <c_wraith> | Do you want to compile the postgres driver into your frontend? |
| 2025-03-01 00:57:00 +0100 | <c_wraith> | that doesn't work when you have to compile eagerly |
| 2025-03-01 00:55:45 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-03-01 00:55:30 +0100 | <haskellbridge> | <Liamzee> data Object = MkObject {frontend :: FrontEnd, client :: ClientCode, backend :: BackEnd} |
| 2025-03-01 00:55:14 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-01 00:54:08 +0100 | <c_wraith> | doing that was a major pain point when I tried it out |
| 2025-03-01 00:53:37 +0100 | <c_wraith> | obelisk also needed a better story for server-side services - a way to say "this calculation needs to run on the server. If this is a client, make a remote call" |
| 2025-03-01 00:53:25 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2025-03-01 00:52:32 +0100 | <c_wraith> | But yeah, being dependent on ghcjs definitely hurt it |
| 2025-03-01 00:52:16 +0100 | <c_wraith> | there's still room for something like obelisk when the new JS backend for GHC stabilizes |
| 2025-03-01 00:51:48 +0100 | <haskellbridge> | <Liamzee> thanks for the discussion! |
| 2025-03-01 00:51:19 +0100 | messewix | (~jmc@user/messewix) messewix |
| 2025-03-01 00:50:52 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-01 00:49:12 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Ping timeout: 252 seconds) |
| 2025-03-01 00:47:44 +0100 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 252 seconds) |
| 2025-03-01 00:46:45 +0100 | Sgeo__ | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-01 00:44:40 +0100 | Sgeo_ | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-01 00:44:29 +0100 | <haskellbridge> | <Liamzee> the reflex package was also updated last month |
| 2025-03-01 00:41:26 +0100 | Googulator79 | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) |
| 2025-03-01 00:41:13 +0100 | Googulator79 | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-03-01 00:41:03 +0100 | <haskellbridge> | <Liamzee> obsidian does direct work, but they also got screwed by being bound to 8.8 because of the old GHCJS being abandonware |
| 2025-03-01 00:40:34 +0100 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/reflex |
| 2025-03-01 00:39:28 +0100 | <haskellbridge> | <Liamzee> actually they're doing better than i remembered |
| 2025-03-01 00:37:42 +0100 | <geekosaur> | not sure I'd call them mistakes considering their website suggests they have a decent number of commercial users |
| 2025-03-01 00:37:29 +0100 | <haskellbridge> | <Liamzee> also iirc Obsidian had a business model of providing support for users, which isn't good for uptake |
| 2025-03-01 00:36:28 +0100 | <haskellbridge> | <Liamzee> being lens/optics-based makes it dumb enough for commodity programmers, being cabal-based means that you don't require learning nix on top of everything else |
| 2025-03-01 00:36:00 +0100 | <haskellbridge> | <Liamzee> overloaded the novelty budget |
| 2025-03-01 00:35:56 +0100 | <haskellbridge> | <Liamzee> i'd see reflex's mistakes as being, #1, nix-bound, #2, FRP |
| 2025-03-01 00:35:41 +0100 | <haskellbridge> | <Liamzee> reflex received an update in january |
| 2025-03-01 00:35:27 +0100 | remexre | (~remexre@user/remexre) remexre |
| 2025-03-01 00:35:07 +0100 | <geekosaur> | one would think so, but then one must ask why only obelisk did so and it's pretty much dead. I wonder if there's a "lessons from" somewhere |
| 2025-03-01 00:33:05 +0100 | <haskellbridge> | <Liamzee> but is my hunch correct, that, say, there is value in being able to define your frontend and your backend at the same time? |