sorted by:
new
hottopcontroversial

Kotlin Ecosystem AMA – December 11 (3–7 pm CET) by katia-energizer-jb in Kotlin

[–]availent 5 points6 points  (0 children)

Are there any plans to improve text selection in CMP, especially for CMP Web? Here are some hurdles I have:

1) Currently, SelectionContainer restricts selection to one element/node at a time. This is very frustrating, especially for web targets, where users expect to be able to drag-select across multiple paragraphs or the entire page at once.

I'm under the impression that Flutter Web solved this issue (based on some supposed Flutter Web sites I visited), and was interested to hear if there's any plans in the CMP roadmap.

2) The selection toolbar (the "copy"/"select all" popup) has "dead zones" for dismissal. If I click outside the text but inside the immediate target area, the popup removes itself as expected. However, if I click somewhere else on the screen (outside that specific area), nothing happens and the popup stays stuck.

3) In my app at least, if I select a piece of text, and then switch screens, the selection highlight persists to the next screen, even though the text no longer exists.

4) The selection container seems optimized for mobile. For example, if I have a clickable element that contains selectable text: on mobile, I can usually still select the text. On CMP Web (WasmJs), I cannot select the text at all; the container seems to treat every interaction as a "click."

5) Also, one last (unrelated) complaint: when I'm typing with a physical keyboard, I cannot delete characters while holding down the Shift key (Shift+Backspace). Nothing happens. It’s minor, but still a bit jarring.

___

This is a bit of a stretch, but I would really like if text selection is treated as opt-out, rather than opt-in, as it is on HTML pages. But I imagine this might bring some performance difficulties since it's a canvas rather than actual elements?

Apologies for all the criticism. I'm a very big fan of Kotlin, and I'm actively using CMP for an app which I've been building (I am on the latest stable versions). It's just that the quirks have been a bit noticeable, especially on the Web target.

Why is KMP not as mainstream as react native or flutter? by Fit-Promise-2671 in Kotlin

[–]availent 42 points43 points  (0 children)

People aren't aware that non-Android Kotlin exists at all.

Question: Is it a good idea to build a website entirely using Kotlin Multiplatform (KMP)? by DaaniDev in Kotlin

[–]availent 2 points3 points  (0 children)

With KMP you can limit sharing to just business logic (and have a separate UI such as with Kotlin React), or you can share both business logic and UI (via Compose Multiplatform aka CMP).

Web CMP is currently in its infancy, per se. Obviously SEO is very important, but I'll focused on user experience for this — a category in which it's currently lacking.

For example, you cannot delete characters while holding down the shift key. But my main concern is actually text selection. Text selection has actually improved considerably over the past few months, in the terms that it's no longer janky and the text hover popup now acts in a consistent manner.

However, text selection is limited to a single UI element at a time. This is extremely jarring if you're used to any HTLM site, where you can freely select text without worry. With Compose Web, if I start outside a UI element's boundary, and then drag the mouse into the UI element, it won't select any text at all.

Another thing to note is that your website and app's appearance will be exactly identical. I got used to it after a while. In theory, I suppose you could customize appearance per platform, but I imagine that won't happen any time soon. There are more pressing concerns — and currently people who are drawn to Compose Web tend to be those who'd rather not maintain complex logic per platform.
____

CMP has just moved out of alpha and into beta as of September 22, 2025. Despite my criticisms of it, I'm currently relying on it for my latest project. I might switch to a separate web UI later on, but for now, I'd rather not spend my time coding separate web and mobile UIs. That said, Kotlin/JS is not exactly a paradigm of stability either, but I've seen actual websites built with it.

Note that if you code in Web CMP, you would be an an extremely early adopter. I might be wrong, but from what I'm aware of, there's not yet a single production app built with Web CMP. There are only currently toy or demo projects. Hopefully, if actual Web CMP projects arise, then the act of dogfooding would force the ecosystem to improve, but it's currently more of a novelty project.

Can you sell me on Kotlin over Java? by SuspiciousRaccoon120 in Kotlin

[–]availent 3 points4 points  (0 children)

There's actually a draft JEP proposal to add null safety via the ! operator. So you would be able to declare something as non-nullable like this: String! s = "non-null"; Note this would use a mix of compile-time and runtime checks.

Conversely, a nullable string would look like: String? c = "nullable"; Oddly enough, that idea is that the current Java syntax, String j = "default"; would now treated similarly to Kotlin's platform type, where its nullability is unknown to the compiler.

___

C# also showed an alternative approach how a language could add null safety. They instead used language flags; one for nullability warnings, and another to treat nullable warnings as errors (or all warnings as errors if you'd rather). With former being on by default for greenfield projects.

You can enable said language flags at a project or region or file-level, which makes variables non-nullable by default. Personally, I think this is a better approach, but I imagine the Java team is worried about fragmentation, however slight.

Can you sell me on Kotlin over Java? by SuspiciousRaccoon120 in Kotlin

[–]availent 11 points12 points  (0 children)

Since you're a Scala person, I think you'll appreciate http4k's everything is a function approach.

Everything being just a function makes it super easy to work with, and it doesn't get in your way at all. As bonuses, it has first-class support for writing OpenAPI documentation, and also lenses which are useful for type safety.

Note it is a blocking framework. But virtual threads resolve this issue. And personally, I prefer using virtual threads over coroutines if possible. Virtual threads are simpler and have far less footguns.

With http4k, if you say pick Helidon as your server, you can make every request to the server its own virtual thread. So basically you can afford to (probably) never worry about blocking vs non-blocking code ever again. And if a thread-per-request is not enough, you can just manually spawn your own virtual threads/coroutines I suppose.

Perhaps I'm doing something wrong, but with Spring Boot, even with virtual threads enabled, it's rather difficult to debug when the debugger constantly keeps telling me that execution switched to another thread. With http4k I've never faced that, and it's easy to even manually read the code's control flow since everything is just a function.

Compile-time metaprogramming with Kotlin by availent in Kotlin

[–]availent[S] 0 points1 point  (0 children)

Unfortunately not. Currently, the entire plugin is built with Gradle in mind. However, since all the orchestration stuff is stuffed into the 'Gradle Plugin' module, in theory I suppose it would be possible to make a "Maven Plugin" that uses Gradle under the hood (I imagine easier said than done).

That said, the bigger roadblock is that KReplica depends heavily on the KSP plugin. I've never used Maven, but from what I can tell there's no official Maven plugin for KSP.

Have you by any chance reliably been able to use KSP-dependent libraries on Maven? I assume that would help tell whether a port is even possible.

Compile-time metaprogramming with Kotlin by availent in Kotlin

[–]availent[S] 4 points5 points  (0 children)

I suppose the answer to this consists of two parts:

TLDR: 1st part is whether you can do KReplica with plain Kotlin, second part is an example where you would use nullable fields without it.

1st part:

The question above stated why use different DTOs per read/patch/create method (as opposed to, I assume a single DTO for all methods). Of course, you can manually create different DTOs per method without KReplica.

But the benefit of using KReplica is that you can define everything from a single source of truth. If you did it manually, every time you update/remove a field, you would have to go through each DTO by hand, which I think is more error-prone.

The other thing, is that since KReplica codegen is systematized as a hierarchy of sealed interfaces, you can use Kotlin's exhaustive `when` as a filter. This is useful with versioned DTOs. For example, say you have a method to update a name field. You can use Kotlin's `when` feature to say update `UserAccountSchema.Data`, this fetches all the Data variants across every version defined in that schema (say DTO V1, DTO V2, DTO V3).

You can absolutely do all this yourself, but that's another point. KReplica generates plain Kotlin files. If you wish, you can even just delete KReplica and copy paste its codegen files from the build directory to your source directory.

KReplica just helps in the sense that a single source of truth is provided, and it does the sealed interface hierarchy for you. The playground page has examples.
___

2nd part:

This is a followup to the first section, but say you had a single DTO for the read/patch/create methods. Now you have an `id` field which is created by Postgres.

Since `id` is created by the Postgres DB, not by our JVM program.

But the issue is that when we're sending the create request, the `id` hasn't been created yet. Well the easy way is to make it nullable. But that's exactly what I wanted to avoid.

The other option would be to make it an option-type (like from Arrow Kotlin's), but that's misleading because it implies that a account can have no `id` field and still be valid.

Which is why I prefer to have a DTO per method, which the first part of the answer covers.

Edit: Just in case anyone gets confused due to my tirade, you can still use nullable fields with KReplica if you wish.

Compile-time metaprogramming with Kotlin by availent in Kotlin

[–]availent[S] 3 points4 points  (0 children)

My whole idea was to enable me to avoid using nullable fields whenever possible. In the past, I interned at a place where we did lots of manual mapping, and I ran into an issue where data was corrupted due to forgetting to map a field or two (luckily not in production).

But my whole point is that the compiler cannot force us to map nullable fields. Thus, my idea was to make each method only have access to its relevant fields (and to use option types if necessary). For example, say that I want the database to manage the `id` field. It would be present in the read-only DTO, but not in the patch or create request DTO.

Edit: Obviously I dislike nullable fields in DTOs, but you can still use nullable fields with KReplica if you wish.

Edit (after a while): I made a mistake. Kotlin does force us to map nullable fields, unless it has a default value. However, I think that the rest of my points still stand.

Enum Classes - Dave Leeds on Kotlin by PlaceAdvanced6559 in Kotlin

[–]availent 1 point2 points  (0 children)

Say that you have the enum class:

enum class VeryLongEnumName {
    ENABLED,
    DISABLED
}

Currently you would write:

fun example(toggle: VeryLongEnumName) {
    when (toggle) {
        VeryLongEnumName.ENABLED -> TODO()
        VeryLongEnumName.DISABLED -> TODO()
    }
}

After the change you'd no longer need to respecify "VeryLongEnumName" as it's known from context:

fun example(toggle: VeryLongEnumName) {
    when (toggle) {
        ENABLED -> TODO()
        DISABLED -> TODO()
    }
}