First, I'm going to call out the air of ungratefulness and animosity in this thread. Evan is giving you software for free, and it's software that's good enough that you invest your time into writing it and commenting about it. You should not expect Elm to move at the same pace as Angular (backed by Google) or React (backed by Facebook). Calling out that you want something done faster or differently, when you are not a financial backer or core contributor (to be fair, there aren't any of those besides Evan), comes off as extremely petulant.
Second, as for elm-community hosting the "greylisted" packages. I'm a core member of elm-community, although obviously I don't speak for the group and opinions are subject to change. I think that elm-community is doing a good job of providing high-quality packages, which largely means they are 100% Elm and have the reliability and free distribution that comes from that. Almost all of our packages are in maintenance mode, stewarded for people who left the community but who wrote useful packages that need to keep pace with language version bumps (oh hello original thread topic). With a small number of exceptions, most of our packages aren't actively developed. Third, regardless of who hosts the greylist, there are other problems. When Evan removed the old graphics library from core and spun it off as a separate package, he inadvertently added or multiple <https://github.com/evancz/elm-graphics/issues/3> runtime <https://github.com/evancz/elm-graphics/issues/14> errors <https://github.com/evancz/elm-graphics/issues/8> (or perhaps the surfaced later). This was a well-used library with native code, meant to not change as it was extracted, by Elm's creator, and runtime errors still happened. It is very easy to break everything that makes Elm nice with native code. Using ports means that you're writing more-or-less normal JavaScript, and it's yours to debug, lint, and fit to your needs, rather than be stuck on a broken library. The open source dream of a project with 100 stars and recent commits is appealing, but what happens during the bring-up when no such project exists? What happens if it never does? What happens if multiple projects look good? Fourth, web components were briefly mentioned. Richard gave a talk on these <https://www.youtube.com/watch?v=ar3TakwE8o0> last year and it seems like everything you need already works. Fifth and finally, to say something positive. (*If you're skimming, please read this part.*) The greylist is built on the idea that the best way to help is by writing code. Instead, let me suggest a collection of markdown documents that research a particular proposed addition and say why it would be useful. This is like doing the lit review before getting to work, and will be helpful to both Evan, anyone pressing ahead with the greylist, any anyone on the list confused as to what a task port is (for example). I think these documents should, for a topic X, define X, say why X is useful, describe the best way(s) to do X in Elm today, describe how other ML-family and JS-ecosystem languages do X, and finally include a brief, "first draft" of an interface or API for X in Elm. I think this will work well for "web platform" things (audio playback, binary data) much better than language features (type classes). -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
