A modern programming language that makes developers happier.

kotlinlang

When will the compiler put properties on the `prototype` of a js class and when will it simply be on `this`? What does this decision depend on?

Probably not an exhaustive list, but compiler put property on `prototype` when:
- it is open, abstract or member of interface
- overrides something
- has custom `get` or `set`
- is delegated
- is lateinit

is it really necessary when it overrides something?

(i mean probably he answer is "yes" but it was so annoying and frustrating for me the last days, that understanding why this is necessary might helpt to overcome my feelings and, of course will help to avoid that kind of bugs in future :-D)

I don't think it's necessary. But it is how they are implemented right now.

if it's not necessary i think it's worth thinking about removing it then.
i think the prototype should be used as spare as possible.

Why do you need a property on the object itself?

because the protoype cannot be considered during a "structured cloning" which is conducted when sending an object to a web worker

we are using (or at least loved to use) `external interface` decalration to negotiate an interface with our js developers so they can easily integrate against our code.
But as soon as i implement that interface. the overriden properties will get name mangeld and the real names are only available through the prototype which will be lost after being sent to the web worker

Yep, structural clone is a bummer. Can see your pain. Could you submit a request at <http://kotl.in/issue|kotl.in/issue>?

done: <https://youtrack.jetbrains.com/issue/KT-31876?project=kt>

Is kotlinx-serialization not capable of doing this?

removing the protoype? maybe by serializing and deserializing the object? Yes this would be possible but also a major performance problem. not using the prototype where possible in the first place would be way better