A kind of FAQ

1,417 views
Skip to first unread message

Evan Czaplicki

unread,
Apr 28, 2017, 4:19:11 PM4/28/17
to elm-dev
I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

Brian Hicks

unread,
Apr 28, 2017, 4:30:17 PM4/28/17
to elm...@googlegroups.com
According to the State of Elm survey data, a roadmap/FAQ is pretty much the top thing people want from "the Elm developers". So yes please! this directly addresses something a bunch of people have voiced, and I'm sure it'll go over great.

My only other feedback is mechanical: "realese", and the first section is very exclamation-point-y.

I'm looking forward to being able to share this!

On Apr 28, 2017, at 3:18 PM, Evan Czaplicki <eva...@gmail.com> wrote:

I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPGqEk1vM2DJwXn39oE0YDqeYropfHdbj-sKD-iAPU1HWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Dustin Farris

unread,
Apr 28, 2017, 4:40:59 PM4/28/17
to elm...@googlegroups.com
Well written and broadly addresses everything I've seen people asking about lately (including me).

Elm's pragmatic march of progress is important to me and my team.  Glad to see this highlighted.

Dustin

Sent from my iPhone

On Apr 28, 2017, at 4:18 PM, Evan Czaplicki <eva...@gmail.com> wrote:

I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--

Richard Feldman

unread,
Apr 28, 2017, 4:53:02 PM4/28/17
to elm...@googlegroups.com
This looks fantastic - love it!

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/959F4F25-6148-4621-AEBE-58000A4426C1%40gmail.com.

Daniel Bachler

unread,
Apr 28, 2017, 5:05:45 PM4/28/17
to elm...@googlegroups.com
Nice to see this!

One big thing that I wonder about and that I was hoping might be answered in this document is what happened to the plan of supporting more Web Platform Apis (e.g. things like binary file uploads etc)? Is that something that is on the horizon for after the current focus you outline in the FAQ or have your priorities shifted away from that for a longer time?

The 0.17 release notes from pretty much a year ago had a lot of wording suggesting this would be a focus for the next few months and it would be great to know how you think about this today. Thanks!


On 28 April 2017 at 22:52, Richard Feldman <richard....@gmail.com> wrote:
This looks fantastic - love it!
On Fri, Apr 28, 2017 at 1:40 PM Dustin Farris <dustin...@gmail.com> wrote:
Well written and broadly addresses everything I've seen people asking about lately (including me).

Elm's pragmatic march of progress is important to me and my team.  Glad to see this highlighted.

Dustin

Sent from my iPhone

On Apr 28, 2017, at 4:18 PM, Evan Czaplicki <eva...@gmail.com> wrote:

I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAORaYgZNhsfWKEELMrd%3DTKkwhLaWsrWxEceYD%2Br2S9f%3DCBgdww%40mail.gmail.com.

Emilien Taque

unread,
Apr 28, 2017, 5:27:39 PM4/28/17
to elm-dev
Hi Evan,
Thanks for writing this.
My reaction on "what happens when a user keeps a tab open for months?" in Servers paragraph. Looks pretty rare to me and an acceptable situation to force an app reboot (like, by comparing app version on client and server). So, I don't think it makes a good argument.

Otherwise, very promising!


Le vendredi 28 avril 2017 23:05:45 UTC+2, Daniel Bachler a écrit :
Nice to see this!

One big thing that I wonder about and that I was hoping might be answered in this document is what happened to the plan of supporting more Web Platform Apis (e.g. things like binary file uploads etc)? Is that something that is on the horizon for after the current focus you outline in the FAQ or have your priorities shifted away from that for a longer time?

The 0.17 release notes from pretty much a year ago had a lot of wording suggesting this would be a focus for the next few months and it would be great to know how you think about this today. Thanks!


On 28 April 2017 at 22:52, Richard Feldman <richard....@gmail.com> wrote:
This looks fantastic - love it!
On Fri, Apr 28, 2017 at 1:40 PM Dustin Farris <dustin...@gmail.com> wrote:
Well written and broadly addresses everything I've seen people asking about lately (including me).

Elm's pragmatic march of progress is important to me and my team.  Glad to see this highlighted.

Dustin

Sent from my iPhone

On Apr 28, 2017, at 4:18 PM, Evan Czaplicki <eva...@gmail.com> wrote:

I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

Evan Czaplicki

unread,
Apr 28, 2017, 5:28:34 PM4/28/17
to elm-dev
Daniel, after 0.19 I think it makes sense to try to go through and do some more web platform APIs.

I have explored some of the most commonly requested APIs quite extensively, like localStorage and IndexedDB, and concluded that "a simple wrapper" is not the right way to go. I think that requires a focused design process on "storage" that takes into account synchronizing data with servers, versioning, etc. Point is, the fact that folks did not see a release when they wanted does not mean that no work was done.

Anyway, I agree that it could be good to talk about this in this document. Thanks for the suggestion!

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAELHGBB-rx0ifzNfvPQtVnRre65yPRBtgrveUCrk7h0%2BkML1og%40mail.gmail.com.

Evan Czaplicki

unread,
Apr 28, 2017, 5:38:08 PM4/28/17
to elm-dev
Emilien, the rate of forced refreshes would be the rate at which you release any sort of update. That can be daily in many companies.

I use pandora, and it feels like I have to refresh the page nearly every day, sometimes multiple times. This seems like a bad experience, especially if you have any "creation" going on in the website, like writing.

So say you release changes once a week. This raises questions:
  • What happens while the servers are transitioning? If one request is routed to a new server, but another to an old one, what happens?
  • What happens when someone is writing a comment while this transition occurs?
  • Now we need some sort of storage thing where any past format can talk to any future format. How does that work?
I think it is naive to think that "having types on both sides" magically resolves the challenges of running client/server code, and I have not seen any compelling evidence that folks make high quality experiences just based on sharing types.

Richard Feldman

unread,
Apr 28, 2017, 5:40:35 PM4/28/17
to elm-dev
My reaction on "what happens when a user keeps a tab open for months?" in Servers paragraph. Looks pretty rare to me and an acceptable situation to force an app reboot (like, by comparing app version on client and server). So, I don't think it makes a good argument.

That's a good point. I had that same reaction but didn't think much of it.

Put another way, most of us aren't GMail. ;)

Might be more effective as "there are non-obvious things to think about, for example [people who don't close tabs]."

Someone on Slack mentioned the "compile on web workers" thing - I've heard people ask about that before. Might be worth a link? (Then again, you have to draw the line somewhere.)

Chad Woolley

unread,
Apr 28, 2017, 6:04:56 PM4/28/17
to elm...@googlegroups.com
We are still most eagerly awaiting improvements to the elm-package workflow and addressing some of the issues reported on `elm-package`.  I know you have some exciting and innovative plans in this area, but it would be great to get a hit when searching this document for "packag" :)

Thanks,
-- Chad

On Fri, Apr 28, 2017 at 1:18 PM, Evan Czaplicki <eva...@gmail.com> wrote:
I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--

Erik Lott

unread,
Apr 28, 2017, 7:31:31 PM4/28/17
to elm-dev
The What is the timeline? paragraph sounds as if you're defending your approach to language design, or responding to criticism. It will read better if you changed the absolutes (this is the right way, and that is wrong way, everyone thinks x)  to "This is how I like to approach x".

Dustin Farris

unread,
Apr 28, 2017, 8:15:59 PM4/28/17
to elm...@googlegroups.com
I agree with Erik—the first bit was a bit negative/defensive.. but that may just be a reflection of some of the threads I've read lately.

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/97491808-27e8-45bb-b383-3b04a53b203b%40googlegroups.com.

Dustin Farris

unread,
Apr 28, 2017, 8:51:35 PM4/28/17
to elm...@googlegroups.com
... re-reading the first paragraph, if this was said in a talk or something I think folks would be nodding their heads in general. 

But in the context of recent threads on /r/elm and elm-users, it reads as a retort—some may find that off-putting. 

Sent from my iPhone

On Apr 28, 2017, at 7:31 PM, Erik Lott <mreri...@gmail.com> wrote:

--

Erik Simmler

unread,
Apr 28, 2017, 9:04:57 PM4/28/17
to elm-dev
> > Looks pretty rare to me and an acceptable situation to force an app reboot
> What happens while the servers are transitioning? If one request is routed to a new server, but another to an old one, what happens?

This is actually a very easy problem to encounter. Unless you are careful to ensure backwards and forwards compatibility between old and new client/server code, some number of users WILL get undefined behavior during a deploy. I can imagine scenarios where you could have more than two versions at a given moment.

In these cases, a naive dependance on matching types could actually be even worse. To maintain any semblance of of the robustness Elm is known for, we'd need some mandatory scheme to migrate data across differing sets of types... which I can imagine quickly coming to resemble certain serialization/deserialization libraries.

I don't think anyone is claiming Elm's front end platform coverage is where we'd like it to be. Officially taking on another platform isn't going to help that effort.

All that said, I'm still going to be experimenting with jamming Elm into a few random places it wasn't designed to go. For science! :)

Mark Hamburg

unread,
Apr 28, 2017, 11:45:25 PM4/28/17
to elm...@googlegroups.com
A timeline doesn't necessarily need dates. Well, I guess to be a true "time" line maybe it does, but a roadmap doesn't. What matters as much is some sense of sequencing and priorities. Are fixing runtime exception generating bugs priorities or is this just something that people should expect to code around? There are vocal contingents asking for binary data support and were expecting some action in the past based on last summer's talk about the overall web APIs and based on hints in things like the HTTP modules. Now, it seems the perfect is the enemy of the good and other distractions have taken hold and the answer is that maybe some progress will get made on some web APIs after 0.19.

So, what is on the roadmap this document lays out? An indication that potentially big changes are coming to the way one writes SPAs. "a much nicer alternative to that 'routing' layer". Bravo if it really is nicer though it will also help if it really is just an alternative, since, as the recent talk from the group building a PLC IDE and heavily using Elm FRP showed, sometimes the Big Secret Thing also blows up everything one was doing.

But the 0.17 changes also call for some assessment as part of laying out a roadmap. Effects managers feel a bit like an abandonware effort. Remember when Phoenix was going to be a prime use case? Why isn't there a Phoenix effects manager in the Elm package repository? There's been effort but it's apparently been stymied. How do you feel effects manager have worked out? Were they the right idea or were they just an interesting idea? Understanding how you grade the past helps people understand how you think about the future. The guide used to talk about more coming soon and now says nothing. Should that change be taken as indication of rethinking?

Consider that half of your roadmap — which lays out virtually nothing about the plan going forward beyond 0.19 — is about telling people "Don't do this". It's not about where you want to take Elm or how you want to get there. It's about telling people not to pursue particular projects. Maybe typed FP on the server isn't about sharing types between the browser and the server but about leveraging common code and providing the benefits of typed FP — there are benefits to it, right? ;-) — to a world that is currently heavily JavaScript running on node.js. Is Elm unsuitable to the task of running in a node environment?

This document isn't really a roadmap. 25% of it talks about the very next release — essentially what you are working on now — and 75% is about saying no to timelines, no to Elm on the server, and no to efforts to take Elm to other platforms. Thank you for writing this. It was clarifying about your thinking. It doesn't, however, answer a lot of the questions that seem to come up routinely on Elm discuss or if it does the answer needs to be read as "if you need X, go elsewhere because it's not even on the roadmap for Elm".

Mark

On Fri, Apr 28, 2017 at 1:18 PM, Evan Czaplicki <eva...@gmail.com> wrote:
I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

Emilien Taque

unread,
Apr 29, 2017, 2:14:30 AM4/29/17
to elm-dev
Yes, that's a more convincing argument. Has to be versioned like a semantic API, in a way. 
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

Carlton Gibson

unread,
Apr 29, 2017, 9:20:03 AM4/29/17
to elm-dev
Hey Evan,

As a jobbing and very happy Django developer, just trying to use Elm in the browser, I found the FAQ very helpful.

The hints on SPAs were very handy.

As a data point: I recently had to "reconstruct" the story about e.g. Cmd.map from experimentation and Older versions of the docs — that stuff, and those examples, are not present in the 0.18 versions. I had worried we were building on a dead end. So, it's good to see that confirmed as a good approach.

(I still wonder why that was taken out of the docs..?)

Thanks!

Keep up the good work.

Mark Hamburg

unread,
Apr 29, 2017, 10:49:32 AM4/29/17
to elm...@googlegroups.com
I was very negative in my review of the piece because I judged it as a roadmap.

On the other hand, if instead you jettisoned everything but the SPA section and then talked about how you believe SPAs should be built and how to do that in 0.18 until 0.19 arrives, that would provide real and useful guidance to the community.

Mark

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

Max Goldstein

unread,
Apr 29, 2017, 12:44:55 PM4/29/17
to elm-dev
Mark, I see where you're coming from (though I don't approve of yelling at some guy on the internet who's giving you software for free). The roadmap is helpfully unhelpful. I would paraphrase it as:
  • You can build a pretty-good webapp in Elm 0.18
  • You'll be able to build a slightly better webapp in 0.19, likely but not certainly because of these features
  • If you want to build something other than a webapp (or library to support a webapp), Elm is not for you in the near future.
Sometimes, knowing what isn't planned it much more helpful than knowing what is.

Dustin Farris

unread,
Apr 29, 2017, 12:54:25 PM4/29/17
to elm-dev
Evan,

I recommend treating each “page” as a separate Elm module

Do you mean as a separate Model-View-Update that is hooked into?

I am trying to refactor to follow this guidance, and ending up with something like:

type alias Model =
    { loginPage : Login.Model
    }

update msg model =
    case msg of
        LoginMsg msg_ ->
            { model | loginPage = Login.update msg_ model.loginPage }
        UrlChange location ->
            { model | currentRoute = parsePath location }

view : Model -> Html Msg
view model =
    case model.currentRoute of
        Just LoginRoute ->
            Html.map LoginMsg (viewLoginPage model.loginPage)

viewLoginPage : Login.Model -> Html Login.Msg
viewLoginPage model =
    ...

I realize this thread isn't for refactor help, but thought you would be interested in how I am interpreting the document—and I'm curious to know if I have understood it correctly.

Dustin

Evan Czaplicki

unread,
Apr 29, 2017, 3:40:06 PM4/29/17
to elm-dev
I will try to add a section on "web platform" stuff.

I share progress on 0.19 on this list, and as I have said before, I will be sharing more details as they become available. The goal of doing this is so that people know what's up as early as possible and surprise will be minimized.

Mark, I need you to be able to regulate your posts on this mailing list. This is your warning. I recommend waiting a bit after writing to post and trying to make things both more concise at least.

Part of what is frustrating about creating a document like this is that I knew people would react this way. "Great, more information, but I wanted even more information. Fucking guy sucks!" I'm certain all the "what about X?" will appear as issues after I publish it more widely, and part of my point is that there's not always a clear answer if you are trying to design well. Anyway, it's all predictable and obviously will happen more times, but elm-dev is "my workplace" to some extent and I cannot have strangers yelling in my workplace.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/7db8bdf6-ef02-40a0-a3bd-e2032951a3dc%40googlegroups.com.

Erik Lott

unread,
Apr 29, 2017, 4:22:22 PM4/29/17
to elm-dev
Dustin, I posted some example spa code in this thread: https://groups.google.com/forum/m/#!topic/elm-discuss/WDDrFq-uP58

Noah Hall

unread,
Apr 29, 2017, 4:23:23 PM4/29/17
to elm...@googlegroups.com
Some feedback that will be helpful for me, from the perspective of
using this document to answer questions:

- tl;dr lists like in the "0.19" part is super helpful, particularly
in the context of a workshop.

- Defining meaning of things like "server-side rendering" would be
particularly helpful. Quite often people will say "When will Elm have
X?", and then what they call X, we call Y, and it sometimes take a
while to connect the two. Descriptions make it easier for people to
call Y the right name in the context of Elm.

- A grouping of each big heading with their promixity would be good.
E.g the 0.19 stuff should be in "Next release", the "Can I use Elm on
the server?" should be in the "distance future", and then "Elm compile
to X" should be in "distant distant future/never". This will help me
get across the approx priority of certain goals to people.

- The note in "How do I make a single-page app?" would be better at
the top, as a generalization across everything in this document.

- Some of the longer-form explanations are good, but I think they
should maybe live outside of the main roadmap items. E.g, the advice
regarding checking what features they actually need with regards to
SPAs
>> email to elm-dev+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elm-dev/7db8bdf6-ef02-40a0-a3bd-e2032951a3dc%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elm-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-dev+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elm-dev/CAF7GuPE-TvF8jtS4VjWmZdwnHjUGSb67PiwBWDJzz_yF0Kr7OA%40mail.gmail.com.

Dustin Farris

unread,
Apr 29, 2017, 4:43:59 PM4/29/17
to elm...@googlegroups.com
Erik, I don't know how I missed that post.  It is very helpful. Thanks for writing it in the first place, and for linking to it here.

Evan, sorry to have trolled dev with a users concern.

Dustin

On Apr 29, 2017, at 1:22 PM, Erik Lott <mreri...@gmail.com> wrote:

Dustin, I posted some example spa code in this thread: https://groups.google.com/forum/m/#!topic/elm-discuss/WDDrFq-uP58

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Dustin Farris



Brian Slesinsky

unread,
Apr 29, 2017, 11:35:38 PM4/29/17
to elm-dev
As someone who occasionally drops in to see what's going on with Elm, this is just what I was looking for.

typo alert: "evaluating Elm may need need"


On Friday, April 28, 2017 at 1:19:11 PM UTC-7, Evan Czaplicki wrote:

Evan Czaplicki

unread,
May 1, 2017, 3:56:55 PM5/1/17
to elm-dev
Thanks Brian :)

I added a section about "the web platform" and the plan is to post it more broadly tomorrow.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/1600eb0e-621b-4e17-90c9-c486c7e4aca1%40googlegroups.com.

Evan Czaplicki

unread,
May 1, 2017, 7:03:43 PM5/1/17
to elm-dev
I decided to just share it now. If it seems relevant to some discussion, feel free to link to it.

Folks who are talking to lots of new folks, LMK if you begin to see patterns of reactions based on it. Can revise based on data.

Zachary Kessin

unread,
May 2, 2017, 3:21:40 AM5/2/17
to elm...@googlegroups.com
Quick question, could you add something about private package repos. I can imagine that if a big company were to adopt elm they would want to have a way to "Publish" internal modules via the elm package system but only do so internally.

Zach
ᐧ

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPHNZ1Z%2BOAX0%2Bhn_MkqQTtDRP4fxRicvYtUhywvUH7u5zg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Zach Kessin
Teaching Web Developers to test code to find more bugs in less time
Skype: zachkessin

ben.fishe...@gmail.com

unread,
May 2, 2017, 11:41:06 AM5/2/17
to elm-dev
As someone that's only experimented with elm a bit in my own free time, the goals of 0.19 have me very excited and hopeful that I'll be able to exclusively use elm on my next UI project at work. Thanks for sharing Evan!

-Ben 


On Tuesday, May 2, 2017 at 12:21:40 AM UTC-7, Zachary Kessin wrote:
Quick question, could you add something about private package repos. I can imagine that if a big company were to adopt elm they would want to have a way to "Publish" internal modules via the elm package system but only do so internally.

Zach
ᐧ
On Tue, May 2, 2017 at 2:03 AM, Evan Czaplicki <eva...@gmail.com> wrote:
I decided to just share it now. If it seems relevant to some discussion, feel free to link to it.

Folks who are talking to lots of new folks, LMK if you begin to see patterns of reactions based on it. Can revise based on data.
On Mon, May 1, 2017 at 12:56 PM, Evan Czaplicki <eva...@gmail.com> wrote:
Thanks Brian :)

I added a section about "the web platform" and the plan is to post it more broadly tomorrow.
On Sat, Apr 29, 2017 at 8:35 PM, Brian Slesinsky <bsles...@gmail.com> wrote:
As someone who occasionally drops in to see what's going on with Elm, this is just what I was looking for.

typo alert: "evaluating Elm may need need"

On Friday, April 28, 2017 at 1:19:11 PM UTC-7, Evan Czaplicki wrote:
I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

Wojciech Piekutowski

unread,
May 2, 2017, 3:42:57 PM5/2/17
to elm...@googlegroups.com
Hi community!

Thanks Evan and everybody else for putting so much effort into everything you do for Elm! This piece clarifies a lot.

I'd like to share one thought about the localStorage section.

One of the things that are great about the html package is that the view part is pretty much obvious for anybody familiar with the HTML standard. I think one of the contributing factors is the fact that you decided to use function names that resemble 1:1 HTML tags interface (where it made sense). I believe the same design decision contributes to the popularity of the svg package – Elm starts to be known as a great tool to work with SVG.

Here's a hypothesis based on the above: Having web platform APIs exposed in a similar "barebones" way, with some modifications to make them feel like first-class citizens in Elm, could reduce the barrier to entry for existing JS devs. If localStorage turns out to be inadequate (as a simple storage solution), there should be enough use cases available to design a general purpose storage library based on these data points.

On 28 April 2017 at 22:18, Evan Czaplicki <eva...@gmail.com> wrote:
I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPGqEk1vM2DJwXn39oE0YDqeYropfHdbj-sKD-iAPU1HWA%40mail.gmail.com.

Richard Dodd

unread,
May 4, 2017, 12:55:46 PM5/4/17
to elm-dev
tl;dr
  1. even to make a bare-bones api, choices must be made
  2. localStorage should be a lot easier than indexeddb
I'd say that getting a localStorage api is MUCH easier than doing IndexedDB, since the api is synchronous and has a much smaller surface area. It's definitely worth doing that API before looking at indexedDB, because it gives folks a simple solution for odd bits of data to store clientside, and I would imagine is harder to get wrong.

An option then is to encourage folks to create storage solutions on top of it in the ecosystem and see what patterns emerge, with these pattern perhaps influencing the final indexeddb implementation.

I posted a rather long and probably boring article about indexeddb, and the real choices that must be made when designing the library. What is a function, and what is data? For example, I experimented with database schema being data, and a diff generated to convert between versions. Also transactions being `transaction : List Query -> List QueryResponse`, instead of using functions somehow. Personally I got stuck on how to extract the known types out of `List QueryResponse` without using `case` and `Debug.crash` for dead branches (I probably have the wrong data model).

IndexedDB API is hard to use, and harder to wrap, but I think has the potential to be very easy to use provided that the api is done right.


On Tuesday, May 2, 2017 at 8:42:57 PM UTC+1, Wojtek Piekutowski wrote:
Hi community!

Thanks Evan and everybody else for putting so much effort into everything you do for Elm! This piece clarifies a lot.

I'd like to share one thought about the localStorage section.

One of the things that are great about the html package is that the view part is pretty much obvious for anybody familiar with the HTML standard. I think one of the contributing factors is the fact that you decided to use function names that resemble 1:1 HTML tags interface (where it made sense). I believe the same design decision contributes to the popularity of the svg package – Elm starts to be known as a great tool to work with SVG.

Here's a hypothesis based on the above: Having web platform APIs exposed in a similar "barebones" way, with some modifications to make them feel like first-class citizens in Elm, could reduce the barrier to entry for existing JS devs. If localStorage turns out to be inadequate (as a simple storage solution), there should be enough use cases available to design a general purpose storage library based on these data points.
On 28 April 2017 at 22:18, Evan Czaplicki <eva...@gmail.com> wrote:
I wrote this document the other day. I guess things are far along enough with 0.19 that it seems reasonable to put these things in a public place.

Before I share more widely, I'm curious what folks think.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

Frank Bonetti

unread,
May 10, 2017, 3:12:32 PM5/10/17
to elm-dev
Evan,

Thank you for writing this document. I think the more information you put out, the more reassured the community will feel.

> First, many people think expanding “web platform” support is easy. “Just copy the JS API into Elm as tasks!” The whole point of Elm is to rethink common problems and try to do better. Figuring out how to do it “the right way” in a typed functional language with no side-effects takes time.

While I understand that you want to do things the right way, and that certain APIs like IndexedDB are inherently difficult to port to a pure language, there are some APIs that are low hanging fruit and don't require much thought. For example, the `window.alert()`, `window.confirm()`, and `window.prompt()` functions could converted to Tasks. In fact, I already wrote the code for it and opened a PR. The battery status API and window.open() function could also be ported over in a straightforward manner.

Given that there are 734 web API interfaces attached the window object, and that you only want the highest quality implementation for each API, it would be totally unreasonable to expect you to wrap every one these yourself. As the creator of Elm, your time is finite, extremely valuable, and better spent on solving big picture problems. Given that constraint, I propose the following solution:

  1. Allow and encourage community members to write their own Native implementations for the web APIs they use. Ask them to open Native Review requests via https://github.com/elm-lang/package.elm-lang.org/issues.
  2. Delegate the responsibility of reviewing these Native packages to a handful of trusted members of the Elm community. Once again, your time is strapped, and is better spent on improving the language.
  3. Reviewers should give timely feedback, even if just to say "this will be reviewed within the next 2 weeks". If the package has no chance of ever being merged, close immediately and explain why.
  4. Once all the package has been signed off by the reviewer, give the reviewer the authority to whitelist the package.

You are one person. You've created a language and ecosystem that real people and real businesses rely on everyday. I can't even imagine the pressure you're under. That's why I think the best way to move forward, and the best way to ensure the continued growth of the language, is to start delegating low-level tasks to other people that you know and trust.

Richard Feldman

unread,
May 10, 2017, 3:25:42 PM5/10/17
to elm-dev
Frank, we tried what you are proposing two years ago, and it went horribly.

Please respect that elm-dev has a clearly-defined scope which explicitly excludes lobbying others to change how they work. :)
Reply all
Reply to author
Forward
0 new messages