Perhaps others disagree with me, but for things that lend themselves to reusable components (in other language) or reusable views in Elm, having to wire up ports every time is more than a bit cumbersome. I’m working on building reusable audio and video players for instance.
Elm Date Picker comes to mind. If Elm Date Picker required you to go outside the Elm ecosystem to NPM or GitHub, and then wire-up ports that would be nuts, and it would discourage people from using.
The problem for me is not that these things can’t be used in Elm-Package, but rather that there’s not really a clear path forward for getting them included officially in the language, so that extraordinary measures don’t have to be taken. Perhaps there is and I’ve missed it, or perhaps there’s fuzzy communication around it.
But for any number of interesting use cases, right now, native code is required. The reason for not just putting it on NPM or GitHub is the same as the reason for not allowing native code in the first place: it will foster bad habits and some members of the community may grow dependent on it. Imagine if great libraries like Style Elements or Elm CSS were distributed through GitHub only, and required a fair bit of port setup…they would see less use and wouldn’t expand what the language can be, but also they would start setting a standard for how libraries should be created and installed.
Reusable views: (https://gist.github.com/rofrol/fd46e9570728193fddcc234094a0bd99), or the most common example: (https://github.com/evancz/elm-sortable-table)
Pieces of UI code that can be reused. The examples I gave are an audio player or a color picker.
My point was that I really don’t use LocalStorage, so can’t speak to any of the specifics of it, but rather that it’s the most requested API I hear.
From the infinitesimally little I know about it, though, it seems like a less compelling case for reuse, and may be a better example of a case where ports are just fine. I just don’t know enough.
And this is precisely how I have been. Attending Elm meet ups, trying to get involved in the Elm Slack, etc.
I think you and I are actually 90% on the same page, and perhaps I am not expressing myself as well as I’d like.
The loss of Native makes me nervous, only because of some fairly glaring gaps in the Web Platform in Elm. I think the no-Native move should be made, but I also think that such a move makes wrapping more of the Web Platform a much higher priority, and I think there’s still a lot of ambiguity about the shape that will take.