New jQuery announced!
in [JavaScript]
|
From: David Mark on 13 Dec 2009 12:44 On Dec 13, 11:55 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote: > >... I made an exception a couple of years back (Google "browser > >scripting library" and click the first hit). It is a functional API > >with an optional jQuery-like (but competently designed) "chainable" OO > >interface (or you could write your own that is exactly like jQuery if > >that's what you really want). I don't recommend using such interfaces > >as they just slow things down, but at least mine is a fairly > >"unobtrusive" layer. > > Thanks, interesting! > > A compatible jQuery replacement may be something interesting > too. Ever thought of that? The stock OO interfaces are just a thin (and optional) layer over the API (as they should be). You could put whatever "face" you want on the API, including jQuery's grotesque profile. Mine is somewhat jQuery like, but instead of $ to create a single type of object, it has:- E - element Q - one or more elements (query) D - document W - window Also, inheriting from E with a few augmentations:- F - form I - image I didn't put a lot of thought into them and I never use them, so they haven't been tested thoroughly. But the typical method is 2-3 lines long. As you might expect, reading those short methods gives quite an insight into the API and how to create an alternative interface. And, of course, they are all "chainable". Q('.myclass').fadeIn().onclick(function() { this.fadeOut(); }, this); Something like that. Perhaps somebody should explore and document these features, but it won't be me. I'm working on something else (and was never particularly interested in the OO interfaces). > > Or maybe a jQuery add-on that fixes jQuery's worst errors, > perhaps by replacing the worst functions with new ones? What I typically do for those who are married to the jQuery interface is to figure out what parts of jQuery they actually use and provide reliable alternatives wrapped in a jQuery-like object. That eliminates the biggest maintenance headache (upgrading jQuery to "keep up" with the latest browsers) and, of course, the parts under the hood actually work. ;) There's no way to write an add-on for jQuery that fixes it. The design was terribly flawed from day one and now they are stuck with it. Sure, there are lots of things that could be improved internally, but who has time to fight with the jQuery people? When it comes to logic and interface design, they are clearly insane (and you just can't argue with crazy people).
From: David Mark on 13 Dec 2009 14:36 On Dec 13, 12:44 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Dec 13, 11:55 am, Hans-Georg Michna <hans- > > georgNoEmailPle...(a)michna.com> wrote: > > On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote: > > >... I made an exception a couple of years back (Google "browser > > >scripting library" and click the first hit). It is a functional API > > >with an optional jQuery-like (but competently designed) "chainable" OO > > >interface (or you could write your own that is exactly like jQuery if > > >that's what you really want). I don't recommend using such interfaces > > >as they just slow things down, but at least mine is a fairly > > >"unobtrusive" layer. > > > Thanks, interesting! > > > A compatible jQuery replacement may be something interesting > > too. Ever thought of that? > > The stock OO interfaces are just a thin (and optional) layer over the > API (as they should be). You could put whatever "face" you want on > the API, including jQuery's grotesque profile. Mine is somewhat > jQuery like, but instead of $ to create a single type of object, it > has:- > > E - element > Q - one or more elements (query) > D - document > W - window > > Also, inheriting from E with a few augmentations:- > > F - form > I - image > > I didn't put a lot of thought into them and I never use them, so they > haven't been tested thoroughly. But the typical method is 2-3 lines > long. As you might expect, reading those short methods gives quite an > insight into the API and how to create an alternative interface. And, > of course, they are all "chainable". > > Q('.myclass').fadeIn().onclick(function() { > this.fadeOut(); > > }, this); Oops, that second argument is obviously wrong. Looking at the prototype, I had the method name wrong too. And I forgot to wrap the - this - identifier. var q = Q('.myclass'); q.fadeIn().on('click', function() { this.fadeOut(); }, q); That would fade all of them out on clicking any. The second argument is the context (the query object in this case). To fade out one at a time:- Q('.myclass').fadeIn().on('click', function() { E(this).fadeOut(); }); Want to remove the click listener for each in turn? var fn = function() { E(this).fadeOut().off('click', fn); }; Q('.myclass').fadeIn().on('click', fn); As for these (poorly named) on/off methods, they do no munging of events (e.g. mouseenter means mouseenter). Cross-browser "smoothing" is done through higher-level methods (e.g. onhover, onmousewheel, oncontextclick). That's the way it should be for clarity (i.e. knowing what to expect from the call) and flexibility (i.e. not restricting the events that can be attached). Such layering is done throughout. For example, setting the opacity style means just that. The higher-level setOpacity method provides the cross-browser opacity solution (which may or may not set that specific style). In contrast, jQuery smashes everything together so that you have no recourse when it's meddling fails (other than to "step outside" of jQuery). For me, I can't see coding like this. But the interface is there (and works efficiently) for those who can.
From: David Mark on 13 Dec 2009 16:19 On Dec 13, 2:36 pm, David Mark <dmark.cins...(a)gmail.com> wrote: [...] > > var q = Q('.myclass'); > > q.fadeIn().on('click', function() { > this.fadeOut(); > > }, q); > > That would fade all of them out on clicking any. The second argument > is the context (the query object in this case). > > To fade out one at a time:- > > Q('.myclass').fadeIn().on('click', function() { > E(this).fadeOut(); > }); On closer inspection, those *in/out methods need a first argument, which is an object specifying various options. Minimum needed to make sense is a duration as the default is 0. Q('.myclass').fadeIn({ duration: 500 }).on('click', function() { E(this).fadeOut({ duration: 500 }); }); At a glance, it appears the other options are ease (easing function-- see API.ease), repeat, revert (reverts altered styles after hide), dir (reversals and "round trip" transitions), to, from (both percentages) and fps (frames per second). The stock reveal effects include "fade", "slide", "drop", "fold", "zoom", "horizontalblinds" and "verticalblinds" (see API.effects). And, as with everything in the library, it is trivial to detect features, allowing for controlled degradation. There are various host methods and properties that must be present and functional to make these animation methods work. Those are taken care of behind the scenes. The calling app only needs to detect the methods on the API objects. For example, if an enhancement requires fadeIn/out and will use the OO interface, the gateway would look like this:- if (E.prototype.fadeIn) { // undefined if not supported // Cool enhancement goes here } It's interesting that libraries like jQuery preach progressive enhancement, yet there is no way to determine if their methods are viable in the given environment. Seems a huge contradiction to me. If you have no way of knowing what will fail, you have no way of knowing what to present to the user. Present something that fails unexpectedly (i.e. throws an exception) and the aspiring enhancement ends up an annoyance at best and a hindrance at worst.
From: Matt Kruse on 13 Dec 2009 23:00 On Dec 12, 2:06 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > In conclusion, results for attribute-related queries would make decent > seeds for random number generators. Can you come up with a real test-case that fails? Matt Kruse
From: Garrett Smith on 14 Dec 2009 02:23
David Mark wrote: > On Dec 13, 12:44 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> On Dec 13, 11:55 am, Hans-Georg Michna <hans- >> >> georgNoEmailPle...(a)michna.com> wrote: >>> On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote: >>>> ... I made an exception a couple of years back (Google "browser [sni[\ > Want to remove the click listener for each in turn? > > var fn = function() { > E(this).fadeOut().off('click', fn); > }; > > Q('.myclass').fadeIn().on('click', fn); > [sni[ > For me, I can't see coding like this. But the interface is there (and > works efficiently) for those who can. It is a pity that this style of programming has become so widely adopted. The design of making a query and performing an action is inherently inefficient. A simple event library can go much further, with much fewer bugs, much less code, much faster performance. Long menthod chains and complex expressions are harder to debug, then again, one-letter functions like 'E' aren't very descriptive, either. Aside: I do mean to get back to that getWindowSize post, I am sorry I have many things going on right now. I have not forgotten that one. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |