> > 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 < eiriksletteb...@gmail.com> 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 <mhamb...@gmail.com> 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 <dandy...@gmail.com> >>> 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 elm-discuss...@googlegroups.com. >>>> >>>> >>>> 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 elm-discuss...@googlegroups.com. >>> 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
