JetBrains Compose
jetbrains.comI wish there was a screenshot of a demo app. How do you market a UI toolkit without any screenshots of what I can do? I'm not going to build a demo project to see what the UI looks like.
This is Desktop interpretation of Google's Jetpack Compose done by JetBrains team.
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...)
There is if you scroll just a little bit down the page
I thought that was a screenshot of the editor!
Same here ... Went back to look at that image after the parent comment!
Hmm. Not on mobile safari. Perhaps that’s the confusion.
I wanted to check if I could build it without any hiccup. It was simple enough. All you need to do it navigate to the example folder and use 'gradle run', assuming you have java and gradle installed on your system.
This has become my way of knowing if a UI framework is garbage or not.
My biggest gripe with virtually every UI is that it forces you to learn yet another language just to code with it. Why can't there be UI APIs that work across languages like there is with loads of other stuff?
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.
> 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.
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?
Sure. My point is that you should be able to have yours in Kotlin and I should be able to use Go or Rust.
Then bind to Skia like both compose and flutter are doing? I don't understand the problem here.
Skia is a drawing library, not a UI library. That's like saying you can substitute DirectX or Metal for a full 3D modeling engine.
I agree as a developer, but I think the economics favour having many incompatible UI libraries:
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.
There's actually an advantage for users. Because you have to enter a new mindset for each platform (or have different devs for each) it pushes you to think about designing the UI to fit the platform. It's nice when the UI and UX feel like they belong with everything else on the system.
Having everything written with Electron is an advantage to users? Because that's the result.
If (B) is the reason, the platforms are eventually killing the golden goose by pushing the entire dev ecosystem onto the web stack for building UIs. Electron will rule.
This looks interesting, having skia as the drawing foundation and reactive as a core element sounds like they’re rewriting a flutter like framework but on the jvm instead of dartvm. Jetbrains sometimes dogfoods their products so I hope to see this technology exercised into utility
This is interesting, in theory it could open a path for their IDEs to go native. This coupled with Kotlin native of course.
Maybe, but for now kotlin native is much slower than kotlin JVM. The JVM is a piece of art. The current jetbrains product UI system is also quite impressive and based on ... Swing...
I ran the samples, the app runs lighter than electron but doesn't feel very native - probably would require a fair amount of styling. I have 200% scaling which worked fine, although I'm guessing some icons should have 2x res to make it crisper.
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.
How is this better than Flutter? If the answer is Kotlin > Dart, then what if Google comes up with a Flutter version that supports multiple languages (Dark/Swift/Kotlin)?
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.
This seems very similar to flutter indeed.
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.
> How is this better than Flutter?
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.
Compose also draws to skia https://github.com/JetBrains/skiko
Stripping copyrights is a great way to start a project: https://github.com/JetBrains/compose-jb/commit/6009cdd6cbdcf...
Quite great. I never understood why you'd want that copy-pasted everywhere: it's just noise.
Isn't a `LICENSE` file at the repo root enough? https://github.com/JetBrains/compose-jb/blob/master/LICENSE
I would love to have a lawyer chime in on this. It seems like the license at the root should be enough to say that you are applying the license to all the code.
Except that whole project is done side-by-side with Google team that works on Jetpack Compose AFAIK. ;)
How does this interact with the Accessibility settings on Mac OS?
I haven't tested this on macOS, but it's completely inaccessible with Windows screen readers.
Accessibility (and testing) in Jetpack Compose is done via [Modifier.semantics](https://developer.android.com/jetpack/compose/testing#semant...).
It's not here yet, but we are planning to add it soon
How do you plan to make the CEF-based browser view accessible? Are you aware of the challenges of making CEF fully accessible with a screen reader when using off-screen rendering?
Good, because its one of those show stoppers for a lot of people. Getting sued isn't fun.
I've found that accessibility is the rock upon which virtually every third party UI option dies (for serious work), save the most mature ones.
I wonder how easy/difficult would it be to use it from other JVM languages. If I can use it from Scala, it would be great.
Compose is based on Kotlin Compiler Plugin. I'm not sure that you can use it from Scala for now.
Ugh, yet another GUI toolkit. Let's spread the work of implementing and debugging accessibility even thinner.
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.
What's even worse - It's Java UI kit.
I know I ranted a bit, but this comment is a shallow dismissal that contributes nothing to the discussion.
Not trying to troll or anything, but what's wrong with Java UI kits?
Nothing.
Can't JavaFX already do a good job here?
I think they don't want to depend on oracle.
Doesn't OpenJFX address that? It still depends on the JVM after all.
I started looking into Flutter. Having to code everything in Dart seems to be a stretch. The cross platform UI toolkits should keep the well established composable abstractions - structure / style / script. This trinity provides developer ergonomics, may be we need a layer on top of these toolkits that gets compiled down to code.
Everyone hates XML, but for structuring UI elements it is one of the best tools.
Not everyone. Give me WPF/WinUI/Android Views and I am good to go.
Wow, this is amazing! Particularly looking forward to using one codebase for Desktop and Android.
somehow reminds me of SWT. could someone more familiar compare this with SWT, Swing, etc. in term of its placement in the ecosystem.
This is very different from SWT. SWT mostly uses the platform's native widgets, whereas this draws its own widgets. SWT is much better for accessibility.
How us this better than JavaFx?