[MTOS-dev] [ProNet] Javascript Library Standardization

Byrne Reese byrne at sixapart.com
Wed Jan 23 14:45:15 PST 2008


First of all, the WYSIWYG editor is completely pluggable ­ the core product
does not need to be modified if all you want is a different editor.

Use FCKEditor if you want ­ which is a more than decent editor. But let¹s
not drive the requirements for our javascript framework based upon anyone¹s
WYSIWYG editor of choice.

More from me about the underlying requirements in a moment.

On 1/23/08 2:13 PM, "Bud Gibson" <fpgibson at gmail.com> wrote:

> I second Su's points in favor of jQuery.  YUI is a bit of a pig.
> 
> However, if YUI leads to a usable wysiwyg editor, I'll switch my vote.
> 
> On Jan 23, 2008 4:58 PM, Timothy Appnel < tim at appnel.com> wrote:
>> On 1/23/08, Chad Everett < 2008 at everitz.com> wrote:
>> 
>>> >  I have to say that I actually don't like YUI.
>> 
>> I haven't looked at it and haven't spent too much time doing
>> JavaScript code, but I don't like the fact that ever tutorial, cool
>> trick and innovative design widget I've seen is NOT using YUI.
>> Assuming I haven't overlooked some great innovations, it would seem to
>> me that standardizing on YUI would remove a lot of the value I
>> expected such a move would deliver. Count mine as a vote against YUI.
>> 
>> What does Six Apart have against Prototype or jQuery that they would favor
>> YUI?
>> 
>>> >  It is an advantage that it doesn't come from your own servers, I guess,
>>> so
>>> > bandwidth is a potential savings, but it does come from somewhere, meaning
>>> > your clients are going to have to get it.  If you're worried about
>>> bandwidth
>>> > that much, then it could be an issue.  You could use expires headers and
>>> > versioning to take care of that to some degree if you really care that
>>> much. 
>>> >  And from what I've seen in my limited testing, YUI sucks - both in terms
>>> of
>>> > the amount of bandwidth it uses and in the usability.
>> 
>> Chad I think you are overlooking browser caching here. Coming from one
>> source the library should get pulled from the local cache no matter
>> which site is using it.
>> 
>> <tim/>
>> 
>> --
>> Timothy Appnel
>> Appnel Solutions
>> http://appnel.com/
>> _______________________________________________
>> MTOS-dev mailing list
>> MTOS-dev at sixapart.com
>> http://www.sixapart.com/mailman/listinfo/mtos-dev
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.sixapart.com/pipermail/mtos-dev/attachments/20080123/b319132d/attachment.html 


More information about the MTOS-dev mailing list