Two experiences with Elm

[DanAbrams]

@opvasger

You can reuse your own code, you can publish (anything) to npm, you could roll your own package manager at work or u

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.

[opvasger]

@DanAbrams

Reusability for other users

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

@DanAbrams

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

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

@DanAbrams

I don’t think Media API is alone in this. What about a reusable view Color Picker that requires canvas? I don’t much about FileReader and LocalStorage, but that’s the one I hear all the time. I’m sure others can think of other examples of reusable views that would be really wonderful to have, but require native/ports and some level of expertise.

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?

@DanAbrams

Obviously we’re all using HTML, but from my perspective as a media specialist, it’s absolutely crazy that WebGL, which is not a widely used API from my perspective is wrapped, but localStorage and Media aren’t.

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

[opvasger]

@KasMA1990

I think this blog post is a good example personally

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.

@KasMA1990

I’m focusing on imaginary code here intentionally, because that’s where I imagine that not having an escape hatch will be an issue for some. Because when you don’t have an escape hatch, you have to predict if you are going to write

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

[brian]

@opvasger

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.

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.

[DanAbrams]

@opvasger

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

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.

@opvasger

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

Reusable views: (elm-best-practices.md · GitHub), or the most common example: (GitHub - evancz/elm-sortable-table: Sortable tables for whatever data you want to display)

Pieces of UI code that can be reused. The examples I gave are an audio player or a color picker.

@opvasger

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?

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.

@opvasger

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

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.

[brian]

or now. Now’s good too.