I have to say I absolutely *hate* the "build your own" library thing. First, 
when trying a new library, I don't often know what I need, so I end up 
downloading one set of files (click, click, click) only to discover I needed 
something else (click, click, click, click) then two weeks later I want 
something ELSE (click, click, click, click, click).

I say, find a standard set of things that should be included in jquery 
(personally, I'd ditch the effects stuff, as they're so minimal it'd be better 
to just pawn those elsewhere) and focus on the expression engine. That's 
jquery's bread and butter.

One simple download link, and a nice page where developers can find plugins.

-----Original Message-----
From: Jason Yeckel <[EMAIL PROTECTED]>
Sent: Wed, November 15, 2006 12:03 am
To: jQuery Discussion. <discuss@jquery.com>
Subject: Re: [jQuery] jQuery 1.1 by the end of Nov

I think over all do a mootools like download / interface jquery lib 
download were the user can pick and choose components.

Just to be fair the only reason it has two was to make perl regex users 
happy :) I do use the perl regex though lol.


Jason Y
www.purepressure.com


dave.methvin wrote:
> John Resig wrote:
>   
>> Right now, the jQuery compressed build is teetering around 18-19KB, I
>> really want to try and cut this down. Any thoughts on particular
>> features that should be extracted into a plugin?
>>
>>     
> I know the macros don't account for _that_ much core code but they do
> complicate the documentation significantly. We have nice short names like
> .attr and .css yet those represent the most-macroed properties. Then we end
> up with (justifiable IMO) situations where valuable names like .height() are
> taken by the .css("height") macro to save five--count 'em--five characters.
> The same goes for the event macros, I think they account for more than half
> the names in the API documentation at this point and they end up creating
> situations like .unload() that are pretty hard to explain.
>
> I would like to see jQuery take more of a Perl path than a PHP one, using a
> small number of consistent and powerful concepts plus the ability to extend
> things with plugins. Perl has one simple consistent regexp operator; PHP has
> two completely different regexp engines, each served by a dozen or more
> differently named functions.
>
>
>   


_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/


_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Reply via email to