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