JetBrains Compose

174 points by brzozowski 5 years ago | 52 comments

I 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.

dector 5 years ago | |

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...)

mikey_p 5 years ago | |

There is if you scroll just a little bit down the page

wodenokoto 5 years ago | | |

I thought that was a screenshot of the editor!

sillysaurusx 5 years ago | | |

Hmm. Not on mobile safari. Perhaps that’s the confusion.

iamcreasy 5 years ago | |

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.

remify 5 years ago | |

This has become my way of knowing if a UI framework is garbage or not.

api 5 years ago |

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.

vips7L 5 years ago | |

> 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?

api 5 years ago | | |

Sure. My point is that you should be able to have yours in Kotlin and I should be able to use Go or Rust.

justsomeuser 5 years ago | |

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.

ziml77 5 years ago | | |

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.

api 5 years ago | | |

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.

bjconlan 5 years ago |

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

kimodi 5 years ago | |

This is interesting, in theory it could open a path for their IDEs to go native. This coupled with Kotlin native of course.

ta988 5 years ago | | |

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...

mping 5 years ago |

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.

lewisjoe 5 years ago |

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.

TeeWEE 5 years ago | |

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.

usrusr 5 years ago | |

> 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.

burntcookie90 5 years ago | |

Compose also draws to skia https://github.com/JetBrains/skiko

screwreg 5 years ago |

Stripping copyrights is a great way to start a project: https://github.com/JetBrains/compose-jb/commit/6009cdd6cbdcf...

tasuki 5 years ago | |

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

kevincox 5 years ago | | |

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.

dector 5 years ago | |

Except that whole project is done side-by-side with Google team that works on Jetpack Compose AFAIK. ;)

protomyth 5 years ago |

How does this interact with the Accessibility settings on Mac OS?

mwcampbell 5 years ago | |

I haven't tested this on macOS, but it's completely inaccessible with Windows screen readers.

dector 5 years ago | |

Accessibility (and testing) in Jetpack Compose is done via [Modifier.semantics](https://developer.android.com/jetpack/compose/testing#semant...).

prepor 5 years ago | |

It's not here yet, but we are planning to add it soon

mwcampbell 5 years ago | | |

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?

protomyth 5 years ago | | |

Good, because its one of those show stoppers for a lot of people. Getting sued isn't fun.

api 5 years ago | |

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.

eklavya 5 years ago |

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.

dector 5 years ago | |

Compose is based on Kotlin Compiler Plugin. I'm not sure that you can use it from Scala for now.

mwcampbell 5 years ago |

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.

romanovcode 5 years ago | |

What's even worse - It's Java UI kit.

mwcampbell 5 years ago | | |

I know I ranted a bit, but this comment is a shallow dismissal that contributes nothing to the discussion.

trinix912 5 years ago | | |

Not trying to troll or anything, but what's wrong with Java UI kits?

MaxBarraclough 5 years ago |

Can't JavaFX already do a good job here?

alex7o 5 years ago | |

I think they don't want to depend on oracle.

MaxBarraclough 5 years ago | | |

Doesn't OpenJFX address that? It still depends on the JVM after all.

crudbug 5 years ago |

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.

pjmlp 5 years ago | |

Not everyone. Give me WPF/WinUI/Android Views and I am good to go.

dindresto 5 years ago |

Wow, this is amazing! Particularly looking forward to using one codebase for Desktop and Android.

firstSpeaker 5 years ago |

somehow reminds me of SWT. could someone more familiar compare this with SWT, Swing, etc. in term of its placement in the ecosystem.

mwcampbell 5 years ago | |

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.

suyash 5 years ago |

How us this better than JavaFx?