jQuery and flXHR… what’s next?
Update: Upon further discussion with some jQuery devs, I’ve decided my hard stance was over-reactionary and that further discussion with them is warranted and appropriate. Please take the rest of this post and comments with a grain of salt, and my apologies for any ill-will it may have caused. For my part, I will be exploring (and assisting them in finding) ways that jQuery can be improved which satisfy all involved (including hopefully to the benefit of flXHR and our community).
I learned some saddening news just now, related to close-mindedness on the part of the jQuery devs. I filed this ticket on behalf of our project and our community a week or two ago:
http://dev.jquery.com/ticket/3087
The problem is that jQuery’s architecture makes it difficult (but not impossible, see http://flxhr.flensed.com/demo.php#demo12) to adapt in a replacement for XHR. Many of the other major frameworks provide a way to do this, meaning they recognize the need to play well with others. At first, things seemed promising. The fix turned out to be a really simple one, like 5 simple lines of code, and this patch was provided:
http://dev.jquery.com/attachment/ticket/3087/ajax_transport.diff
I then followed up by asking if that patch would make it into a jQuery release. As you can see by the final comments on that ticket 3087, the jQuery devs have decided that flXHR and its effort to provide an XHR replacement is too narrow and is irrelevant since it’s only for “one user”. I know that’s not the case, because I know there are hundreds of you out there using flXHR already, and I’m sure some of you are trying to make it work in a jQuery environment. For what it’s worth, until this debacle, jQuery was my library of choice. This changes my whole opinion. I guess they’re so busy they just can’t be bothered with 5 simple lines of code patch.
As I mention above, the good news is that there’s still a workaround, though not as graceful as hoped, as illustrated with demo #12. Basically, this is the catch-all example for how *any* page or set of code can be changed to use flXHR, without the existing code even knowing it, by simply using the dynamic nature of the Javascript language and overwriting the native XHR object with flXHR. It’s actually really quite simple, but it’s a little more “heavy-handed” and brute-force in nature. But there are some libraries and code where this will be the only choice (like jQuery!), so there ya go.
Anyway, I was hoping maybe to stir up some sentiment from anyone here reading this blog to perhaps feel like they could make a counter-statement on that closed ticket, just so jQuery devs know that it’s indeed not just “one user” they so casually dismissed. You have to have a jQuery dev account to comment, but it’s easy to sign up here: http://dev.jquery.com/register
I’m sure this won’t really make a difference in their mind. But on principle alone, I think their poor social skills are something that should at least be called out and kept to task. [I would like to retract this previous statement, as it's come across as mean and that was not my intent.] And maybe it’ll help them re-consider in the future when other projects are hoping to coordinate with their framework.
Why not just replace the XMLHttpRequest object with your custom one? You wouldn’t have to modify any libraries and the user would get the full benefit.
I’ve created fake XMLHttpRequest objects in the past – simply saving a reference to the old object and adding in my new methods (to support cross-domain requests). It certainly sounds like something similar can be done here.
“But on principle alone, I think their poor social skills are something that should at least be called out and kept to task.”
I think that’s just being mean. We discussed this extensively on the mailing list – with you – and the only possible use case we could come up with was possibly doing mock unit testing (external to your library). But once it was determined that not even unit testing was a valid use case there really wasn’t much left.
A point to consider is that for every single change we make to the API (and every new API point we add) we have to document and support it indefinitely – if we were to ever change it or remove it we would have to provide alternatives. We never take API changes lightly – which is why we always look for multiple use cases whenever we add a new one. At this point, this change does not warrant it. Especially since when alternatives exist.
Comment by jeresig — July 3, 2008 @ 9:08 am
>> “Why not just replace the XMLHttpRequest object with your custom one? ”
In fact, that’s exactly what I’ve already advised the users to do, using the method in Demo #12 (http://flxhr.flensed.com/demo.php#demo12)
This works just fine, you’re right, but the problem is that it relies on a rather heavy-handed approach (brute force replacement of native browser functionality), as opposed to simply changing, extending, or overriding a framework defined function.
It puts the onus more on the author to be sure that this is something they are doing correctly, and makes the support of it (from my project’s end) more risky. Authors choosing this approach have to be a lot more sure they are not causing other types of difficult-to-track-down bugs and other such things, as surely browser vendors don’t really intend for their native code to be overwritten carte blanche.
It just makes things more complicated and less flexible to do it that way. For instance, imagine that there was a page with multiple toolsets in it, only one of which the author wanted flXHR to be used in (for performance or other reasons). By overwriting the main native one, they have no choice.
It’s one thing to overwrite a native XHR object for unit testing under controlled circumstances… it’s quite another to suggest to the general public that this is the best method of adapting one framework with another.
Moreover, the whole reason I designed flXHR the way I did (as a direct API compatible drop-in replacement) was so that user’s could take advantage of the already great intelligence built into the different frameworks, including jQuery. I wouldn’t have wanted to basically remove a huge chunk of what jQuery does, and while this doesn’t do that exactly, it does move a lot closer to that then I would have hoped for. I spent a considerable amount of time during early dev on this project to make sure that what I developed would play nicely with the JS frameworks. That was my attempt to be respectful of what had come before me, rather than trying to do casual end-arounds of that body of work.
>> “I think that’s just being mean. We discussed this extensively on the mailing list – with you – and the only possible use case…”
I apologize for coming off as mean. That was not my intent.
The point about social skills is more directed at the impression I got of how the dev team handled my request, but the wording was perhaps a little poor and reactionary on my part than it should have been.
From only the few email exchanges and comment posts (maybe less than 10 in all), I had little to gather my opinions on how cooperative the jQuery dev team is or would be. And I would believe that the dev team similarly had little to go on in making the decision.
What I do know is that things seemed positive for a little bit, but as soon as I mentioned flXHR, the ticket was summarily dismissed as not having much relevance. For a project like flXHR that’s just starting out, I hope you can understand why the timing and handling of that seemed rather dismissive, with the phrase “not enough for just one person”.
Moreover, I fully respect any dev team’s right to discuss and make decisions about their own codebase. But I felt like there was a good case for why the change would help make jQuery more “friendly” with other efforts, such as my project (or plenty of others that came before mine). And I felt like that benefit well outweighed the minor point that 3 lines of code were moved verbatim into a separate function. I didn’t ask for a functional change to jQuery, I just asked for a minor code organization change, one which in many circles can be argued as proper anyway (though that is not enough by itself to warrant a change, I agree)
A snarky comment was made that just because the other frameworks do it doesn’t mean jQuery should do it. That seems a little elitist and dismissive to me as well. Again, I wasn’t part of any development on any of those frameworks, but I can see that there surely was a reason (and I think a good one) why all the other major ones *did* make the decision to separate out the transport layer into a factory method. Or are we just to assume that “the 4 out of 5 dentists who recommend this toothpaste” must all be wrong?
How have you already concluded that this is “the only possible use case”, with such a brief set of exchanges and maybe 6 different opinions (5 of which are on your project) on the topic?
Consider also that as the new generation of browsers (IE8, FF3) are diverging even further from the standard XHR (like IE including the whole XDR thing), the need for authors and these popular frameworks to be flexible in what transport layer is being used ought to be a worthy concern, as it will probably become more and more needed as time goes on.
Really, with flXHR, I’m trying to make the larger point to the webdev community that the transport layer OUGHT to be hot-swappable, with a standardized API, so that troubling concerns such as cross-domain communication *can* be addressed without a bunch of ugly inefficient workaround code. This kind of thing alone ought to be music to framework’s ears, because it cuts down on the amount of forked mess your code has to deal with.
Hot-swappable, drop-in replacements are only as useful as the pieces of code they are dropped into, and jQuery’s code organization makes that much more difficult unfortunately. I had just hoped that jQuery would be more able or willing to come play nicely in the same sandbox as the rest of us, rather than keeping this project, and all others like it, at arm’s distance.
Again, my reaction with this post, what I said in the ticket, and in this comment, was that it didn’t feel like the most important part of my concerns were “extensively” taken into account. It felt like flXHR was being dismissed as being small and irrelevant, rather than the decision being more based on the bigger issue of cooperation and interoperability between various different open-source efforts, and on future-proofing code as much as possible.
If those discussions DID happen, and I just wasn’t part of them, and jQuery still felt like there was no need for them to participate in that effort, the least you could have done was better explain that than just call this project’s effort, which I’ve put lots of time into, “just one person”.
Comment by Shade — July 3, 2008 @ 2:36 pm
You talk as if this is a done deal – it’s not, at all – we’re always open to further discussion and critical analysis. For example, I’m not sure why this blog post even occurred and didn’t happen on the jQuery-dev list along with the original discussion. Considering that, previously, the whole jQuery development community could participate in the discussion but now we’re limited to those who find this blog post.
It’s important to note that when we say “one person” it’s really just that there’s one (physical) person asking for this change. For example when we made internal API changes to how events were handled there were a large number of developers asking for this reorganization – backed with reasoned analysis and some solid patches. We worked with them to come up with an API that would work in the long-term and that we were willing to support. Any particular company, project, or organization doesn’t have any more weight than an other when it comes to jQuery – we’re not trying to squash your project, or some such, we just didn’t find evidence — at this time — to warrant introducing this *specific* API change.
Personally, I would much prefer a patch that has a holistic re-organization of the $.ajax() method. Breaking out the XHR creation into a new method is really only half the problem – what about things like cross-domain JSON/Script requests, which we handle in a completely different manner. Implementing your patch, as proposed, would prevent cross-domain JSON/Script requests from working correctly.
If such a patch had generic points for “creation”, “send data”, “wait for response”, and “handle response data” (possibly – just off the top of my head). That would be more optimal. But as it stands I worry about quickly applying a patch that’ll only solve part of the issues at play – and require an additional API change at a later time.
I’d love to continue this discussion on the jQuery-dev list and I’d invite you to help us in working to make an appropriate API change happen.
Comment by jeresig — July 3, 2008 @ 4:05 pm
I am glad to know the issue is not dead, but please understand the way the ticket resolution was worded it didn’t really leave me with that much hope as my first impression.
I too want to help make something work. Like I said, I never wanted to tell jQuery how to solve the problem. I just asked if there was a way to address my specific need, which either a small or even much more complex solution could have equally accomplished. My only real goal is that flXHR be able to easily integrate with any framework so that it’s a benefit rather than hindrance to the general web developer community. In doing so, I think it proves the larger point that pluggable XHR is a smart approach.
(Let’s face it, especially in the javascript framework world, a flash solution is not going to tend to be well accepted at first anyway. So my goal has been to remove as many roadblocks as I can.)
To the point about $.ajax, I agree that more refactoring can certainly benefit other things and serve other needs as well. And the more flexibility that is introduced, the better (as far as I’m concerned). But I did think, and still think, that even a smaller change (like the one that was proposed) could have been a valid incremental step in the right direction. However, if the devs at jQuery believe that a larger, more comprehensive change process is warranted, I would support that too, and even offer any help I can be in the process.
BTW, the reason (however unwise in retrospect) I posted *this* blog was not to start a fight with jQuery, but to bring my community up to speed and document what had happened. I didn’t want to hijack either that ticket thread or the mailing list with a fight that appeared (based on what I read) basically already over. As stated before, I should have been more careful in my choice of words, even here on my own blog.
I’m glad to hear that there’s willingness to work on a good solution for all involved. I’ll definitely be happy to participate in those discussions on the jQuery dev list.
Comment by Shade — July 3, 2008 @ 4:37 pm