https://kotlinlang.org logo
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
benchmarks
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
confetti
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
lincheck
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by
Title
l

Landry Norris

02/22/2023, 5:31 PM
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?
c

CLOVIS

02/22/2023, 5:44 PM
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.
l

Landry Norris

02/22/2023, 5:46 PM
That makes sense. It looks like a cool idea. You bring up an interesting point about potential compatibility between this and redwood.
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?
c

CLOVIS

02/22/2023, 5:52 PM
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).
l

Landry Norris

02/22/2023, 5:54 PM
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.
c

CLOVIS

02/22/2023, 5:56 PM
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).
I'm not familiar enough with Swing & AWT to confirm or deny that
d

David Herman

02/22/2023, 5:56 PM
It's probably even a bit more radical than Swing / AWT
Swing / AWT is more like different themes per desktop platform?
Whereas this is more like letting you write a declarative UI call and each platform can handle it however it wants, including ignoring it?
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)
c

CLOVIS

02/22/2023, 6:01 PM
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
l

Landry Norris

02/22/2023, 6:02 PM
I like the idea of the type safe availability of components.
c

CLOVIS

02/22/2023, 6:04 PM
For everyone joining the channel now, I highly recommend you read this thread, it answers a lot of commonly-asked questions a lot of people I talked with had (maybe I should just write an FAQ 😅)
l

Landry Norris

02/22/2023, 6:06 PM
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?
c

CLOVIS

02/22/2023, 6:12 PM
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)
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 :)
l

Landry Norris

02/22/2023, 6:17 PM
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)?
c

CLOVIS

02/22/2023, 6:18 PM
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)
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 🙂
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.
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)
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 🙂