JQuery Shutters Plugin Site(plugins.jquery.com)
plugins.jquery.com
JQuery Shutters Plugin Site
http://plugins.jquery.com/
17 comments
I would volunteer to help curate the plugins. However, to be clear, I didn't necessarily mean manually curate them. You all can simply create a mechanism for the community to curate them (vote up/down, track number of downloads, reviews etc). When I said you all aka jquery.com, I simply meant that it will be controlled on your domain - not that you have to give more of your time.
With that being said, thank you for giving your time freely to help grow the community. I think I speak for most when I say, I appreciate it.
With that being said, thank you for giving your time freely to help grow the community. I think I speak for most when I say, I appreciate it.
A site that has good curation of a large number of small, useful code snippets: http://phpjs.org/
at long last! and not just because of the spam. i hope you guys make something much more awesomer. the old plugin site was infuriating to use/search.
Being involved with plugins (not jQuery) I've struggled with working out the best way to curate quality.
User ratings? Self-certification? iTunes-style pay + review? Combination of all of the above?
Certifying code quality (whether free or paid) is a tough thing to do, yet it's going to be massively important going forwards. I'm keen to here of how the new jQuery plugin site plans to tackle this.
User ratings? Self-certification? iTunes-style pay + review? Combination of all of the above?
Certifying code quality (whether free or paid) is a tough thing to do, yet it's going to be massively important going forwards. I'm keen to here of how the new jQuery plugin site plans to tackle this.
Would love to help curate the new plugins site.
Why waste one minute cleaning up spam on the old site, if you were planning on opening a new site that replaces it? Wouldn't it have been better (and less riskier ahem) to have simply put that effort towards the new site instead?
If I was to create a jQuery plugin site, I would make it a "shopping cart" system where you can pick and choose all the (curated) plugins you want and the site will package it all in a nice zip, provide you with a snippet of code to run it properly, and optionally give you a (paid) hosting of the customized code on a CDN. It could eventually have paid plugins available for further monetization.
Please please please do this.
If you do this, and the interface is good, you'll have a hugely popular website. Do it.
If you do this, and the interface is good, you'll have a hugely popular website. Do it.
I agree. When I wanted to make a new jQuery plugin site (until this post!), I planned on being able to view the plugin source online, like on GitHub. Aside from viewing the code and its quality immediately, it would also let us copy-paste plugins that are just one .js file. It's a bit bothersome to have a .zip in that case.
Actually, that is a great idea... why not just make a site that links everything to github? The plugin pages could just be github pages and downloads. Issue tracking? github. Pull requests. github. Makes perfect sense to me.
Please please don't. The mess that is JQuery ui download is evidence enough to avoid this like the plague.
Or at least make it incredibly optional.
Or at least make it incredibly optional.
Agreed. I still don't understand the jQuery UI download options; despite having used it many a time.
I've been toying with the idea of doing something like that as an optional way to download packages from the site I've been building. I like the way you put it, as a "shopping cart" type system, that's a good way of thinking about it.
I've been disappointed by the quality of many of the plugins listed on the site for a while. I often have to rely on plugins I have used before, read of on HN in the past, or ask other developers--rather than going to the plugins page. Granted the plugins I end up using are also in the list I would have seen, there is nothing separating them from the really bad ones.
I wonder if the number of bad plugins comes from the relatively small disparity between being able to use jQuery and writing a plugin. jQuery's whole premise is being an easy to use programming language. In other models (wordpress for example) the bottom 50% (or more, I don't know, I'm just making up numbers) of "administrators" would have no idea how to make a plugin. Verses the bottom 15% (again completely fake numbers, just for demonstration) of jQuery users may be unable to do so.
I wonder if the number of bad plugins comes from the relatively small disparity between being able to use jQuery and writing a plugin. jQuery's whole premise is being an easy to use programming language. In other models (wordpress for example) the bottom 50% (or more, I don't know, I'm just making up numbers) of "administrators" would have no idea how to make a plugin. Verses the bottom 15% (again completely fake numbers, just for demonstration) of jQuery users may be unable to do so.
jQuery isn't a programming language and most 'plugins' for it are simply libraries that have a dependency on jQuery. That's where the glut of low quality 'plugins' comes from. Anybody that knows a little javascript can write some garbage code and then turn around and call it a jQuery plugin.
A jQuery 'plugin' can be written in one line... the level of functionality one might provide is much lower than the minimum functionality found in a WordPress plugin.
A WordPress plugin can be just one line too. There used to be a very popular one whose only job was to disable the WordPress filter that turned line breaks into paragraph tags.
<?php remove_filter('the_content', 'wpautop'); ?>Aha, good point. So there isn't really any skill difference between the minimum jQuery plugin and the minimum WordPress plugin.
Right, but my point was of the difference in disparity between the minimum plugin and minimum usage. To use jQuery is closer to creating a plugin than using wordpress is to creating a plugin.
Is that what you should be comparing, though? I think there's an impedance mismatch between WordPress and jQuery. WordPress is not seen primarily as a programming tool.
'Using' jQuery could mean visiting a website that employs jQuery which doesn't bring you any closer to writing anything. What we mean is people who program with jQuery, though.
The average WordPress user (say, an author or site owner) doesn't do any programming at all. A user who does do programming, like someone who customizes WordPress for people, could write one of these one line plugins. Ultimately it's comparing JavaScript to PHP, and I don't think one is more difficult.
'Using' jQuery could mean visiting a website that employs jQuery which doesn't bring you any closer to writing anything. What we mean is people who program with jQuery, though.
The average WordPress user (say, an author or site owner) doesn't do any programming at all. A user who does do programming, like someone who customizes WordPress for people, could write one of these one line plugins. Ultimately it's comparing JavaScript to PHP, and I don't think one is more difficult.
Finally. It would be great for the end user and plugin authors if they (jquery.com) curates the plugins themselves. I'm sure a lot more exploration will happen on their site vs scouring the web. I know I've never relied on their old plugin site to find anything.
I would rather they defer the handling of plugins to Github. The social features of Github makes it easy to evaluate what plugins are popular among respected developers. Github also encourages contribution to an existing plugin as opposed to creating two dozen plugins that all do the same thing.
My preferred solution is Ender (http://ender.no.de/) and searching sites like GitHub.
If I remember right, the jQuery plugins site was one of the only other open-source repositories powered by the Drupal Project module (drupal.org/project/project) besides drupal.org itself. I think that jQuery might even have been running the Drupal 5 version. The Project module, which they'd have to either fix or dig out of, is a massive chunk of code. Upgrading to Drupal 6 would be painful, and finding people who have the knowledge and desire to hack on the Drupal 5 version would probably be really tough.
Please forgive me, but I'll use this post to ask a question I've been wondering for a while. Is it better to use a minified js/css of all pages of the website or to make each pages as minimal as possible? For instance, if I use 4 jquery plugins on a splash page, 2 jquery plugins in the "signup" part and 5 other jquery plugins a little bit everywhere.. should I bundle all these plugins into one big .js, minified it and put it on the splash page so that it is cached?
It depends on how big it all is when it comes together.
For example, you'll have 7 plugins (and associated code that runs them) that won't be used at all on the splash screen. That's going to increase load-time when someone hits that page.
If someone hits a page direct and avoids the splash screen, it's not going to be cached in the first place so it'll all be loaded. Only this time they're loading 4 plugins and the related code that won't even be used.
IMO you should compress what's needed for each page. Several smaller downloads is often better than one large download, and you shouldn't be relying on a user's cache to gauge your own site's performance. If you're not going to use it, don't include it.
For example, you'll have 7 plugins (and associated code that runs them) that won't be used at all on the splash screen. That's going to increase load-time when someone hits that page.
If someone hits a page direct and avoids the splash screen, it's not going to be cached in the first place so it'll all be loaded. Only this time they're loading 4 plugins and the related code that won't even be used.
IMO you should compress what's needed for each page. Several smaller downloads is often better than one large download, and you shouldn't be relying on a user's cache to gauge your own site's performance. If you're not going to use it, don't include it.
It is probably best to bundle all of your application code and plugins into one big JavaScript file, while loading jQuery itself from one of the CDNs (and excluding it from the bundle). I think it's only when this bundle file gets massive or initial page load time is critical that it makes sense to load individual modules on-demand. When your application gets so big that it uses a dozen plugins and a dozen of its own files, the HTTP requests caused my loading them individually will start to hurt.
I'm a fan of the "package once, use everywhere" approach.
Clients will use exactly 1 HTTP connection to download exactly 1 gzipped file, which is then cached and recalled from the cache for every subsequent pageview. HTTP overhead is significant! Furthermore, if you have everything in one scope, a Javascript minifier is going to be able to crunch it down significantly more than it could if you have a bunch of separate files in separate scopes.
What you want to avoid doing is executing a ton of JS in the top-level scope. JQuery plugins are great examples here, because they are often function definitions which require parsing, but are not executed until invoked. If you're worried about how much code you're executing per page, you can segment it by creating functions for your individual pages, and then calling the appropriate function on document.ready.
If you end up with 3MB of JS/CSS, then that's probably something that needs to be split up, but for a lot of use cases, combined is just fine. When in doubt, test it on a smartphone over a mobile data connection and see how it feels.
Clients will use exactly 1 HTTP connection to download exactly 1 gzipped file, which is then cached and recalled from the cache for every subsequent pageview. HTTP overhead is significant! Furthermore, if you have everything in one scope, a Javascript minifier is going to be able to crunch it down significantly more than it could if you have a bunch of separate files in separate scopes.
What you want to avoid doing is executing a ton of JS in the top-level scope. JQuery plugins are great examples here, because they are often function definitions which require parsing, but are not executed until invoked. If you're worried about how much code you're executing per page, you can segment it by creating functions for your individual pages, and then calling the appropriate function on document.ready.
If you end up with 3MB of JS/CSS, then that's probably something that needs to be split up, but for a lot of use cases, combined is just fine. When in doubt, test it on a smartphone over a mobile data connection and see how it feels.
jQuery is modular. You can minify the plugins. For the sake of maintenance, clarity and speed of your documents, I think it's best to use plugins only as needed.
I believe this is a good thing. I jQuery daily, and when searching for a plugin lately I would avoid the plugins site when it came up in search results. It was outdated and the stuff in there isn't generally well maintained. I was glad to hear about a new plugin site coming (it was announced at jqcon in Oct I believe) and see this as a positive move towards that being live.
What's the advantage of shuttering a site over just leaving the existing site running and developing a new one behind the scenes?
Getting a bad reputation from the spam it has been encountering apparently.
Good move. Reputation is far more important than people getting easy access to useful tools.
Don't get me wrong - it's their fair right to shut down a site they own. It's just highlighting a particular set of priorities they seem to have.
Don't get me wrong - it's their fair right to shut down a site they own. It's just highlighting a particular set of priorities they seem to have.
Think of it this way: what if someone new to jQuery (although jQuery is almost like a household name to us, there are a lot of people new to web development) wanted some plugins? They would look at the page on the jQuery web site, and they would see spam. This is bad for new users, and especially bad for the jQuery community as a whole if they wind up using buggy or outdated plugins. By contrast, an experienced person who's already been using jQuery is probably just going to go on Github or do their own searching. There's no tangible benefit to keeping it around.
The question you really have to ask: how useful is the plugin page? From my experience, it's pretty useless. A newbie will find most of the widgets they need (with high-quality code) in the jQuery UI/Mobile projects, and there are tons of authoritative blog posts if they do a little bit of searching.
The question you really have to ask: how useful is the plugin page? From my experience, it's pretty useless. A newbie will find most of the widgets they need (with high-quality code) in the jQuery UI/Mobile projects, and there are tons of authoritative blog posts if they do a little bit of searching.
But actually the most annoying thing is the huge amount of broken links; they should host the plugins themselfs.
Maybe a third-party curated site like rubygems.org would be better.
This certainly is interesting timing. I've been dissatisfied with plugins.jquery.com for quite a while. Earlier this year, I began development of an entirely new site for hosting javascript packages (including but not limited to jquery plugins (after all, jquery plugins are nothing but normal javascript code with a dependency on jquery)).
As of last week, that site is finally up and ready for beta. I was planning on announcing it this week or next.
If anyone here on HN has a jquery plugin or any other opensource javascript library or framework, and would like to give some feedback, please let me know via twitter or email (see my HN profile for both). The more people that can test it out privately, the better I'll feel launching it :-)
EDIT: Also, I plan on completely open-sourcing the site itself, like Github has done, once the site is launched.
As of last week, that site is finally up and ready for beta. I was planning on announcing it this week or next.
If anyone here on HN has a jquery plugin or any other opensource javascript library or framework, and would like to give some feedback, please let me know via twitter or email (see my HN profile for both). The more people that can test it out privately, the better I'll feel launching it :-)
EDIT: Also, I plan on completely open-sourcing the site itself, like Github has done, once the site is launched.
Misleading headline, it is only temporarily closed.
I assume it was effecting their Google rank, otherwise they would have left the old one open.
I assume it was effecting their Google rank, otherwise they would have left the old one open.
It's not misleading; it says 'shutters' not 'shut'. As in how you'd close a shop overnight by pulling the shutters down..
Not only that, but the linked to page also says "shutters."
Confusing word choice. Not sure why they couldn't say "temporarily unavailable" or something else.
Although WordPress' repo uses SVN (I prefer Git), it runs really smoothly. Something like that would be great for jQuery, but you wouldn't need the whole update feature set.
A new jQuery plugins site isn't too far away. We should have a blog post up in the next few days with the details, I won't steal the thunder but the new site will discourage spam, promote plugins with higher quality, and provide a consistent way for users to report/discuss bugs.
> Wouldn't it be better to open the new plugin site then close the old one?
Yeah that was our goal. 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.
> It would be great for the end user and plugin authors if they (jquery.com) curates the plugins themselves.
Most of us are volunteering our time to the jQuery project. If you are agreeable to the same pay scale, you can be one of us and help curate the new plugins site. Get your company to give you 20%-time.