[MTOS-dev] [ProNet] Javascript Library Standardization

[Bud Gibson]

jQuery scores high on all of these.  That's one reason I've used it.

On Jan 23, 2008 5:58 PM, Byrne Reese <byrne at sixapart.com> wrote:

> 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
>
> _______________________________________________
> MTOS-dev mailing list
> MTOS-dev at sixapart.com
> http://www.sixapart.com/mailman/listinfo/mtos-dev
>



-- 
Bud Gibson
cell:  734-657-4800
web:  http://michiganinnovators.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.sixapart.com/pipermail/mtos-dev/attachments/20080123/b4e53301/attachment-0002.html