Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for A Funny Thing Happened On The Way To The Future...

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.

by Mike Johnson at

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.


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.


by alex at

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.

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?