[MTOS-dev] [ProNet] Javascript Library Standardization

[Byrne Reese]

In regards to the inevitable debate about what library to adopt, I wonder if
it would be more productive and tractable to list compelling reasons NOT to
use a framework, because as Ben rightly points out, "there aren't many
technical differences between these frameworks" and no doubt every one will
have their list of reasons for preferring A over B.

What I am most concerned with are the reasons NOT to use a framework.
Reasons might include:

* poor documentation
* small community of users
* incompatible with x
* poor record of security
* stagnant development
* etc


On 1/23/08 2:49 PM, "Benjamin Trott" <ben at sixapart.com> wrote:

> Speaking for myself, it has nothing to do with a dislike of Prototype
> or jQuery, or even a profound love of YUI. I have a slight preference
> for YUI because the documentation is fantastic, and that's a really
> big win in my book--the docs manage to combine a full (but
> unobtrusive) API reference with a useful user guide, with examples
> that I *actually want to use*.
> 
> Generally speaking, though, the big win here--both for us internally
> at 6a, and for everyone in the MT community--is standardizing on a
> library that has users, and community support, and documentation, as
> opposed to an internal framework that has none of those things. Those
> are my basic requirements, along with the added requirement that, no
> matter what we choose, it can't preclude developers from using
> something else that they prefer.
> 
> YUI meets all of those requirements, which, you'll notice, aren't
> technical requirements at all, because there aren't many technical
> differences between these frameworks, when you really get down to it--
> it's mostly a matter of personal preference about syntax, and how much
> the framework should much with and/or redefine the core language.
> 
> Any framework that meets all of those requirements will put both 6a
> and MT developers in a much better position than we/they are now:
> 
> * MT ships with a very solid JS framework that plugin developers can
> depend upon and build upon
> * developers can use another framework of their choosing knowing that
> it won't conflict with the core framework
> * people coming new to the MT community (or to 6a itself) can get up
> to speed quickly, because they'll already be familiar with the framework
> 
> Ben
> 
> On Jan 23, 2008, at 1:58 PM, Timothy Appnel 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
> 
> _______________________________________________
> MTOS-dev mailing list
> MTOS-dev at sixapart.com
> http://www.sixapart.com/mailman/listinfo/mtos-dev