What distinguishes this project from redwood and C...

# decouple

[Landry Norris]

What distinguishes this project from redwood and Compose UI in the long term? If I were to choose a UI for a new project what would lead me to decouple?

[CLOVIS]

My understanding of Redwood (I have not used it but I followed the announcements) is that it aims to help convert non-composable libraries (e.g. SwiftUI) to composable functions. In that sense, Redwood and Decouple are parallel projects that are compatible with each other.

"Compose UI" is not really a specific thing, so you'd have to be more precise of what you mean. Depending on which you want to talk about:
• Jetpack Compose, Compose for Web (canvas), Compose for Desktop all share the same components, so you can share code between them
• Compose for Web (DOM) has different components, so you cannot share UI components with it
• Jewel (Compose for Desktop components for IntelliJ plugins) does not share components, so you cannot share UI with it
• Mosaic (CLI apps) does not share components, so you cannot share UI with it
• …you get the idea
What I aim to do is to provide a unified component API that you can write shared code with, but switch at runtime which of all of these choices you actually want to use (e.g. write a single application, which uses Jetpack Compose on Android, but Compose for Web DOM on the web).

Essentially, Decouple is a small component layer that lives on top of any composition of all existing Compose-based libraries, so you can transparently write applications that use whatever exists on whatever platform, even if they are based on completely different components.

[Landry Norris]

That makes sense. It looks like a cool idea. You bring up an interesting point about potential compatibility between this and redwood.

[Landry Norris]

With such a wide range of targets, how do you plan to support concepts that may not make sense on all platforms (button or date picker might be hard to convert to CLI). Will it create the closest analog?

[CLOVIS]

Of course this means it's not possible to create an API as low level as Jetpack Compose, but that's not my goal: as you say, a date picker on Android has nothing to do with a date picker in the terminal. But the concept of a date picker is the same: e.g. I want to be able to write

var instant by remember { mutableStateOf(Clock.System.now()) }

LocalDateTimeField(
    label = "Select a timestamp",
    value = instant,
    onChange = { instant = it },
)

and each platform decides entirely what this actually looks like. The benefit is your UI looks native on whatever platform you want (because… it is!). The downside is your UI looks different on each platform (and you'll find that JetBrains is aiming for exactly the opposite: writing all platforms on top of Skia so they all look exactly the same).

[Landry Norris]

I see. So this would be similar to Swing vs AWT (same look on every platform vs same concept on every platform) in the Java world.

[CLOVIS]

The other answer if a concept really makes no sense at all: all platforms do not have to implement all components. For example, scrolling may not make any sense in a CLI. In that case, you cannot call the component in common code (this is possible because the library is interface-based, not expect-actual-based, so end users can create their own interfaces with their own subsets or supersets of components that they want to use).

[CLOVIS]

I'm not familiar enough with Swing & AWT to confirm or deny that

[David Herman]

It's probably even a bit more radical than Swing / AWT

[David Herman]

Swing / AWT is more like different themes per desktop platform?

[David Herman]

Whereas this is more like letting you write a declarative UI call and each platform can handle it however it wants, including ignoring it?

[David Herman]

Note that this is a problem you might face in general multiplatform code -- you might put something in common that doesn't make sense for a particular target (I see Android's context concept sneaking into common code sometimes)

[CLOVIS]

The end goal of Decouple is that you create an interface in your common code that has all the components you want

interface MyStyle : UIMetadata, Buttons, …

and you can now execute your UI on whatever platform for which you can implement all components of that interface, while easily building new 100% cross-platform components as extension functions of that interface.

The Decouple project itself will have ready-to-use implementations of many components for multiple platforms etc, so you can bootstrap your project with one of our interfaces, and replace each component one by one by a more custom implementation if your needs are too different, without having to write them all before starting working on your app

[Landry Norris]

I like the idea of the type safe availability of components.

[Landry Norris]

You mentioned that this won’t be as low-level as Jetpack Compose. Will it be feasible to build a full app with just this library, or is it more or less for building higher level UI, with some platform-specific layer handling the lower level aspects? Where is the goal for the bar of what we can use this for?

[CLOVIS]

I'm not sure yet exactly how far this can go. For now, the demo app (linked on top of the channel) is 100% shared, but it's also a quite simple app (before looking at it, keep in mind it's still very experimental and I'm not a UX person). My goal is that you will be able to write as much as possible in shared code, while always having the option to implement the components yourself if you feel limited.

Generally you can expect that anything "used in most apps" (date pickers, navigation, buttons, …) will be implemented, and anything "used in rare cases" (Google maps components…) won't (or maybe as an add-on, but that's a long time away)

[CLOVIS]

Currently, my main focus is to decide on the API surface and to provide one or two complete implementations (as well as the demo app). The first implementation will be web-based (Material You, because I can follow along the specification literally and not have to make UX decisions 👼). The next one will be either Android or Compose Desktop, but I'm not familiar enough to them to do them justice yet.

Of course, if you are interested by the project and have some time to spare, I would love contributions on any platform you like :)

[Landry Norris]

I mainly ask so many questions because I’m looking to standardize how I build UI for different projects. I just switched from Swing/UIKit/Compose to Compose Multiplatform for most of my app-related projects. I’m looking at redwood in the future because it delegates to the native UI, meaning it should work better with tooling. Would be nice to see where this fits in. Maybe as a way to add web support (something I often skip) and CLI support (As a linux user at heart, this seems nice)?

[CLOVIS]

I have a friend who does a lot of CSS who will likely do another web-based implementation for TailwindUI (again, because it's interface-based and not expect-actual based, you can have as many implementations you want per platform, and even mix-and-match them)

[CLOVIS]

Don't worry, it's great to be asked these questions because it confirms that I'm not the only one feeling the lack of solution in this space, and it also confirms to me that this is the right way forward since I can answer them 🙂

[CLOVIS]

There's a big emphasis on "in the future" though. Decouple will not be production-ready in less than a year for sure, and even then I'm not making any promises. My goal is to use it in production myself around this summer on another project (currently written in Kotlin React), but I'm not afraid of using it in production while it's not stable because I know exactly what breaking changes happen and how to fix them.

[CLOVIS]

As a bare minimum, Decouple is currently very limited by the lack of context receivers (it's written to use them, after all!), so it's not possible to release it before context receivers are available on JVM and JS (since these the two platforms I know best)

[CLOVIS]

You mentioned that this won’t be as low-level as Jetpack Compose.

In theory, it's also possible to write really weird things like using Kotlin Native to implement Decouple on top of GTK or KDE to have truly native desktop applications, all with the same codebase as Android and everything else

That's not on an short-term roadmaps, but for the far future I think the mere fact that it is possible is worth pursuing 🙂