I think the framing of this post needs some reconciliation.
People that are generally okay with how things are tend not to spend their time posting on the internet about how ports are pretty much good enough. There’s no conflict with the present situation, so there’s nothing to express. For this reason, conversation that is purely about how some people don’t like something, or think it can be ugly, or a hack, tends not to factor into decision making. Developing Elm involves weighing an incredible number of tradeoffs at every decision. If one of those tradeoffs was “I can do this thing that is good from every important angle, but some people will write negative posts about it,” nothing would ever get done. I don’t mean that community feedback isn’t important or legitimate. I mean that reacting to the mood on the forums in a given month isn’t an accurate or reasonable way to evaluate it.
First I want to address that you are contending in this post and with this question that sometimes using ports is not an acceptable way to use Web APIs. Personally, what is important to me about writing software is building the thing that I want to build. In that respect, using a port or taking advantage of some other means of interop that does not use Native is fine. I’ve also used Native in the past because it was expedient. We did the same at NoRedInk. Now it’s going away, and we changed stuff to use ports and custom elements and other DOM APis, and we found that it was also fine and that in some cases code quality actually improved.
So I’m thrilled to engage in discussions about scenarios where the thing you need to do is (a) critical to your software exactly as designed, and (b) actually impossible without assistance from the kernel. I don’t agree that ports aren’t good enough to cover just about everything, because my experience and my observations and preferences lead me to feel that way. For that reason, I don’t think conversations about how people feel about ports provide very much value because nothing is blocked in a technical way, and the advantages of ports over FFI have been widely discussed and are firmly embedded into Elm’s existence.
I can also try to address the question of timing of Web API development, absent the notion that ports aren’t acceptable:
The work on 0.19 needs to be finished first, and it’s not finished. I don’t want to communicate more about that because it is either (a) not known, or (b) up to Evan to decide how to talk about it. After it’s out, attention will turn to the web platform. Packages aren’t going to start being released over night. There’s a lot of design work that needs to be done, and sometimes we’ll want to identify and design for use cases rather than just building bindings to
window.X. For example, we might learn that most people want to use localstorage for caching request data, in which case a higher-level caching API that is backed by the safer and more powerful indexedDB might be what ultimately gets made.
If you feel strongly about a particular API, have a lot of experience with it, and have an idea for what a really great Elm API could be, then you can start the conversation on here, or on slack, or via email, or however you want to communicate, and we’ll work with you to see how it fits in and whether the story that explains the API is compelling. That process is long and unique for every individual idea. It isn’t done by just submitting code for review, and it requires more and different interest in the particular API and the Elm community than just “I want to use it in my app.” You can use ports for that.