nandi (Dec 26 2025 at 22:54): nandi (Dec 26 2025 at 22:54):https://github.com/lukewilliamboswell/roc-htmx-playground/pull/12
Luke Boswell (Dec 27 2025 at 00:39):Thank you.
Hopefully we can upgrade to the new compiler soon. Just need to get our rust platforms like basic-cli and basic-webserver upgraded first :smiley:
Alec Gargett (Jan 23 2026 at 00:27):Has anyone here checked out Datastar?
Luke Boswell (Jan 23 2026 at 00:30):Looks pretty cool
Luke Boswell (Jan 23 2026 at 00:31):I've been working on a roc-dom platform in my spare time.
Luke Boswell (Jan 23 2026 at 00:32):Datastar could be a nice package to go with basic-webserver
Rick Hull (Jan 23 2026 at 00:46):I have long been interested in HTMX (javascript-hater). Carson Gross is giving a talk alongside Richard in July in Missouri #off topic > Conference Suggestions . I looked at Datastar as an alternative. I was trying remember its name, in the shower this morning. All I could think of was "WS-deathstar", back in the SOAP/REST holy wars with Ryan Tomayko
Alec Gargett (Jan 23 2026 at 00:59):From what I understand, it's a smaller library that gives you more power than htmx by putting even more of the logic and control for http on the server-side, using the more flexible approach of SSE and declarative signals that allow it to replace htmx, Alpine, React etc.
The creator isn't as good at meme-marketing and is more disagreeable on twitter, but I think it's a better tech, especially for a non-JS framework or web server where you want to allow people as much as flexibility as possible and to do as much as possible in your server-side language.
Rick Hull (Jan 23 2026 at 01:13):Yes -- I think there is a "culture" aspect to both communities -- but HTMX was first so I am partial, but I am a big fan of "second system syndrome" where the following system is technically better.
Alec Gargett (Jan 23 2026 at 01:46):I think the internal culture of the datastar community is great. Delaney just gets in disputes on twitter with React and htmx people, and prolongs them, which Carson avoids better.
And yeah Delaney was an htmx dev who left because he was frustrated with the limitations. Carson even acknowledged at one point that datastar is "probably the better approach".
Alec Gargett (Jan 26 2026 at 22:30):Luke Boswell said:
Datastar could be a nice package to go with basic-webserver
Sorry to turn this into a Datastar thread. I'm just obsessed with Datastar and I think it's awesome that you're working on this type of thing. If you wanted to give it a try you can reach out to Delaney with any questions. He's very helpful with anyone who is open minded. And others on the Datastar discord can help out too.
Just today they completed this one-page version of the tutorial and reference for LLM, search etc: https://data-star.dev/docs
Luke Boswell (Jan 26 2026 at 23:00):I haven't progressed my roc-dom platform much lately... I switched my focus to roc-ray for graphics and working on Roc compiler bugs or tooling upgrades. Only so many hours in the day :sweat_smile:
But definitely looking forward to restarting the front-end web efforts soon - I think after we land the LLVM backend the .wasm modules Roc produces will be tiny again and that will be a good time to revisit this work -- it sill needs some re-engineering to be really usable... I went for the more ambitious approach to implement a VDOM to minimise the traffic across the JS<->WASM boundary.
Luke Boswell (Jan 26 2026 at 23:07):For background @Niclas Ahden has been using his Joy platform https://github.com/niclas-ahden/joy for a while now and shared in the meetup that it's working well.
That uses an API more akin to the Elm architecture.
The roc-dom idea I've been experimenting with is Richard's vision for Action State -- which is a bit different.
Eli Dowling (Jan 27 2026 at 02:00):@Alec Gargett
I'd be interested to know if you've used or considered using inertia.JS?
I've investigated it a little bit, and I've used hotwire which is a lot like htmx and friends.
I think if I wanted a bsckend frontend combo that weren't one of the highly integrated frameworks like sveltekit, it would be my first port of call.
Mainly this is because I feel like all these htmx like libraries don't address the issue of components and scoped css. In a big project, or when adding to a big legacy project I almost always want css localized to a component. For isolation, but also for per page css trimming. Because different parts of the app/site are likely to have different styles.
Also I often want simple components that I can drop anywhere that have inputs and logic and styling combined.
Just my thoughts after having tried hotwire a bunch and determined I'd much rather write svelte than html. Even if it's mostly ssr
Luke Boswell (Jan 27 2026 at 02:28):don't address the issue of components and scoped css
I think this is the main idea behind Action-State -- what would that look like in Roc
Dan G Knutson (Jan 27 2026 at 02:47):Remix (the react version) does a version of scoped css that looked nice to me, although I haven't used it for real. My impression is that the tricks for getting scoped css are kind of orthogonal to the different kinds of state management.
Dan G Knutson (Jan 27 2026 at 02:59):I'd have to re-read the action-state doc, because it's been a while. But I wonder if Roc's open unions plus the new procedural niceties make one of the more event-oriented patterns (like solid/leptos or the sort of manual events they're doing in Remix 3) a potentially good fit.
Actually looking at it again, maybe action-state is kind of like Remix 3? Or has some things in common, anyway. You explicitly choose when to re-render by calling Action.update, and there's no re-renders if you don't say to re-render? If I understand that right, it'd be similar. The lensy thing with Elem.translate looks different. But I wonder if static dispatch changes that API in a way that makes it suddenly look more similar, though.
Alec Gargett (Jan 27 2026 at 03:48):Luke Boswell said:
I haven't progressed my roc-dom platform much lately... I switched my focus to roc-ray for graphics and working on Roc compiler bugs or tooling upgrades. Only so many hours in the day :sweat_smile:
No worries. At some point I will try to implement something very basic in datastar and Roc myself, in a few months at the earliest, like just get the basic SSE function set up, if no one else has already done it by then.
Alec Gargett (Jan 27 2026 at 03:50):@Eli Dowling
I've never heard of it. Thanks for letting me know about it. I'll check it out.
Datastar have a web components integration system (Rocket) and a CSS system in development (Stellar) and they look great but they are part of the paid Datastar Pro.
Alec Gargett (Jan 27 2026 at 03:53):Eli Dowling said:
Alec Gargett
Just my thoughts after having tried hotwire a bunch and determined I'd much rather write svelte than html. Even if it's mostly ssr
When you're using Datastar you are mostly working in your server-side language of choice. I don't think you're doing more html than you would be doing in Svelte, maybe less, but I could be wrong.
Alec Gargett (Jan 27 2026 at 04:05):Dan G Knutson said:
I wonder if Roc's open unions plus the new procedural niceties make one of the more event-oriented patterns (like solid/leptos or the sort of manual events they're doing in Remix 3) a potentially good fit.
I think with all of those tools you'll end up writing less Roc and a lot more Javascript/Typescript, compared to something like htmx and especially datastar, unless you're writing your own plugins for datastar in which case you'll be doing the same.
Of course the functionality isn't exactly the same so it depends what you're doing. But even just the standard free version of Datastar will allow you to control more of the front end behaviour with Roc itself than other systems, so I think it's a good default if you want to do as much as possible of the logic in Roc itself (or whatever your preferred language is).
Dan G Knutson (Jan 27 2026 at 04:12):I think with all of those tools you'll end up writing less Roc and a lot more Javascript/Typescript, compared to something like htmx and especially datastar, unless you're writing your own plugins for datastar in which case you'll be doing the same.
Ah, sorry, what I mean is the state management patterns, not literally using those libraries. Like ways you could implement a Roc-only UI, either for a desktop app or for a compiled-to-wasm frontend webapp. The action-state doc was about a Roc-focused state management pattern for that kind of all-Roc client-side app. I'm curious if stealing the state management patterns from those JS libraries is viable for an all-Roc UI state management system, or if there are already similarities between how they work and the action-state doc.
Alec Gargett (Jan 27 2026 at 04:16):Ah Ok gotcha
Alec Gargett (Jan 27 2026 at 04:19):I think those libraries are trying to get around all of the issues with using so much Javascript in the browser with more Javascript, so if your goal is doing something with wasm it's probably better to just copy whatever Odin developers have been doing.
Alec Gargett (Jan 27 2026 at 04:24):Eli Dowling said:
Alec Gargett
I'd be interested to know if you've used or considered using inertia.JS?
Just had a quick look. Looks neat. I'd need to try it to figure out if it's a good approach. I think I'd prefer to do all of the logic including templating in the backend language and just send html or text, an avoid the JS frameworks altogether, but I guess it depends on your mental model and much you like the framework components vs html components and templating.
Eli Dowling (Jan 27 2026 at 05:12):I find the model of having one system for both frontend interactivity and props/templating is nice.
DataStar obviously provides signals which I imagine helps but in the past I've found thst disconnect frustrating whenever I need to cross into a more interactive frontend component.
Last updated: Feb 20 2026 at 12:27 UTC