> > Better javascript interop to allow the community to provide the missing > web APIs and effect managers (task ports have been mooted on several > occasions)
I'd much rather have the web APIs available natively within Elm, so that javascript interops are minimal/unnecessary. On Wednesday, April 26, 2017 at 7:08:08 PM UTC-4, Oliver Searle-Barnes wrote: > > I've been using Elm for about 10 months now and have had an app in > production for the last 2, I share the general feeling of this thread. > > I've addressed Evan directly here because it's impossible not to when > discussing these topics, I hope my thoughts are taken as sincere and full > of respect. > > Currently under development are: Elm the language, Elm the web platform > APIs, Elm tooling and effect managers. Evan is an absolute hero for taking > on the challenge to reimagine and build all of these different aspects of > web development and his success to date has inspired a lot of enthusiasm in > this fledgling community. The challenge can not be overstated though, this > is a gigantic undertaking, and it currently feels like too much for a > single individual. > > It seems clear that the community has many experienced and talented > developers within it's ranks. They've all bought into Evan's vision and I > believe would be willing to go to great lengths in support of it. While I > can understand that Evan wants to retain control over what represents his > gold standard there does seem to be an opportunity to help other developers > help Evan. At a practical level I see two parts to this: > > 1) Better javascript interop to allow the community to provide the missing > web APIs and effect managers (task ports have been mooted on several > occasions) > > 2) A development process that encourages the use of packages from the > wider community _before_ they've had sufficient design attention and > matured to the point where they may be considered gold standard. The > exceptionally high quality of the solutions that Evan puts out is a > destination that we all aspire to. Getting there may take a while though, > in the mean time people are building apps and having to settle with their > own half baked solutions which are difficult to share with the community. > This situation is particularly grevious because the time spent building > these half baked solutions takes time away from focusing on a single aspect > that they could develop to a higher standard and share with the community. > As an engineer it's hard to see this process as efficient and optimal. > > I don't want to be too prescriptive here but one suggestion might be to > introduce the concept of a quality or status metric for each package e.g. > exploratory, draft, candidate, ready (those were chosen purely for > illustrative purposes). This would allow the community to benefit from each > other's work without requiring any compromise in standards. Versus forcing > every team to reimplement the same things with ports this seems like a > distinct improvement (IMHO). Potentially packages could even be kept in an > entirely different package site until they'd graduated to > http://package.elm-lang.org/. (this would allow beginners to be kept in a > safer environment until they needed to reach into the community packages) > > Hopefully my thoughts will be taken in the postive light that they're > intended, I'm a huge fan of Elm and would love to see it go from strength > to strength. As the opportunity doesn't often present itself I'd like to > extend a huge thankyou to Evan for all the great work you've been putting > in! > > -- 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.
