<https://youtu.be/z-u99yZFn5o?t=767> That was an i...

# javascript

[Edoardo Luppi]

https://youtu.be/z-u99yZFn5o?t=767▾

That was an interesting watch. And the Long issue is now pretty much resolved with bigint.
Tho @Arkadii Ivanov I'm curious to understand why you guys think annotating declaration isn't ideal. Which kind of solution would you prefer? Gradle-based to mass export?

[Arkadii Ivanov]

@edenman might have more context. But I think it's just inconvenient to annotate hundreds of entities. You can export entire Gradle modules to iOS, so probably something similar would be great for Web as well.

[Edoardo Luppi]

Thank you! Didn't know he was on Slack too, that's why I tagged you.

I get what you mean, especially during the prototyping phase it would be easier to just say "export everything". However, the problem with this approach imo is that not everything is thought out to be interoperable with JS. Some declarations require more consideration than others, and that's why I kinda appreciate the more granular @JsExport, it makes us reason about it.

[Edoardo Luppi]

I'm also curious to understand how you plan (if web is still on your radar) to tackle the current monolithic export model with eager resolution of dependencies. Are you going to somehow figure out code splitting with Webpack or an alternative bundler?

[Arkadii Ivanov]

Well, the interop with iOS is not great either. E.g. currently interface generics are lost, sealed classes are not great, and many other things. Yet, if an entity is defined as public and I explicitly specify to export the module, then everything public gets exported somehow. In most cases it works as expected, and when it's not, we can jump and tweak the API as needed. So I really believe this would be the best option for Web as well.

Adding @Klara Erlebachova for other web specific questions. Thanks Klara!

[Edoardo Luppi]

Probably the best approach to make everyone happy is still https://youtrack.jetbrains.com/issue/KT-47200
The export model needs to take into account third-party dependencies (which again might have subtle incompatibilities or performance issues in JS). Think about the early design of UUID, it had so many Long bitwise operations that it would have been a disaster in JS, while under the JVM it's a no brainer. This is the reason I'm always cautious about exporting.

[Arkadii Ivanov]

Yep, I have that ticket started and following!