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