News for hackers. Stuff that matters.
Re:Overview of Scala.js from a GWT developer perspective by mbell on Tuesday June 27, 2017 @07:14PM (#14650435)
How does Scala.js deal with inconsistent browser APIs and type safety? Does it just include all of core-js and hope for the best?
Re:Overview of Scala.js from a GWT developer perspective by raquo on Tuesday June 27, 2017 @07:42PM (#14650586)
I don't know, but I would be surprised if Scala.js does anything in that regard. It's a Scala-to-JS compiler, its job is to translate Scala code to JS code.

Scala.js lets you require any npm modules, so you can `require()` any JS polyfills you want just like you would do if writing JS code by yourself.

Re:Overview of Scala.js from a GWT developer perspective by fwefwwfe on Tuesday June 27, 2017 @09:30PM (#14651052)
It lets you define types for more safely interacting with other Javascript code. It doesn't magically make browsers have consistent behavior.
Re:Overview of Scala.js from a GWT developer perspective by mbell on Tuesday June 27, 2017 @11:14PM (#14651446)
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?

Re:Overview of Scala.js from a GWT developer perspective by sjrd on Wednesday June 28, 2017 @12:08AM (#14651621)
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

Re:Overview of Scala.js from a GWT developer perspective by fwefwwfe on Wednesday June 28, 2017 @09:26PM (#14660063)
> It lets you define types for more safely interacting with other Javascript code

You define types for everything.

Re:Overview of Scala.js from a GWT developer perspective by audi100quattro on Tuesday June 27, 2017 @10:33PM (#14651308)
About as well as jquery-ui or bootstrap would deal with browser inconsistencies if that's what you use for pre-made widgets/forms/layouts/themes/etc.. as other have said, you can use any js library.