I guess, for Alpha stage they are not targeting wide audience but mostly people that are familiar with Compose (or wanted to try it).
In most cases you can just copy-paste your Android UI layer or make it cross-platform (like in this code-viewer example https://github.com/JetBrains/compose-jb/tree/master/examples...)
We have this for networking, disk I/O, common OS operations, and even 3D graphics, but for some reason 2D user interfaces just can't be presented in this way. Why can't there be an OpenGL-like thing for desktop-style and mobile-style UIs that presents the most universal design patterns via standard APIs and allows access to OS or UI-layer specific extensions? How hard is this?
There is one lone project by one developer that seems to have been trying to do this, but it seems dead. Probably far larger than one developer can tackle in their spare time, but the effort is admirable:
https://github.com/andlabs/libui
This one person somehow gets it.
Back to the topic at hand. It's not that Kotlin is a bad language. I've heard it's quite nice. The problem is that it's yet another language which means more cognitive load, more build complexity, and so on. If my project is in Go or C++ or Rust, I want my UI in Go or C++ or Rust.
All that being said, I use Jetbrains IDEs and am generally impressed. They make very high quality stuff, so this merits at least a look.
Can we not pretend that go and rust are the only languages people use? What if my project is in Kotlin? Maybe I want my UI in Kotlin too?
A. It’s expensive to standardise and agree on what the UI primitives would be, and a standard would force the lowest common denominator of features. If you want a new whizz bang button now you have to create an RFC and cajole agreement.
B. It’s profitable to own the platform, which includes the UI, because then you can charge 30% taxes. If Apple spent money making a portable library they would be attacking their own income source.
It's good to have options, and if jetbrains want to pave the way then I just hope they make it fast and with a native feel.
If I'm to pick Flutter vs Jetbrains/Jetpack Compose - I'd pick Flutter because it supports desktop, mobile & web. And Flutter's philosophy of rendering directly using Skia on all platforms seems to be a sound strategy.
I think flutter is more mature and has way better widgets.
However I like the general move towards "One UI Toolkit for all platforms" approach..
Off course we already have this but then never really worked on mobile: - QT - Java Swing - SWT - Flash
And I think, Web makes it easy to run a browser anywhere, but technically needing a whole browser engine to show a UI is just overcomplicated designs... I know web developers like it because they often dont know how UI toolkits are build outside of web... I think Flutter hits the nail on the head with the best of both worlds: Browser makers created flutter optimized for UI native applications, not for WEB in general.
The lower bound of an answer is this: when the core of your work is kotlin android dev and you are only occasionally required to dabble in desktop (perhaps for some internal tooling related to the backend of your app) skill transferability will be worth a lot. Everybody can throw together hello world and some buttons in any toolkit, but reaching any meaningful level of productivity requires a lot of experience in the toolkit.
Something designed from the beginning for multiplatform will very likely end up not productive overall of you have a 50:50 distribution, but if you have a clear first class platform for product / second class platform for the occasional supporting tool situation, then something designed specifically for the first class platform that also has some capability for the second class platform can easily be superior.
Isn't a `LICENSE` file at the repo root enough? https://github.com/JetBrains/compose-jb/blob/master/LICENSE
I understand that by drawing its own widgets on desktop, Compose can provide greater parity with Android. But that benefits developers at the cost of some users.
I think what I would have done is implement the widgets on the web platform and use CEF for the whole application, not just the browser widget. Then they could also target web applications through Kotlin/JS, though potentially with an oversized JS bundle. It would also be important in that case to avoid the pitfalls of Flutter for Web, e.g. requiring the user to press a button to turn on full accessibility.
Speaking of CEF, making their embedding of that accessible is going to be particularly problematic, because they're using it in off-screen rendering mode, so they can render the page to a bitmap and draw that onto their own canvas. That means they don't benefit from Chromium's mature support for platform accessibility APIs. CEF does expose Chromium's cross-platform accessibility tree (thanks Adobe!), but then it's up to you to expose that to the host platform. Windows screen readers in particular have special support for Chromium's Windows accessibility implementation, allowing users to use special keyboard commands when browsing web pages. Unless Compose's accessibility implementation is a bug-for-bug emulation of Chromium's, Windows screen reader users won't have the usual level of access to web content.
Everyone hates XML, but for structuring UI elements it is one of the best tools.
