Elm, JavaScript, and Web APIs

[rupert]

@norpan

Now contrast this with the process suggested for implementing, say, an interface to FileReader. Why would it be bad to use the same process there? Is there something fundamentally different that makes it so that it’s bad to have multiple choices regarding that?

I understand full and well that once there is an official FileReader API, then people will see that as the definite API, but what is the way towards that?

Nobody would be happier than me if there was an official FileReader API that was superior to my “hackish” norpan/elm-file-reader so that it could be retired and migrated from.

So why do you not do the following.

1. Try to document use cases for FileReaders. Or really for all file handling in Elm. Write down what it is that people want to do with files. Post about it here, or do some kind of survey online.
2. Take a look around at how other languages do it. How does purescript handle files? Is it good, can we use it in Elm, or can Elm be better than that.
3. Sketch out an API that satisfies these requirements and is also a good API for Elm. Using your experience and intuition as an Elm developer to guide you.
4. Propose that we create an elm-exploration for this, providing 1, 2 and 3 to document your proposal.