> > 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.
