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".
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 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.
> 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.
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.
"Even more unfortunately, I didn’t back up the database before I began this process."
That's the takeaway here, no matter how much of a hassle it is backup the DB before you practice delete-fu - no matter how ninja you are you will make a mistake.
We had this debate a couple of weeks ago: always clone your DB to a staging or local server and practice on that, and never do your delete-fu in a REPL!
But as we all hated that bloody website anyway I doubt anyone will shed a tear.
Maybe it was a relational-algebra-based freudian slip...
If you have a good setup, you shouldn't need to backup the database before every destructive operation. If I went in and accidentally deleted every user record in my database right now -- the site would crash -- but I would be able to restore the site to the point judt before I screwed it up. This recovery would come from the last full backup and the transaction logs.
If my server crashes, the hot replicated backup server will take over. If a hacker destroys both servers and all local backups then I have my last full offsite backup and my nightly off-site transaction log backups so, at most, I'd lose one day.
And I'm not much of a sysadmin -- I've a sole developer and I usually sysadmin by Googling everything and using some common sense and yet I still managed to throw this setup together. You would think a site as big and important as jQuery would put have some common-sense backup procedures in place.
There are two periods in your career when you are most likely to this: when you very little experience or a whole lot of experience. The former because you have no idea what you are doing, the latter because goddamnit I know what I'm doing.
Apart from the actual takeaway here, it is interesting to see how more and more projects are moving away from Content Management Systems, custom CMS scripts, and related solutions and instead host everything on Github. This is really good, especially because Github has a hell of an interface compared to most home-baked solutions.
Another thing that comes to mind here are Jekyll, Hyde, and Toto, content management / blog engines that make it easy to host everything on Github and use it as a storage. Toto even uses Github as the main and only storage.
I don't see why that would be so good. Even if github is the best thing thing in the world after chocolate cookies.
Personally I don't like jquery plugins website, I find it clunky. Secondly, I agree that github has a nice slick interface.
I still don't think the massive migration to github is a good thing. I would much prefer more diversity. Github doesn't even have a discussion/mailing list platform, I don't think that's a very positive thing for many projects, just to give an example.
But mostly I'm curios, 'specially because of their interface', what are the other reasons?
From the original response:
"In cleaning up spam on the old site we got a bit overeager and decided it wouldn't make sense to leave the broken remains."
Meh. Previous discussion centered around the distinction between shuttered and shut down. Now that it is a moot point, we can get on with actually having a jQuery plugins database that is more useful than blindly using google hoping to see the right plugin for the job.
I think this may be intentional and not accidental to weed out obviously dated plugins. I mean if a developer cares enough about his or her plugin, then they will update it on the new site - is what my guess is about their reasoning.
when I worked at motorola, there are sysadmins that were fired _immediately_ after they did 'rm -rf /'.
on another company, those sysadmin could not recover from a mis-operation either, the whole company lost 4 month of development time. those people, amazingly, still keep their jobs.
Adam should leave this project the second day, this kind of error is simply unforgivable.
Sounds to me like your CTOs should have been fired and the admins kept their jobs. If your company can be crippled by a single box being destroyed, it's probably not the individual devs or admins at fault. An errant 'rm' or damaging programming error is more of a risk than a disk failure or a building fire. If you don't plan for that, your company is making a scapegoat out of the person who made an honest mistake. At my last two companies I worked for, it would have taken multiple geographic regions being simultaneously affected by major catastrophes for 4 months of work to be destroyed, and I'm not even sure that would have done it with any degree of certainty.
Where were your redundant source control servers, local and offsite backups, iterative staging environments, etc? Hell, I have all of those at my current workplace and I still keep unofficial backups of everything critical on my workstation. These are all long-established best practices and relatively simple and cheap. The only way I'd fire someone over 'rm -rf /' was if it was done with malicious intent or was one of many examples of someone's ineptitude of negligence.
On an open-source project with low/no budget and less checks and balances, I think you have to be even more forgiving.
Why in the world i'm being downvoted? Fact is that plugin repository was deleted and everyone acts like no damage was done. It's perfectly valid to use more full featured js stack and do not depend on 3rd party code that can get unmaintained/disappear any day.
[+] [-] jasonkester|14 years ago|reply
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.
[+] [-] tptacek|14 years ago|reply
[+] [-] pwaring|14 years ago|reply
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.
[+] [-] rufugee|14 years ago|reply
[+] [-] lukeholder|14 years ago|reply
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.
[+] [-] weego|14 years ago|reply
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.
[+] [-] tomlin|14 years ago|reply
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.
[+] [-] betageek|14 years ago|reply
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.
[+] [-] yesimahuman|14 years ago|reply
[+] [-] paulhauggis|14 years ago|reply
Yes, there are terrible Jquery plugins out there. But, I have a nice collection of ones I've used in previous projects that have saved me many hours.
I can now concentrate on the functionality of my application rather than writing yet another table pagination plugin.
It's also nice because if you can find a mature enough plugin, most of the bugs have been fixed for you through the community of people that use it.
[+] [-] betageek|14 years ago|reply
That's the takeaway here, no matter how much of a hassle it is backup the DB before you practice delete-fu - no matter how ninja you are you will make a mistake.
[+] [-] JonnieCache|14 years ago|reply
But as we all hated that bloody website anyway I doubt anyone will shed a tear.
Maybe it was a relational-algebra-based freudian slip...
[+] [-] wvenable|14 years ago|reply
If my server crashes, the hot replicated backup server will take over. If a hacker destroys both servers and all local backups then I have my last full offsite backup and my nightly off-site transaction log backups so, at most, I'd lose one day.
And I'm not much of a sysadmin -- I've a sole developer and I usually sysadmin by Googling everything and using some common sense and yet I still managed to throw this setup together. You would think a site as big and important as jQuery would put have some common-sense backup procedures in place.
[+] [-] billybob|14 years ago|reply
[+] [-] angrycoder|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] terhechte|14 years ago|reply
Another thing that comes to mind here are Jekyll, Hyde, and Toto, content management / blog engines that make it easy to host everything on Github and use it as a storage. Toto even uses Github as the main and only storage.
[+] [-] tkrajcar|14 years ago|reply
[+] [-] skeptical|14 years ago|reply
I don't see why that would be so good. Even if github is the best thing thing in the world after chocolate cookies.
Personally I don't like jquery plugins website, I find it clunky. Secondly, I agree that github has a nice slick interface. I still don't think the massive migration to github is a good thing. I would much prefer more diversity. Github doesn't even have a discussion/mailing list platform, I don't think that's a very positive thing for many projects, just to give an example.
But mostly I'm curios, 'specially because of their interface', what are the other reasons?
[+] [-] oliveoil|14 years ago|reply
Damage controlling like a ninja.
[+] [-] nitrogen|14 years ago|reply
badger7 39 minutes ago | link [dead]
Many of us have made that mistake - we're the ones with 'WHERE' tattood on the back of our right hands.
[+] [-] tim_iles|14 years ago|reply
[+] [-] iclelland|14 years ago|reply
From the original response: "In cleaning up spam on the old site we got a bit overeager and decided it wouldn't make sense to leave the broken remains."
[+] [-] Maxious|14 years ago|reply
[+] [-] johnx123-up|14 years ago|reply
[+] [-] nhebb|14 years ago|reply
[+] [-] sneak|14 years ago|reply
[+] [-] pbhjpbhj|14 years ago|reply
[+] [-] nt_mark|14 years ago|reply
[+] [-] moe|14 years ago|reply
Don't get me wrong, I love jquery. Just the website is an abomination...
Curiously a large portion of their target audience consists of web-designers. Has really nobody offered to replace that mess with something good?
[+] [-] dhruvbird|14 years ago|reply
[+] [-] jaequery|14 years ago|reply
[+] [-] Pawka|14 years ago|reply
[+] [-] badger7|14 years ago|reply
[deleted]
[+] [-] pablospr|14 years ago|reply
[deleted]
[+] [-] RusAlexander|14 years ago|reply
[deleted]
[+] [-] xxiao|14 years ago|reply
on another company, those sysadmin could not recover from a mis-operation either, the whole company lost 4 month of development time. those people, amazingly, still keep their jobs.
Adam should leave this project the second day, this kind of error is simply unforgivable.
[+] [-] evilduck|14 years ago|reply
Where were your redundant source control servers, local and offsite backups, iterative staging environments, etc? Hell, I have all of those at my current workplace and I still keep unofficial backups of everything critical on my workstation. These are all long-established best practices and relatively simple and cheap. The only way I'd fire someone over 'rm -rf /' was if it was done with malicious intent or was one of many examples of someone's ineptitude of negligence.
On an open-source project with low/no budget and less checks and balances, I think you have to be even more forgiving.
[+] [-] emilsedgh|14 years ago|reply
He just made an honest mistake.
The only sad/odd thing is that they had no daily backups.
[+] [-] ergo14|14 years ago|reply
I think this should be reminder it's not a bad idea to use more comprehensive solutions like dojo toolkit or YUI.
[+] [-] ergo14|14 years ago|reply