jquery vs dojo vs yui etc

[johncoltrane]

We started a project last week. JQuery was, as usual, mentioned both in
functional and technical specs in an attempt to reuse some older bits of
code and, supposedly, ease the job for everyone.

I was ready to accept this as I don't feel confident enough to start a
project at my day job all with my limited skills.

There is a carrousel at the bottom of the page. After a while looking
for a suitable JQuery-related plugin/tutorial I settled down for one
which had the exact same features as we had planned and that we had used
previously. After reviewing the code I had a bizarre impression: all the
dollar signs seemed completely useless.

It actually took me less than 10 mn to transform this heavily JQuery
reliant script into a straight "raw" script without adding more than a
couple of lines. JQuery was used only to query DOM elements by ID and
move around a couple of those elements. Every

$('#id').method();

was readily replaceable by a

var foo = d.getElementById('id'); // "cached" early on
foo.bar = 'value';

or some similarly simple code.

In 10 mn I was able to remove entirely any dependency on JQuery from the
whole project. That's 70 Kb less, and that's good for everyone involved
: lighter, faster, more compatible, more reliable, more readable...

Now, I don't want to fall in the trap of becoming too confident over
such a small win but shit, but it doen't feel that hard to learn to
write real "JavaScript" for simple tasks like that.

 

[RobG]

I've written table-striping code for when I can't add the "odd"
classes on the server. I've written several different version of such
code. It's not at all difficult to write. But including that code in
my build and adding whatever calls are needed to apply it is more
difficult than doing this:

$("#myTable tbody trdd").addClass("odd");

Presuming this is a task you've done often, you should be re-using a
simple function that should not be re-written every time. So the
alternative is something like:

stripeTable(tableId, oddClass[, evenClass]);

Damn, that is so much more difficult.

Moreover if I decide I want to apply it to a certain class of tables
instead, I don't need to ensure that I can collect them by class name
and then run a loop over the bunch. I can do this instead:

$("table.zebra tbody trdd").addClass("odd");

Extending the functionality of the stripeTable function (once) to
support selecting tables by class, or to accept an array of tables to
stripe, is trivial too. e.g.

stripeTable(getByClass(className), oddClass[, evenClass]);

The examples suggest someone who uses jQuery because they don't want
to maintain their own (or a development team's) library of proven
code. Such libraries require effort to develop, support and maintain,
but the payback is worth it.

 

[S.T.]

The examples suggest someone who uses jQuery because they don't want
to maintain their own (or a development team's) library of proven
code. Such libraries require effort to develop, support and maintain,
but the payback is worth it.

So you agree JS libraries are generally a good idea... you just think
every developer should write and maintain their own.

The jQuery project should be scrapped and replaced by tens of thousands
of individually developed and maintained general purpose DOM/Ajax
libraries. Perhaps hundreds of thousands. Each one slowly expanded over
time as a developer comes to realize he/she would find value in another
bit of reusable functionality in his arsenal.

Genius!

 

[Garrett Smith]

[...]

One thing that I have wanted to change is the "Avoid modifying objects
you don't own. ". While that is a nice trite phrase, it doesn't cover
the aspects of defining cohesive objects.

I think it gets the point across. It's very easy to by accident (or
in haste).

Which point?

In contrast, I don't know what that means; so the first one is
definitely better.

Any programmer should know what cohesion is. Google is your friend.

The reason "don't modify objects you don't own" isn't enough is that,
say, Joe Coder creates and ADT* Menu and puts that in Menu.js, then he
creates an ADT FlyMenu and puts that in FlyMenu.js. So far so good. Then
he realizes that for FlyMenu, the show behavior needs to be different,
and so within FlyMenu.js, he modifies Menu.js. This creates a coupling
so that when FlyMenu is used, it works, but when Menu is used and
FlyMenu.js is on the same page, Menu doesn't work the same.

According to code guidelines doc, that's allowable.

So clearly, the "don't modify object's you don't own" is not enough. The
concept of a person owning an object is irrelevant to the code. What
matters is how the objects communicate, not who their respective authors
or "owners" may be.


* (ADT in this paradigm means a constructor + associated prototype, plus
possibly a few functions hidden in a closure).

But something else altogether.

Not entirely. I like this. "Avoid" is good here because it doesn't say
"don't ever create a dependency."

 

[Garrett Smith]

When choosing a script, the relative proficiency of the author(s) is
certainly relevant.

The code itself is what matters.

Though it might make you angry, in the case of an author such as
yourself, I can see why some might make an exception to that.

It was also once claimed that you threatened to sue John Resig while he
was in the midst of publicly discussing porting over your tests. if that
is true, then I can see why one in John Resig's position would want to
avoid using your code.

 

[Garrett Smith]

That are implies that incompetent authors can and do write "good" code.

I'd be more likely to trust code from a source I know is reliable but
when it comes to assessing the code, the code alone should be assessed.

And if it's not good code, then the mistakes can be pointed out so the
author can learn from them.

 

[RobG]

So you agree JS libraries are generally a good idea...

Where a library is a repository of reusable code, yes.

you just think
every developer should write and maintain their own.

Why not? Developers would learn a lot by developing their own
libraries as a professional development exercise and for potential use
for small jobs where a larger library is not required.

The jQuery project should be scrapped

Preferably it will be replaced by one or more competent libraries that
are used for projects where such a libraries are beneficial.

 

[John G Harris]

On Fri, 6 Aug 2010 at 09:18:01, in comp.lang.javascript, S.T. wrote:

So you agree JS libraries are generally a good idea...

If they are competent.

you just think every developer should write and maintain their own.

If they can't find a competent one, or can't find one that does just
what's needed without extra unused bloat.

The jQuery project should be scrapped

Yup! My ISP uses jQuery. It isn't compatible with my up to date IE8.

and replaced by tens of thousands of individually developed and
maintained general purpose DOM/Ajax libraries.

<snip>

You seem to be having trouble thinking straight. (Hint : there are more
than two choices.)

John

 

[David Mark]

So you agree JS libraries are generally a good idea...

Virtually any re-usable bit of code written in JS could be (and often
is) called a "library". Thus the term is generally meaningless.

you just think
every developer should write and maintain their own.

No, that's the old "write everything from scratch as the only
alternative" non-argument.

The jQuery project should be scrapped and replaced by tens of thousands
of individually developed and maintained general purpose DOM/Ajax
libraries.

The "jQuery project" is just a bad script that's been demonstrated to
fail at virtually everything it has tried to do. It's become a symbol
of JS futility, just like Prototype and countless others like it.

Perhaps hundreds of thousands. Each one slowly expanded over
time as a developer comes to realize he/she would find value in another
bit of reusable functionality in his arsenal.

When you consider how bad jQuery has been demonstrated to be, it
doesn't make a hell of a lot of sense to for everyone to use it for
everything, does it?

 

[David Mark]

[...]

One thing that I have wanted to change is the "Avoid modifying objects
you don't own. ". While that is a nice trite phrase, it doesn't cover
the aspects of defining cohesive objects.

I think it gets the point across.  It's very easy to by accident (or
in haste).

Which point?

The point about not modifying objects you don't own.

Any programmer should know what cohesion is. Google is your friend.

That's not what I said. Google yourself.

The reason "don't modify objects you don't own" isn't enough is that,
say, Joe Coder creates and ADT* Menu and puts that in Menu.js, then he
creates an ADT FlyMenu and puts that in FlyMenu.js. So far so good. Then
he realizes that for FlyMenu, the show behavior needs to be different,
and so within FlyMenu.js, he modifies Menu.js. This creates a coupling
so that when FlyMenu is used, it works, but when Menu is used and
FlyMenu.js is on the same page, Menu doesn't work the same.

See, that's a completely different point.

According to code guidelines doc, that's allowable.

You lost me, doc.

 

[David Mark]

The code itself is what matters.

Try to follow me on this. Authors who don't know what they are doing
usually attempt to "solve" problems by mystical incantation. That
never leads to good code. So if you know the relative proficiency of
the author(s) is poor you can skip wading through their magic spells.

Though it might make you angry, in the case of an author such as
yourself, I can see why some might make an exception to that.

How can something that makes no sense make me angry?

It was also once claimed that you threatened to sue John Resig while he
was in the midst of publicly discussing porting over your tests.

I'll sue anyone who tries to steal material bearing my copyright. And
you are really all over the map here. Try to focus.

if that
is true, then I can see why one in John Resig's position would want to
avoid using your code.

You mean why he would try to avoid (blatantly) stealing my code. And,
again, this has no relevance to the fact that jQuery is junk. Whether
I posted a library or not, it's still junk.

 

[Scott Sauyet]

I've written table-striping code for when I can't add the "odd"
classes on the server.  I've written several different version of such
code.  It's not at all difficult to write.  But including that code in
my build and adding whatever calls are needed to apply it is more
difficult than doing this:

    $("#myTable tbody trdd").addClass("odd");

Presuming this is a task you've done often, you should be re-using a
simple function that should not be re-written every time. So the
alternative is something like:

    stripeTable(tableId, oddClass[, evenClass]);

Damn, that is so much more difficult.

Sorry for the late response. Just catching up from two weeks'
vacation.

I believe you're missing the point here. I was saying that I have
done exactly that, and can do so competently and without issue. If I
needed to add zebra striping to an otherwise static page, I would
certainly not introduce a library as large as jQuery to do so. But in
a page that needs some simple animation, perhaps some rounded corners,
a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
coder before me may well have introduced a library which makes this
new zebra call quite easy, without introducing any other old scripts
of mine.

So, coding in a page that already uses jQuery, I can either (a) dig
through my libraries and find an existing zebra function, add that to
my custom JS or import a new JS file, making sure that it's included
in all pages that might want to stripe, and then call it with a one-
liner or (b) include a jQuery one-liner.

Determining the exact threshhold of when to introduce a larger library
is tricky, and crossing it often means going through existing code and
removing parts duplicated by the library, but it will generally speed
up further development.

I've recently joined a new project that had already gotten underway
and was heavily using two of the big libraries. Just today, I helped
remove the last vestiges of YUI from the code, but only by using the
equivalent jQuery tools. I wouldn't even consider trying to replace
all the jQuery in the application with custom code right now, and even
if I were to try, I'd never convince management of my teammates of the
rationale for it, not unless they were to run across issues with
jQuery that seemed substantial. I've been in the same place with Dojo
in the past. It's not that I think these libraries are even remotely
close to perfect, but they fit the need of the client.

 

[Garrett Smith]

I've written table-striping code for when I can't add the "odd"
classes on the server. I've written several different version of such
code. It's not at all difficult to write. But including that code in
my build and adding whatever calls are needed to apply it is more
difficult than doing this:

$("#myTable tbody trdd").addClass("odd");

Presuming this is a task you've done often, you should be re-using a
simple function that should not be re-written every time. So the
alternative is something like:

stripeTable(tableId, oddClass[, evenClass]);

Damn, that is so much more difficult.

Sorry for the late response. Just catching up from two weeks'
vacation.

I believe you're missing the point here. I was saying that I have
done exactly that, and can do so competently and without issue. If I
needed to add zebra striping to an otherwise static page, I would
certainly not introduce a library as large as jQuery to do so. But in
a page that needs some simple animation, perhaps some rounded corners,
a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
coder before me may well have introduced a library which makes this
new zebra call quite easy, without introducing any other old scripts
of mine.

A server side function has the advantage in that it requires no JS -- no
js to download and none to execute for that. Better performance and
works in any browser.

if you reduce dependency upon a generalized object, then that thing can
be removed. The jQuery object is about animation, dom manipulation, DOM
events, and finding other elements, so a generalized object.

If animation is being used as a visual enhancement then why not use
degrading CSS transitions? Rounded corners is a visual effect and
border-radius and friends (-moz-border-radius etc) is widely supported.

A function to stripe a table makes sense but it could be more
generalized though, such forEach. Where supported, static array generic
Array.forEach, Array.prototype.forEach.call, or, where neither are
available, a fallback.


A little psycho eye candy will stimulate the neuron of Google Group'ers.

forEach(document.getElemnetsByTagName("td"), function(el, i, arr) {
el.style.background = (i % 2 === 0) ? "papayawhip" : "lawngreen";
});

// Untested:
var forEach = Array.prototype.forEach ? function(arr, callable, thisp) {
Array.prototype.forEach.call(arr, callable, thisp);
} : function (arr, callable, thisp) {
// Handle callable object that is not a function.
var call = Function.prototype.call;
for (var i = 0, len = arr.length >>> 0; i < len; i++) {
if (i in arr)
call.call(callable, thisp, arr, i, arr);
}
};

Keep in mind that those methods perform [[HasProperty]] checks operator
and when the implementations uses a catchall, as some browsers do, the
function will have inconsistent and surprising results. Example:

var form = document.forms[0];
"0" in form; // false in Gecko
Array.prototype.indexOf.call(form, form[0]);

Firefox: -1
Safari: 0

And likewise,

var form = document.forms[0];
"0" in form; // false in Gecko
Array.prototype.forEach.call(form, console.log, console);

No logging in Firefox, yet:

// Use elements collection.
var elements = document.forms[0].elements;
Array.prototype.forEach.call(elements, console.log, console);

Observe logging.

So, coding in a page that already uses jQuery, I can either (a) dig
through my libraries and find an existing zebra function, add that to
my custom JS or import a new JS file, making sure that it's included
in all pages that might want to stripe, and then call it with a one-
liner or (b) include a jQuery one-liner.

Well with jQuery you don't have to write a function. However, the
forEach approach has concise clean implementation, is very flexible, it
requires a minimal dependency (the forEach fallback), it's a standard
ECMAScript method and supported natively in newer browsers.

The downside to forEach is that it will be slower in older browsers that
don't support it natively.

Determining the exact threshhold of when to introduce a larger library
is tricky, and crossing it often means going through existing code and
removing parts duplicated by the library, but it will generally speed
up further development.

Rather than choosing a larger library, I'd favor choosing more pieces
that can function independently. The independent pieces can take in
other interface objects with which to work.

I've recently joined a new project that had already gotten underway
and was heavily using two of the big libraries. Just today, I helped
remove the last vestiges of YUI from the code, but only by using the
equivalent jQuery tools. I wouldn't even consider trying to replace
all the jQuery in the application with custom code right now, and even
if I were to try, I'd never convince management of my teammates of the
rationale for it, not unless they were to run across issues with
jQuery that seemed substantial. I've been in the same place with Dojo
in the past. It's not that I think these libraries are even remotely
close to perfect, but they fit the need of the client.

What I always prefer in those cases is to find the sorest parts, go back
to the original requirements, get refinement on those (based on feedback
and collaboration) and then redo the feature based on those requirements.

 

[Garrett Smith]

[...]
Keep in mind that those methods perform [[HasProperty]] checks operator

Bad edit. HasProperty is an internal method, not an operator!

 

[Evertjan.]

Garrett Smith wrote on 20 aug 2010 in comp.lang.javascript:

A server side function has the advantage in that it requires no JS

There is no advantage for a serverside function not to be in JS.

And, a serverside function can easily be in JS.

This has the added advantage you [often] can use the same or highly
simmilar function both serverside and clientside.

Serverside functions in general have the advantage
that they are by nature highly cross-browser compatibel.

 

[Scott Sauyet]

[ ... ]
If I needed to add zebra striping to an otherwise static page, I would
certainly not introduce a library as large as jQuery to do so.  But in
a page that needs some simple animation, perhaps some rounded corners,
a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
coder before me may well have introduced a library which makes this
new zebra call quite easy, without introducing any other old scripts
of mine.

A server side function has the advantage in that it requires no JS -- no
js to download and none to execute for that. Better performance and
works in any browser.

....and only works if the DOM is static. I usually do this on the
server when the DOM is static; then my eye-candy is visible even when
the user isn't using JS. But if the DOM is dynamic, server-side
techniques are irrelevant.

[ .. ]
A function to stripe a table makes sense but it could be more
generalized though, such forEach. Where supported, static array generic
Array.forEach, Array.prototype.forEach.call, or, where neither are
available, a fallback.

A little psycho eye candy will stimulate the neuron of Google Group'ers.

forEach(document.getElemnetsByTagName("td"), function(el, i, arr) {
   el.style.background = (i % 2 === 0) ? "papayawhip" : "lawngreen";

});

// Untested:
var forEach = Array.prototype.forEach ? function(arr, callable, thisp) {
     Array.prototype.forEach.call(arr, callable, thisp);
   } : function (arr, callable, thisp) {
   // Handle callable object that is not a function.
   var call = Function.prototype.call;
   for (var i = 0, len = arr.length >>> 0; i < len; i++) {
     if (i in arr)
       call.call(callable, thisp, arr, i, arr);
   }
};
[ ... ]

Or, if you already have a library such as MooTools, Prototype, or
jQuery, you might just choose to use the one that's built into that
library, for example in jQuery:

$.each(myArrayLikeObject, function(index, element) {
// whatever
});

No new custom code to test, just the same function I used in other
places in this and other recent applications.

Or of course:

$("tddd").css("background-color": "papayawhip");
$("td:even").css("background-color": "lawngreen");

I can write a forEach if I need to. But I may not need to, and that
frees me up to work on the more interesting parts of the application.

So, coding in a page that already uses jQuery, I can either (a) dig
through my libraries and find an existing zebra function, add that to
my custom JS or import a new JS file, making sure that it's included
in all pages that might want to stripe, and then call it with a one-
liner or (b) include a jQuery one-liner.

Well with jQuery you don't have to write a function. However, the
forEach approach has concise clean implementation, is very flexible, it
requires a minimal dependency (the forEach fallback), it's a standard
ECMAScript method and supported natively in newer browsers. [ ... ]

You seem to be missing the point. A competent programmer can build
these functions. But a competent programmer will usually also take
advantage of libraries that make the job easier.

Rather than choosing a larger library, I'd favor choosing more pieces
that can function independently. The independent pieces can take in
other interface objects with which to work.

When I do build my own JS without using such a library, I do try to do
just that. But I'm often working in environments in which a library
is already present, or I'm working with an application that requires
enough different features supported by a library that it makes sense
to use one. Assembling the few dozen little scripts required to
fulfill all the requirements is often significantly more burdensome
than including a library.

What I always prefer in those cases is to find the sorest parts, go back
to the original requirements, get refinement on those (based on feedback
and collaboration) and then redo the feature based on those requirements.

But I'm simply not seeing many pain points.

Yesterday was the first time in this project we had to work around a
limitation of jQuery on the project. It took half an hour. Writing
all the code that we were using jQuery for here would have taken many
hours, or even days.

I think jQuery has substantial flaws. I'd like to find an
alternative. But licensing issues would prohibit even trying APE in
this project, even if it were more mature. My Library has the obvious
issue of no one who can offer support. Nothing else has caught my eye
yes.

 

[Garrett Smith]

[ ... ]
If I needed to add zebra striping to an otherwise static page, I would
certainly not introduce a library as large as jQuery to do so. But in
a page that needs some simple animation, perhaps some rounded corners,
a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
coder before me may well have introduced a library which makes this
new zebra call quite easy, without introducing any other old scripts
of mine.

A server side function has the advantage in that it requires no JS -- no
js to download and none to execute for that. Better performance and
works in any browser.

...and only works if the DOM is static. I usually do this on the
server when the DOM is static; then my eye-candy is visible even when
the user isn't using JS. But if the DOM is dynamic, server-side
techniques are irrelevant.

[ .. ]
A function to stripe a table makes sense but it could be more
generalized though, such forEach. Where supported, static array generic
Array.forEach, Array.prototype.forEach.call, or, where neither are
available, a fallback.

A little psycho eye candy will stimulate the neuron of Google Group'ers.

forEach(document.getElemnetsByTagName("td"), function(el, i, arr) {
el.style.background = (i % 2 === 0) ? "papayawhip" : "lawngreen";

});

// Untested:
var forEach = Array.prototype.forEach ? function(arr, callable, thisp) {
Array.prototype.forEach.call(arr, callable, thisp);
} : function (arr, callable, thisp) {
// Handle callable object that is not a function.
var call = Function.prototype.call;
for (var i = 0, len = arr.length>>> 0; i< len; i++) {
if (i in arr)
call.call(callable, thisp, arr, i, arr);
}
};
[ ... ]

Or, if you already have a library such as MooTools, Prototype, or
jQuery, you might just choose to use the one that's built into that
library, for example in jQuery:

$.each(myArrayLikeObject, function(index, element) {
// whatever
});

No new custom code to test, just the same function I used in other
places in this and other recent applications.

A tested fallback would follow the standard Array.prototype[xxx], simply
shifting the thisArg to the first parameter.

Or of course:

$("tddd").css("background-color": "papayawhip");
$("td:even").css("background-color": "lawngreen");

Rather than reducing dependency on a generalized object, that adds
dependency on a generalized object. That makes the removal of said thing
harder.

It also much less efficient (provided you fix the errors) than forEach.
jQuery methods are long and complicated and take a long time to analyze.
I've gone over the complexity of these methods before.

Here's the jQuery.init method discussed:
<http://groups.google.kg/group/comp.object/msg/eed4f90405ab91b9?dmode=source>

Your approach also uses the jQuery `css` method, which has been
discussed a number of times and also complex.

So, coding in a page that already uses jQuery, I can either (a) dig
through my libraries and find an existing zebra function, add that to
my custom JS or import a new JS file, making sure that it's included
in all pages that might want to stripe, and then call it with a one-
liner or (b) include a jQuery one-liner.

Well with jQuery you don't have to write a function. However, the
forEach approach has concise clean implementation, is very flexible, it
requires a minimal dependency (the forEach fallback), it's a standard
ECMAScript method and supported natively in newer browsers. [ ... ]

You seem to be missing the point. A competent programmer can build
these functions. But a competent programmer will usually also take
advantage of libraries that make the job easier.

It seems that the competent programmer has a penchant for jQuery
javascript library that is getting in the way of seeing pros and cons of
other solutions.

You're criticism against forEach is that it wasn't tested and that it's
too much trouble to test.

Did I get that right?

[...]

But I'm simply not seeing many pain points.

I'm not talking about problems in jQuery. I'm talking about sore parts
of an application (that need refinement, etc, as explained).

Seems a little defensive there.

Yesterday was the first time in this project we had to work around a
limitation of jQuery on the project. It took half an hour. Writing
all the code that we were using jQuery for here would have taken many
hours, or even days.

I think jQuery has substantial flaws. I'd like to find an
alternative. But licensing issues would prohibit even trying APE in
this project, even if it were more mature. My Library has the obvious

APE is designed to use a custom build with ANT. That means you make a
one or more builds of the things you need. It sounds like you want an
all-in-one or drop-in library.

APE is licensed as FreeBSD.

 

[Scott Sauyet]

On 2010-08-19 08:21 PM, Scott Sauyet wrote:
[ Garrett's `forEach` deleted ]

Or, if you already have a library such as MooTools, Prototype, or
jQuery, you might just choose to use the one that's built into that
library, for example in jQuery:

     $.each(myArrayLikeObject, function(index, element) {
         // whatever
     });

No new custom code to test, just the same function I used in other
places in this and other recent applications.

A tested fallback would follow the standard Array.prototype[xxx], simply
shifting the thisArg to the first parameter.

Then why write your custom code?

Rather than reducing dependency on a generalized object, that adds
dependency on a generalized object. That makes the removal of said thing
harder.

You seem to assume that there is a goal to reduce the dependency of an
application on a library it uses. While there are certainly times to
do that, at other times its much more efficient to use the library as
needed, keeping in mind its limitation. If I were trying to reduce
the dependency on jQuery in my application, I would not write code
like that; I would use a custom "stripe" function or something like
your "forEach" solution; those might still depend upon jQuery, but I'd
be comfortable knowing that to remove the jQuery for this sort of
code, I could do so in one place. But that has not been my goal.

It also much less efficient (provided you fix the errors) than forEach.
jQuery methods are long and complicated and take a long time to analyze.

There are times when the ability to analyze the source is very
important. But with many tools I never bother to look into their
source. I use a large number of open-source Java libraries whose
source I don't examine. Joda is a great replacement for Java's flawed
date and time handling, but I haven't once dug into its source; it
just works for me. Javascript libraries, when they simply do as I
expect them to and don't cause noticeable performance problems, are
easy for me to treat as black boxes.

Of course I have looked at the jQuery source, and I agree that it
tries to be too tricky. Advantages in file download size don't seem
enough compensation for that sort of code. But it hasn't yet made me
lose any sleep.

  I've gone over the complexity of these methods before.

Here's the jQuery.init method discussed:
<http://groups.google.kg/group/comp.object/msg/eed4f90405ab91b9?dmode=....>

I saw it the first time around. That complexity has more to do with
the overloaded API for the jQuery function than with poor
implementation. I really don't like that complexity myself, but some
people seem to love how much can be done with `$`.

Your approach also uses the jQuery `css` method, which has been
discussed a number of times and also complex.


It seems that the competent programmer has a penchant for jQuery
javascript library that is getting in the way of seeing pros and cons of
other solutions.

I don't think so. As I said, I wouldn't introduce jQuery just for one
or two otherwise simple-to-duplicate features. I certainly wouldn't
do it just for table-striping. But I also would not avoid using a
jQuery-based one-liner to stripe my tables if I was already using it
in the project.

You're criticism against forEach is that it wasn't tested and that it's
too much trouble to test.

Did I get that right?

Not really. To me the main issue is that it's unnecessary. I already
have a library in this application that does forEach, and it also has
tools that make the striping a one-liner. Why write another?

[...]

But I'm simply not seeing many pain points.

I'm not talking about problems in jQuery. I'm talking about sore parts
of an application (that need refinement, etc, as explained).

I'm not sure what "these cases" means to you, then.

As we extend the application, there will surely be issues that need to
be addressed. Of course we'll address them and rethink approaches
based upon a reexamination of the requirements. But it is not a goal
of the team, or even a goal of my own, to remove jQuery or reduce
dependence upon it.

Seems a little defensive there.

I didn't feel that way at all.

[ ... ] I think jQuery has substantial flaws.  I'd like to find an
alternative.  But licensing issues would prohibit even trying APE in
this project, even if it were more mature.  My Library has the obvious

APE is designed to use a custom build with ANT. That means you make a
one or more builds of the things you need. It sounds like you want an
all-in-one or drop-in library.

We won't use Ant on my current project (my first time in the .NET
world) but I'm sure I could port the build over to the .NET port of
Ant. I don't mind making building our script from parts a task in the
build process, so I don't need a library that is all-in-one. But I do
prefer a library whose parts are not too granular, generally. I'd
rather know that, e.g., I have all the AJAX tools when I import the
AJAX module rather than having to grab a number of related AJAX
pieces. But that preference would never be a show-stopper in choosing
a library.

APE is licensed as FreeBSD.

Oh, that's a nice change. Last I knew (February?) it was AFL.