A Funny Thing Happened On The Way To The Future…

There’s a post on the fetch() API by Ludovico Fischer doing the rounds. As a co-instigator for adding the API to the platform, it’s always a curious thing to read commentary about an API you designed, but this one more than most. It brings together the epic slog that was the Promises design (which we also waded into in order to get Service Workers done and which will improve with await/async) with the in-process improvements that will come from Streams and it mixes it with a dollop of FUD, misunderstanding, and derision.

This sort of article is emblematic of a common misunderstanding. It expresses (at the end) a latent belief that there is some better alternative available for making progress on the web platform than to work feature-by-feature, compromise-by-compromise towards a better world. That because the first version of fetch() didn’t have everything we want, it won’t ever. That there was either some other way to get fetch() shipped or that there was a way to get cancellation through TC39 in ’13. Or that subclassing is somehow illegitimate and “non-standard” (even though the subclass would clearly be part of the Fetch Standard).

These sorts of undirected, context-free critiques rely on snapshots of the current situation (particularly deficiencies thereof) to argue implicitly that someone must be to blame for the current situation not yet being as good as the future we imagine. To get there, one must apply skepticism about all future progress; “who knows when that’ll be done!” or “yeah, fine, you shipped it but it isn’t available in Browser X!!!”.

They’re hard to refute because they’re both true and wrong. It’s the prepper/end-of-the-world mentality applied to technological progress. Sure, the world could come to a grinding halt, society could disintegrate, and the things we’re currently working on could never materialize. But, realistically, is that likely? The worst-case-scenario peddlers don’t need to bother with that question. It’s cheap and easy to “teach the controversy”. The appearance of drama is its own reward.

Perhaps most infuriatingly, these sorts of cheap snapshots laced with FUD do real harm to the process of progress. They make it harder for the better things to actually appear because “controversy” can frequently become a self fulfilling prophesy; browser makers get cold feet for stupid reasons which can create negative feedback loops of indecision and foot-gazing. It won’t prevent progress forever, but it sure can slow it down.

I’m disappointed in SitePoint for publishing the last few paragraphs in an otherwise brilliant article, but the good news is that it (probably) won’t slow Cancellation or Streams down. They are composable additions to fetch() and Promises. We didn’t block the initial versions on them because they are straightforward to add later and getting the first versions done required cuts. Both APIs were designed with extensions in mind, and the controversies are small. Being tactical is how we make progress happen, even if it isn’t all at once. Those of us engaged in this struggle for progress are going to keep at it, one feature (and compromise) at a time.

4 Comments

  1. Mike Johnson
    Posted July 3, 2015 at 2:15 pm | Permalink

    I’m sorry, Alex, but I just don’t see any controversy or FUD in the original article and I can’t understand why it would bring out this kind of response. It raised a few points that others have brought up, and I think it addresses them fairly. The “Backlash” section brings up a couple objections and suggests workarounds. From my reading of the mailing lists, it sounds more like a recap of what’s been going on.

    Are you sure you’re not just reacting unfairly to criticism you’ve received in the past? Perhaps your criticism would be best done in private by reaching out to the publisher and providing clarification.

    Web work is hard stuff, and you’re working to make it better. I think you do yourself a disservice by writing a post like this, which sounds a lot like “Web work is hard stuff, and I’m doing hard stuff, and you have no right to criticize me.”

    Keep doing good work.

  2. Posted July 3, 2015 at 2:38 pm | Permalink

    Hey Mike,

    I’m with you until you said “…addresses them fairly”. Lines like this ignore both the history and trajectory and make things harder:

    Because of the dubious success of some past efforts (the HTML5 Drag and Drop API stands accused of mediocrity, and Web Components of futility), a replacement for battle-tested XHR has incited perplexity.

    and:

    This proposal undermines the purpose a bit since fetch Promises won’t be totally standard any more. But maybe this work could influence a future cancellable Promise standard.

    The post also doesn’t call out that even without streaming, the current situation is better than XHR on large-body deserialization because it can be async (the methods return Promises) and off the main thread.

    Perhaps I am very sensitive about these issues, but that’s because I’m very sensitive to the fine balance that’s required to move things forward. Web developers assuming that hope is lost for Web Components or for Cancelability (which these seem to imply) misrepresent the trajectory and make life harder for those who are working to improve things. I know that’s hard to see from the outside, but it happens often enough that it needed a rebuttal; one I can link to in future. My goal was to call out the pattern (and the Publisher), not the writer. Apologies if I strayed from that mark.

    Regards

  3. Posted July 6, 2015 at 6:03 am | Permalink

    Hi,

    I’m Ludovico Fischer, the author of the original article. I was upset when my editor first pointed me to this post, because I felt I had been totally misread. I did not wish to imply any ‘derision’ for the work of standard developers or people who have worked on fetch. It would be helpful if you could point out the places that you felt implied irony or derision. In addition, if you wish to make corrections concerning technical misunderstandings in the article, my editor and I are totally available to post them. Feel free to contact me by the email address I left with the comment.

  4. Posted July 7, 2015 at 4:54 pm | Permalink

    Hi Alex.

    As the editor of the SitePoint’s JavaScript channel, I feel I have to reply to your post. I totally agree with Mike and I think you definitely overreacted to the article of Ludovico. It was nothing but a recap of what others have said about the Fetch API, either good or bad, and for the completeness of the information we included links to other articles discussing this topic. He wasn’t really critiquing the Fetch API. He pointed out a couple of issues but also how to solve them now. So, what’s wrong the article? By reading your post, I can definitely see that you took it personally.

    Besides, you mention this sentences:

    “Because of the dubious success of some past efforts (the HTML5 Drag and Drop API stands accused of mediocrity, and Web Components of futility)”

    but here the author is clearly saying something like “these are facts I’ve read/heard by several people” and not “I think this and that”. So, you can agree or not with this statement, but you should accept that some people might now like this or that API. There’s nothing harsh in that sentence.

    Moreover, you wrote:

    “I’m disappointed in SitePoint for publishing the last few paragraphs”

    Personally, and I think this is the approach of other editors at SitePoint, we don’t cut the throat of our writers. I might agree or disagree with a statement, but every author is free to write his/her thoughts regardless of what I think. As an editor, I check (at the best of my knowledge and possibility) that the article is technically correct, but I’d never remove a paragraph just because I or others agree/disagree.

    Finally, you wrote:

    “the good news is that it (probably) won’t slow Cancellation or Streams down.”

    I don’t really see how Ludovico’s article or any other critique can have so much power to do that. On the web what works survive, what doesn’t work will eventually be discarded or replaced. That’s the beauty of the web, isn’t it?