A modern programming language that makes developers happier.

kotlinlang

About Compose HTML: It would be cool if some day Compose HTML used the `org.jetbrains.kotlin-wrappers:kotlin-browser` APIs instead of using the default bindings provided in Kotlin, mostly because it is a pain when mixing both APIs in a single project, especially because the `kotlin-browser` bindings are better than the default bindings (which is what Compose uses)

Just for fun I've tried porting Compose HTML to use the `kotlin-wrappers/kotlin-browser` bindings, to see if it would be hard and to learn how Compose HTML works under the hood. I recommend reading Compose HTML's code! It isn't that complicated as I thought, but that's because Jetpack Compose is doing a lot of work behind the scenes. :kodee-loving:

Do I recommend using this? Nope! <https://github.com/PerfectDreams/ComposeHTMLDreams>

Great effort! I appreciate your approach to learning. 

Based on the work you've done so far, do you think that if JB ever actually migrated Compose HTML to their latest wrappers that there would be a way to create a backwards compatible compat artifact that was just a bunch of type aliases to the new location? Or would that run into walls due to fundamental API differences, and a heavy manual migration would be required?

<@U02AB5P2XU6> it depends on how much do you want to support the org.w3c elemntes:

Do you want to support only the `renderComposable` calls? That's pretty easy!

However the supporting the old API gets harder if code depends on `ref { ... }` (because the element that is passed to the ref callback is a `web.html` element), or if the code depends on the SyntheticEvent `nativeEvent` (because that's also a `web.html` event)

Because to support the old API, you probably would need to copy the entire DSL API to `unsafeCast` the new elements to the old elements when invoking the `ref` block and, for native events, you would need to copy all events and replace the native event with a org.w3c event