The moment Evan gave the "Let's Be Mainstream" talk and linked to it from elm-lang.org, the pretense that Elm was sheltered in a pre-1.0 world was pretty heavily undermined. Elm has been promoted as being ready for the mainstream. The fact that it bears a version number that is less than 1.0 doesn't mean much — at least not without a roadmap spelling out the differences between where it is now and 1.0.
On Wed, Apr 26, 2017 at 1:00 PM, Joey Eremondi <[email protected]> wrote: > There is an underlying premise of Elm that there is One Correct Way™ to >> solve a problem in an application written in Elm, it takes "a long time" to >> discover the One Correct Way™, and Evan is the only person capable of >> doing it. > > > It's not that there's one way of doing it, but that once a bad way of > doing it is widespread, it never dies. Once you give people a tool, you can > never take it back, even if it is a bad tool. The goal is to make Elm solid > *before* 1.0, so that after 1.0, we won't be plagued by backwards > compatibility issues. > > On Wed, Apr 26, 2017 at 12:57 PM, Eirik Sletteberg < > [email protected]> wrote: > >> I used the persistent-cache code once. I just copied the source code into >> my project. The library readme makes some bold statements, like "it is the >> right technical choice" to expose a LRU cache for localStorage in Elm. It >> certainly wasn't the right choice for my use case, where "least recently >> used" wasn't a relevant factor regarding which elements to retain in >> localStorage; there were a few very important keys, and a couple of "less >> important" keys. The Task-based LocalStorage API that is included in >> persistent-cache works very well. It works very well because it mirrors the >> native API. As a developer, I also prefer the freedom to make my own >> technical choices that are right given the circumstances. I need the power >> of the Web API, I just want it with types and without runtime exceptions. >> >> There is an underlying premise of Elm that there is One Correct Way™ to >> solve a problem in an application written in Elm, it takes "a long time" to >> discover the One Correct Way™, and Evan is the only person capable of >> doing it. (An exaggeration of course) As far as web APIs are concerned, >> there is only one Correct Way™ we all have to deal with, which is W3C >> standards, as they are implemented in the browsers. Maybe it's possible to >> take WebIDL definitions and convert them to Elm bindings, then one would >> have a type-safe, exception-free interface to the browsers, without all the >> maintenance overhead. >> >> BDFL for both a language and its ecosystem is perfectly fine for a >> project philosophy, but it is intrinsically linked to having a small niche >> community. Then again, broad adoption may not be a significant priority for >> Elm during the next few years, so that might be a good thing. In the case >> of commercial software development, cash is king, and delivering working >> features is the top priority. Nobody cares that your car is shiny and >> polished, if it cannot drive in reverse. The article Choose Boring >> Technology <http://mcfunley.com/choose-boring-technology> comes to mind. >> >> Bottom line, there is a huge untapped potential here, people are excited >> about Elm, want to use it in production, but then there are small things >> like missing support for localStorage, file uploads, audio playback, binary >> data, being able to control event.preventDefault(). Many of those are >> problems that people would fix themselves and publish as a package. All it >> takes is to trust the broader community. Even if you end up with 5 >> different libraries dealing with cookies, one of them will probably >> prevail, and all 5 of them will learn from each other's advantages and >> drawbacks. I don't buy the argument that opening up the ecosystem will ruin >> Elm's guarantees - I would trust the robustness of a third party cookie >> package with 5000 GitHub stars and 100 merged pull requests just as much as >> (or more than) I trust the Elm core. Just look at what npm did for the >> JavaScript community. Look at the success of React and Redux, which are >> more or less based on TEA. But they have excellent JS interop and an open >> ecosystem. Wouldn't it be great if Elm were just as widespread? And had >> just as many contributors? >> >> >> onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende: >>> >>> The thing is that this exact kind of cache (LRU) might not work for all >>> people, so it'd be great to have barebones interface to >>> localStorage/sessionStorage/etc. Then higher level abstractions, like >>> persistent-cache, could be easily built on top of it. >>> >>> On Wed, 26 Apr 2017 at 18:24, Mark Hamburg <[email protected]> wrote: >>> >>>> Exactly and look at the months old comment at the top of the read me: >>>> >>>> NOT RELEASED YET — I hope to release it relatively soon, but I cannot >>>> make any promises. Until then, please use ports if you want to use >>>> localStorage. >>>> >>>> >>>> On Wed, Apr 26, 2017 at 9:22 AM Rex van der Spuy <[email protected]> >>>> wrote: >>>> >>>>> On Wednesday, April 26, 2017 at 5:07:39 AM UTC-4, Wojtek Piekutowski >>>>> wrote: >>>>>> >>>>>> >>>>>> https://github.com/elm-lang/persistent-cache? >>>>>> >>>>> >>>>> Wow, that's exactly what I need! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> -- >>>> 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. >>>> >>> -- >> 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. >> > > -- > 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. > -- 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.
