This post proves create-on-GET is untenable

CommitsTo
1

It turns out that when editing a post in a Discourse forum, Discourse does GET requests (ie, fetches the URL) over and over again with every keystroke as you type it. Check out poor Alice’s commits.to gallery on our staging server: http://alice.commitsto.review/ – It’s empty right now as I type this paragraph.

But when I start typing a commitment for her like so:

http://alice.commitsto.review/show_off_how_bad_create-on-GET_can_be

Then, yeah, unmitigated disaster.

image
image.png1180×667 53.1 KB

I’m inclined to say that that alone is all the argument we need for dropping create-on-GET.

(If that’s indeed the conclusion, which, btw, @bee thought was obvious all along, then it will be super frustrating the amount of work we put in to countering spam bots and crawlers so that create-on-GET could function at all. I suppose eventually spam bot mitigation will be valuable anyway but we could’ve put it off till way later without create-on-GET.)

Quick background: I got excited about create-on-GET for the reasons described in the spec. Then I started having doubts when I realized that you can’t count on the person you’re typing to to click on your URLs so you really need to be in the habit of clicking them yourself. And if you’re doing that then one more click to create the promise may be no big deal.

2

Hahaha! Not laughing at you, just at the silliness of having one commitment for every prefix of your intended title. =)

Yes, doing one more click to create the promise seems very sensible, especially in relation to the other idea about having commitments be “pending” at first, so you have an opportunity to set the due date appropriately.

1 Like
3

Turns out @chrisbutler solved this without needing to kill create-on-GET. I don’t know if it’s tenable long term but for now it lives on!

4

How, exactly?

5
1 Like