> > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
