In the 15-odd years I've been doing client-side web development, I've seen precisely one piece of script on the internet that worked as advertised and was durable enough to consider including in one my projects. That exception to the rule is jQuery itself.
jQuery plugins, however, exemplify that golden rule. Every time I've tried to use one (being a hopeless optimist and breaking my own rule), I've been bitten hard and ended up either rewriting it from scratch or spending more time trying to get it to work in a reliable manner than it would have taken to rewrite it from scratch.
I have no idea why this has to be the case, but it is. Javascript you find on the internet is worse than worthless. As such, while it's a shame they lost their plugin site, we're all probably a little better off for having to write our own stuff for a while.
That sounds like an excuse for NIH. It's an easy one to make because there are so. many. bad. jquery. "plugins". But there are also excellent ones; for instance, it seems like a big waste of time to replace jQuery Cycle. Similarly, I'm 50/50 on implementing dynamic tables by hand and using DataTables, but it seems silly to say "never use DataTables".
It seems very unlikely that any truly useful jQuery plugins are lost from this though, it seems likely that any that are unrecoverable (or extremely difficult to recover) meet the description he is making.
I never used the "plugins" site; it was impossible to know which "plugins" were truly careful and well-designed libraries, and which were just extractions from some web designer's last portfolio site.
I think it's a bit unfair to suggest that all jQuery plugins have problems (I use the validation plugin and it is excellent for catching mistakes before a user submits a form and starts the backend processing). I see them as being in the same boat as WordPress plugins - there are some which are well maintained and up to date, and then a huge pile of others which were quickly hacked together and then never looked at again.
It's the same with CPAN, PEAR and anything else where you allow users to contribute additional separate components which aren't maintained by the core developers.
I don't know if it is because of the javacript implementations being historically so distinct among themselves, and I maybe weego exaggerated a little bit. But that seems to be true to some extent among javascript libraries.
I'm not a very a very experienced javascript developer, just the occasional user, but the malfunctioning third party script syndrom is still out there on the javascript world. Sure the situation might be better than in 1997 but still...
I wouldn't say CPAN is comparable, the standard is higher and the modules work without glitches in most of the cases.
The comparison with CPAN was more to do with the abandoned modules - if you go onto CPAN you'll find lots of modules which were created years ago and then never updated, but they still show up in search results.
(Author of DataTables here) Thanks! There are some fantastic plug-ins out there, such as qTip, ColorBox, jqGrid, SlickGrid and many many others. Personally I take great pride in trying to maintain useful, up-to-date documentation, a large battery of unit tests and just generally trying to make the software as useful as possible, for the job that it is intended to do.
So there are (hopefully :-) exceptions to the rule!
Legacy basically... When I wrote the first version of DataTables the company I was working fir then had strict coding standards that required the use of Hungarian notation, so I was "trained" in at at the time, and I've never wanted to break compatibility with old versions. v2 might see a clean break though (whenever I get the time to do that :-) ).
Don't bother breaking compatibility with old versions.
You want to know something that is 100x better? This exact comment on your FAQ page. More people will read it, understand you made that decision, and move on.
If someone cares enough they will fork it and change the variable names. But in reality it doesn't matter.
please don't do that. part of what makes using jquery plugins so horrific is that every new version is a "total rewrite" and/or drastically changes the API.
the API might use hungarian notation, and you might have fallen out of love with it, but so what? it's a pretty decent API and there's no real benefit to users in changing it. they'll all to have to update/rewrite their JS to stay up to date with the library for effectively no reason.
Thanks for the feedback - I really appreciate it. I'm currently in the middle of developing v1.9 of DataTables and backwards compatibility is key for me here. v2 is a good way off, and I'm certainly not committed to removing the hungarian notation (actually I find it quite useful personally). 1.x and the current API have been going since 2007 and is going to be supported for as long as I can see at the moment. If there are any breaking changes in v2, will be supported in parallel.
I know I don't want to update my own code for a new API on every release! Going back to the point of the OP there are certainly cases when writing custom code is beneficial for that reason, and equally (I believe) there are times when a tried and tested library such as DataTables is suitable.
I've found if the plugin has enterprise/business implementations, often that is a good indicator of durability.
Most of the jQuery plugins I've implemented involve me doing a proof of concept with the original plugin, then stripping it down or modifying it to meet any unmet performance or
Mixing plugins can be frustrating - it would be nice if some of them got together to do a plugin distro... it's the next logical extension.
I think there are a couple others trustworthy like backbone.js.
Most jQuery plugins were spagetti dom manipulations with a config object passed/merged in to defaults.
I never trusted that plugin site, and would always make sure the plugin was on github and being actively maintained etc.
I really like the idea of https://www.ruby-toolbox.com/ the stats on last update issue fixed, and popularity metrics helps allot. JS should have the same.
An important point is that even if the plugin is completely robust, it probably contains a huge amount of code/options that you personally will never need or use, so while finding something for proof of concept is easy, finding production practical plugins are hard.
An example for me was that we needed something that would float buttons in certain positions depending on user input, so the obvious solution was to get a plugin that did tooltips and change the graphics to hide everything but a button. Worked like a charm and not a single error on any browser or mobile device. The problem was it was nearly 75k all in. This is no criticism of the author, he did an amazing job of being as broadly adopted as possible by giving every option everyone had asked for and more. Obviously though I only need 1 set of those options out of the hundreds he'd had squeezed into his code.
Before we went live I decided to find time over a weekend to rewrite and got it just as stable and robust for under 6k. Clearly as a one off this is could be considered a minor issue but with times that by 5 plugins and you start having an unpleasant experience for people.
I think what you have highlighted is really a general problem with a lot of freely available software and that is the authors set out to solve a problem that they have, release it to the public and then get deluged with feature requests, which being nice people, they duly implement. Before anyone knows what has hit them, the little solution has become a big bloated piece of crap that is too large to use.
I've released a number of WordPress themes and I always get requests like "put in an option so the menu can be on the left or the right", "make it so I can pick any font from Google fonts using just a dropdown in the theme options" and many other wacky requests. I find myself having to draw a line between useful requests that everyone will benefit from and crazy edge cases that just serve one or two people but will destroy the elegance of my original vision. It's hard saying no to people, but it has to be done.
> One rule to live by: Never use 3rd party javascript
This is a curious blanket statement. While I have run up against the odd crappy jQuery plugin, the tried-and-true plugins work flawlessly - often throughout jQuery's versions.
I think you're doing a disservice to those who take the time to make great jQuery plugins. The web - as a whole - is better because of the power that these plugins offer designers and developers alike. More people can abandon Flash for simplistic bells & whistles because of the jQuery Plugin.
This is a general point for all 3rd party code and has been on my mind for a while. What I'd really like are developer plugins that are documented not just functionally but architecturally.
Ideally they would be something you could pull off github, read the docs and understand the main architectural concepts involved (say, autocomplete) and then easily extend. This would be of far more value to me than a plug-in that try's to do everything under the sun for a mythical end user.
When I first started using jquery, that's exactly what I thought plugins would do.
To my surprise, a huge slice of plugins are basically non-flexible widgets. This is rather childish and useless. Why would a javascript developer want a fancy styled fragment of a page?
While I think that's a bit dramatic, I do find that I often have to manually modify javascript libraries I use before they work the way I expect. I'm thankful for the 90% of the library I did use, though.
Never use 3rd party javascript
In the 15-odd years I've been doing client-side web development, I've seen precisely one piece of script on the internet that worked as advertised and was durable enough to consider including in one my projects. That exception to the rule is jQuery itself.
jQuery plugins, however, exemplify that golden rule. Every time I've tried to use one (being a hopeless optimist and breaking my own rule), I've been bitten hard and ended up either rewriting it from scratch or spending more time trying to get it to work in a reliable manner than it would have taken to rewrite it from scratch.
I have no idea why this has to be the case, but it is. Javascript you find on the internet is worse than worthless. As such, while it's a shame they lost their plugin site, we're all probably a little better off for having to write our own stuff for a while.