Two experiences with Elm

Reusability for other users: color picker, audio player, video player, these are examples of reusable views that are widely required for many web apps.

Theoretically, elm-markdown could do it’s markdown parsing through ports, but it doesn’t, because it would be cludgy. It’s a reusable package that many people want to use and don’t want to have to write from scratch, or wire up ports for. Ditto with Elm-lang/dom. It’s a bit crazy to imagine people hooking up a port just because they want to focus and blur.

Honestly, it may be as simple as figuring out where the biggest gaps in the Web Platform are and committing to getting those in. I suspect that with implementations for like 6-7, 70% of the concerns would go away. Some of those API’s are particularly hard to design elmic APIs around, but not all are.

Then put it on NPM and Github? Why does it have to be the Elm package-manager?

What do you mean by reusable views? Do you mean view as in view/model/update?

I don’t understand how LocalStorage requires any level of expertise; it seems fairly straight-forward to just wire up ports, decoders and encoders, no?

This hangout is part of the effort that was made to support WebGL in Elm, and as per the work that was done in collaboration with Evan, WebGL was integrated and got pretty good support; This community-effort was, as far as I’ve understood, the moving force behind getting it done, which I don’t think is crazy at all.

I can’t speak to what efforts will go into covering more of the Web API’s, but I do know how collaboration happens, so perhaps this is how you should pursue year dreams of better media-API support :sunny:

I don’t - it’s a big discussion (on multiple topics, at this point) and doesn’t illustrate anything concrete about what is and what isn’t. Real cases are important to get anywhere.

Regardless of my opinion of imaginary examples, work on Elm is based on the real issues people encountering while using the language

This is a good signal that this topic is mostly finished. If folks have concrete things you’d like to discuss, could you please open new topics? I’ll probably lock this soon so it doesn’t spiral into (more) subthreads. :slight_smile:


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: (, or the most common example: (

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.


or now. Now’s good too.