jquery vs dojo vs yui etc
in [JavaScript]
|
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
From: Captain Paralytic on 5 Aug 2010 10:23 On 17 June, 08:10, Joe Nine <j...(a)yahoo.com> wrote: > it's like it's own new > language Talking of language, possessive its has no apostrophe (see: http://groups.google.co.uk/group/alt.possessive.its.has.no.apostrophe)
From: RobG on 5 Aug 2010 19:54 On Jul 16, 7:21 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: [...] > 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 tr:odd").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 tr:odd").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. -- Rob
From: S.T. on 6 Aug 2010 12:18 On 8/5/2010 4:54 PM, RobG wrote: > 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!
From: Garrett Smith on 6 Aug 2010 19:48 On 2010-07-17 07:12 PM, David Mark wrote: > On Jul 17, 9:41 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > [...] >> 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? >> >> "Define cohesive objects" is better but that does not imply that doing >> the opposite is wrong. > > 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). >> >> "Avoid interdependencies" is better > > 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
From: Garrett Smith on 6 Aug 2010 20:01
On 2010-07-14 09:58 PM, David Mark wrote: > On Jun 18, 11:06 am, Johannes Baagoe<baa...(a)baagoe.com> wrote: >> Thomas 'PointedEars' Lahn : >> >>> Matt is still not getting that (JS) libraries as a concept are not the >>> issue, but the people writing them. >> >> That, exactly, is what bothers me in those discussions : the issue seems >> to be *the people* writing those libraries. Technical objections alone >> would hardly justify personal smears. >> > > 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 |