We've just published a blog post about the updates...

# javascript

[Artem Kobzar]

We've just published a blog post about the updates on Kotlin/JS we will have.
Please let me know if you have something (related to it or not) to share.
The present and future of Kotlin for Web!

[CLOVIS]

Thanks a lot for this! I've been pushing for a while to use Kotlin/JS as a way to share DTOs and complex validation algorithm between our Kotlin/JVM backend and our TypeScript frontends, it's great to see a lot of progress in that area recently + this promises for the future!

[Artem Kobzar]

Thank you for your feedback and participating in a lot of discussions. Your use case is quite interesting and I would like to know more about the implementation. I feel that at least we can improve a lot on our side to support this use case more seamless and (as maximum) to support such a use case out of the box.

[CLOVIS]

@Artem Kobzar If you have any questions about what I'm doing, don't hesitate to get in touch. In the past I've participated in JB research studies on this too

[Edoardo Luppi]

There has been positive reception on Reddit. This comment has good feedback https://www.reddit.com/r/Kotlin/comments/1khu4wt/comment/mrameb1/

[Arjan van Wieringen]

We are embedding our Compose HTML app in web components and having good results there. Love to provide input as well. The combination Compose HTML and web components is great.

[Edoardo Luppi]

@Artem Kobzar wondering what you think about the feasibility of https://youtrack.jetbrains.com/issue/KT-60561
Especially related to my comment. It's something that has been "bothering" me for quite some time at this point although I managed to solve it with workarounds.

[Artem Kobzar]

I discussed it with @bobko and we've found a few unsound ways to use it, so it's quite hard to "fix" it in a general way:
1. Type-checks/Type-casts

// commonMain
expect class Foo

expect fun createAny(): Any?

fun main() { 
  val test = createAny()
  println(test as Foo) // No warnings/errors in this case
}

// jsMain
actual typealias Foo = Promise<Unit>
actual fun createAny() = Promise<Int> { it.toFloat() }

2. Inheritance

// commonMain
expect open class Foo
class FooChild : Foo() // No warnings/errors in this case

// jsMain
actual typealias Foo = Promise<*>

[Edoardo Luppi]

I'm not familiar with how typealiases are resolved, but, why wouldn't unchecked cast warnings be emitted? From an outside perspective I would think the typealias is resolved to its underlying type on each platform compilation, which would mean the compiler is not working with Foo anymore, but with Promise<Unit>. Maybe this is what @bobko meant with platform checkers in common?

[Artem Kobzar]

Because from the common-code perspective it's just a regular class without type-parameters