Tobias Steckenborn (Dec 22 2025 at 06:24): Tobias Steckenborn (Dec 22 2025 at 06:24):I assume that platform-specific APIs (for example, macOS-only APIs) could require dedicated (roc) platforms, even if the application provides the (generally) same GUI on both macOS and Windows. Or e.g. if there's a web or mobile release (if that's something event targeted).
Given the platform-oriented approach and the possibility that a codebase will need to be released across multiple platforms, has there been any consideration of an abstracted component library that could be shared across them (potentially including web)?
Luke Boswell (Dec 22 2025 at 07:37):My roc-ray platform provides graphics cross platform using raylib. There has been some discussion using something like Zed's gpui library to make a platform.
A while back Richard Action-State as a different way to do UIs similar to Elm but more suited to Roc.
Luke Boswell (Dec 22 2025 at 07:39):I'd like to start porting roc-ray over early next year to the new compiler'scalling convention. Everything is ready now for that work to start I think.
nandi (Dec 26 2025 at 21:22):was playing with roc-ray today, really cool stuff!
Brendan Hansknecht (Dec 27 2025 at 02:28):I'm a sucker for platforms with graphics. roc-ray and roc-wasm4 are both amazing to me.
Tobias Steckenborn (Dec 27 2025 at 06:59):Where I‘m still a bit curious is how it‘ll play out with just a single platform. Basically you’d need the platform to expose all capabilities you‘re looking for + the respective visualization layer.
That can work out well, or lead to a thousand and one platforms with smaller differences :sweat_smile: that’s why I thought some abstraction layer (such as common components / tokens) might make sense to easier switch them (without having multiple platforms yet that’s challenging to know though)
Brendan Hansknecht (Dec 27 2025 at 07:07):Yeah, I think it will take time but that common abstractions will arise. I would guess first many forks and splits and explorations will be built though.
Karl (Dec 27 2025 at 07:11):Wasm's modules/interfaces are an in-progress take on a very similar problem. I'm interested in what problems they'll run into.
Krzysztof Skowronek (Jan 02 2026 at 16:18):I've been reading a lot about this recently, because I imagined a GUI framework bit like SOLID or LiveView for Elixir
Basically actor system + a view definition that subscribes to one or more actors and uses signals to update the view
I was also thinking about doing something like React Native/UNO platform, where on each platform you could use native components, but that's a dead end. More realistic goal would be to have something like Flutter/Avalonia + cross platform accessibility layer, and do the rendering using something like Impeller or even GPUI from Zed
Krzysztof Skowronek (Jan 02 2026 at 16:22):As for platforms, I believe that we will just end up with a platform that has a FFI function, and this will cover "most" of the issues.
Like for example, let's say you want to use OpenCV - you need FFI for that. But it should be the same whether you are doing a backend service, cli tool or a gui app.
Alternatively, maybe it would be worth considering having a special case for packages like "plugins" that come with already precompiled binaries (kind of like platforms) that are just linked into your app.
There is more examples for this, like SQLite, maybe some database drivers (Snowflake comes to mind - there is a native driver written in Go, that can be used from Rust also)
Brendan Hansknecht (Jan 02 2026 at 16:34):I believe that we will just end up with a platform that has a FFI function
Quite possibly. This definitely could become the standard. That said, it would likely hurt roc style a lot. Everything would be effectful. You would lose the ability to audit what a library can do. It could do anything with FFI.
Brendan Hansknecht (Jan 02 2026 at 16:35):So I think there is a strong precedence in Roc core philosophy that will end up pushing against this compare to properly wrapped apis or things re-implemented in pure roc where possible.
Krzysztof Skowronek (Jan 02 2026 at 16:43):with time, yes. But there is no reason to rewrite a Snowflake driver IMO
or OpenCV
Brendan Hansknecht (Jan 02 2026 at 16:47):Yeah, totally agree. Or many other things. That said, if using them ruins a significant portion of the value of roc, I think the default would be to either move those projects to other languages or port the part you need.
Depends heavily on how pure and testable and clean of a codebase you want (and I expect the general consensis to be high in roc).
Tobias Steckenborn (Jan 02 2026 at 18:00):I think that also will depend on platforms. Are there a few common use case ones, or a flood of very similar but slightly different ones (e.g. around different capabilities with ui lib, with some database, with some web capabilities or without some of them). Time will tell…
Ben Thomas (enkidatron) (Jan 02 2026 at 18:49):This challenge (cross-roc-platform UIs) reminds me of Clay (the C Layout library), by the impressive Nic Barker. That library does the layout logic, but explicitly leaves the actual rendering to a "lower level" library (such as raylib or HTML/CSS). It just needs the rendering library to be able to do things like "draw a rectangle at these coordinates" or "draw this text at these other coordinates" (you know, rendering primitives).
I think that it would be possible to make a nice roc library that only handles the layout of UIs and outputs a series of "rendering primitives" that can then be mapped to the actual rendering commands in the different roc platforms (roc-raylib, something for rendering html, etc). "Components" (carousel, data table, menu, etc) can then be built on top of that layout abstraction layer and provided as their own libraries.
Basically, I think that "layout engine" may be a useful abstraction layer between "rendering engine" (provided by each roc platform, potentially) and "components" (their own roc libraries, potentially). This doesn't do anything about the larger questions about FFI that things like OpenCV or DB drivers bring up, it is just way that I have been thinking about GUIs specifically lately.
Brendan Hansknecht (Jan 02 2026 at 20:29):Yeah, I think the default will for most things will be these kinds of effect intefaces. A platform gives tcp, a library implements postgres or mysql or etc. Same with rendering as mentioned above. Same with many many things
Last updated: Jun 16 2026 at 16:19 UTC