How does one contact elm-explorations?
I maintain the ‘library’ that uses native code to access the file reader API from within Elm. While its been popular, its core part will not survive into 0.19 … unless the (secretive) elm-explorations repo wants to take it over (at which point it would more seemlessly than it has before).
Hence my question
Maybe we can join forces here
Your post provided further evidence that FileReader is an HTML5 API that many people wish Elm would have access to.
I’m really hoping that elm-explorations provides a means of accelerating widening API coverage in a alpha-like manner, i.e. with no guarantees of Elm-api stability. That might enable local storage solutions to be ‘explored’ too.
I imagine you’d like to use Files in Elm, not just the FileReader API, right? So the first thing to do is forget you’ve written any code and research how other languages have handled files. See what works and what doesn’t. Once you know that, it’s easier to present something that will definitely be a pretty big language feature. Write a proposal for your API–still not code–and see what happens.
As a note: the elm-experiments organization is not secretive, it’s new. There’s a big difference. There’s not a secret process, there’s no process. For now, pretend it doesn’t exist. Behave as you would in the 0.18 world and you’ll get better results. I understand being excited about the next version and wanting to get going on it (right there with ya), but it’s not released and having to re-explain this every time takes away time the moderators could be helping people.
It’s just the FileReader API. It is a very specific functionality of the Browser. It is not about general use of files in an hypothetic ideal Elm that has support for out of browser environments.
Focusing on general use of files risks leading to a “persistent cache” kind of problem. Instead of giving people access to a specific browser technology that they know from JS world, an extra abstraction is attempted in order to solve a different kind of problem that aims to be a more generic solution and when that fails, instead of just giving people access to the browser technology, the implementation gets blocked indefinitely.
I understand what you’re saying generally, and I know it’s frustrating. It takes time to make something good, and it’s hard to not be able to use it right away.
“just” is one of those words. It sounds so easy! Let’s just do such-and-such a thing, and life will be better! And yes, that may be true immediately, but I’ve been in too many situations where we did “just” the thing, and then had to support that decision forever. In this particular situation, you can refer to Reframing “native” code as “kernel” code. Specifically:
Having Elm expose the entire Web Platform is the long-term goal. The process outlined here will be slower than other methods, but when the priority is quality, I think this is the best path.
So that brings me back to my original point: make a proposal. Talk early. If it needs to be expanded or changed, it’s much much easier to change markdown document or something than it is to rewrite a whole library.
Thanks Brian, but your premise is incorrect - I was modestly only talking about FileReader. Evan has stated before that he’s got blobs on his agenda, and I still see Elm as a browser technology so wasn’t thinking about node’s ‘fs’ library. I guess there will be a process at some stage, which it would no doubt be best to wait for.
I should clarify. There’s no process for elm-explorations yet. That doesn’t mean there’s no process for making these proposals right now! Check out what Richard wrote yesterday, for example: Building Trust: What Has Worked
The best advice I’ve received on this subject was “pretend 0.19 is not happening.” This was amazingly helpful to unblock me mentally from shipping elm-benchmark 2.0.0. What if we did that here? What specific Elm API do you want to see? How would it be used? What gotchas will there be, and when would you expect to hit them?
From Richard’s post:
If you’re looking for a concrete first step to take, I’d always begin with trying to understand the whole problem. Not just part of it! Maybe you have one use case, but what are other Elm community members’ use cases? What are the relevant use cases people have in other communities outside Elm, which we ought to be aware of? Research these problems and use cases, and post your findings. Talk with people. Ask questions. Be patient!
You can write the proposal, sketch out an API, and start communicating these ideas now. If you don’t think now is the time for a full-blown File API, fine! Having opinions about quality and scope is an important part of writing any proposal. This might seem a little more complicated because there’s already code in your repo, but it’s not really. Treat it as a first step, not a last one.