[fwefwwfe]

It lets you define types for more safely interacting with other Javascript code. It doesn't magically make browsers have consistent behavior.

[mbell]

What I'm getting at is how it handles type safety at the browser API boundary. e.g. how does it handle a situation like:

`eventTgt.addEventListener('whatever', fn, true)`

vs

`eventTgt.addEventListener('whatever', fn, { passive: true })`

Does it just allow 'Any' for the type of the third param and thus somewhat punt on type safety at the browser API boundary or is there some attempt at defining an algebraic type for that param?

Or as another example, how would it handle the object passed to `fn` above, presumably some sort of event type, having different properties in different browsers?

[sjrd]

In the standard types for the DOM [1], only types for standardized browser APIs are made available. Browser inconsistencies wrt. standards are dealt with polyfills, either written in JS because they already exist, or you can write them in Scala.js too if you prefer.

But Scala.js doesn't force the standard typings on you. If you prefer another strategy, you can write your own types for the browser. You could use overloads in your example above.

That wouldn't prevent you from using the wrong overload on the wrong browser at the type system level, though, obviously. Doing so might be possible if you're willing to go very far with Scala's path-dependent types, but I won't go into details here. Scala.js users tend to prefer the earlier solutions.

[1] https://github.com/scala-js/scala-js-dom

[fwefwwfe]

> It lets you define types for more safely interacting with other Javascript code

You define types for everything.