I agree. I don't want to see jQuery get bloated, but if it was between the two options of "Keep it < 20kb but slower" or "Go to 25-30kb and get major improvements" I'd vote for number two. I'd only go for number one if there was really going to be little improvement to any of the changes.
One of the great things for me about jQuery is the shear number of plugins that add functionality, rather than putting them in the core. I think more needs to be made of that fact, rather than Prototype's "Lets put everything in one file" philosophy. And the jQuery MVC - Jamal - interests me too. I'm a CakePHP developer, and I'd love to start applying the same principles that I use in that to my jQuery code. But I don't want the bloat of say Dojo or Freja. On 6/12/07, Su <[EMAIL PROTECTED]> wrote:
On 6/12/07, Rey Bango <[EMAIL PROTECTED]> wrote: - We can increase selector speeds at the expense of file size How about looking at this specifically a little closer? It's already been pointed out that jQuery could get a lot bigger and /still/ remain the smallest library. So, the question is why 20k? I'm not saying damn the filesize, but let's just say that some test comes out which does illustrated a /significant/ deficiency which is being brought about by the filesize restriction. What would the argument then be for staying at 20k? Is the goal "keep the library small" or "keep the library at 20k?" And if the latter, what is the basis for that number?
-- Tane Piper http://webrocket.wordpress.com This email is: [ ] blogable [ x ] ask first [ ] private
