jQuery Data Link considered harmful
“Considered harmful” has always been good link bait.
I am not trying to start a flamewar, but merely express my concerns over the recent decisions of the jQuery team to actively endorse plugins that deserves no special treatment from any other plugins out there.
If you have different opinions, please do respond in the comments or write a blog post expressing them.
Extending globals with interesting side effects
Prototype allowed us previously unseen productivity as the library matured and evened out the playing field between browser capabilities, quirks and different interpretation of specs.
But, Prototype is not all double rainbows and have certainly made some mistakes that they’re still paying for. Over the years the Prototype library has been getting a lot of grief over extending the native prototypes and extending the DOM, both of which are considered bad practices.
For a history lesson on why all of this is considered bad practice:
What the whole discussion about not extending globals and not modifying objects you don’t own boils down to is this:
- Collisions causes very hard to find bugs
- Avoiding collisions is very, very difficult
- DEVELOPERS DON’T LIKE SURPRISES
Data in the DOM is the new extended prototype ^h global scope
Fast forward to present day.
There is plenty of good learning material about jQuery to absorb out there, both on the internet and even in bookstores and libraries.
The jQuery team has been very vigilant in not leaking anything into the global scope, not extending the globals or extending the DOM. The api is documented and very thoroughly tested.
On the whole, jQuery tries incredibly hard to not create collisions and not surprising it’s users.
Sure there are still a few surprises: jQuery custom events are using the DOM to store data about subscribers to specific events. But, that’s actually reasonable compromise when you consider that they found it important to have the events bubble and be just like the native events of the DOM. It is unfortunate that they’re simply stored under a name of “events”, and doesn’t use a more unique key like “jquery-custom-events” … I’ve already discovered one clash with this, leading to unexpected side effects.
Clearly, the maintainers of jQuery have taken the lessons from the mistakes of Prototype to heart.
jQuery Data Link plugin
The jQuery team is now making the same mistakes that the Prototype team got chastised over, maybe not in jQuery Core itself, but with accepting overly complex and mostly untested plugins as official ones.
We’ve seen this pattern before … we’ve agreed that having a direct and strong coupling between the DOM and our code is just plain stupid.
Data Link makes heavy use of the
changeData event introduced in jQuery 1.4.3, and seems to work almost automagically… too automagically.
I am surprised that someone as experienced as John Resig is actually endorsing this misguided practice.
The plugin has even made it’s way into the official documentation of jQuery, even though it can by no stretch of the imagination be considered of the same quality as the rest of the official jQuery code.
Data Link has no automated test cases. Go see for yourself at GitHub.
If there are no test cases, how are we supposed to assess the maturity of the code? How are we going to contribute to it it, without causing defects?
Unsurprisingly, Data Link originates from Redmond, the same company that “blessed” frontend developers with the much hated ViewState and hijacking as much as they could in our browsers, effectively creating a breeding ground for collisions and very strong ties between the client side code and server side code.
Collisions made easy with Data Link
I present to you: an easy to follow recipe for creating collisions with Data Link.
There’s plenty documentation on how to achieve this on the Data Link plugin page on GitHub.
Now imagine that you’d like to use some of the elegant features of HTML5, like placeholder attribute. Modern browsers already support this, and there are several good examples on how to retrofit older browsers to enhance the user experience.
Now imagine that you’re using two different plugins that rely on Data Link, and you’ve got a recipe for some really, really hard to find collisions.
Simplicity and uni-lateral control over open source
In a comment to the question of How could YUI3 improve its image compared to jQuery John states
Simplicity is far harder to get right than building complex applications.
He couldn’t be more right.
Data Link is by no means simple, and it’s use will lead to a a lot of interesting collisions.
Accepting Data Link as an official plugin and having jQuery endorse it, is in my opinion a mistake, especially considering it’s maturity.
In the very same comment, John also states
Yahoo completely controls the direction and destiny of YUI. This should not be the case …
This seems to suggest that we can talk Resig out of actively pushing Data Link, and focus his efforts on making jQuery itself the best it can be.
What do you think?