[api]

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]

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

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

[vips7L]

Then bind to Skia like both compose and flutter are doing? I don't understand the problem here.

[api]

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.

[justsomeuser]

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]

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]

Having everything written with Electron is an advantage to users? Because that's the result.

[api]

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.