This is because in Elm a runtime error is a compiler bug. If you want no runtime errors, interoperating blindly with JavaScript is a great way to fail :-\

Another great thing about the community is a goal of a single great library for every use case, rather than a lot of half-baked competing libraries. So expect there to be a single great modal library. Etc.

That last part sounds pretty cool, how is this sort of thing being encouraged?

As a corollary to what shados was saying, now that 0.17 is out the elm-lang organization will make a library to cover every single part of the web platform [0], at which point you will never need to.

[0] https://platform.html5.org/

I'm no Elm expert, but as far as I understand, the "native library" APIs, the kind that are used to actually wrap browser APIs and interface with javascript in a way that can be published and made reusable, is "private". I mean, you can look at the source and make your own, but you're playing in undocumented, unstable territory.

The only "official" interop channel is the "port" system, which only lets you do a publisher/subscriber type thing with your application at runtime, and cannot be used in a library.

So you basically cannot make a "blessed" library that uses native browser APIs.