JS framework
Ivan S
I'll build web application which is "portlet-like" ... I like JQuery,
but I'm opened to new or better solutions.
What do you think about Dojo?
Thanks in advance.
Ivan
rf
> What JS framework would you guys recommend to me?
Notepad.
Start typing...
Ivan S
I don't think that a good idea. Notepad++ is much better. :)
Just kidding ... I don't want to code all by my self, it would take me
a lot of time to develop things that I need (and some frameworks have
it all done).
Conrad Lender
> On 27 svi, 16:05, "rf" <r...@z.invalid> wrote:
>> Ivan S wrote:
>> > What JS framework would you guys recommend to me?
>>
>> Notepad.
> I don't want to code all by my self, it would take me a lot of time
> to develop things that I need (and some frameworks have it all done).
You're not likely to get any recommendations for libraries or frameworks
in cljs. From the FAQ [1]: "No javascript libraries are endorsed by this
group. If you are looking for help using a library, visit that library's
discussion group instead." Search the group archive for some library
names and you'll find a lot of heated discussions and code "dissections"
of the more popular libraries.
- Conrad
Thomas 'PointedEars' Lahn
> What JS framework would you guys recommend to me?
Yours. It's not that hard to do. In fact, without being presumptuous, I
don't think one can do worse than what is on the advertised market right
now. If only I had the time ...
HTH
PointedEars
Ricardo
David Mark
Oh, it's the guy who thinks all of the bugs, memory leaks and other
incompetence in jQuery is an evil bias against jQuery and other
"frameworks" by this newsgroup. Weren't you just in here whining
about some bug report? The "attr" method I think. Was explained to
you in painful detail, but you just scuttled off and did nothing.
Your whole professional future relies on the kindness of other hacks
and you are too inept to relay a simple bug report. Ironic,
considering that community is supposed to be a selling point. I don't
think a community of inept imbeciles is what the browser scripting
world needs right now.
David Mark
No they do not. Not by a long shot and there aren't enough man-hours
in the year for them to catch up. Search the archive for more
information.
David Mark
> What JS framework would you guys recommend to me?
>
> I'll build web application which is "portlet-like" ... I like JQuery,
> but I'm opened to new or better solutions.
>
> What do you think about Dojo?
I think that, unlike jQuery and the rest, it has a bright future.
There are some very smart people involved. I am personally tying some
things down for them so that even the most grizzled Javascript
veterans will approve. The next version will leave all of the rest
behind. You can put that in the bank.
In a sentence, they are *listening*, which does not describe the other
efforts at all.
Garrett Smith
> On 27/05/09 17:27, Ivan S wrote:
>> On 27 svi, 16:05, "rf" <r...@z.invalid> wrote:
>>> Ivan S wrote:
>>>> What JS framework would you guys recommend to me?
>>> Notepad.
> ...
>> I don't want to code all by my self, it would take me a lot of time
>> to develop things that I need (and some frameworks have it all done).
>
> You're not likely to get any recommendations for libraries or frameworks
> in cljs. From the FAQ [1]: "No javascript libraries are endorsed by this
> group.
Should links to reviews be in the FAQ? If so, only the best reviews
should be linked. Best=highest s/n, least rudeness.
If you agree, find a link and post up. Maybe it goes in the FAQ.
Garrett
David Mark
> Conrad Lender wrote:
> > On 27/05/09 17:27, Ivan S wrote:
> >> On 27 svi, 16:05, "rf" <r...@z.invalid> wrote:
> >>> Ivan S wrote:
> >>>> What JS framework would you guys recommend to me?
> >>> Notepad.
> > ...
> >> I don't want to code all by my self, it would take me a lot of time
> >> to develop things that I need (and some frameworks have it all done).
>
> > You're not likely to get any recommendations for libraries or frameworks
> > in cljs. From the FAQ [1]: "No javascript libraries are endorsed by this
> > group.
>
> Should links to reviews be in the FAQ? If so, only the best reviews
> should be linked. Best=highest s/n, least rudeness.
Yes, but never mind judging "rudeness." Replies can be rude (like
Resig's various lame attempts to head off criticism), but reviews are
not replies to anyone, just the expression of opinions, hopefully
buttressed with facts. Are movie critics rude when they savage the
latest Hollywood monstrosity?
Nest = more controversy = more readers = more enlightenment. If
people can't deal with harsh criticism, they should seek careers out
of the spotlight. I am sick and tired of hearing that outrageous
incompetence and waste - not to mention outright fraud - is justified
and criticism is socially unacceptable. As for harshness, it is
required as nobody seems to hear whispers of mild encouragement.
>
> If you agree, find a link and post up. Maybe it goes in the FAQ.
Ah, you know where the significant ones are. I believe jQuery,
MooTools and Cappuccino have been sufficiently debunked in the last
year or so. Not just reviewed, but dissected to show that there's
nothing proficient or maintainable inside. Is it rude to say
Cappuccino is worthless? Perhaps those who worked on it may think so,
but it's a nice gesture for all of the people who will save time by
avoiding it. I hear from those people occasionally. It makes it all
worthwhile. Well, that and all the publicity. :)
David Mark
> On May 28, 2:23 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
>
>
> > Conrad Lender wrote:
> > > On 27/05/09 17:27, Ivan S wrote:
> > >> On 27 svi, 16:05, "rf" <r...@z.invalid> wrote:
> > >>> Ivan S wrote:
> > >>>> What JS framework would you guys recommend to me?
> > >>> Notepad.
> > > ...
> > >> I don't want to code all by my self, it would take me a lot of time
> > >> to develop things that I need (and some frameworks have it all done).
>
> > > You're not likely to get any recommendations for libraries or frameworks
> > > in cljs. From the FAQ [1]: "No javascript libraries are endorsed by this
> > > group.
>
> > Should links to reviews be in the FAQ? If so, only the best reviews
> > should be linked. Best=highest s/n, least rudeness.
>
> Yes, but never mind judging "rudeness." Replies can be rude (like
> Resig's various lame attempts to head off criticism), but reviews are
> not replies to anyone, just the expression of opinions, hopefully
> buttressed with facts. Are movie critics rude when they savage the
> latest Hollywood monstrosity?
>
> Nest = more controversy = more readers = more enlightenment. If
"Best" was intended.
Ivan S
Thanks.
Conrad Lender
>> What do you think about Dojo?
>
> I think that, unlike jQuery and the rest, it has a bright future.
> There are some very smart people involved. I am personally tying some
> things down for them so that even the most grizzled Javascript
> veterans will approve. The next version will leave all of the rest
> behind. You can put that in the bank.
Dojo is interesting, but I'm surprised to read what almost sounds like
an endorsement from you. The current version of Dojo still relies
heavily on browser sniffing via navigator.userAgent. Will all that be
gone in the next release?
- Conrad
David Mark
Dojo is *very* interesting. Yes, like virtually every script (scripts
in this case) written since 2005, it relies on the UA string. I said
it had a bright *future* because:
- The browser detection is going away (of course.)
- High degree of modularity and flexibility
- Fastest by far
- Well documented and supported
- Adding state of the art feature testing throughout
- Lots of ready-made widgets with consistent UI
- Active community creating add-ons
- Intelligent and thoughtful people involved
- Backed by major players and an established foundation
It's got a bit of a bad rap for being too large, but that's a myth.
It is certainly expansive, but there is no requirement to use *all* of
it. Same for the perception that toys like jQuery are easier to use.
I was surprised to find out that there is a ready-made single file
version, served via AOL's CDN that can easily replace the toy
monoliths.
As for speed, see the TaskSpeed results, which runs tests supplied by
the each script's author(s). It's not even a horse race. Appears
jQuery broke down and will have to be destroyed. :)
If you are going to bet on a horse, I'd definitely pick this one. I'm
now involved and as for the other contenders:
- Who would put a penny on John Resig at this point?
- Prototype is dying, despite the best efforts of Kangax.
- YUI is nothing but an ongoing public Beta for Yahoo. I find their
marketing to be disgustingly disingenuous.
What else is there for those who want/need a toolkit? I don't even
consider things like jQuery to be toolkits, more like random
collections of related scripts ranging in "quality" from very bad to
completely unusable (e.g. jQuery UI, which is only for those bent on
career suicide.)
I'm not saying it is perfect for everyone. But it seems virtually
everyone wants something in this mold. The powers that be at Dojo
have asked me to help out, which is certainly a credit to them and
will result in lots of improvements over the next few months. Seems
like that is what the jQuery proponents have been begging me to do for
years (except with *their* script.) They should have asked in a more
*polite* manner. :)
And, of course, you should learn Javascript and basic browser
scripting techniques, regardless of what is out there.
Matt Kruse
> Dojo is *very* interesting.
After years of you saying no one should ever use a general-purpose
library and that the entire concept is flawed, you were asked to help
with one (ego stroke) and suddenly it's not such a bad idea anymore.
You have been critical of including a script on every page even if you
aren't going to use most of it, but now it's fine with Dojo because
its large size "is a myth". You've pointed out the stupidity of
framework speed comparisons, and now you're pointing to them as
evidence. You tear apart jQuery and repeatedly point out how bad it is
because it features browser-sniffing, but can overlook that in your
script of choice because they are "working on it".
I would call you a hypocrite, but I'm actually kind of glad that
you're catching up with the rest of the scripting community and
realizing the importance of scripting frameworks. I hope you don't
"search the archives" and read your own posts and convince yourself
what a bad idea it is again.
Matt Kruse
Matt Kruse
> Dojo is *very* interesting.
From just a few months ago:
http://groups.google.com/group/comp.lang.javascript/msg/fe6de478b23ddc97
"> Can you recommend another library? Dojo looks like an alternative
It's crap and general purpose browser scripting libraries are
generally a bad idea."
-- David Mark
Matt Kruse
rf
Good call :-)
mark...@villageprofilemail.com
Yahoo's YUI is also an option. Just do a google search for YUI. It has
good documentation and examples to get you going.
David Mark
> On May 28, 11:09 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Dojo is *very* interesting.
>
> After years of you saying no one should ever use a general-purpose
> library and that the entire concept is flawed, you were asked to help
> with one (ego stroke) and suddenly it's not such a bad idea anymore.
And, when did I tell you to use a library? Any library?
> You have been critical of including a script on every page even if you
> aren't going to use most of it, but now it's fine with Dojo because
> its large size "is a myth".
It's modular, stupid. You know, like mine. Did you read my post?
> You've pointed out the stupidity of
> framework speed comparisons, and now you're pointing to them as
> evidence.
I never said anything about TaskSpeed as it did not exist at the
time. It's a much better test than the query comparisons.
> You tear apart jQuery and repeatedly point out how bad it is
> because it features browser-sniffing, but can overlook that in your
> script of choice because they are "working on it".
Again, did you read my post at all? *I* am working on it and it will
be gone in the next release.
>
> I would call you a hypocrite, but I'm actually kind of glad that
> you're catching up with the rest of the scripting community and
> realizing the importance of scripting frameworks. I hope you don't
> "search the archives" and read your own posts and convince yourself
> what a bad idea it is again.
I just don't think you can read for comprehension at all.
David Mark
> On May 28, 11:09 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Dojo is *very* interesting.
>
> From just a few months ago:
>
[snip]
Shut up, idiot. You know better.
David Mark
[snip]
>
> Good call :-)
Good what? You find it odd that I would disparage a browser sniffing
script? Really?
Garrett Smith
Of all of the projects that used Dojo, none of the teams were satisfied
with the application's performance.
One of the projects had hired the sitepen guys to do the work. During
the interview, I asked them to show me the page. It took 11 seconds to
load the app. Failure
Another was a team who started using dojo "to save time" but realized
that the performance and configurability was not to their liking. Having
to shoehorn a particular widget to accomplish a task by "turning off"
certain features took time. Not just that, the performance was slow.
They realized early enough and replaced Dojo. Success.
Another was a public website that realized dojo was needed for a two
dependencies, but added a lot of weight to the site. They could not or
did not want to spend the effort to remove it and replace it. Then they
decided to have me remove it. Then to not remove it, but change the
implementation, then to remove it, then to do it his (manager's) way.
The manager, being more arrogant and less competent than most managers
(comical) proposed an approach that was naive and error-prone. Not doing
that, I left. The type of thinking that went into the decision to use
Dojo was continuing to plague the development team and no amount of
stern meetings (called by me) could help them pull their heads out.
It is this type of thinking that I watch out for. When I find a company
that says they are using a library. I want to know why. If they reply
with things like "standard libraries saves us time" that sounds like
poor decision making skills. Leads to the question "save time doing
what," which can sound confrontational.
> If you are going to bet on a horse, I'd definitely pick this one. I'm
> now involved and as for the other contenders:
I have greater disinterest in animal abuse than I do in Dojo.
Regardless, betting is irrelevant in matters of science.
>
> - Who would put a penny on John Resig at this point?
> - Prototype is dying, despite the best efforts of Kangax.
He's made some contributions to APE, too!
> - YUI is nothing but an ongoing public Beta for Yahoo. I find their
> marketing to be disgustingly disingenuous.
YUI core is not as large as dojo core (very large). Well, except for
APE. :-) APE doesn't really count because it is AFL and because it is
not major.
>
> What else is there for those who want/need a toolkit? I don't even
> consider things like jQuery to be toolkits, more like random
> collections of related scripts ranging in "quality" from very bad to
> completely unusable (e.g. jQuery UI, which is only for those bent on
> career suicide.)
>
> I'm not saying it is perfect for everyone. But it seems virtually
> everyone wants something in this mold. The powers that be at Dojo
Uh.
Garrett
David Mark
And you know this... how? And why are you arguing about the *past*
anyway? Sounds like you have Matt Kruse myopia.
>
> One of the projects had hired the sitepen guys to do the work. During
> the interview, I asked them to show me the page. It took 11 seconds to
> load the app. Failure
One of what projects? Oh, something about you. Why would I care
about this anecdote? See above.
>
> Another was a team who started using dojo "to save time" but realized
> that the performance and configurability was not to their liking. Having
> to shoehorn a particular widget to accomplish a task by "turning off"
> certain features took time. Not just that, the performance was slow.
> They realized early enough and replaced Dojo. Success.
Or this one?
>
> Another was a public website that realized dojo was needed for a two
> dependencies, but added a lot of weight to the site. They could not or
> did not want to spend the effort to remove it and replace it. Then they
> decided to have me remove it. Then to not remove it, but change the
> implementation, then to remove it, then to do it his (manager's) way.
Huh?
>
> The manager, being more arrogant and less competent than most managers
> (comical) proposed an approach that was naive and error-prone. Not doing
> that, I left. The type of thinking that went into the decision to use
> Dojo was continuing to plague the development team and no amount of
> stern meetings (called by me) could help them pull their heads out.
Huh again. What are we talking about here?
>
> It is this type of thinking that I watch out for. When I find a company
> that says they are using a library. I want to know why. If they reply
> with things like "standard libraries saves us time" that sounds like
> poor decision making skills. Leads to the question "save time doing
> what," which can sound confrontational.
So what?
>
> > If you are going to bet on a horse, I'd definitely pick this one. I'm
> > now involved and as for the other contenders:
>
> I have greater disinterest in animal abuse than I do in Dojo.
> Regardless, betting is irrelevant in matters of science.
Whatever.
>
>
>
> > - Who would put a penny on John Resig at this point?
> > - Prototype is dying, despite the best efforts of Kangax.
>
> He's made some contributions to APE, too!
LOL. That's your problem.
>
> > - YUI is nothing but an ongoing public Beta for Yahoo. I find their
> > marketing to be disgustingly disingenuous.
>
> YUI core is not as large as dojo core (very large). Well, except for
> APE. :-) APE doesn't really count because it is AFL and because it is
> not major.
I agree that APE doesn't really count. And the Dojo core is not "very
large." Not to mention that it will be smaller (and faster) when I am
done with it. :)
>
>
>
> > What else is there for those who want/need a toolkit? I don't even
> > consider things like jQuery to be toolkits, more like random
> > collections of related scripts ranging in "quality" from very bad to
> > completely unusable (e.g. jQuery UI, which is only for those bent on
> > career suicide.)
>
> > I'm not saying it is perfect for everyone. But it seems virtually
> > everyone wants something in this mold. The powers that be at Dojo
>
> Uh.
What does that grunt mean?
Ironic that after listening to people (e.g. Matt Kruse) whine for
*years* that I wasn't helping with crap like jQuery, despite the fact
that I was virtually the only one doing *anything* to help it (see the
archive), people are now upset that I am helping another effort.
Would you rather use a script that copies me (badly) or one that I am
actually working on? We all know that jQuery's "feature testing" is
nothing but bogus object inferences. So now Dojo will have the real
thing. Seems like a good move for them. ;)
And, for those who cannot read, I haven't changed my mind one bit
about browser scripting, libraries, etc. Learn Javascript, learn
browser scripting, avoid monolithic kiddie scripts, etc. BUT, if you
are dead-set on using a toolkit, Dojo should probably be in your
future. What else is there?
Garrett Smith
> On May 29, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On May 28, 6:55 am, Conrad Lender <crlen...@yahoo.com> wrote:
>>>> On 28/05/09 02:06, David Mark wrote:
>>>>>> What do you think about Dojo?
>>>>> I think that, unlike jQuery and the rest, it has a bright future.
[...]
>
> And you know this... how? And why are you arguing about the *past*
> anyway? Sounds like you have Matt Kruse myopia.
>
>> One of the projects had hired the sitepen guys to do the work. During
>> the interview, I asked them to show me the page. It took 11 seconds to
>> load the app. Failure
>
> One of what projects?
Projects that I have seen using Dojo.
Oh, something about you. Why would I care
> about this anecdote? See above.
>
So an application take 11 seconds to load is not too slow, huh? The app
was, according to the developers, developed by Sitepen guys.
I've done numerous phone screens with companies that have said "we're
using dojo" and "we want the application to be faster." As if they now
need the "speed" button pressed.
My point (that you missed) was Dojo isn't helping. It is large.
Dojo is not helping because the reasons given for using it in the first
place are usually based on unreasonable thinking, magical thinking, or
lack of thinking altogether.
And I'm sticking to what I wrote: betting is irrelevant. Think.
>>
>>
>>> - Who would put a penny on John Resig at this point?
You popped a tent for John Resig again. You can put that away now.
>>> - Prototype is dying, despite the best efforts of Kangax.
>> He's made some contributions to APE, too!
>
> LOL. That's your problem.
>
Certainly helpful to have feedback. Even when I disagree, it is helpful.
Having others review code is very beneficial. It makes me look at the
code differently. It also finds flaws.
[...]
>> YUI core is not as large as dojo core (very large). Well, except for
>> APE. :-) APE doesn't really count because it is AFL and because it is
>> not major.
>
> I agree that APE doesn't really count. And the Dojo core is not "very
> large."
dojo.js.uncompressed 305k
Not to mention that it will be smaller (and faster) when I am
> done with it. :)
If it makes you feel better, I'm for it.
>
>>
>>
>>> What else is there for those who want/need a toolkit? I don't even
>>> consider things like jQuery to be toolkits, more like random
>>> collections of related scripts ranging in "quality" from very bad to
>>> completely unusable (e.g. jQuery UI, which is only for those bent on
>>> career suicide.)
>>> I'm not saying it is perfect for everyone. But it seems virtually
>>> everyone wants something in this mold. The powers that be at Dojo
>> Uh.
>
> What does that grunt mean?
>
"powers that be" is pathetic.
> Ironic that after listening to people (e.g. Matt Kruse) whine for
> *years* that I wasn't helping with crap like jQuery, despite the fact
> that I was virtually the only one doing *anything* to help it (see the
> archive), people are now upset that I am helping another effort.
Your constant negative comments about John Resig and others draw
attention to you. A lot of that attention is negative ("whining"). A
respectful tone and professional candor might garner a different
response. Certainly easier said than done (I know).
[...]
> And, for those who cannot read, I haven't changed my mind one bit
> about browser scripting, libraries, etc. Learn Javascript, learn
> browser scripting, avoid monolithic kiddie scripts, etc. BUT, if you
> are dead-set on using a toolkit, Dojo should probably be in your
> future. What else is there?
Other modular toolkits include: YUI, APE, Qoodoox, Mochikit.
I am partial to APE, unsurprisingly. APE.js minified is < 2k. Everything
else is optional, and is part of the build process. I have explained
that build process on the group previously.
Garrett
David Mark
> David Mark wrote:
> > On May 29, 1:17 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On May 28, 6:55 am, Conrad Lender <crlen...@yahoo.com> wrote:
> >>>> On 28/05/09 02:06, David Mark wrote:
> >>>>>> What do you think about Dojo?
> >>>>> I think that, unlike jQuery and the rest, it has a bright future.
>
> [...]
>
>
>
> > And you know this... how? And why are you arguing about the *past*
> > anyway? Sounds like you have Matt Kruse myopia.
>
> >> One of the projects had hired the sitepen guys to do the work. During
> >> the interview, I asked them to show me the page. It took 11 seconds to
> >> load the app. Failure
>
> > One of what projects?
>
> Projects that I have seen using Dojo.
Okay then. Shall we assume a very small subset?
>
> Oh, something about you. Why would I care
>
> > about this anecdote? See above.
>
> So an application take 11 seconds to load is not too slow, huh?
Anecdotes about some application you once saw don't cut any ice with
me.
> The app
> was, according to the developers, developed by Sitepen guys.
Objection. Hearsay.
>
> I've done numerous phone screens with companies that have said "we're
> using dojo" and "we want the application to be faster." As if they now
> need the "speed" button pressed.
Same. Are you kidding with this bullshit?
Isn't helping what? And statements like "it is large" aren't exactly
scientific. The point that you and Matt Kruse seem to have missed is
that I am focused on the *future* of this toolkit, not the past. Big
change in the landscape, huh?
>
> Dojo is not helping because the reasons given for using it in the first
> place are usually based on unreasonable thinking, magical thinking, or
> lack of thinking altogether.
Um, okay. I don't care what reasons people have for using it. People
are using it and I am out to make that experience better. As I don't
see any other projects with a minimal clue about how to proceed, I
think we have a winner.
>
> And I'm sticking to what I wrote: betting is irrelevant. Think.
I suggest you drop it. Think.
>
>
>
> >>> - Who would put a penny on John Resig at this point?
>
> You popped a tent for John Resig again. You can put that away now.
>
> >>> - Prototype is dying, despite the best efforts of Kangax.
> >> He's made some contributions to APE, too!
>
> > LOL. That's your problem.
>
> Certainly helpful to have feedback. Even when I disagree, it is helpful.
> Having others review code is very beneficial. It makes me look at the
> code differently. It also finds flaws.
You would have Resig review code for you. Really?
>
> [...]
>
> >> YUI core is not as large as dojo core (very large). Well, except for
> >> APE. :-) APE doesn't really count because it is AFL and because it is
> >> not major.
>
> > I agree that APE doesn't really count. And the Dojo core is not "very
> > large."
>
> dojo.js.uncompressed 305k
So, you are just ignorant about the toolkit. Get the facts and try
again.
>
> Not to mention that it will be smaller (and faster) when I am
>
> > done with it. :)
>
> If it makes you feel better, I'm for it.
Makes me feel better? Who asked you?
>
>
>
> >>> What else is there for those who want/need a toolkit? I don't even
> >>> consider things like jQuery to be toolkits, more like random
> >>> collections of related scripts ranging in "quality" from very bad to
> >>> completely unusable (e.g. jQuery UI, which is only for those bent on
> >>> career suicide.)
> >>> I'm not saying it is perfect for everyone. But it seems virtually
> >>> everyone wants something in this mold. The powers that be at Dojo
> >> Uh.
>
> > What does that grunt mean?
>
> "powers that be" is pathetic.
How so? I suggest you stop trying to irritate me.
>
> > Ironic that after listening to people (e.g. Matt Kruse) whine for
> > *years* that I wasn't helping with crap like jQuery, despite the fact
> > that I was virtually the only one doing *anything* to help it (see the
> > archive), people are now upset that I am helping another effort.
>
> Your constant negative comments about John Resig and others draw
> attention to you. A lot of that attention is negative ("whining").
Deserved negative comments. Are you kidding or what? Nobody has done
more to change the course (for the better) than me. What have you
done?
> A
> respectful tone and professional candor might garner a different
> response. Certainly easier said than done (I know).
No, you have it backwards. Go back to October 2007 and start reading
the interactions between me, Matt Kruse and John Resig from the start.
>
> [...]
>
> > And, for those who cannot read, I haven't changed my mind one bit
> > about browser scripting, libraries, etc. Learn Javascript, learn
> > browser scripting, avoid monolithic kiddie scripts, etc. BUT, if you
> > are dead-set on using a toolkit, Dojo should probably be in your
> > future. What else is there?
>
> Other modular toolkits include: YUI, APE, Qoodoox, Mochikit.
We have established that APE doesn't matter. You know that the last
two are junk. That leaves YUI. I don't see it.
>
> I am partial to APE, unsurprisingly. APE.js minified is < 2k. Everything
> else is optional, and is part of the build process. I have explained
> that build process on the group previously.
Who cares?
David Mark
[snip]
>
> You popped a tent for John Resig again. You can put that away now.
I missed this gem. The OP asked about jQuery vs. Dojo (or whatever.)
Get it? If not, Resig is the one responsible for jQuery.
I don't "pop tents" for anybody. Read your history, gain some
perspective and perhaps you will understand. Why you didn't get it
the first time around is anybody's guess. I seem to remember you
being around, but you didn't say much. I sure don't remember you in
Resig's corner, unlike Matt Kruse, who everyone knows is suffering
from cognitive dissonance (I know jQuery is junk, but I use it, so it
must be good), not to mention amnesia.
[snip]
Ahrjay
> I think that, unlike jQuery and the rest, it has a bright future.
> There are some very smart people involved. I am personally tying some
> things down for them so that even the most grizzled Javascript
> veterans will approve. The next version will leave all of the rest
> behind. You can put that in the bank.
>
> In a sentence, they are *listening*, which does not describe the other
> efforts at all.
That is really encouraging to hear, whats the ETA of the next version?
David Mark
Later this summer I think.
kangax
[...]
> Dojo is *very* interesting. Yes, like virtually every script (scripts
> in this case) written since 2005, it relies on the UA string. I said
> it had a bright *future* because:
>
> - The browser detection is going away (of course.)
> - High degree of modularity and flexibility
> - Fastest by far
> - Well documented and supported
> - Adding state of the art feature testing throughout
> - Lots of ready-made widgets with consistent UI
> - Active community creating add-ons
> - Intelligent and thoughtful people involved
> - Backed by major players and an established foundation
>
> It's got a bit of a bad rap for being too large, but that's a myth.
> It is certainly expansive, but there is no requirement to use *all* of
> it. Same for the perception that toys like jQuery are easier to use.
> I was surprised to find out that there is a ready-made single file
> version, served via AOL's CDN that can easily replace the toy
> monoliths.
>
> As for speed, see the TaskSpeed results, which runs tests supplied by
> the each script's author(s). It's not even a horse race. Appears
> jQuery broke down and will have to be destroyed. :)
>
> If you are going to bet on a horse, I'd definitely pick this one. I'm
> now involved and as for the other contenders:
I remember I was quite surprised when Higgins showed me a link to your
patch in their Trac about a month ago :)
>
> - Who would put a penny on John Resig at this point?
> - Prototype is dying, despite the best efforts of Kangax.
> - YUI is nothing but an ongoing public Beta for Yahoo. I find their
> marketing to be disgustingly disingenuous.
I'm not sure which YUI marketing you're talking about. Could you expand
on that?
I think YUI and Dojo are the only two *major* frameworks suitable for
general web scripting as of now.
Prototype and Mootools are out. Both augment environment too
aggressively. Prototype developers (that would be me and 2 more) at
least *understand* that playing with host objects is idiotic. The only
reason Prototype.JS still didn't drop augmenting environment is due to
backwards compatibility and lack of time.
Mootools developers, on the other hand, say that they "let you have
javascript your way" <http://jqueryvsmootools.com/#yourway>. From what I
can see they endorse and encourage host and native objects augmentation.
I don't see that library as a viable option for general web scripting.
I'm even surprised they don't understand problems that come with their
approach. Oh well.
jQuery has a huge momentum and support behind it, but the quality of
numerous plugins it relies upon is often sadly low. I have just finished
a project where they were using jQuery extensively. I had to dig into
plugins used in the app and fix things manually (mainly in IE). Perhaps,
developers of this project I've been working on just chose poor plugins
in the first place, but it wasn't exactly a smooth ride for me. Besides,
I'm not a fan of jQuery naming convention; One of the goals of
Prototype.js, for example, was to keep API descriptive (compare
`getStyle`/`setStyle` and `css`).
That leaves us with 2 frameworks - both of which, IIRC, do not augment
host/native objects (unlike Prototype/MooTools) and which have
"in-house" widgets and so keep their quality on a high level (unlike
jQuery).
I haven't looked into Dojo's code thoroughly, but I know that YUI still
uses sniffing too extensively in DOM module. Last time I pointed it out
to them, there was no response :(
Nevertheless, I think YUI has very smart people involved and it is
experimenting with some great ideas/implementations. It learned from
previous mistakes and tries not to repeat them in the future. That's
what I like about them. They also pay a lot of attention to
accessibility (although, so does Dojo. IIRC, Dojo was one of the first
to start experimenting with ARIA in their widgets). Check out this video
about YUI3 <http://yuiblog.com/blog/2009/05/12/video-desai-yui3/>. I
found it quite enlightening.
It would be helpful to make a thorough comparison of YUI and Dojo.
Perhaps, mention the least of two evil in FAQ as well?
[...]
--
kangax
David Mark
I'm quite surprised he showed you a link a month ago. Hadn't really
done anything at that point.
>
>
>
> > - Who would put a penny on John Resig at this point?
> > - Prototype is dying, despite the best efforts of Kangax.
> > - YUI is nothing but an ongoing public Beta for Yahoo. I find their
> > marketing to be disgustingly disingenuous.
>
> I'm not sure which YUI marketing you're talking about. Could you expand
> on that?
Virtually all I've seen of it. Start with "browser grading." Or
charts showing how small their huge files will be if you GZIP them
(think how small your smaller files will be without YUI and with
compression.) It's called spin.
>
> I think YUI and Dojo are the only two *major* frameworks suitable for
> general web scripting as of now.
Absolutely.
>
> Prototype and Mootools are out.
Where have you been? They were never close to in.
> Both augment environment too
> aggressively. Prototype developers (that would be me and 2 more) at
> least *understand* that playing with host objects is idiotic.
That's called insanity.
> The only
> reason Prototype.JS still didn't drop augmenting environment is due to
> backwards compatibility and lack of time.
Put that on its headstone. ;)
>
> Mootools developers, on the other hand, say that they "let you have
> javascript your way" <http://jqueryvsmootools.com/#yourway>.
So they are sort of the Burger King of frameworks? Eat mor chikin.
> From what I
> can see they endorse and encourage host and native objects augmentation.
Yes, for a start. There's no point in discussing that script. Just
read the review from a few months ago. In two words: hell no.
> I don't see that library as a viable option for general web scripting.
Nobody could. Well, nobody who knows the first thing about browser
scripting.
> I'm even surprised they don't understand problems that come with their
> approach. Oh well.
Nothing surprises me anymore.
>
> jQuery has a huge momentum and support behind it, but the quality of
> numerous plugins it relies upon is often sadly low.
The quality of plugins? What do you think they are plugging into?
They have rolling logic outages and the development effort is more
cult than collective. And those scripts don't add up to a framework
anyway.
> I have just finished
> a project where they were using jQuery extensively.
Pfft.
> I had to dig into
> plugins used in the app and fix things manually (mainly in IE).
I'm shocked.
> Perhaps,
> developers of this project I've been working on just chose poor plugins
> in the first place, but it wasn't exactly a smooth ride for me.
They chose a poor *script*. The plugins have to deal with that script
too. Most are bad in their own right I've observed.
> Besides,
> I'm not a fan of jQuery naming convention; One of the goals of
> Prototype.js, for example, was to keep API descriptive (compare
> `getStyle`/`setStyle` and `css`).
That's a relatively minor quibble, considering that jQuery could never
deal with IE6 and paid little attention to anything but a crystal ball
as IE8 was released. They are sleeping.
>
> That leaves us with 2 frameworks - both of which, IIRC, do not augment
> host/native objects (unlike Prototype/MooTools) and which have
> "in-house" widgets and so keep their quality on a high level (unlike
> jQuery).
I'd say Dojo and YUI are apples to the other oranges. What sort of a
framework is a script like MooTools?
>
> I haven't looked into Dojo's code thoroughly, but I know that YUI still
> uses sniffing too extensively in DOM module. Last time I pointed it out
> to them, there was no response :(
All of those eyes... Oh well, they could remove all of the sniffs
yesterday and they still have no shot.
>
> Nevertheless, I think YUI has very smart people involved and it is
> experimenting with some great ideas/implementations. It learned from
> previous mistakes and tries not to repeat them in the future. That's
> what I like about them. They also pay a lot of attention to
> accessibility (although, so does Dojo. IIRC, Dojo was one of the first
> to start experimenting with ARIA in their widgets). Check out this video
> about YUI3 <http://yuiblog.com/blog/2009/05/12/video-desai-yui3/>. I
> found it quite enlightening.
Accessibility is certainly key for widgets, but first they have to
work properly. And YUI's are too bloated from what I've seen,
creating some monstrous markup structures.
>
> It would be helpful to make a thorough comparison of YUI and Dojo.
I'm sure it's been done. The TaskSpeed and other performance tests,
blogs, etc.
> Perhaps, mention the least of two evil in FAQ as well?
You mean as far as the code? Lets make a very gross approximation and
say they are even right now. I'm saying it will be over in a month or
two. It will be smaller, faster and the cross-browser compatibility
will be unprecedented for a JS project of this scope. By all means,
watch and learn (but please leave Prototype alone.)
I'm sure there will still be people willing to Beta test for Yahoo,
but YUI will not be the JS framework of choice (at least not for those
who know what they are doing.)
kangax
>>> now involved and as for the other contenders:
>> I remember I was quite surprised when Higgins showed me a link to your
>> patch in their Trac about a month ago :)
>
> I'm quite surprised he showed you a link a month ago. Hadn't really
> done anything at that point.
I was looking at their DOM methods back then (shortly after its latest
release) and saw sniffing used in almost every single method. It was
used much more extensively than say, in Prototype or jQuery, which I'm
sure you know better than me. But that's besides the point.
This is when I asked Higgins why they do it so carelessly and he pointed
me to your patch in "feature detection" branch, saying that they are
working on it <http://twitter.com/phiggins/status/1428053875>
>
>>
>>
>>> - Who would put a penny on John Resig at this point?
>>> - Prototype is dying, despite the best efforts of Kangax.
>>> - YUI is nothing but an ongoing public Beta for Yahoo. I find their
>>> marketing to be disgustingly disingenuous.
>> I'm not sure which YUI marketing you're talking about. Could you expand
>> on that?
>
> Virtually all I've seen of it. Start with "browser grading." Or
I personally don't agree with YUI dropping Safari 2 from browser table,
but overall it does make sense. Which desktop browsers did they forget
to include? Or are you talking about an approach? AFAIK, their widgets
degrade gracefully in non-supporting browsers, just like Dojo ones.
Looking at Dojo
<http://www.dojotoolkit.org/support/faq/what-browsers-does-dojo-support>
I see that they don't support Safari 2.x either (which Prototype, for
example, still supports entirely), nor do they support "older" (<9.6)
Opera (again, Prototype supports 9.2+). I don't want to start a pissing
contest about browser support of Prototype vs Dojo vs YUI. It's just
that Safari 3.x and Opera 9.6 stand out (as well as, say, IE5.5, but
then almost none of major libraries support that one).
> charts showing how small their huge files will be if you GZIP them
> (think how small your smaller files will be without YUI and with
> compression.) It's called spin.
>
>> I think YUI and Dojo are the only two *major* frameworks suitable for
>> general web scripting as of now.
>
> Absolutely.
>
>> Prototype and Mootools are out.
>
> Where have you been? They were never close to in.
We already had a conversation about Prototype. It works without problems
in local intranets and limited environments. Nothing more, nothing less.
Mootools probably does so as well, but we are talking about general web
here, so those don't apply.
>
>> Both augment environment too
>> aggressively. Prototype developers (that would be me and 2 more) at
>> least *understand* that playing with host objects is idiotic.
>
> That's called insanity.
>
>> The only
>> reason Prototype.JS still didn't drop augmenting environment is due to
>> backwards compatibility and lack of time.
>
> Put that on its headstone. ;)
But what will I be having fun hacking then? ;)
Why apples to oranges? Both provide core methods as well as widgets
based on those methods. Both provide ways to skin those widgets. Both
are backed by corporate companies. Both have developers working on them
full time. Both have been out for quite a while. Both are modular. Both
pay attention to a11n and l18n. Both have good ideas in them and both
make mistakes like sniffing or using overly-heavy abstractions. Both are
documented nicely. Both are unit tested. Even both have members in
ECMAScript comitee (Crockford from YUI and Kris Zyp from Dojo) :)
What's different about them?
>
>> I haven't looked into Dojo's code thoroughly, but I know that YUI still
>> uses sniffing too extensively in DOM module. Last time I pointed it out
>> to them, there was no response :(
>
> All of those eyes... Oh well, they could remove all of the sniffs
> yesterday and they still have no shot.
Why?
>
>> Nevertheless, I think YUI has very smart people involved and it is
>> experimenting with some great ideas/implementations. It learned from
>> previous mistakes and tries not to repeat them in the future. That's
>> what I like about them. They also pay a lot of attention to
>> accessibility (although, so does Dojo. IIRC, Dojo was one of the first
>> to start experimenting with ARIA in their widgets). Check out this video
>> about YUI3 <http://yuiblog.com/blog/2009/05/12/video-desai-yui3/>. I
>> found it quite enlightening.
>
> Accessibility is certainly key for widgets, but first they have to
> work properly. And YUI's are too bloated from what I've seen,
> creating some monstrous markup structures.
Interesting. I've heard same things about Dojo, including something
about using non-standard attributes extensively. Again, I can't judge
either, since I haven't reviewed them thoroughly.
>
>> It would be helpful to make a thorough comparison of YUI and Dojo.
>
> I'm sure it's been done. The TaskSpeed and other performance tests,
> blogs, etc.
I'll definitely look at Dojo when I get a chance. Perhaps someone else
will chime in as well.
[...]
--
kangax
David Mark
> David Mark wrote:
> > On Jun 4, 5:21 pm, kangax <kan...@gmail.com> wrote:
> >> David Mark wrote:
> [...]
> >>> If you are going to bet on a horse, I'd definitely pick this one. I'm
> >>> now involved and as for the other contenders:
> >> I remember I was quite surprised when Higgins showed me a link to your
> >> patch in their Trac about a month ago :)
>
> > I'm quite surprised he showed you a link a month ago. Hadn't really
> > done anything at that point.
>
> I was looking at their DOM methods back then (shortly after its latest
> release) and saw sniffing used in almost every single method. It was
> used much more extensively than say, in Prototype or jQuery, which I'm
> sure you know better than me. But that's besides the point.
It's a large group effort. I've only gotten involved recently.
>
> This is when I asked Higgins why they do it so carelessly and he pointed
> me to your patch in "feature detection" branch, saying that they are
> working on it <http://twitter.com/phiggins/status/1428053875>
Sure enough.
>
>
>
> >>> - Who would put a penny on John Resig at this point?
> >>> - Prototype is dying, despite the best efforts of Kangax.
> >>> - YUI is nothing but an ongoing public Beta for Yahoo. I find their
> >>> marketing to be disgustingly disingenuous.
> >> I'm not sure which YUI marketing you're talking about. Could you expand
> >> on that?
>
> > Virtually all I've seen of it. Start with "browser grading." Or
>
> I personally don't agree with YUI dropping Safari 2 from browser table,
> but overall it does make sense.
I don't agree with any sort of browser table.
> Which desktop browsers did they forget
> to include? Or are you talking about an approach? AFAIK, their widgets
> degrade gracefully in non-supporting browsers, just like Dojo ones.
A document cannot degrade gracefully without proper feature testing.
Like most libraries, frameworks, etc. they only test in a microscopic
subset of browsers and configurations. And what are they testing?
Whether the UA parse will spot "MSIE" reliably?
>
> Looking at Dojo
> <http://www.dojotoolkit.org/support/faq/what-browsers-does-dojo-support>
> I see that they don't support Safari 2.x either (which Prototype, for
> example, still supports entirely), nor do they support "older" (<9.6)
> Opera (again, Prototype supports 9.2+). I don't want to start a pissing
> contest about browser support of Prototype vs Dojo vs YUI. It's just
> that Safari 3.x and Opera 9.6 stand out (as well as, say, IE5.5, but
> then almost none of major libraries support that one).
I've talked to them about that. Dojo has been demonstrated to work in
environments other than those on the official list. I see no reason
why it can't work on - for example - Opera 8. Certainly it will when
I am done with it. :)
>
> > charts showing how small their huge files will be if you GZIP them
> > (think how small your smaller files will be without YUI and with
> > compression.) It's called spin.
>
> >> I think YUI and Dojo are the only two *major* frameworks suitable for
> >> general web scripting as of now.
>
> > Absolutely.
>
> >> Prototype and Mootools are out.
>
> > Where have you been? They were never close to in.
>
> We already had a conversation about Prototype. It works without problems
> in local intranets and limited environments. Nothing more, nothing less.
May appear to work fleetingly. Things change. Those scripts will be
left behind.
> Mootools probably does so as well, but we are talking about general web
> here, so those don't apply.
That one is a non-entity (strictly for kids.)
>
>
>
> >> Both augment environment too
> >> aggressively. Prototype developers (that would be me and 2 more) at
> >> least *understand* that playing with host objects is idiotic.
>
> > That's called insanity.
>
> >> The only
> >> reason Prototype.JS still didn't drop augmenting environment is due to
> >> backwards compatibility and lack of time.
>
> > Put that on its headstone. ;)
>
> But what will I be having fun hacking then? ;)
Well, to each his own. If by hacking you mean improving code, why
don't you come on in for the big win? :)
jQuery is a monolithic, interdependent mess. Dojo is modular. And
jQuery's widgets don't count anyway. Would you use widgets built by
jQuery users, knowing they rely on code from John Resig?
> Both provide ways to skin those widgets.
That's marketing speak. And how many seconds would I have to spend
reading jQuery CSS before recoiling in horror?
> Both
> are backed by corporate companies.
No corporation in its right mind would bet on jQuery. And if you mean
MS, you misunderstand what is going on there. They are not "backing"
anything, but leeching onto a name. If you buy an expensive
development tool from them, they'll gladly give you a free jQuery. It
doesn't even work with the Intellisense crap (you have to use an
alternate version of jQuery.)
> Both have developers working on them
> full time.
LOL. Somebody is working full time on *that*. What the hell are they
doing all day, printing T-shirts?
> Both have been out for quite a while. Both are modular.
Yes and no. jQuery is not modular at all. I don't care how much crap
they pile on top of it, the core script is the antithesis of
modularity. The other thing is that Dojo supports interchangeability
as it has an offline build process. You can guess what I am going to
do with that (if not, see the old CWR threads.)
> Both
> pay attention to a11n and l18n.
Pay attention? I've never seen a competent rendition of anything in
jQuery. Are you saying they nailed that stuff?
> Both have good ideas in them and both
> make mistakes like sniffing or using overly-heavy abstractions.
No, the problem is that jQuery started as a bad idea and Dojo started
as a good one. There's no going back at this point.
As for sniffing, everybody did it until I started going off about it.
If you want to go back to the beginning of this movement, you have to
find the Flash/JS article on A List Apart where I commented that
sniffing was a very bad idea. Know what the author said? It's good
enough for jQuery and Dojo. Two years later, here we are. Turns out
it wasn't good enough. Wonder if he changed *his* script?
And thanks to Thomas for posting examples of jQuery's incessant
sniffing (around the fall of 2007.) That really kick-started the
effort. And to that weasel Matt Kruse for making such a spectacular
fool of himself the whole time (his first response was that jQuery did
not use browser sniffing, his last was just an infantile tantrum.)
> Both are
> documented nicely.
Hell no. The jQuery docs are mostly fiction.
> Both are unit tested. Even both have members in
> ECMAScript comitee (Crockford from YUI and Kris Zyp from Dojo) :)
Aren't we comparing frameworks (or toolkits if you prefer) like Dojo
to the aforementioned oranges (e.g. jQuery?)
>
> What's different about them?
You want to know what the real difference was/is? John Resig and co.
can't read. That pretty much sums it up. They had the answers all
along, so there can be no excuses for their present failings.
>
>
>
> >> I haven't looked into Dojo's code thoroughly, but I know that YUI still
> >> uses sniffing too extensively in DOM module. Last time I pointed it out
> >> to them, there was no response :(
>
> > All of those eyes... Oh well, they could remove all of the sniffs
> > yesterday and they still have no shot.
>
> Why?
Just because. ;)
>
>
>
> >> Nevertheless, I think YUI has very smart people involved and it is
> >> experimenting with some great ideas/implementations. It learned from
> >> previous mistakes and tries not to repeat them in the future. That's
> >> what I like about them. They also pay a lot of attention to
> >> accessibility (although, so does Dojo. IIRC, Dojo was one of the first
> >> to start experimenting with ARIA in their widgets). Check out this video
> >> about YUI3 <http://yuiblog.com/blog/2009/05/12/video-desai-yui3/>. I
> >> found it quite enlightening.
>
> > Accessibility is certainly key for widgets, but first they have to
> > work properly. And YUI's are too bloated from what I've seen,
> > creating some monstrous markup structures.
>
> Interesting. I've heard same things about Dojo, including something
> about using non-standard attributes extensively. Again, I can't judge
> either, since I haven't reviewed them thoroughly.
The widgets do use custom attributes, but you don't have to use them
in your markup.
>
>
>
> >> It would be helpful to make a thorough comparison of YUI and Dojo.
>
> > I'm sure it's been done. The TaskSpeed and other performance tests,
> > blogs, etc.
>
> I'll definitely look at Dojo when I get a chance. Perhaps someone else
> will chime in as well.
And I'll look at YUI (again) when I have a chance, but it will all be
academic by the end of the summer.
kangax
>>>>> - YUI is nothing but an ongoing public Beta for Yahoo. I find their
>>>>> marketing to be disgustingly disingenuous.
>>>> I'm not sure which YUI marketing you're talking about. Could you expand
>>>> on that?
>>> Virtually all I've seen of it. Start with "browser grading." Or
>> I personally don't agree with YUI dropping Safari 2 from browser table,
>> but overall it does make sense.
>
> I don't agree with any sort of browser table.
Ok.
>
>> Which desktop browsers did they forget
>> to include? Or are you talking about an approach? AFAIK, their widgets
>> degrade gracefully in non-supporting browsers, just like Dojo ones.
>
> A document cannot degrade gracefully without proper feature testing.
> Like most libraries, frameworks, etc. they only test in a microscopic
> subset of browsers and configurations. And what are they testing?
> Whether the UA parse will spot "MSIE" reliably?
YUI does feature test, but not as much as they should, imo. I'm not
really interested in defending YUI here. All I can see is that it's very
similar to Dojo. We both know the optimal way to design scripts for the
web. Neither YUI nor Dojo rely on isHostMethod and Co. Both use
sniffing. If Dojo changes that with your efforts, and YUI still keeps
sniffing, it's clear which one will be more reliable. No questions there.
>
>> Looking at Dojo
>> <http://www.dojotoolkit.org/support/faq/what-browsers-does-dojo-support>
>> I see that they don't support Safari 2.x either (which Prototype, for
>> example, still supports entirely), nor do they support "older" (<9.6)
>> Opera (again, Prototype supports 9.2+). I don't want to start a pissing
>> contest about browser support of Prototype vs Dojo vs YUI. It's just
>> that Safari 3.x and Opera 9.6 stand out (as well as, say, IE5.5, but
>> then almost none of major libraries support that one).
>
> I've talked to them about that. Dojo has been demonstrated to work in
> environments other than those on the official list. I see no reason
> why it can't work on - for example - Opera 8. Certainly it will when
> I am done with it. :)
That's good to hear.
[...]
>>>> The only
>>>> reason Prototype.JS still didn't drop augmenting environment is due to
>>>> backwards compatibility and lack of time.
>>> Put that on its headstone. ;)
>> But what will I be having fun hacking then? ;)
>
> Well, to each his own. If by hacking you mean improving code, why
> don't you come on in for the big win? :)
I do mean improving code. I don't care much which code it is - whether
it's Prototype.js, your "My Library", Garrett's APE, PointedEars's
dhtml.js, Dojo, YUI or jQuery :)
It's all Javascript, which is what I enjoy.
I've seen something weird in all of those and I usually mention it.
[...]
>>> I'd say Dojo and YUI are apples to the other oranges. What sort of a
>>> framework is a script like MooTools?
>> Why apples to oranges? Both provide core methods as well as widgets
>> based on those methods.
>
> jQuery is a monolithic, interdependent mess. Dojo is modular. And
> jQuery's widgets don't count anyway. Would you use widgets built by
> jQuery users, knowing they rely on code from John Resig?
Damn it. I just reread and realized you said "Dojo and YUI are apples to
the other oranges". I thought you were comparing Dojo to YUI, not Dojo
to jQuery.
All the points I made above were to compare Dojo vs. YUI (not Dojo vs.
jQuery). jQuery definitely has a different "philosophy" than Dojo/YUI.
If you reread my comparison again, I'm sure you'll agree with most of it.
[...]
>
> As for sniffing, everybody did it until I started going off about it.
> If you want to go back to the beginning of this movement, you have to
> find the Flash/JS article on A List Apart where I commented that
> sniffing was a very bad idea. Know what the author said? It's good
> enough for jQuery and Dojo. Two years later, here we are. Turns out
> it wasn't good enough. Wonder if he changed *his* script?
>
> And thanks to Thomas for posting examples of jQuery's incessant
> sniffing (around the fall of 2007.) That really kick-started the
> effort. And to that weasel Matt Kruse for making such a spectacular
> fool of himself the whole time (his first response was that jQuery did
> not use browser sniffing, his last was just an infantile tantrum.)
I thought Matt has been around here for a long time. I remember "seeing"
him when reading some of the older threads.
[...]
>>>> Nevertheless, I think YUI has very smart people involved and it is
>>>> experimenting with some great ideas/implementations. It learned from
>>>> previous mistakes and tries not to repeat them in the future. That's
>>>> what I like about them. They also pay a lot of attention to
>>>> accessibility (although, so does Dojo. IIRC, Dojo was one of the first
>>>> to start experimenting with ARIA in their widgets). Check out this video
>>>> about YUI3 <http://yuiblog.com/blog/2009/05/12/video-desai-yui3/>. I
>>>> found it quite enlightening.
>>> Accessibility is certainly key for widgets, but first they have to
>>> work properly. And YUI's are too bloated from what I've seen,
>>> creating some monstrous markup structures.
>> Interesting. I've heard same things about Dojo, including something
>> about using non-standard attributes extensively. Again, I can't judge
>> either, since I haven't reviewed them thoroughly.
>
> The widgets do use custom attributes, but you don't have to use them
> in your markup.
So you can configure widgets in such way that they don't pollute
document with custom attributes?
>
>>
>>
>>>> It would be helpful to make a thorough comparison of YUI and Dojo.
>>> I'm sure it's been done. The TaskSpeed and other performance tests,
>>> blogs, etc.
>> I'll definitely look at Dojo when I get a chance. Perhaps someone else
>> will chime in as well.
>
> And I'll look at YUI (again) when I have a chance, but it will all be
> academic by the end of the summer.
Sounds good.
--
kangax
Garrett Smith
> David Mark wrote:
[...]
For a while there were a lot of jQuery and Prototype posts here. It was
requested to put something in the FAQ, for reasons given in a few threads.
YUI and Dojo don't come up as much. Doesn't really seem like something
that needs to be in the FAQ.
If you feel otherwise, and are so compelled, I'll read your draft.
Garrett
--
The official comp.lang.javascript FAQ:
http://jibbering.com/faq/
David Mark
Agreed.
>
>
> >> Looking at Dojo
> >> <http://www.dojotoolkit.org/support/faq/what-browsers-does-dojo-support>
> >> I see that they don't support Safari 2.x either (which Prototype, for
> >> example, still supports entirely), nor do they support "older" (<9.6)
> >> Opera (again, Prototype supports 9.2+). I don't want to start a pissing
> >> contest about browser support of Prototype vs Dojo vs YUI. It's just
> >> that Safari 3.x and Opera 9.6 stand out (as well as, say, IE5.5, but
> >> then almost none of major libraries support that one).
>
> > I've talked to them about that. Dojo has been demonstrated to work in
> > environments other than those on the official list. I see no reason
> > why it can't work on - for example - Opera 8. Certainly it will when
> > I am done with it. :)
>
> That's good to hear.
I expect it will work (or allow apps to degrade gracefully) with
virtually anything. That's the missing link. Other than My Library
and Fork Javascript (next version?) nothing else does that. In other
words, how do you know which API methods are safe to call? If you
don't know that, all you can do is blunder into an exception (or other
unexpected behavior.)
>
> [...]
>
> >>>> The only
> >>>> reason Prototype.JS still didn't drop augmenting environment is due to
> >>>> backwards compatibility and lack of time.
> >>> Put that on its headstone. ;)
> >> But what will I be having fun hacking then? ;)
>
> > Well, to each his own. If by hacking you mean improving code, why
> > don't you come on in for the big win? :)
>
> I do mean improving code. I don't care much which code it is - whether
> it's Prototype.js, your "My Library", Garrett's APE, PointedEars's
> dhtml.js, Dojo, YUI or jQuery :)
>
> It's all Javascript, which is what I enjoy.
Cool. Of those, Dojo is the one with a future. But if it is JS that
you enjoy, then I suppose that doesn't matter.
>
> I've seen something weird in all of those and I usually mention it.
Absolutely. You've got a good eye for "weirdness" and I value your
opinion. Would be great if you could lend a hand with Dojo over the
summer.
>
> [...]
>
> >>> I'd say Dojo and YUI are apples to the other oranges. What sort of a
> >>> framework is a script like MooTools?
> >> Why apples to oranges? Both provide core methods as well as widgets
> >> based on those methods.
>
> > jQuery is a monolithic, interdependent mess. Dojo is modular. And
> > jQuery's widgets don't count anyway. Would you use widgets built by
> > jQuery users, knowing they rely on code from John Resig?
>
> Damn it. I just reread and realized you said "Dojo and YUI are apples to
> the other oranges". I thought you were comparing Dojo to YUI, not Dojo
> to jQuery.
I thought that was what happened.
>
> All the points I made above were to compare Dojo vs. YUI (not Dojo vs.
> jQuery). jQuery definitely has a different "philosophy" than Dojo/YUI.
> If you reread my comparison again, I'm sure you'll agree with most of it.
Yes. More or less.
>
> [...]
>
>
>
> > As for sniffing, everybody did it until I started going off about it.
> > If you want to go back to the beginning of this movement, you have to
> > find the Flash/JS article on A List Apart where I commented that
> > sniffing was a very bad idea. Know what the author said? It's good
> > enough for jQuery and Dojo. Two years later, here we are. Turns out
> > it wasn't good enough. Wonder if he changed *his* script?
>
> > And thanks to Thomas for posting examples of jQuery's incessant
> > sniffing (around the fall of 2007.) That really kick-started the
> > effort. And to that weasel Matt Kruse for making such a spectacular
> > fool of himself the whole time (his first response was that jQuery did
> > not use browser sniffing, his last was just an infantile tantrum.)
>
> I thought Matt has been around here for a long time. I remember "seeing"
> him when reading some of the older threads.
He has. I was talking about the movement of the "major libraries"
from browser sniffing to feature testing. That started almost exactly
two years ago. First it was jQuery doesn't sniff browsers. Then it
was, okay it does a little. Okay a lot. Be fair, it's completely
fucked. But I use it and it can always be improved, so it isn't all
bad (cognitive dissonance.) Then it was, you couldn't do better
(irrelevant.) Then, oh you did. Then he vanished for a while and
came back to start the whole conversation over like nothing happened.
In the meantime, Resig (who had a similar opinion about who could do
better and why) removed the browser sniffing and replaced it with bad
object inferences that seem to ape my feature testing code.
And that's just the browser sniffing "argument." Look up "attr" (have
to go back to around October 2007) to see a real horror show unfold.
Now that Matt Kruse has no reputation left, he pops up once in a while
to hurl infantile insults (from a safe distance.) Odd, as his only
remaining "argument" was that jQuery people are polite and everyone
else involved with browser scripting is rude and focused on ad hominem
attacks. Looks like quite the opposite these days.
The first time the infamous "stab at competence" review popped up on
Reddit, the comments were virtually all personal insults and "where's
your cool JS library." A year and a half since Resig and I had such
an exchange. Still going strong in syndication, BTW.
http://www.reddit.com/r/programming/comments/8ndyw/jquerys_latest_stab_at_competence/
Actually a few thoughtful replies in there. :) The message is
definitely getting through. Had to be *really* loud though. ;)
>
> [...]
>
>
>
> >>>> Nevertheless, I think YUI has very smart people involved and it is
> >>>> experimenting with some great ideas/implementations. It learned from
> >>>> previous mistakes and tries not to repeat them in the future. That's
> >>>> what I like about them. They also pay a lot of attention to
> >>>> accessibility (although, so does Dojo. IIRC, Dojo was one of the first
> >>>> to start experimenting with ARIA in their widgets). Check out this video
> >>>> about YUI3 <http://yuiblog.com/blog/2009/05/12/video-desai-yui3/>. I
> >>>> found it quite enlightening.
> >>> Accessibility is certainly key for widgets, but first they have to
> >>> work properly. And YUI's are too bloated from what I've seen,
> >>> creating some monstrous markup structures.
> >> Interesting. I've heard same things about Dojo, including something
> >> about using non-standard attributes extensively. Again, I can't judge
> >> either, since I haven't reviewed them thoroughly.
>
> > The widgets do use custom attributes, but you don't have to use them
> > in your markup.
>
> So you can configure widgets in such way that they don't pollute
> document with custom attributes?
I think it still uses them in most cases (something I will be working
to remedy), but at least you don't have to pollute the static markup.
>
>
>
> >>>> It would be helpful to make a thorough comparison of YUI and Dojo.
> >>> I'm sure it's been done. The TaskSpeed and other performance tests,
> >>> blogs, etc.
> >> I'll definitely look at Dojo when I get a chance. Perhaps someone else
> >> will chime in as well.
>
> > And I'll look at YUI (again) when I have a chance, but it will all be
> > academic by the end of the summer.
>
> Sounds good.
It's going to be very good. :)
Peter May
> What JS framework would you guys recommend to me?
Try http://www.domassistant.com/
--
Peter
RobG
No, don't. It seems to munge the worst of jQuery CSS-style selectors
and Prototype.js augmentation of host objects together in one script
that is also depenent on browser sniffing.
The authors' claim that it is the fastest script in the SlickSpeed
tests isn't substantiated - in Safari 4 it comes in 4th out of 7, even
jQuery is faster.
--
Rob
Garrett Smith
Knowing how to use document.getElementById, event bubbling (also called
"delegation") would offer much superior runtime performance.
A codebase that does not have a selector API should be smaller. In
comparison to a codebase that has a selectors API, the one that does
notshould be downloaded faster, interpreted faster, and should have a
smaller memory footprint.
Selectors API: YAGNI.
kangax
> RobG wrote:
>> On Jun 8, 8:34 pm, Peter May <peter....@poczta.fm> wrote:
>>> Ivan S pisze:
>>>
>>>> What JS framework would you guys recommend to me?
>>> Tryhttp://www.domassistant.com/
>>
>>
>> No, don't. It seems to munge the worst of jQuery CSS-style selectors
>> and Prototype.js augmentation of host objects together in one script
>> that is also depenent on browser sniffing.
>>
>> The authors' claim that it is the fastest script in the SlickSpeed
>> tests isn't substantiated - in Safari 4 it comes in 4th out of 7, even
>> jQuery is faster.
>>
>
> Knowing how to use document.getElementById, event bubbling (also called
> "delegation") would offer much superior runtime performance.
You can't do much with `document.getElementById`. Sometimes you want to
select by class, attribute, descendant or a combination of those. I
agree that more complex selectors are rarely needed (well, except maybe
something like `nth-child("odd")`).
Event delegation is great, but then you might want some kind of `match`
method to determine whether a target element matches selector. `match`
is not necessary, of course, but testing an element manually adds noise
and verbosity.
>
> A codebase that does not have a selector API should be smaller. In
> comparison to a codebase that has a selectors API, the one that does
> notshould be downloaded faster, interpreted faster, and should have a
> smaller memory footprint.
That much is... obvious :)
I don't think last two really matter. Execution of an entire fully CSS3
compliant selector engine (such as NWMatcher - the best one of them I've
even seen) doesn't take more than few milliseconds. It's 2ms in
FF3.0.10. Probably not more than 20-30ms in relatively slow IE6,7. Would
you really care about those?
--
kangax
Garrett Smith
I would definitely care about 20ms.
As discussed in previous mails, I have not ever needed an API to check
the tagName and className; that is a very simple and straightforward
thing to do and does not require abstraction.
In my experience, I have not ever needed to check much more than that. I
can't really think of a problem that would be best solved by NWMatcher,
nor can I imagine where NWMatcher would provide a clearer and faster
abstraction.
Why add something that is not necessary?
FWICS, NWMatcher still uses function decompilation.
http://github.com/dperini/nwmatcher/blob/ceaa7fdf733edc1a87777935ed05d6bb74d7722a/src/nwmatcher.js#L44
RobG
> Garrett Smith wrote:
> > RobG wrote:
> >> On Jun 8, 8:34 pm, Peter May <peter....@poczta.fm> wrote:
> >>> Ivan S pisze:
>
> >>>> What JS framework would you guys recommend to me?
> >>> Tryhttp://www.domassistant.com/
>
> >> No, don't. It seems to munge the worst of jQuery CSS-style selectors
> >> and Prototype.js augmentation of host objects together in one script
> >> that is also depenent on browser sniffing.
>
> >> The authors' claim that it is the fastest script in the SlickSpeed
> >> tests isn't substantiated - in Safari 4 it comes in 4th out of 7, even
> >> jQuery is faster.
>
> > Knowing how to use document.getElementById, event bubbling (also called
> > "delegation") would offer much superior runtime performance.
>
> You can't do much with `document.getElementById`. Sometimes you want to
> select by class, attribute, descendant or a combination of those. I
> agree that more complex selectors are rarely needed (well, except maybe
> something like `nth-child("odd")`).
Perhaps, but I can't see a real need for a general purpose solution.
CSS is primarily designed to apply to layout and formatting, it should
be very rare to apply other types of programing logic based on the
same criteria. Most use of CSS selectors seems to be related to
applying CSS 3 styling in browsers that don't support it (such as
putting classes on odd and even table rows) or applying animations
(such as expanding or collapsing all the child elements of an LI in a
menu).
If the specific requirements of an application are addressed directly,
and the design of the layout considers efficient programming, most
such requirements can be met in a few short lines of script. For
example, there was a question in the jQuery group about how to adjust
alternating odd/even classes below an LI that was deleted from a
list. Here was one response:
$("li").removeClass("even").removeClass("odd")
.filter(":odd").addClass("odd")
.end()
.filter(":even").addClass("even");
All that is required is to traverse all elements below the item to be
deleted and toggle the odd/even class, it can be achieved in about the
same amount of code, but vastly less computation is required.
Considering the OP couldn't work out how to do it using jQuery, it
seems the library doesn't really offer any saving in development time
in this particular case.
function toggleOddEven(el) {
var ul = li.parentNode;
var li, lis = ul.getElementsByTagName('li');
var i = lis.length;
while (i--) {
li = lis[i];
if (li == el) {
return;
}
toggleClass(li, 'odd', 'even');
}
where toggleClass is a simple function to swap the class if an element
has one of them. The function (untested) should be very much faster
than the jQuery code it replaces, and took about 1 minute to write.
It should not take any longer than the jQuery equivalent to test
(perhaps less).
The above is unnecessary in browsers that support CSS 3 :nth-child(odd/
even) pseudo-classes.
> Event delegation is great, but then you might want some kind of `match`
> method to determine whether a target element matches selector. `match`
> is not necessary, of course, but testing an element manually adds noise
> and verbosity.
But using the document structure to make that decision is a bad
strategy in the first place. Isn't it simpler to add a class to the
element and test that?
Using the document structure in application logic intrinsicly binds
the structure to behaviour, which I thought was a bad thing. If an
element is a menu item that should appear when its parent is clicked
on and disappear for some other reason, just give it a class of
'menuItem' or similar. Then you don't care if it's an LI, A, DIV or
whatever or what it's position in the DOM tree is, so rather than
something like:
$(this).filter('li').show();
you have:
show(getElementsByClassName(this, 'menuItem'));
> > A codebase that does not have a selector API should be smaller. In
> > comparison to a codebase that has a selectors API, the one that does
> > notshould be downloaded faster, interpreted faster, and should have a
> > smaller memory footprint.
>
> That much is... obvious :)
>
> I don't think last two really matter. Execution of an entire fully CSS3
> compliant selector engine (such as NWMatcher - the best one of them I've
> even seen) doesn't take more than few milliseconds. It's 2ms in
> FF3.0.10. Probably not more than 20-30ms in relatively slow IE6,7. Would
> you really care about those?
I think the real issue is what is the point of the selector engine in
the first place. Given that HTML 5 will usher in querySelectorAll
(QSA) - which unfortunately will be a static collection, not live -
what is the future of script-based solutions other than as a crutch
for a few years until QSA becomes sufficiently common?
--
Rob
Jorge
> (...) Given that HTML 5 will usher in querySelectorAll
> (QSA) - which unfortunately will be a static collection, not live -
What is it that you like so much about a live collection, the word
"live" in its name, or the fact that any items might get swapped by
the browser behind the scenes ? Why don't you prefer to have a fixed,
static set of items, a snapshot of the state of things at a given
time, more so given that you can refresh it as needed ?
Because, while you can easily and for free make a static list "live"
just by re-fetching it (that's what the browser does for you
automatically behind the scenes in a live collection), the opposite
operation is more expensive as it requires duplicating the live list
into another, additional array.
Video is a good thing, but sometimes a photo is much better.
--
Jorge.
kangax
Just to be sure, I checked IE6. It was reporting either 0 or 16ms (with
16ms occurring much more rarely), so I assume it's somewhere in that range.
I'm surprised you would care about those milliseconds. I would worry
about size (48KB original, probably ~30-40 minified and ~15-20 gzipped)
much more than this practically instant initialization.
But then again, most of the time, you wouldn't use all of CSS3
selectors. There's often need for fully-compliant CSS3 selector engine.
>
> As discussed in previous mails, I have not ever needed an API to check
> the tagName and className; that is a very simple and straightforward
> thing to do and does not require abstraction.
Of course. Testing class is easy. It is descendant and attribute values
(as well as combination of those) that introduce complexity.
>
> In my experience, I have not ever needed to check much more than that. I
> can't really think of a problem that would be best solved by NWMatcher,
> nor can I imagine where NWMatcher would provide a clearer and faster
> abstraction.
I'll follow up if I can present a good example.
>
> Why add something that is not necessary?
Necessity is a relative concept ;) Whether such abstraction is to be
used should be determined on a per-project bases, based on the
application nature and its requirements. As always, it's all about
context and balance.
>
> FWICS, NWMatcher still uses function decompilation.
> http://github.com/dperini/nwmatcher/blob/ceaa7fdf733edc1a87777935ed05d6bb74d7722a/src/nwmatcher.js#L44
That's one of the things I dislike in it. Overall, though, it's much
better than anything else I've seen. I helped its author with some of
the feature tests, so I know it doesn't use sniffing or any nonsense
inference. If you see something suspicious, speak up, an author is
usually very responsive to any kind of feedback.
--
kangax
Thomas 'PointedEars' Lahn
> Garrett Smith wrote:
>
> You can't do much with `document.getElementById`. Sometimes you want to
> select by class, attribute, descendant or a combination of those. I
> agree that more complex selectors are rarely needed (well, except maybe
> something like `nth-child("odd")`).
>
> Event delegation is great, but then you might want some kind of `match`
> method to determine whether a target element matches selector. `match`
> is not necessary, of course, but testing an element manually adds noise
> and verbosity.
Iterating over all elements to add event listeners to all target elements
adds much more noise and unreliability. For universally bubbling events,
use event bubbling, and add one event listener to a common ancestor. For
the rest, it depends on how many target elements are there: the more there
are, the more likely is it that the listeners should be added dynamically
(to ease maintenance). That said, some of those events, like `mouseover' on
links, do not even require DOM scripting nowadays (not even in bad old IE 6).
As for verbosity, I fail to see how that could be a drawback.
>> A codebase that does not have a selector API should be smaller. In
>> comparison to a codebase that has a selectors API, the one that does
>> notshould be downloaded faster, interpreted faster, and should have a
>> smaller memory footprint.
>
> That much is... obvious :)
>
> I don't think last two really matter. Execution of an entire fully CSS3
> compliant selector engine (such as NWMatcher - the best one of them I've
> even seen) doesn't take more than few milliseconds. It's 2ms in
> FF3.0.10. Probably not more than 20-30ms in relatively slow IE6,7. Would
> you really care about those?
Yes, because even milliseconds do add up.
PointedEars
Matt Kruse
> there was a question in the jQuery group about how to adjust
> alternating odd/even classes below an LI that was deleted from a
> list. Here was one response:
> $("li").removeClass("even").removeClass("odd")
> .filter(":odd").addClass("odd")
> .end()
> .filter(":even").addClass("even");
Wow, what an uninformed "solution"! Where is that thread? I hope
better alternatives were offered.
> All that is required is to traverse all elements below the item to be
> deleted and toggle the odd/even class, it can be achieved in about the
> same amount of code, but vastly less computation is required.
> Considering the OP couldn't work out how to do it using jQuery, it
> seems the library doesn't really offer any saving in development time
> in this particular case.
Your solution may work, but I think a sane jQuery solution is even
better:
$li.nextAll('li').toggleClass('odd');
Simple and efficient.
Matt Kruse
Thomas 'PointedEars' Lahn
> Your solution may work, but I think a sane jQuery solution is even
> better:
Who can find the contradiction in this sentence?
SCNR
PointedEars
kangax
> kangax wrote:
>> Garrett Smith wrote:
>>> Knowing how to use document.getElementById, event bubbling (also called
>>> "delegation") would offer much superior runtime performance [than jQuery]
>> You can't do much with `document.getElementById`. Sometimes you want to
>> select by class, attribute, descendant or a combination of those. I
>> agree that more complex selectors are rarely needed (well, except maybe
>> something like `nth-child("odd")`).
>>
>> Event delegation is great, but then you might want some kind of `match`
>> method to determine whether a target element matches selector. `match`
>> is not necessary, of course, but testing an element manually adds noise
>> and verbosity.
>
> Iterating over all elements to add event listeners to all target elements
> adds much more noise and unreliability. For universally bubbling events,
I never said anything about adding event listeners to elements being
iterated over. I stopped doing that a while ago in favor of event
delegation. Nevertheless, I still do iterate over elements (by class,
descendant, attribute, etc.) to perform certain action on them, such as
toggling visibility.
I suppose manipulating relevant stylesheet rules could achieve similar
result.
How do you do it?
> use event bubbling, and add one event listener to a common ancestor. For
> the rest, it depends on how many target elements are there: the more there
> are, the more likely is it that the listeners should be added dynamically
> (to ease maintenance). That said, some of those events, like `mouseover' on
> links, do not even require DOM scripting nowadays (not even in bad old IE 6).
>
> As for verbosity, I fail to see how that could be a drawback.
Verbosity has a tendency to add noise. Noise makes it hard to
understand, maintain and refactor code. That's all I meant.
Compare:
if (matches(element, '#sidebar .faq-section .toggle')) { ... };
vs. something like:
if (hasClass(element, 'toggle') &&
hasParentWithClass(element, '.faq-section') &&
hasParentWithId(element, 'sideabar')) { ... }
CSS syntax is concise and well-known. It's easy to understand and maintain.
[...]
--
kangax
Garrett Smith
> On Jun 9, 2:06 am, RobG <robg...@gmail.com> wrote:
[...]
>
> Your solution may work, but I think a sane jQuery solution is even
> better:
>
> $li.nextAll('li').toggleClass('odd');
..^
what is $li?
> Simple and efficient.
>
Relatively, it is not as inefficient, but it is far from ideal. You
don't need any selector API for that.
When a pattern applies to universally to descendants, it is more
efficient to let the browser handle the cascade and inheritance, rather
than do all that traversing manually.
To let the browser handle the cascade, change the class of the
containing element and define a rule for that in the stylesheet.
Example:
css:
.itemList .zebra{
background: #ffe;
}
.itemListRestriped .zebra{
background: #fff;
}
html:
<ul>
<li>
one
</li>
<li class="zebra">
two
</li>
<li>
three
</li>
<li class="zebra">
four
</li>
</ul>
By leting the browser apply the cascade in the stylesheet, the
javascript code is reduced to a couple of lines. No selector API needed:
Example:-
<!doctype html>
<html>
<head>
<title>Toggling Cascade</title>
<style type="text/css">
.zebra{
background: #ffd;
}
.itemListRestriped li {
background: #ffd;
}
.itemListRestriped .zebra{
background: #fff;
}
</style>
</head>
<body>
<ul id="itemList">
<li>
one
</li>
<li class="zebra">
two
</li>
<li>
three
</li>
<li class="zebra">
four
</li>
</ul>
<script type="text/javascript">
// TODO: Replace global var with object state property.
var isRestriped = false;
// TODO: refactor to object.
function restripe() {
var itemList = document.getElementById("itemList");
// TODO: use addClass/removeClass functions.
if(isRestriped) {
itemList.className = "";
} else {
itemList.className = "itemListRestriped";
}
isRestriped = !isRestriped;
}
</script>
<button type="button" onclick="restripe()">restripe()</button>
</body>
</html>
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> Garrett Smith wrote:
>>>> Knowing how to use document.getElementById, event bubbling (also called
>>>> "delegation") would offer much superior runtime performance [than jQuery]
>>> You can't do much with `document.getElementById`. Sometimes you want to
>>> select by class, attribute, descendant or a combination of those. I
>>> agree that more complex selectors are rarely needed (well, except maybe
>>> something like `nth-child("odd")`).
>>>
>>> Event delegation is great, but then you might want some kind of `match`
>>> method to determine whether a target element matches selector. `match`
>>> is not necessary, of course, but testing an element manually adds noise
>>> and verbosity.
>> Iterating over all elements to add event listeners to all target elements
>> adds much more noise and unreliability. For universally bubbling events,
>
> I never said anything about adding event listeners to elements being
> iterated over. I stopped doing that a while ago in favor of event
> delegation. Nevertheless, I still do iterate over elements (by class,
> descendant, attribute, etc.) to perform certain action on them, such as
> toggling visibility.
>
> I suppose manipulating relevant stylesheet rules could achieve similar
> result.
>
> How do you do it?
By ID. It is the most efficient and compatible by far.
>> use event bubbling, and add one event listener to a common ancestor. For
>> the rest, it depends on how many target elements are there: the more there
>> are, the more likely is it that the listeners should be added dynamically
>> (to ease maintenance). That said, some of those events, like `mouseover' on
>> links, do not even require DOM scripting nowadays (not even in bad old IE 6).
>>
>> As for verbosity, I fail to see how that could be a drawback.
>
> Verbosity has a tendency to add noise. Noise makes it hard to
> understand, maintain and refactor code. That's all I meant.
>
> Compare:
>
> if (matches(element, '#sidebar .faq-section .toggle')) { ... };
>
> vs. something like:
>
> if (hasClass(element, 'toggle') &&
> hasParentWithClass(element, '.faq-section') &&
> hasParentWithId(element, 'sideabar')) { ... }
>
> CSS syntax is concise and well-known. It's easy to understand and maintain.
But that is why one uses CSS for formatting and not scripting. For example,
if it is necessary to hide elements in a certain context on click, this
stylesheet fragment:
#sidebar .faq-section div.toggle.hidden {
display: none;
}
The only thing that needs to be in the client-side script now is changing
the `className' property of the event target to add/remove `hidden' if its
`className' property includes `toggle'.¹ BTDT (with mouseover and mouseout).
HTH
PointedEars
___________
¹ Meaning that the white-space separated list of the `className'
property/`class' attribute value contains or does not contain
said substring.
Matt Kruse
> Matt Kruse wrote:
> > Your solution may work, but I think a sane jQuery solution is even
> > better:
> > $li.nextAll('li').toggleClass('odd');
> ..^
> what is $li?
Assumed to be a jQuery object referencing the LI element to be
removed.
> > Simple and efficient.
> Relatively, it is not as inefficient, but it is far from ideal.
Depends on how you define "ideal". In that it is short, easily
written, easy to understand, easy to debug, and fast enough under any
realistic usage situation, I would say it is as ideal as other
options.
> You don't need any selector API for that.
True, but if jQuery is on the page already, you might as well use it.
I certainly wouldn't introduce jQuery into a page just to do this.
> To let the browser handle the cascade, change the class of the
> containing element and define a rule for that in the stylesheet.
> Example:
> css:
> .itemList .zebra{
> background: #ffe;
> }
> .itemListRestriped .zebra{
> background: #fff;
> }
That doesn't address the original problem or removing an element from
the list and having to re-apply the striping because your odd/even
distinctions have been messed up.
Of course, this is certainly best handled by using pure CSS alone, but
we're stilling living in a web where that's not practical for most.
Matt Kruse
kangax
> kangax wrote:
>> Compare:
>>
>> if (matches(element, '#sidebar .faq-section .toggle')) { ... };
>>
>> vs. something like:
>>
>> if (hasClass(element, 'toggle') &&
>> hasParentWithClass(element, '.faq-section') &&
>> hasParentWithId(element, 'sideabar')) { ... }
>>
>> CSS syntax is concise and well-known. It's easy to understand and maintain.
>
> But that is why one uses CSS for formatting and not scripting. For example,
> if it is necessary to hide elements in a certain context on click, this
> stylesheet fragment:
>
> #sidebar .faq-section div.toggle.hidden {
> display: none;
> }
Btw, IIRC, IE6 - not understanding multiple classes - will parse this as:
#sidebar .faq-section div.hidden
But that could be worked around, of course.
>
> The only thing that needs to be in the client-side script now is changing
> the `className' property of the event target to add/remove `hidden' if its
> `className' property includes `toggle'.¹ BTDT (with mouseover and mouseout).
This is a very elegant approach, indeed. The only problem is that
clicking on `.toggle` should usually hide *another element*. For
example, toggle link can be located in H2 and H2 might be followed by
DIV; That DIV is the one that needs to be toggled. I suppose one can add
"hidden" class to a parent element (or any other ancestor) but then
relevant CSS rules add up in complexity.
Besides, one would need to constantly look up corresponding declarations
in stylesheet when reading/changing this code.
--
kangax
Conrad Lender
>> #sidebar .faq-section div.toggle.hidden { display: none; }
>
> Btw, IIRC, IE6 - not understanding multiple classes - will parse this
> as:
>
> #sidebar .faq-section div.hidden
Even IE5 understands div.toggle.hidden (IE4 doesn't, but who cares).
- Conrad
kangax
It's possible that I'm going crazy...
Do you see all 3 div's of different color in IE6?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
<title></title>
<style type="text/css">
.foo { background-color: red; }
.bar { background-color: green; }
.foo.bar { background-color: blue; }
</style>
</head>
<body>
<div class="foo">foo</div>
<div class="bar">bar</div>
<div class="foo bar">foo bar</div>
</body>
</html>
--
kangax
Matt Kruse
> Even IE5 understands div.toggle.hidden (IE4 doesn't, but who cares).
IE6 does not understand a rule like:
div.a.b { ... }
It treats it the same as:
div.b { ... }
Matt Kruse
Conrad Lender
You're both correct. I made a silly mistake in my test...
div.foo.bar { border: 1px solid red; }
<div class="foo bar">x</div>
...and concluded from this that it was working properly with two class
names, which of course it wasn't. I was wondering why this hasn't caused
problems for me before, and looked through some recent style sheets. By
pure coincidence, the last class name was always unique in the document,
so I never noticed the problem. Thanks for pointing it out!
- Conrad
RobG
> On Jun 9, 9:06 am, RobG <robg...@gmail.com> wrote:
>
> > (...) Given that HTML 5 will usher in querySelectorAll
> > (QSA) - which unfortunately will be a static collection, not live -
> > (...)
>
> What is it that you like so much about a live collection, the word
> "live" in its name, or the fact that any items might get swapped by
> the browser behind the scenes ?
The fact that you can get a reference to them once, then they
automatically update when the DOM changes.
> Why don't you prefer to have a fixed,
> static set of items, a snapshot of the state of things at a given
> time, more so given that you can refresh it as needed ?
Because browser-native code will do that much, much faster that
javascript.
How do you pass a static collection to another method in a way that it
knows how to update it? You either have to create your own object
with an update method, the callee has to update it before passing it
or the receiving function has to make a guess about the parameter
being passed. Passing a live collection doesn't have all those
issues, it just has to deal with the collection knowing that at any
point in time it represents the actual DOM.
> Because, while you can easily and for free make a static list "live"
> just by re-fetching it
That isn't "free", nor live; and there are other issues (see below).
> (that's what the browser does for you
> automatically behind the scenes in a live collection),
You can only make that statement if you have read the actually
implementation of live collections in more than a couple of browsers.
Have you? It is just as likely that the browser caches the collection
and updates it whenever the DOM changes so it never "re-fetches" the
entire collection. Browsers have been dealing with live lists since
CSS 1 at least, the code should already be highly optimised and deal
with a changing DOM.
In any case, the browser will do it much more efficiently than
javascript.
> the opposite
> operation is more expensive as it requires duplicating the live list
> into another, additional array.
Only if you want a static list. What is it that you like so much
about static lists? The only trick with live collections is if you
are adding or deleting items in a loop. If all collections are live,
then once you learn to do that, life is easy.
I think the supposed performance penalty of a live list is a furphy
put about by those who like static lists (possibly motivated by the
fact that current javascript implementations of qSA are static). On
the HTML 5 mailing list, one of the Firefox developers wrote in to say
that live lists are actually faster, because Firefox already creates
lots of them and has highly optimised code for doing so. Their static
lists would actually be live lists converted to static.
--
Rob
Garrett Smith
Solving the wrong problem doesn't help much, does it?
When the element is removed, loop through the remaining elements,
starting at that next sibling element.
jQuery.dir = function( elem, dir ){
var matched = [], cur = elem[dir];
while ( cur && cur != document ) {
if ( cur.nodeType == 1 )
matched.push( cur );
cur = cur[dir];
}
return matched;
};
I don't much like identifier name |dir|, but it would seem to accomplish
traversal of "parentNode", "nextSibling", and "previousSibling". I
rather think elementsFromNode( node, dir ) explains the intent a bit
more clearly.
The solution requires a double traversal, though, once to collect the
nodes, then once to iterate over the returned array.
Writing it out by hand would be more tedious, but could be more
efficient. If the logic occurred in a few spots, a Restriper that could
work with TR or LI would be another possible solution.
> Of course, this is certainly best handled by using pure CSS alone, but
> we're stilling living in a web where that's not practical for most.
Right. Selectors Level 3 ":nth-child" makes logical sense but it doesn't
work in IE.
Purely presentation stuff like that does not belong in javascript. It
should be possible without script. Not olnly avascript should not be
required for that to work, it is the wrong way to solve that problem.
Other options include not restriping, or a page refresh.
It seems the CSSWG has had a working draft for the ":nth-child" selector
since 2005[1]. Before that, :nth-child() was a candidate recommendation
in "Selectors", going back to 1999[2]. Four years seems like a long time
for a Working Draft status, and for that a proposal to get out the door,
ten years seems like a long time.
Since it is a working draft, Microsoft has a valid reason for not
implementing it[3][4].
IMO, the Selectors Level 3 working draft should be completed promptly
with a test suite for implementations to verify against.
[1]Selectors 2005: http://www.w3.org/TR/2005/WD-css3-selectors-20051215/
[2]Selectors 1999: http://www.w3.org/TR/1999/WD-CSS3-selectors-19990803
[3]IE Bugtracker:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=445224&wa=wsignin1.0
[4]MSDN CSS Compatibility:
http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx?ppud=4
Garrett Smith
> Matt Kruse wrote:
>> On Jun 9, 1:43 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>> Matt Kruse wrote:
[...]
>
> When the element is removed, loop through the remaining elements,
> starting at that next sibling element.
>
> jQuery.dir = function( elem, dir ){
> var matched = [], cur = elem[dir];
> while ( cur && cur != document ) {
> if ( cur.nodeType == 1 )
> matched.push( cur );
> cur = cur[dir];
> }
> return matched;
> };
>
> I don't much like identifier name |dir|, but it would seem to accomplish
> traversal of "parentNode", "nextSibling", and "previousSibling". I
> rather think elementsFromNode( node, dir ) explains the intent a bit
> more clearly.
>
> The solution requires a double traversal, though, once to collect the
> nodes, then once to iterate over the returned array.
>
Post post idea...
Performance coudl be improved by having elementsFromNode accepts a
callback function.
But then it would not have a return, so would want a new name. Like
iterateElementsFromNode.
Given a starting node, iteration iterates through element nodes in a
given direction, after |node|.
// untested.
function iterateElementsFromNode( node, dir, callback, context ) {
var n, i = 0, doc = node.ownerDocument;
for(n = node[dir]; n != null && n !== doc; n = n[dir]) {
if ( n.nodeType === 1 ) {
callback.call(context, n, i++);
}
}
}
// Sample callback would be something like:
function cb(n, i) {
var zebra = (i % 2 === 0) ? "even" : "odd";
document.writeln(n.tagName + ", ", i + ", " + zebra);
}
Simpler than using a selctors API.
Garrett
Matt Kruse
>...
> Simpler than using a selctors API.
That's still up to personal preference. I wrote working code in
literally about 10 seconds which does the exact same thing you are
trying to do with many lines of code and a few attempts.
In my mind, this is a demonstration of why libraries like jQuery are
useful and beneficial. IMO, the one-line, straight-forward jQuery
solution is by far the simplest. I'm not sure why you would consider
your example code simpler. But that's fine :)
Matt Kruse
Garrett Smith
> On Jun 9, 7:46 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> ...
>> Simpler than using a selctors API.
>
> That's still up to personal preference. I wrote working code in
> literally about 10 seconds which does the exact same thing you are
> trying to do with many lines of code and a few attempts.
>
Sorry, but where is the usage of "Selector API" in your code?
> In my mind, this is a demonstration of why libraries like jQuery are
> useful and beneficial. IMO, the one-line, straight-forward jQuery
> solution is by far the simplest. I'm not sure why you would consider
> your example code simpler. But that's fine :)
>
Traversal functions are often useful. The jQuery |dir| function is what
the |nextAll| method comes down to. That could be improved and that is
what my revisions are based on. It would be clearer if revised.
THe code I wrote is a comparison to the jQuery dir function (jQUery.dir
is called by nextAll and nextAll is what your code called). While
jQuery.dir is pretty simple, I thought it could a little be better,
starting with the name.
The code using the dir method had to iterate through the returned array
and perform a callback on each item, roughly doubling the number of
iterations. In our case, it is more efficient to have that method accept
a callback function and call it there. There may be other situations
where the caller wants an array back (to reverse or sort it). I can see
that. It might be OK to leave good enough alone.
Still, I think the name ought to change.
RobG
> On Jun 9, 2:06 am, RobG <robg...@gmail.com> wrote:
>
> > there was a question in the jQuery group about how to adjust
> > alternating odd/even classes below an LI that was deleted from a
> > list. Here was one response:
> > $("li").removeClass("even").removeClass("odd")
> > .filter(":odd").addClass("odd")
> > .end()
> > .filter(":even").addClass("even");
>
> Wow, what an uninformed "solution"! Where is that thread? I hope
> better alternatives were offered.
<URL: http://groups.google.com/group/jquery-en/msg/6ac7678377414207>
>
> > All that is required is to traverse all elements below the item to be
> > deleted and toggle the odd/even class, it can be achieved in about the
> > same amount of code, but vastly less computation is required.
> > Considering the OP couldn't work out how to do it using jQuery, it
> > seems the library doesn't really offer any saving in development time
> > in this particular case.
>
> Your solution may work, but I think a sane jQuery solution is even
> better:
>
> $li.nextAll('li').toggleClass('odd');
Sure, but clearly you know jQuery better than most. The first step is
to deternine a suitable algorithm for the solution (toggle the class
of subsequent LI siblings), then to implement it. I don't think any
library inherently creates "better" solutions as shown by the
"solution" offered above.
Is someone better off learning jQuery, or learning javascript - which
they are going to have to learn anyway if they have a future in web
development?
> Simple and efficient.
But it isn't either. If it was simple, one of the posters in the
thread would have known it - jQuery doesn't give you the answer, it's
just a tool that can be used to implement a solution. It may be
efficient in terms of the time it takes someone experienced with
jQuery to write it versus someone experienced in javascript, however
it is certainly not efficient in terms of CPU usage. That may not be
an issue in a menu list of 10 items, but there are regular posters
talking about tables of 4,000 rows. It would be nice to see jQuery vs
POJS in that case.
--
Rob
Garrett Smith
Jorge
> On Jun 9, 7:27 pm, Jorge <jo...@jorgechamorro.com> wrote:
> > Why don't you prefer to have a fixed,
> > static set of items, a snapshot of the state of things at a given
> > time, more so given that you can refresh it as needed ?
>
> Because browser-native code will do that much, much faster that
> javascript.
If the browser implements qSA() as native code, native code is what's
going to be executed in both cases (1). And, BTW, in the event that the
browser doesn't implement it natively, it can be easily implemented in
javascript for static lists, but *not* so for live collections: that
would *require* a getter...
> How do you pass a static collection to another method in a way that it
> knows how to update it? You either have to create your own object
> with an update method, the callee has to update it before passing it
> or the receiving function has to make a guess about the parameter
> being passed. Passing a live collection doesn't have all those
> issues, it just has to deal with the collection knowing that at any
> point in time it represents the actual DOM.
Of course, but you wouldn't expect a static list to be live, would you ?
> > Because, while you can easily and for free make a static list "live"
> > just by re-fetching it
>
> That isn't "free", nor live; and there are other issues (see below).
>
> > (that's what the browser does for you
> > automatically behind the scenes in a live collection),
>
> You can only make that statement if you have read the actually
> implementation of live collections in more than a couple of browsers.
> Have you?
For an experienced programmer like you that ought be so obvious (!).
Think about it again.
> It is just as likely that the browser caches the collection
> and updates it whenever the DOM changes so it never "re-fetches" the
> entire collection. Browsers have been dealing with live lists since
> CSS 1 at least, the code should already be highly optimised and deal
> with a changing DOM.
A live collection is no more than a static list whose getters do a
refresh, an update, a re-build. Conceded that there's no need to refresh
it unless the "dirty bit" is set in the DOM tree. But a similar strategy
can be applied to static lists as well.
> In any case, the browser will do it much more efficiently than
> javascript.
See above (1).
> > the opposite
> > operation is more expensive as it requires duplicating the live list
> > into another, additional array.
>
> Only if you want a static list. What is it that you like so much
> about static lists? The only trick with live collections is if you
> are adding or deleting items in a loop. If all collections are live,
> then once you learn to do that, life is easy.
Life would be easier if you didn't have to walk around with tricks each
and every time. It's better to be able to command a refresh when a
refresh is what you need, than to have the browser command refreshes for
you unnecessarily or at arbitrary and often inconvenient times.
> I think the supposed performance penalty of a live list is a furphy
> put about by those who like static lists (possibly motivated by the
> fact that current javascript implementations of qSA are static). On
> the HTML 5 mailing list, one of the Firefox developers wrote in to say
> that live lists are actually faster, because Firefox already creates
> lots of them and has highly optimised code for doing so. Their static
> lists would actually be live lists converted to static.
Both take as long to build the first time a certain query is made, and
subsequent updates can be optimized equally in both cases.
--
Jorge.
Matt Kruse
> On Jun 10, 2:21 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> > Wow, what an uninformed "solution"! Where is that thread? I hope
> > better alternatives were offered.
> <URL:http://groups.google.com/group/jquery-en/msg/6ac7678377414207>
I see that someone else replied with a solution similar to mine, thank
goodness.
> > $li.nextAll('li').toggleClass('odd');
> Sure, but clearly you know jQuery better than most. The first step is
> to deternine a suitable algorithm for the solution (toggle the class
> of subsequent LI siblings), then to implement it. I don't think any
> library inherently creates "better" solutions as shown by the
> "solution" offered above.
I most certainly agree. jQuery provides tools. An uninformed developer
can take any tool and create something terrifying! :)
Some say that jQuery provides the tools in a way that almost
encourages misuse, and I'm inclined to agree in many areas. Which is
why I'm pretty specific about who I think should use jQuery and under
what circumstances.
As it applies to the topic at hand, I would say:
1. The developer should have a good understanding of CSS/JS before
even facing this problem
2. The algorithm is independent of the coding and should be easily
found by a developer with moderate experience and logical thinking.
3. The developer should be familiar enough with jQuery to know the
range of tools it provides. I consulted my cheat sheet to find the
name of the nextAll() method because I didn't remember the name,
having never used it before, AFAIK. But I knew the functionality
existed because I have a broad view of the library.
4. The developer should hopefully be experienced enough to look at the
longer proposed solution and know that something is fishy in there,
and it could be simplified. But the ability to "sense" the opportunity
for optimization it something that is learned with time and
experience.
5. The developer should have enough experience to know that this
solution will be efficient enough for most cases. But jQuery starts to
break down when asked to do too much, so if performance suffers, the
developer should have enough js experience to recognize this, rip out
the jQuery code, and replace it with POJS.
It's unfortunate that many developers lack the skills to properly
understand all these points. And it's unfortunate that so many people
are looking to "learn jQuery" because POJS is "too hard".
> Is someone better off learning jQuery, or learning javascript - which
> they are going to have to learn anyway if they have a future in web
> development?
Two posts in the jQuery group recently are typical of the mindset that
is troubling, IMO.
One was looking for jQuery books because they wanted to learn jQuery
before learning javascript. Cart. Horse. The other said that
javascript is "voodoo" to them, so they were complaining about
implementing the datePicker and not understanding the _javascript_
required! Shocking!
This kind of thing is typical of any tool that tries to bring a
sufficiently complicated technology to the masses, though.
Years ago, people figured out how to beam signals through the air,
build devices to capture these invisible signals, amplify them with
electricity, and use them to control a gun firing millions of
electrons into a screen to show 29.97 pictures per second and simulate
a moving image. Very complex technology brought into the living room
of the masses, yet decades later people still can't figure out their
remote control. Typical.
> it is certainly not efficient in terms of CPU usage. That may not be
> an issue in a menu list of 10 items, but there are regular posters
> talking about tables of 4,000 rows. It would be nice to see jQuery vs
> POJS in that case.
Indeed, many users wielding the jQuery hammer only see nails. I have
ripped out jQuery code and replaced it with POJS more times than I
care to count.
As I said to a fellow developer yesterday... "jQuery provides
convenience, not power. Don't confuse the two."
Matt Kruse
RobG
> On Jun 10, 1:03 am, RobG <robg...@gmail.com> wrote:
> > On Jun 9, 7:27 pm, Jorge <jo...@jorgechamorro.com> wrote:
> > (...)
> > > Why don't you prefer to have a fixed,
> > > static set of items, a snapshot of the state of things at a given
> > > time, more so given that you can refresh it as needed ?
> >
> > Because browser-native code will do that much, much faster that
> > javascript.
>
> If the browser implements qSA() as native code, native code is what's
> going to be executed in both cases (1). And, BTW, in the event that the
> browser doesn't implement it natively, it can be easily implemented in
> javascript for static lists, but *not* so for live collections: that
> would *require* a getter...
The point is that if the choice is only one or the other, I'd prefer
to have live lists and convert them to static using JS than having
static lists that I have to update every time I use them to imitate
live lists. One suggestion on the HTML 5 list was to have both live
and static collections, either as separate methods or using a
parameter. To me that would be the best solution.
[...]
>
> > > Because, while you can easily and for free make a static list "live"
> > > just by re-fetching it
> >
> > That isn't "free", nor live; and there are other issues (see below).
> >
> > > (that's what the browser does for you
> > > automatically behind the scenes in a live collection),
> >
> > You can only make that statement if you have read the actually
> > implementation of live collections in more than a couple of browsers.
> > Have you?
>
> For an experienced programmer like you that ought be so obvious (!).
So you haven't.
> Think about it again.
Unless you provide new information, the I'll reach the same conclusion
(to do otherwise would be illogical). There are dozens of ways to
implement particular functions, 5 or 10 will be equivalent for
criteria such as performance, robustness and maintainability. It is
myopic to assume that there is only one way to do something and naive
to think that that one way will occur to everyone who approaches the
problem independently.
If collections are re-fetched every time they are used, the speed of a
loop using a live collection should be very much slower than one using
a static collection. In IE, working with collections generated by
getElementsByTagName is very much faster than using HTML DOM
collections like table.rows (both collections are live). That
provides a hint to me that one has been implemented efficiently, the
other hasn't. If all such collections were simply re-fetched every
time (or implemented using the same basic logic, whatever that might
be), the speed difference would not be so pronounced. So there are
likely at least two different approaches implemented in IE, and any
claims that there is only one way to do it need more proof than simple
conjecture.
The fact that browsers have been dealing with live collections for
over a decade and that some perform very much faster than others
indicates to me that they likely use highly optimised algorithms that
do not simply re-get entire collections every time they are required.
> > It is just as likely that the browser caches the collection
> > and updates it whenever the DOM changes so it never "re-fetches" the
> > entire collection. Browsers have been dealing with live lists since
> > CSS 1 at least, the code should already be highly optimised and deal
> > with a changing DOM.
>
> A live collection is no more than a static list whose getters do a
> refresh, an update, a re-build.
Unless you *know* that to be the case (and I don't think you do), you
can't claim that is how it has been implemented as a general solution
in modern browsers. In any case, it is irrelevant how the browser
does it - at the end of the day the question is whether working with
live or static lists with javascript in a particular case is
preferable based on some objective criteria (performance, robustness,
maintainability, complexity, etc.).
> Conceded that there's no need to refresh
> it unless the "dirty bit" is set in the DOM tree. But a similar strategy
> can be applied to static lists as well.
Your argument is based on the supposed performance issue of re-
fetching a live collection whenever it is used. Now you're saying
browsers don't do it because it's inefficient, so there may not be any
performance issue at all (and that view was supported by someone on
the Firefox development team).
[...]
> > I think the supposed performance penalty of a live list is a furphy
> > put about by those who like static lists (possibly motivated by the
> > fact that current javascript implementations of qSA are static). On
> > the HTML 5 mailing list, one of the Firefox developers wrote in to say
> > that live lists are actually faster, because Firefox already creates
> > lots of them and has highly optimised code for doing so. Their static
> > lists would actually be live lists converted to static.
>
> Both take as long to build the first time a certain query is made,
That statement directly contradicts the evidence above and your own
argument. If a static list is a live list converted to static (which
is how Firefox developers plan to implement at least some parts of
qSA), you are assuming the conversion takes zero time. Maxwell's
demon lives! :-)
> and
> subsequent updates can be optimized equally in both cases.
So there is no inherent performance issue. Whether live or static
lists are "better" in a particular case should be discussed in terms
of specific specific requirements related to javascript and the
general statement that live lists are slower or harder to work with is
debunked.
QED.
--
Rob
Jorge
> On Jun 10, 10:21 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > If the browser implements qSA() as native code, native code is what's
> > going to be executed in both cases (1). And, BTW, in the event that the
> > browser doesn't implement it natively, it can be easily implemented in
> > javascript for static lists, but *not* so for live collections: that
> > would *require* a getter...
>
> The point is that if the choice is only one or the other,
A live collection can *not* be emulated in JS.
> I'd prefer
> to have live lists and convert them to static using JS than having
> static lists that I have to update every time I use them to imitate
> live lists.
>
>
> > > > Because, while you can easily and for free make a static list "live"
> > > > just by re-fetching it
>
> > > That isn't "free", nor live; and there are other issues (see below).
>
> > > > (that's what the browser does for you
> > > > automatically behind the scenes in a live collection),
>
> > > You can only make that statement if you have read the actually
> > > implementation of live collections in more than a couple of browsers.
> > > Have you?
>
> > For an experienced programmer like you that ought be so obvious (!).
>
> So you haven't.
>
> > Think about it again.
>
> Unless you provide new information, the I'll reach the same conclusion
> (to do otherwise would be illogical). There are dozens of ways to
> implement particular functions, 5 or 10 will be equivalent for
> criteria such as performance, robustness and maintainability. It is
> myopic to assume that there is only one way to do something and naive
> to think that that one way will occur to everyone who approaches the
> problem independently.
(1) There are only 2 possibilities:
Upon entering the getter, you either
-are confident that the collection is already updated (in that case,
every DOM touch operation must update all the live collections ~=
nonsense),
or,
-it needs to check first wether an update is required, and update or
not, accordingly.
> If collections are re-fetched every time they are used, the speed of a
> loop using a live collection should be very much slower than one using
> a static collection.
And they always are, much more so if/when the DOM is dirty.
> In IE, working with collections generated by
> getElementsByTagName is very much faster than using HTML DOM
> collections like table.rows (both collections are live). That
> provides a hint to me that one has been implemented efficiently, the
> other hasn't. If all such collections were simply re-fetched every
> time (or implemented using the same basic logic, whatever that might
> be), the speed difference would not be so pronounced. So there are
> likely at least two different approaches implemented in IE, and any
> claims that there is only one way to do it need more proof than simple
> conjecture.
I'm not saying there's just one way of doing it.
> The fact that browsers have been dealing with live collections for
> over a decade and that some perform very much faster than others
> indicates to me that they likely use highly optimised algorithms that
> do not simply re-get entire collections every time they are required.
>
> > > It is just as likely that the browser caches the collection
> > > and updates it whenever the DOM changes so it never "re-fetches" the
> > > entire collection. Browsers have been dealing with live lists since
> > > CSS 1 at least, the code should already be highly optimised and deal
> > > with a changing DOM.
>
> > A live collection is no more than a static list whose getters do a
> > refresh, an update, a re-build.
>
> Unless you *know* that to be the case (and I don't think you do), you
> can't claim that is how it has been implemented as a general solution
> in modern browsers.
I don't (you neither) need to see the source code: just think: (1)
> In any case, it is irrelevant how the browser
> does it - at the end of the day the question is whether working with
> live or static lists with javascript in a particular case is
> preferable based on some objective criteria (performance, robustness,
> maintainability, complexity, etc.).
> (...)
> Your argument is based on the supposed performance issue of re-
> fetching a live collection whenever it is used. Now you're saying
> browsers don't do it because it's inefficient, so there may not be any
> performance issue at all (and that view was supported by someone on
> the Firefox development team).
> (...)
> That statement directly contradicts the evidence above and your own
> argument. If a static list is a live list converted to static (which
> is how Firefox developers plan to implement at least some parts of
> qSA), you are assuming the conversion takes zero time. Maxwell's
> demon lives! :-)
> (...)
> So there is no inherent performance issue. Whether live or static
> lists are "better" in a particular case should be discussed in terms
> of specific specific requirements related to javascript and the
> general statement that live lists are slower or harder to work with is
> debunked.
>
> QED.
See for yourself:
http://jorgechamorro.com/cljs/058/
qSA is available in Safari 3 and 4, Chrome, FF3.5b, Opera 10 and IE8,
AFAIK.
When dirty DOM: ON, the DOM is touched to be sure that it's dirty.
And let me know,
TIA,
--
Jorge.
Jorge
>
> (1) There are only 2 possibilities:
>
> Upon entering the getter, you either
>
> -are confident that the collection is already updated (in that case,
> every DOM touch operation must update all the live collections ~=
> nonsense),
> or,
> -it needs to check first wether an update is required, and update or
> not, accordingly.
or,
-Blindly update it ever, just in case. (~= lazy)
--
Jorge.
RobG
> On Jun 11, 2:07 am, RobG <robg...@gmail.com> wrote:
>
> > On Jun 10, 10:21 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > > If the browser implements qSA() as native code, native code is what's
> > > going to be executed in both cases (1). And, BTW, in the event that the
> > > browser doesn't implement it natively, it can be easily implemented in
> > > javascript for static lists, but *not* so for live collections: that
> > > would *require* a getter...
>
> > The point is that if the choice is only one or the other,
>
> A live collection can *not* be emulated in JS.
We're talking about *browser* methods, and whether the specification
should or shouldn't support live collections. I've already said that
it would be great if it allowed both live and static. The reason I
would like live collections is that for those cases where a static
collection is indicated, it is much simpler in JS to convert a live
collection to static than vice versa (e.g. you have to re-fetch the
static collection each time or update it some other way).
In any case, live collections can be emulated in JS, e.g. you can
provide a DOM manipulation API and specify that collections are only
live if the API is used. You don't have to emulate all the features
of general DOM manipulation API, just the bits required for the job.
At the risk of repeating myself...
> > I'd prefer
> > to have live lists and convert them to static using JS than having
> > static lists that I have to update every time I use them to imitate
> > live lists.
[...]
> > Unless you provide new information, the I'll reach the same conclusion
> > (to do otherwise would be illogical). There are dozens of ways to
> > implement particular functions, 5 or 10 will be equivalent for
> > criteria such as performance, robustness and maintainability. It is
> > myopic to assume that there is only one way to do something and naive
> > to think that that one way will occur to everyone who approaches the
> > problem independently.
>
> (1) There are only 2 possibilities:
>
> Upon entering the getter, you either
>
> -are confident that the collection is already updated (in that case,
> every DOM touch operation must update all the live collections ~=
> nonsense),
Not at all. Another method is to keep references to the collections
that an element belongs to so that when the element is modified so is
the collection. Another is to create an index system for the most
common collections, there are likely others.
> or,
> -it needs to check first wether an update is required, and update or
> not, accordingly.
>
> > If collections are re-fetched every time they are used, the speed of a
> > loop using a live collection should be very much slower than one using
> > a static collection.
>
> And they always are, much more so if/when the DOM is dirty.
I guess you are basing that on your tests, see comments below.
[...]
> See for yourself:
>
> http://jorgechamorro.com/cljs/058/
>
> qSA is available in Safari 3 and 4, Chrome, FF3.5b, Opera 10 and IE8,
> AFAIK.
>
> When dirty DOM: ON, the DOM is touched to be sure that it's dirty.
>
> And let me know,
The flaws I see in the test are:
1. It doesn't update the static collection when the DOM is dirty -
clearly that needs to be done if the static collection is to provide
the same functionality as a live one
2. It doesn't test scenarios of looping over a collection when some
part of the DOM that doesn't belong to the collection is modified
3. It gets the length of collections every time - that may be
irrelevant, but it might not either.
I ran the script in Safari 4 on a 1GHz G4 MacBook, Firefox 3 died. The
results were:
Method Dirty not Dirty
(ms) (ms)
live 350 2.61
static 118 0.35
qSA 122 2.49
Summary: static was about 3 times faster than live for dirty, 8 times
faster for clean. qSA is the same speed as static for dirty, but the
same speed as live for clean (dunno what to make of that).
What do I get from the above?
1. Live collections are updated whenever elements in the collection
are modified (as expected). It doesn't show whether it is updated:
a. unconditionally whenever the DOM is modified,
b. only when a member of the collection is modified,
c. only when the collection is accessed, or
d. some other epoch
can't be determined from this test (the suggested non-collection DOM
modification will help clear that up). The test also doesn't reveal
how the collection is updated (is it re-fetched or a more
sophisticated algorithm used).
2. The comparison between qSA and static shows probably nothing
special happens when a static collection is accessed (as expected)
3. Accessing the members of an array by index is faster than accessing
the members of a live collection by index. Why that occurs can't be
determined by the test, it may have nothing to do with the nature of
the collection and more to do with the fact that arrays might be more
highly optimsed for such access. There is no reason why accessing the
collection is slower when the DOM hasn't been modified.
4. Whether a live or static collection is more efficient can only be
determined on a case by case basis.
If the DOM methods don't provide live collections, that's one option
that isn't available. Implementing live collections from static in JS
is likely much more expensive than implementing static from live.
However, the best solution would be for both to be available so
programers have a wider range of tools at their disposal.
--
Rob
kangax
> On Jun 11, 8:30 pm, Jorge <jo...@jorgechamorro.com> wrote:
>> On Jun 11, 2:07 am, RobG <robg...@gmail.com> wrote:
>>
>>> On Jun 10, 10:21 pm, Jorge <jo...@jorgechamorro.com> wrote:
>>>> If the browser implements qSA() as native code, native code is what's
>>>> going to be executed in both cases (1). And, BTW, in the event that the
>>>> browser doesn't implement it natively, it can be easily implemented in
>>>> javascript for static lists, but *not* so for live collections: that
>>>> would *require* a getter...
>>> The point is that if the choice is only one or the other,
>> A live collection can *not* be emulated in JS.
>
> We're talking about *browser* methods, and whether the specification
> should or shouldn't support live collections. I've already said that
> it would be great if it allowed both live and static. The reason I
> would like live collections is that for those cases where a static
> collection is indicated, it is much simpler in JS to convert a live
> collection to static than vice versa (e.g. you have to re-fetch the
> static collection each time or update it some other way).
>
> In any case, live collections can be emulated in JS, e.g. you can
> provide a DOM manipulation API and specify that collections are only
> live if the API is used. You don't have to emulate all the features
> of general DOM manipulation API, just the bits required for the job.
Yep, it will most definitely be inefficient, error-prone and limited by
a tiny subset of browsers, but it is possible :)
I just wrote a simple implementation as a silly but fun exercise (tested
in FF3.0.10, but should work in any client that supports mutation
events, i.e. "DOMSubtreeModified"):
var getLive = (function(){
var collections = { };
var _slice = Array.prototype.slice;
window.addEventListener('DOMSubtreeModified', function(){
for (var prop in collections) {
// keep same array object, but clear it
collections[prop].length = 0;
var temp = getByTagName(prop);
// overwrite
for (var i=temp.length; i--; ) {
collections[prop][i] = temp[i];
}
temp = null;
}
}, false);
function getByTagName(tagName){
// replace with qSA
var collection = document.getElementsByTagName(tagName);
return _slice.call(collection, 0);
}
return function(tagName) {
// memoize
return collections[tagName] ||
(collections[tagName] = getByTagName(tagName));
}
})();
var divs = getLive('div');
divs.length; // 10
var div = document.getElementsByTagName('div')[0];
div.parentNode.removeChild(div);
divs.length; // 9
[...]
--
kangax
Jorge
> RobG wrote:
> > On Jun 11, 8:30 pm, Jorge <jo...@jorgechamorro.com> wrote:
> >> On Jun 11, 2:07 am, RobG <robg...@gmail.com> wrote:
>
> >>> On Jun 10, 10:21 pm, Jorge <jo...@jorgechamorro.com> wrote:
> >> A live collection can *not* be emulated in JS.
> > In any case, live collections can be emulated in JS, e.g. you can
> > provide a DOM manipulation API and specify that collections are only
> > live if the API is used. You don't have to emulate all the features
> > of general DOM manipulation API, just the bits required for the job.
>
> Yep, it will most definitely be inefficient, error-prone and limited by
> a tiny subset of browsers, but it is possible :)
>
> I just wrote a simple implementation as a silly but fun exercise (tested
> in FF3.0.10, but should work in any client that supports mutation
> events, i.e. "DOMSubtreeModified"):
Both of you're cheating... :-) I said emulate a live collection, say
dGEBTN, i.e. with the same "API". You can't do that without getters,
AFAICS. So, nowadays, not cross-browser. Am I wrong ?
e.g., fetching collection.length might need to trigger a refresh .
e.g., fetching collection[n] might need to trigger a refresh.
Also, you can't depend on events to refresh it: if you do, it won't be
refreshed untill the next event dispatch cycle... or IOW, too late to
be a valid solution to the problem. Or not ?
Nice try, anyways !
--
Jorge.
kangax
> On Jun 11, 6:37 pm, kangax <kan...@gmail.com> wrote:
>> RobG wrote:
>>> On Jun 11, 8:30 pm, Jorge <jo...@jorgechamorro.com> wrote:
>>>> On Jun 11, 2:07 am, RobG <robg...@gmail.com> wrote:
>>>>> On Jun 10, 10:21 pm, Jorge <jo...@jorgechamorro.com> wrote:
> (...)
>>>> A live collection can *not* be emulated in JS.
>> (...)
>
>>> In any case, live collections can be emulated in JS, e.g. you can
>>> provide a DOM manipulation API and specify that collections are only
>>> live if the API is used. You don't have to emulate all the features
>>> of general DOM manipulation API, just the bits required for the job.
>> Yep, it will most definitely be inefficient, error-prone and limited by
>> a tiny subset of browsers, but it is possible :)
>>
>> I just wrote a simple implementation as a silly but fun exercise (tested
>> in FF3.0.10, but should work in any client that supports mutation
>> events, i.e. "DOMSubtreeModified"):
>
> Both of you're cheating... :-) I said emulate a live collection, say
> dGEBTN, i.e. with the same "API". You can't do that without getters,
> AFAICS. So, nowadays, not cross-browser. Am I wrong ?
>
> e.g., fetching collection.length might need to trigger a refresh .
> e.g., fetching collection[n] might need to trigger a refresh.
Well, of course you can't refresh collection contents on `length` access
without having getters :)
But even if you do have getters, I don't see how you could implement
live collection with them. Initializing a getter for every "numeric"
property of an array object is silly. I suppose you could do it with
"catch-all's" in some environments (IIRC, Rhino supports them)
Anyway, it's much easier to "refresh" all "existent" collections when
document changes. Most of the time, it is not as efficient as refreshing
collection on property access, of course.
>
> Also, you can't depend on events to refresh it: if you do, it won't be
> refreshed untill the next event dispatch cycle... or IOW, too late to
> be a valid solution to the problem. Or not ?
Interesting. I didn't think about it.
--
kangax
Jorge
> Jorge wrote:
> (...)
> > Also, you can't depend on events to refresh it: if you do, it won't be
> > refreshed untill the next event dispatch cycle... or IOW, too late to
> > be a valid solution to the problem. Or not ?
>
> Interesting. I didn't think about it.
Well, forget it because those mutation events get executed
instantaneously !
Those are really mutation "interrupts"... :
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Interrupts or events ?</title>
<!-- Date: 2009-06-11 -->
<script type="text/javascript">
window.onload= function () {
var ctr= 0;
var getLive = (function () {
var collections = {};
var _slice = Array.prototype.slice;
window.addEventListener('DOMSubtreeModified', function () {
ctr++;
for (var prop in collections) {
// keep same array object, but clear it
collections[prop].length = 0;
var temp = getByTagName(prop);
// overwrite
for (var i=temp.length; i--; ) {
collections[prop][i] = temp[i];
}
temp = null;
}
}, false);
function getByTagName(tagName){
// replace with qSA
var collection = document.getElementsByTagName(tagName);
return _slice.call(collection, 0);
}
return function(tagName) {
// memoize
return collections[tagName] ||
(collections[tagName] = getByTagName(tagName));
}
})();
var div, divs = getLive('div');
var after, before= divs.length; // 5
alert( divs[0].parentNode.removeChild(divs[0]).innerHTML+ "["+
ctr+ "] "+
divs[0].parentNode.removeChild(divs[0]).innerHTML+ "["+ ctr+ "]
"+
divs[0].parentNode.removeChild(divs[0]).innerHTML+ "["+ ctr+ "]
"+
divs[0].parentNode.removeChild(divs[0]).innerHTML+ "["+ ctr+ "]
"+
divs[0].parentNode.removeChild(divs[0]).innerHTML+ "["+ ctr+ "]
"+
" divs.length: "+ divs.length); // 0 !
};
</script>
</head>
<body>
<div>1</div>
<div>2</div>
<div>3</div>
<div>4</div>
<div>5</div>
</body>
</html>
Yields: 1[1] 2[2] 3[3] 4[4] 5[5] divs.length: 0
!!!
--
Jorge.
VK
is this discussion about? NodeList and legacy HTMLCollection are both
dynamic ("live"). So why anyone needs such a twisted around code for
something that already done on system level?
Jorge
querySelectorAll isn't a live collection: that's what started the
debate.
--
Jorge.
kangax
Nobody should use this code. It was meant to be purely an academic exercise.
--
kangax
Conrad Lender
> On Jun 10, 10:21 pm, Jorge <jo...@jorgechamorro.com> wrote:
>> If the browser implements qSA() as native code, native code is what's
>> going to be executed in both cases (1). And, BTW, in the event that the
>> browser doesn't implement it natively, it can be easily implemented in
>> javascript for static lists, but *not* so for live collections: that
>> would *require* a getter...
>
> The point is that if the choice is only one or the other, I'd prefer
> to have live lists and convert them to static using JS than having
> static lists that I have to update every time I use them to imitate
> live lists. One suggestion on the HTML 5 list was to have both live
> and static collections, either as separate methods or using a
> parameter. To me that would be the best solution.
Could you give an example of where a live qSA result would be useful? I
understand the use of live collections like mySelectElement.options and
others, but qSA or even gEBTN? I can't remember a situation where it
would have mattered if that result is live or not.
It would probably have to be a loop too, because otherwise the possible
performance penalty of re-getting the list wouldn't matter very much.
- Conrad
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> Compare:
>>>
>>> if (matches(element, '#sidebar .faq-section .toggle')) { ... };
>>>
>>> vs. something like:
>>>
>>> if (hasClass(element, 'toggle') &&
>>> hasParentWithClass(element, '.faq-section') &&
>>> hasParentWithId(element, 'sideabar')) { ... }
>>>
>>> CSS syntax is concise and well-known. It's easy to understand and maintain.
>> But that is why one uses CSS for formatting and not scripting. For example,
>> if it is necessary to hide elements in a certain context on click, this
>> stylesheet fragment:
>>
>> #sidebar .faq-section div.toggle.hidden {
>> display: none;
>> }
>
> Btw, IIRC, IE6 - not understanding multiple classes - will parse this as:
>
> #sidebar .faq-section div.hidden
Good catch, thanks.
> But that could be worked around, of course.
Like
#sidebar.toggle .faq-section div.hidden {
display: none;
}
?
>> The only thing that needs to be in the client-side script now is changing
>> the `className' property of the event target to add/remove `hidden' if its
>> `className' property includes `toggle'.¹ BTDT (with mouseover and mouseout).
>
> This is a very elegant approach, indeed. The only problem is that
> clicking on `.toggle` should usually hide *another element*. For
> example, toggle link can be located in H2 and H2 might be followed by
> DIV; That DIV is the one that needs to be toggled. I suppose one can add
> "hidden" class to a parent element (or any other ancestor) but then
> relevant CSS rules add up in complexity.
Not necessary:
<h2 class="toggler" id="foo" ...>
<div id="foo-div" ...>...</div>
That said, elements related this way should be nested. The above example is
an exception.
> Besides, one would need to constantly look up corresponding declarations
> in stylesheet when reading/changing this code.
CSS syntax is concise and well-known. It's easy to understand and maintain.
-- kangax, <news:PoKdnRVj96DnI7PX...@giganews.com>
PointedEars
kangax
> kangax wrote:
[...]
>>> #sidebar .faq-section div.toggle.hidden {
>>> display: none;
>>> }
>> Btw, IIRC, IE6 - not understanding multiple classes - will parse this as:
>>
>> #sidebar .faq-section div.hidden
>
> Good catch, thanks.
>
>> But that could be worked around, of course.
>
> Like
>
> #sidebar.toggle .faq-section div.hidden {
> display: none;
> }
>
> ?
Yep. That should work.
[...]
>
>> Besides, one would need to constantly look up corresponding declarations
>> in stylesheet when reading/changing this code.
>
> CSS syntax is concise and well-known. It's easy to understand and maintain.
> -- kangax, <news:PoKdnRVj96DnI7PX...@giganews.com>
You got me :)
This approach looks interesting. I'm just not sure about all the
implications; Maybe simply not used to it. I'll experiment with it
sometime in the future and see if it's easier to work with.
Thanks.
--
kangax
Garrett Smith
> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> Knowing how to use document.getElementById, event bubbling (also
>>>> called "delegation") would offer much superior runtime performance
>>>> [than jQuery]
>>> You can't do much with `document.getElementById`. Sometimes you want
>>> to select by class, attribute, descendant or a combination of those.
>>> I agree that more complex selectors are rarely needed (well, except
>>> maybe something like `nth-child("odd")`).
>>>
>>> Event delegation is great, but then you might want some kind of
>>> `match` method to determine whether a target element matches
>>> selector. `match` is not necessary, of course, but testing an element
>>> manually adds noise and verbosity.
>>
>> Iterating over all elements to add event listeners to all target elements
>> adds much more noise and unreliability. For universally bubbling events,
>
> I never said anything about adding event listeners to elements being
> iterated over. I stopped doing that a while ago in favor of event
> delegation. Nevertheless, I still do iterate over elements (by class,
> descendant, attribute, etc.) to perform certain action on them, such as
> toggling visibility.
>
> I suppose manipulating relevant stylesheet rules could achieve similar
> result.
>
> How do you do it?
>
>> use event bubbling, and add one event listener to a common ancestor. For
>> the rest, it depends on how many target elements are there: the more
>> there
>> are, the more likely is it that the listeners should be added dynamically
>> (to ease maintenance). That said, some of those events, like
>> `mouseover' on
>> links, do not even require DOM scripting nowadays (not even in bad old
>> IE 6).
>>
>> As for verbosity, I fail to see how that could be a drawback.
>
> Verbosity has a tendency to add noise. Noise makes it hard to
> understand, maintain and refactor code. That's all I meant.
>
> Compare:
>
> if (matches(element, '#sidebar .faq-section .toggle')) { ... };
>
> vs. something like:
>
> if (hasClass(element, 'toggle') &&
> hasParentWithClass(element, '.faq-section') &&
> hasParentWithId(element, 'sideabar')) { ... }
>
>
I agree. More to that: CSS is easier to understand when it contains
meaningful and specific names.
Regarding the example code posted, that much should never be necessary.
It is a straw man argument there and nothing more.
If the document has more than one type of toggle, then "toggle" is not
specific enough. In that case, the actionable object's class can be
changed to something that describes it more specifically.
var cn = target.className;
if(cn && hasToken(cn, "faq-toggle")) {
FAQExpander.getByNode( target ).toggle();
}
hasToggle is useful, BTW, because it allows the className property to be
retrieved once and checked multiple times, for an element that may have
multiple className tokens, where the additional token(s) may represent
different state e.g. "faq-toggle-expanded".
David Mark
[snip]
>
> As I said to a fellow developer yesterday... "jQuery provides
> convenience, not power. Don't confuse the two."
You say a lot of things. Take this:
http://groups.google.com/group/jquery-dev/browse_thread/thread/8d7752dcfedb1c08
"Yes. Avoid the attr() function in jQuery, it's been broken for a long
time."
LOL. Two years too late. What an ineffectual douche bag.
"Wow, why would you want to use jQuery to do this? Instead, try:"
Probably because disingenuous, know-nothing dip-shits have been
promoting it for years as "easier than Javascript." Never mind that
it *is* Javascript or that it introduces far more headaches than it
alleviates.
Or this:
http://groups.google.com/group/jquery-dev/browse_thread/thread/4bab8abc05e60c80#
That's right genius, jQuery sucks at IE, even versions that have been
out for a decade. As you know:
"IE6 has been around for a decade"
...it's like hearing my words coming out of your mouth (two years
later.) Odd as you spent much of those two years bitching about such
criticism of jQuery. Meanwhile you've been patching your own private
jQuery. I don't know if you are delusional, hypocritical or what, but
you are definitely something less than useful.
And pity this poor guy as he probably heard jQuery was "wonderful"
from some "expert" like you.
http://groups.google.com/group/jquery-en/browse_thread/thread/70e8a050f60f8b08#
You couldn't see jQuery had issues with browser sniffing. You
couldn't see that the pivotal ready, attr, etc. methods were pure
fantasy. You couldn't see me writing a better script. You couldn't
see how that script was as simple to use as jQuery. You sure as hell
couldn't see how influential that script would become. Small wonder
you can't see what is happening now. You are just a back-pedaling
schmuck with a big mouth.
And to take a page out of your pathetic playbook: seems nobody wants
to work with you, even your fellow jQuery washouts.
HTH.
Matt Kruse
> http://groups.google.com/group/jquery-dev/browse_thread/thread/4bab8a...
> That's right genius, jQuery sucks at IE
I've only hit this bug once or twice before, because I don't use many
animations in jQuery. For the most part, the problems that jQuery has
with IE haven't affected me. When they do, I talk about it in order to
figure out the best way to handle it.
It's odd to me that you would read the support groups for a script
that you find so repulsive and useless. Seems like a waste of time on
your part.
> "IE6 has been around for a decade"
> ...it's like hearing my words coming out of your mouth (two years
> later.)
Your criticisms have certainly taught me some things and probably
affected my attitude towards jQuery in some ways. But you are just one
fish in a sea of opinions, ideas, and thoughts. You are not quite as
important or wise or influential as you seem to think you are. Your
fascination with pointing out how "right you were" two years ago and
how nobody listened to you seems... well... odd to me.
> You couldn't see jQuery had issues with browser sniffing. You
> couldn't see that the pivotal ready, attr, etc. methods were pure
> fantasy. You couldn't see me writing a better script. You couldn't
> see how that script was as simple to use as jQuery. You sure as hell
> couldn't see how influential that script would become. Small wonder
> you can't see what is happening now. You are just a back-pedaling
> schmuck with a big mouth.
http://en.wikipedia.org/wiki/Megalomania
Matt Kruse
Diego Perini
> kangax wrote:
> > Garrett Smith wrote:
> >>> On Jun 8, 8:34 pm, Peter May <peter....@poczta.fm> wrote:
> >>>> Ivan S pisze:
>
> >>>>> What JS framework would you guys recommend to me?
> >>>> Tryhttp://www.domassistant.com/
>
> >>> No, don't. It seems to munge the worst of jQuery CSS-style selectors
> >>> and Prototype.js augmentation of host objects together in one script
> >>> that is also depenent on browser sniffing.
>
> >>> The authors' claim that it is the fastest script in the SlickSpeed
> >>> tests isn't substantiated - in Safari 4 it comes in 4th out of 7, even
> >>> jQuery is faster.
>
> >> Knowing how to use document.getElementById, event bubbling (also
>
> > You can't do much with `document.getElementById`. Sometimes you want to
> > select by class, attribute, descendant or a combination of those. I
> > agree that more complex selectors are rarely needed (well, except maybe
> > something like `nth-child("odd")`).
>
> > Event delegation is great, but then you might want some kind of `match`
> > method to determine whether a target element matches selector. `match`
> > is not necessary, of course, but testing an element manually adds noise
> > and verbosity.
>
> >> comparison to a codebase that has a selectors API, the one that does
> >> notshould be downloaded faster, interpreted faster, and should have a
> >> smaller memory footprint.
>
> > That much is... obvious :)
>
> > I don't think last two really matter. Execution of an entire fully CSS3
> > compliant selector engine (such asNWMatcher- the best one of them I've
> > even seen) doesn't take more than few milliseconds. It's 2ms in
> > FF3.0.10. Probably not more than 20-30ms in relatively slow IE6,7. Would
> > you really care about those?
>
> I would definitely care about 20ms.
>
> As discussed in previous mails, I have not ever needed an API to check
> the tagName and className; that is a very simple and straightforward
> thing to do and does not require abstraction.
>
> In my experience, I have not ever needed to check much more than that. I
> can't really think of a problem that would be best solved byNWMatcher,
> nor can I imagine whereNWMatcherwould provide a clearer and faster
> abstraction.
>
> Why add something that is not necessary?
>
> FWICS,NWMatcherstill uses function decompilation.http://github.com/dperini/nwmatcher/blob/ceaa7fdf733edc1a87777935ed05...
Garret,
if I where to be sure nobody had overwritten native functions with
broken replacements I wouldn't had used function decompilation, I
would probably have replaced that hated line:
(/\{\s*\[native code[^\]]*\]\s*\}|^\[function\]$/).test(object
[method]);
with a simpler:
typeof object[method] == 'function';
You don't see the problem because you haven't faced it, but it is a
problem and a very frequent one when you have to ensure compatibility
with code written by others not interested in keeping a clean
environment.
Diego Perini
Diego Perini
> 16ms occurring much more rarely), so I assume it's somewhere in that range.
>
> I'm surprised you would care about those milliseconds. I would worry
> about size (48KB original, probably ~30-40 minified and ~15-20 gzipped)
> much more than this practically instant initialization.
>
> But then again, most of the time, you wouldn't use all of CSS3
> selectors. There's often need for fully-compliant CSS3 selector engine.
>
>
>
> > As discussed in previous mails, I have not ever needed an API to check
> > the tagName and className; that is a very simple and straightforward
> > thing to do and does not require abstraction.
>
> (as well as combination of those) that introduce complexity.
>
>
>
> > In my experience, I have not ever needed to check much more than that. I
> > can't really think of a problem that would be best solved byNWMatcher,
> > nor can I imagine whereNWMatcherwould provide a clearer and faster
> > abstraction.
>
>
>
>
> > Why add something that is not necessary?
>
> used should be determined on a per-project bases, based on the
> application nature and its requirements. As always, it's all about
> context and balance.
>
>
>
> > FWICS,NWMatcherstill uses function decompilation.
> >http://github.com/dperini/nwmatcher/blob/ceaa7fdf733edc1a87777935ed05...
>
> That's one of the things I dislike in it. Overall, though, it's much
> better than anything else I've seen. I helped its author with some of
> the feature tests, so I know it doesn't use sniffing or any nonsense
> inference. If you see something suspicious, speak up, an author is
> usually very responsive to any kind of feedback.
>
> --
> kangax
@kangax,
about the size of NWMatcher, latest version is currently 15 KBytes
minified and about 5.5 KBytes gzipped. There are a lot of comment in
the original sources and NWMatcher is bigger because it tries to
comply with most CSS3 and HTML5 specifications where others just
skipped them.
NWMatcher is not a framework, so if you don't need it just do not load
it. NWEvents will offer delegation also without NWMatcher, it has a
minimal matcher built in for simple selectors which are probably the
most used in general. If one need complex selectors support to add
behaviors in big and complex HTML then there is no other way then to
load a capable CSS engine like NWMatcher.
The strong points in delegation is that it works cross-browser and
help avoid "onload" problems and other tricky "ready" detections.
NWEvents offer W3C capturing and bubbling emulation on IE to achieve
cross-browser delegation and works also with all forms events.
Thank you for promoting my humble contribution.-
Diego Perini
Thomas 'PointedEars' Lahn
> You don't see the problem because you haven't faced it,
I don't think so.
> but it is a problem and a very frequent one when you have to ensure
> compatibility with code written by others not interested in keeping a
> clean environment.
The problem arises in the first place by using code written by others not
interested in keeping a clean environment (unmodified). Working competently
avoids the problem.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Diego Perini
wrote:
Fortunately I am not in the position to force users to only use code
keeping a clean environment, I would loose my time.
I prefer to write my own code and ensure as much as I can that it
works with other FW or snippet of code.
Actually I use feature testing wherever possible and try not to
pollute the global scope.
Diego Perini
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Diego Perini wrote:
>>> You don't see the problem because you haven't faced it,
>> I don't think so.
>>
>>> but it is a problem and a very frequent one when you have to ensure
>>> compatibility with code written by others not interested in keeping a
>>> clean environment.
>> The problem arises in the first place by using code written by others
>> not interested in keeping a clean environment (unmodified). Working
Please trim your quotes, do not quote signatures.
> Fortunately I am not in the position to force users to only use code
> keeping a clean environment,
I would not call that "fortunate".
> I would loose my time.
You prefer it fastened? ;-)
> I prefer to write my own code and ensure as much as I can that it works
> with other FW or snippet of code.
By which you promote the proliferation of code of bad quality.
> Actually I use feature testing wherever possible and try not to pollute
> the global scope.
Good.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Garrett Smith
Maybe your way is not the only way. Could it be that there is another
way to approach the problem that is at least as good?
but it is a
> problem and a very frequent one when you have to ensure compatibility
> with code written by others not interested in keeping a clean
> environment.
>
Modifying host objects is known to be problematic.
Hiding that mistake does not make it go away. If the code is broken, fix
it. The code should not be broken in the first place, and certainly not
in the way that your workaround caters to.
General purpose frameworks are often chosen to "save time". Prototype,
Mootools, Cappucino, Mojo all modify host objects. Interesting that
NWMatcher has extra code created for working around such problematic
design of the modification of host objects. Wouldn't it make more sense
to just not use those?
Bubbling is fast, can result in smaller, cleaner code, and often
obviates the perceived need for a "document ready" handler. Examining
the target on a bubbled event is usually trivial.
NWMatcher does not seem to provide a cleaner and faster abstraction than
simply examining the target with tagName and a hasClass function. YAGNI.
No reason to need it and no reason for the workaround in it.
> Diego Perini
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
Diego Perini
wrote:
> Diego Perini wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Diego Perini wrote:
> >>> You don't see the problem because you haven't faced it,
> >> I don't think so.
>
> >>> but it is a problem and a very frequent one when you have to ensure
> >>> compatibility with code written by others not interested in keeping a
> >>> clean environment.
> >> The problem arises in the first place by using code written by others
> >> not interested in keeping a clean environment (unmodified). Working
> >> competently avoids the problem. [...]
>
> Please trim your quotes, do not quote signatures.
>
> > Fortunately I am not in the position to force users to only use code
> > keeping a clean environment,
>
> I would not call that "fortunate".
>
If it where so easy to do I would have said "unfortunately".
> > I would loose my time.
>
> You prefer it fastened? ;-)
>
No, but your are already doing a good job and I hope some day you will
succeed ! ;-)
> > I prefer to write my own code and ensure as much as I can that it works
> > with other FW or snippet of code.
>
> By which you promote the proliferation of code of bad quality.
>
I do not promote them in the sense you are underlining, though I like
their intentions even if they didn't fullfill perfection. ;-)
> > Actually I use feature testing wherever possible and try not to pollute
> > the global scope.
>
> Good.
>
Thanks. Also you haven't looked to my code, I perfectly understand you
may not have the time nor be interested in it.
Diego Perini
> Diego Perini wrote:
> > On 9 Giu, 08:52, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> kangax wrote:
> >>> Garrett Smith wrote:
> >>>> RobG wrote:
> >>>>> On Jun 8, 8:34 pm, Peter May <peter....@poczta.fm> wrote:
> >>>>>> Ivan S pisze:
> >>>>>> Tryhttp://www.domassistant.com/
> >>>>> No, don't. It seems to munge the worst of jQuery CSS-style selectors
Correct you are. Maybe you have a better solution. Just show me so I
can compare.
> but it is a
>
> > problem and a very frequent one when you have to ensure compatibility
> > with code written by others not interested in keeping a clean
> > environment.
>
> Modifying host objects is known to be problematic.
>
Again, you are correct, but I have to live with it. I personally don't
do it, but I don't know what library will my choosen by my users nor
can I force them to choose one or another.
> Hiding that mistake does not make it go away. If the code is broken, fix
> it. The code should not be broken in the first place, and certainly not
> in the way that your workaround caters to.
>
You correctly use "should" but reality is what I work with. Will be
happy to include APE in my library chooser as soon as possible, still
I would have to support all the libraries with that shaming habit.
Sure when there are enough "perfect" libraries I could start to leave
out those that are not perfect.
> General purposeframeworksare often chosen to "save time". Prototype,
> Mootools, Cappucino, Mojo all modify host objects. Interesting that
> NWMatcher has extra code created for working around such problematic
> design of the modification of host objects. Wouldn't it make more sense
> to just not use those?
>
The extra code is very small and worth it currently; it comes down I
only needed to know that get/hasAttribute where the native browser
implementations and not a third party attempt to fix them, no third
party extension of get/hasAttribute for IE that I know has the
equivalent capabilities of IE regarding XML namespaced attributes.
> Bubbling is fast, can result in smaller, cleaner code, and often
> obviates the perceived need for a "document ready" handler. Examining
> the target on a bubbled event is usually trivial.
>
Yes bubbling is fast and capturing is faster, both are offered
integrated in an easy set of API (that can be changed) for event
management and are in NWEvents which does not need NWMatcher to be
loaded for simple selectors.
> NWMatcher does not seem to provide a cleaner and faster abstraction than
> simply examining the target with tagName and a hasClass function. YAGNI.
> No reason to need it and no reason for the workaround in it.
>
NWMatcher primarily provides a "match()" method which still does not
exists in any browser.
Doing the same with native QSA on Safari /Chrome is 4 to 10 time
slower than with NWMatcher.
If you havent, I suggest you read a bit about the importance of a
"match()" method from this great reading from David Andersson
(Liorean):
http://web-graphics.com/2006/05/12/javascript-and-selectors/
I will try to search specific archive of webapi ml to find out when
that proposal was discarded.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Diego Perini wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Diego Perini wrote:
>>>>> You don't see the problem because you haven't faced it,
>>>> I don't think so.
>>>>> but it is a problem and a very frequent one when you have to ensure
>>>>> compatibility with code written by others not interested in keeping a
>>>>> clean environment.
>>>> The problem arises in the first place by using code written by others
>>>> not interested in keeping a clean environment (unmodified). Working
>>>> competently avoids the problem. [...]
>>> keeping a clean environment,
>> I would not call that "fortunate".
>
> If it where so easy to do I would have said "unfortunately".
Your logic module is borken.
>>> I would loose my time.
>> You prefer it fastened? ;-)
>
> No, but your are already doing a good job and I hope some day you will
> succeed ! ;-)
I don't follow. Maybe you want to look up "loose"?
>>> I prefer to write my own code and ensure as much as I can that it works
>>> with other FW or snippet of code.
>> By which you promote the proliferation of code of bad quality.
>
> I do not promote them in the sense you are underlining,
Yes, you do. If you go to great lengths like this to support inherently
faulty concepts, you are promoting them, if you want it or not. Because
if you would not support them, their problems would not be covered up, which
has at least a chance to lead to better code quality. In addition, your
concept of covering up is faulty, too, so the overall code quality certainly
cannot increase with this approach.
> though I like their intentions even if they didn't fullfill perfection. ;-)
Spoken like a true promoter of heavily advertised libraries: clueless and
irresponsible.
>>> Actually I use feature testing wherever possible and try not to pollute
>>> the global scope.
>> Good.
>
> Thanks. Also you haven't looked to my code,
It's been reviewed in this very thread already; along with your responses,
that sufficed for me to assess your position in the learning curve. You
have a rather long way to go.
> I perfectly understand you may not have the time nor be interested in it.
Rest assured you don't understand anything (about me).
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Diego Perini
wrote:
> Diego Perini wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> Diego Perini wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>>> Diego Perini wrote:
> >>>>> You don't see the problem because you haven't faced it,
> >>>> I don't think so.
> >>>>> but it is a problem and a very frequent one when you have to ensure
> >>>>> compatibility with code written by others not interested in keeping a
> >>>>> clean environment.
> >>>> The problem arises in the first place by using code written by others
> >>>> not interested in keeping a clean environment (unmodified). Working
> >>>> competently avoids the problem. [...]
> >>> Fortunately I am not in the position to force users to only use code
> >>> keeping a clean environment,
> >> I would not call that "fortunate".
>
> > If it where so easy to do I would have said "unfortunately".
>
> Your logic module is borken.
>
> >>> I would loose my time.
> >> You prefer it fastened? ;-)
>
> > No, but your are already doing a good job and I hope some day you will
> > succeed ! ;-)
>
> I don't follow. Maybe you want to look up "loose"?
>
slipped a double "o" I meant "lose". Thanks for the correction.
> >>> I prefer to write my own code and ensure as much as I can that it works
> >>> with other FW or snippet of code.
> >> By which you promote the proliferation of code of bad quality.
>
> > I do not promote them in the sense you are underlining,
>
> Yes, you do. If you go to great lengths like this to support inherently
> faulty concepts, you are promoting them, if you want it or not. Because
> if you would not support them, their problems would not be covered up, which
> has at least a chance to lead to better code quality. In addition, your
> concept of covering up is faulty, too, so the overall code quality certainly
> cannot increase with this approach.
>
> > though I like their intentions even if they didn't fullfill perfection. ;-)
>
> Spoken like a true promoter of heavily advertised libraries: clueless and
> irresponsible.
>
I always feel clueless when somebody teach me something new. This has
not been the case.
I never feel irresponsible even when I say something wrong, there is
always time to rectify or change mind.
> >>> Actually I use feature testing wherever possible and try not to pollute
> >>> the global scope.
> >> Good.
>
> > Thanks. Also you haven't looked to my code,
>
> It's been reviewed in this very thread already; along with your responses,
> that sufficed for me to assess your position in the learning curve. You
> have a rather long way to go.
>
I will try to do better, I am not competing with any FW I just have
working events/selectors libraries that perfectly fit my needs, it was
designed and discussed far before these threads with far more
competent people and was referenced by others to implement similar
solutions.
Ok. Ok we are all culprit. And I can accept if we are not in the same
hell circle.
> > I perfectly understand you may not have the time nor be interested in it.
>
> Rest assured you don't understand anything (about me).
>
Really, I didn't come here for that particularly.
Can you finally point me to a better "match()" method and delgation
implementation just to compare ?
Anyway I still appreciate your time to comment. Sad it hasn't yet show
so useful as I would expect.
Garrett Smith
APE is AFL, so would probably not licenseable for most projects. Having
effectively no user-base, I can remove things that should not be there.
Perhaps in the future, I'll go with a less restrictive mozilla-type
license.
Supporting potential problems in third party libraries is a *choice*.
Piggybacking off the popular libraries probably results in a larger user
base. The obvious downside is that additional code is required to hide
the inherently faulty design of those libraries. What is less obvious is
that the additional code requires "implementation dependent" function
decompilation, which is known to be faulty in at least opera mobile[1]
and is defined to return a FunctionDeclaration, which is not what IE,
Gecko, Safari, Chrome, Opera do when Function.prototype.toString is
called on an anonymous function.
>> General purposeframeworksare often chosen to "save time". Prototype,
>> Mootools, Cappucino, Mojo all modify host objects. Interesting that
>> NWMatcher has extra code created for working around such problematic
>> design of the modification of host objects. Wouldn't it make more sense
>> to just not use those?
>>
>
> The extra code is very small and worth it currently; it comes down I
> only needed to know that get/hasAttribute where the native browser
> implementations and not a third party attempt to fix them, no third
> party extension of get/hasAttribute for IE that I know has the
> equivalent capabilities of IE regarding XML namespaced attributes.
>
If I understand correctly, the concern is that a third party library may
have attempted to fix IE's getAttribute/hasAttribute methods by defining
those methods on the element, and that if that had happened, it would
cause the script to not function properly.
XML Namespaced attributes should be avoided. Why would you want to use that?
>> Bubbling is fast, can result in smaller, cleaner code, and often
>> obviates the perceived need for a "document ready" handler. Examining
>> the target on a bubbled event is usually trivial.
>>
>
> Yes bubbling is fast and capturing is faster, both are offered
> integrated in an easy set of API (that can be changed) for event
> management and are in NWEvents which does not need NWMatcher to be
> loaded for simple selectors.
>
Bubbling is available for free without NWEvents. I can't see any reason
for wanting to try to add a code to simulate capturing in IE.
>> NWMatcher does not seem to provide a cleaner and faster abstraction than
>> simply examining the target with tagName and a hasClass function. YAGNI.
>> No reason to need it and no reason for the workaround in it.
>>
>
> NWMatcher primarily provides a "match()" method which still does not
> exists in any browser.
>
I am aware of that. I don't need that.
> Doing the same with native QSA on Safari /Chrome is 4 to 10 time
> slower than with NWMatcher.
>
QuerySelectorAll was, I think, a design mistake inspired by (a)
javascript libraries.
> If you havent, I suggest you read a bit about the importance of a
> "match()" method from this great reading from David Andersson
> (Liorean):
>
> http://web-graphics.com/2006/05/12/javascript-and-selectors/
>
I see:
| I think they�re currently about to make several design errors that I
| would prefer to be corrected before people start implementing the
| thing.
He goes on to make some good points, Anne van Kesteren did not comment
on those in his response. None of the points raised stopped
implementations from implementing the thing and none of his ideas got
into the API, as Anne published it. What a surprise.
http://www.mail-archive.com/public...@w3.org/msg00782.html
Looks like the last of that one and the reason given:-
| Parsing the selector string is will likely be by far the least
| expensive part of the match operation.
- Maciej totally missed the point.
If Selectors had used those ideas, it could have been designed in a way
that was (more) useful, but that is fiction.
Given the problem you have presented to solve with NWMatcher, I can
solve that with the following code:-
- which, as you see, is exactly 0 lines.
The problem of examining a target node is usually trivial. A
well-structured semantic page should be easy to navigate using the DOM.
I've been using bubbling for years. Checking tagName, id, and className,
perhaps other properties is enough. A selectors API is not needed.
Imposing arbitrary structural requirements about where an element must
exist is makes the code more fragile and more brittle. When IDs are used
in the HTML, someone editing the HTML can be expected not to change it
without first ascertaining that doing so will not create a bug. I
mention this because like xpath, a selectors API makes it easy to fall
into this trap of referencing fragments which are arbitrary and whose
existence is insignificant or coincidental. Sort of a "non sequitir"
code assertion where the code looks for something matching an arbitrary
fragment.
What's worse is that the code required for checking selectors would be
checking the attribute values. Attributes are broken in IE. Instead of
trying to "make it work", "don't do that" and just use properties. This
means the hand-rolled Selectors API goes out the window. YAGNI anyway.
There is no reason to add the overhead of anything else to the page.
Less code to maintain means less potential for bugs and faster to
download. Less is more. The XP pertinent adage: "Do the simplest thing
that could possibly work, but not any simpler". We're not getting paid
by SLOC.
I see where you are coming from with the API. It would be convenient to
have that supported by native code, but that is not the case.
Looking at the code, I think I see a problem in NW.Dom.getChildren:-
| getChildren =
| function(element) {
| // childNodes is slower to loop through because it contains
| // text nodes
| // empty text nodes could be removed at startup to compensate
| // this a bit
| return element[NATIVE_CHILDREN] || element.childNodes;
| },
The children property is inconsistent across the most common browsers.
It is best left alone.
For Firefox 3.1, there is no "children", so the childNodes property is
used. For childNodes, textNodes and comment nodes will be included and
returned. In Firefox 3.5, and versions of Safari, Opera, and probably
other browsers, "children" is only Elements. In IE, the "children"
property returns a list of "DHTML Objects" and this includes comment
nodes. So, your function returns different results in IE, Firefox <=
3.1, and {Firefox 3.5, Opera, and Safari}.
<IE Madness>
MSIE's "DHTML Objects" includes comment nodes, which MSDN calls "Comment
Elements". They have all the methods and properties of other elements,
such as "attachEvent", "style", "offsetTop", a read-only "innerHTML",
and ironically, "children".
Try the innerHTML property of a comment in IE:-
javascript: alert(document.createComment("foo").innerHTML = "test");
This shows an obvious LSP violation. The API design of shoehorning a
Comment interface as a subclass to the Element interface was a mistake
that has persisted into IE8.
</IE Madness>
Regardless of the getChildren method inconsistency, I don't need that.
AISB, YAGNI!
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Diego Perini wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Diego Perini wrote:
>>>>> I prefer to write my own code and ensure as much as I can that it works
>>>>> with other FW or snippet of code.
>>>> By which you promote the proliferation of code of bad quality.
>>> I do not promote them in the sense you are underlining,
>> Yes, you do. If you go to great lengths like this to support inherently
>> faulty concepts, you are promoting them, if you want it or not. Because
>> if you would not support them, their problems would not be covered up, which
>> has at least a chance to lead to better code quality. In addition, your
>> concept of covering up is faulty, too, so the overall code quality certainly
>> cannot increase with this approach.
>>
>>> though I like their intentions even if they didn't fullfill perfection. ;-)
>> Spoken like a true promoter of heavily advertised libraries: clueless and
>> irresponsible.
>
> I always feel clueless when somebody teach me something new. This has
> not been the case.
>
> I never feel irresponsible even when I say something wrong, there is
> always time to rectify or change mind.
That's what I mean. A responsible person would first think, then speak.
>>>>> Actually I use feature testing wherever possible and try not to pollute
>>>>> the global scope.
>>>> Good.
>>> Thanks. Also you haven't looked to my code,
>> It's been reviewed in this very thread already; along with your responses,
>> that sufficed for me to assess your position in the learning curve. You
>> have a rather long way to go.
>
> I will try to do better, I am not competing with any FW
FW?
> I just have working events/selectors libraries that perfectly fit my needs,
> it was designed and discussed far before these threads with far more
> competent people
People you *assume* to be far more competent.
> and was referenced by others to implement similar solutions.
A million flies can't be wrong? I wondered whether that "argument" would
come. You script-kiddies are so very predictable.
> Ok. Ok we are all culprit. And I can accept if we are not in the same
> hell circle.
We are not even in the same sphere, if you want to employ that figure of speech.
>>> I perfectly understand you may not have the time nor be interested in it.
>> Rest assured you don't understand anything (about me).
>
> Really, I didn't come here for that particularly.
Then why not stop making assumptions about it?
> Can you finally point me to a better "match()" method and delgation
> implementation just to compare ?
"Better" would be defined by the (for me) unacceptable conditions that your
approach is based on, therefore no.
> Anyway I still appreciate your time to comment. Sad it hasn't yet show
> so useful as I would expect.
I am not here to entertain you.
Diego Perini
> >> design of the modification of host objects. Wouldn't it make more sense
> >> to just not use those?
>
> > The extra code is very small and worth it currently; it comes down I
> > only needed to know that get/hasAttribute where the native browser
> > implementations and not a third party attempt to fix them, no third
> > party extension of get/hasAttribute for IE that I know has the
> > equivalent capabilities of IE regarding XML namespaced attributes.
>
> If I understand correctly, the concern is that a third party library may
> have attempted to fix IE's getAttribute/hasAttribute methods by defining
> those methods on the element, and that if that had happened, it would
> cause the script to not function properly.
>
Correct, in that case it was Prototype messing with those native
functions.
> XML Namespaced attributes should be avoided. Why would you want to use that?
>
NWMatcher try to support as much as possible the W3C specifications
(xml:lang attribute and similar) which are suported by the IE natives.
> >> Bubbling is fast, can result in smaller, cleaner code, and often
> >> obviates the perceived need for a "document ready" handler. Examining
> >> the target on a bubbled event is usually trivial.
>
> > Yes bubbling is fast and capturing is faster, both are offered
> > integrated in an easy set of API (that can be changed) for event
> > management and are in NWEvents which does not needNWMatcherto be
> > loaded for simple selectors.
>
> Bubbling is available for free without NWEvents. I can't see any reason
> for wanting to try to add a code to simulate capturing in IE.
>
Form events do not bubble in IE and other browsers (submit/reset),
other events do not bubble consistently across browsers, NWEvents
turns this into a cross-browser technique that allows any event to
bubble (or be captured).
> >>NWMatcherdoes not seem to provide a cleaner and faster abstraction than
> >> simply examining the target with tagName and a hasClass function. YAGNI.
> >> No reason to need it and no reason for the workaround in it.
>
> >NWMatcherprimarily provides a "match()" method which still does not
> > exists in any browser.
>
> I am aware of that. I don't need that.
>
It is OK if you don't need it, assuming nobody else is needing it is a
big pretention.
> > Doing the same with native QSA on Safari /Chrome is 4 to 10 time
> > slower than withNWMatcher.
>
> QuerySelectorAll was, I think, a design mistake inspired by (a)
> javascript libraries.
>
> > If you havent, I suggest you read a bit about the importance of a
> > "match()" method from this great reading from David Andersson
> > (Liorean):
>
> > http://web-graphics.com/2006/05/12/javascript-and-selectors/
>
> I see:
> | I think they’re currently about to make several design errors that I
> | would prefer to be corrected before people start implementing the
> | thing.
>
> He goes on to make some good points, Anne van Kesteren did not comment
> on those in his response. None of the points raised stopped
> implementations from implementing the thing and none of his ideas got
> into the API, as Anne published it. What a surprise.
>
> http://www.mail-archive.com/public-web...@w3.org/msg00782.html
>
> Looks like the last of that one and the reason given:-
> | Parsing the selector string is will likely be by far the least
> | expensive part of the match operation.
> - Maciej totally missed the point.
>
> If Selectors had used those ideas, it could have been designed in a way
> that was (more) useful, but that is fiction.
>
NWMatcher tries to fill this gap and seems you agrre that the idea was
a good one.
> Given the problem you have presented to solve withNWMatcher, I can
> solve that with the following code:-
>
> - which, as you see, is exactly 0 lines.
>
> The problem of examining a target node is usually trivial. A
> well-structured semantic page should be easy to navigate using the DOM.
> I've been using bubbling for years. Checking tagName, id, and className,
> perhaps other properties is enough. A selectors API is not needed.
>
I wouldn't rewrite the matching algorithm each time I need a specific
node, and as kangax already explained sometime we need to combine
positional (ancestor, descendant) and properties checking (id, class,
tag).
> Imposing arbitrary structural requirements about where an element must
> exist is makes the code more fragile and more brittle. When IDs are used
> in the HTML, someone editing the HTML can be expected not to change it
> without first ascertaining that doing so will not create a bug. I
> mention this because like xpath, a selectors API makes it easy to fall
> into this trap of referencing fragments which are arbitrary and whose
> existence is insignificant or coincidental. Sort of a "non sequitir"
> code assertion where the code looks for something matching an arbitrary
> fragment.
>
By doing the matching manually you will be in the same problem, if the
structure or the names (id, class) change you will have to review your
traversal and names checking and act accordingly. If you insert a
comment node in the wrong place you will fall in the same problem too
since next/previousSibling has changed.
> What's worse is that the code required for checking selectors would be
> checking the attribute values. Attributes are broken in IE. Instead of
> trying to "make it work", "don't do that" and just use properties. This
> means the hand-rolled Selectors API goes out the window. YAGNI anyway.
>
> There is no reason to add the overhead of anything else to the page.
> Less code to maintain means less potential for bugs and faster to
> download. Less is more. The XP pertinent adage: "Do the simplest thing
> that could possibly work, but not any simpler". We're not getting paid
> by SLOC.
>
> I see where you are coming from with the API. It would be convenient to
> have that supported by native code, but that is not the case.
>
Nice to hear you deem "match()" adequate for a browser native
implementation, it seems Safari/Chrome will be having that in future
releases.
> Looking at the code, I think I see a problem in NW.Dom.getChildren:-
>
> | getChildren =
> | function(element) {
> | // childNodes is slower to loop through because it contains
> | // text nodes
> | // empty text nodes could be removed at startup to compensate
> | // this a bit
> | return element[NATIVE_CHILDREN] || element.childNodes;
> | },
>
> The children property is inconsistent across the most common browsers.
> It is best left alone.
>
There are no problems there, the returned children collection is
filtered for "nodeType == 1" or "nodeName == tag" afterwards.
> For Firefox 3.1, there is no "children", so the childNodes property is
> used. For childNodes, textNodes and comment nodes will be included and
> returned. In Firefox 3.5, and versions of Safari, Opera, and probably
> other browsers, "children" is only Elements. In IE, the "children"
> property returns a list of "DHTML Objects" and this includes comment
> nodes. So, your function returns different results in IE, Firefox <=
> 3.1, and {Firefox 3.5, Opera, and Safari}.
>
> <IE Madness>
> MSIE's "DHTML Objects" includes comment nodes, which MSDN calls "Comment
> Elements". They have all the methods and properties of other elements,
> such as "attachEvent", "style", "offsetTop", a read-only "innerHTML",
> and ironically, "children".
>
> Try the innerHTML property of a comment in IE:-
> javascript: alert(document.createComment("foo").innerHTML = "test");
>
> This shows an obvious LSP violation. The API design of shoehorning a
> Comment interface as a subclass to the Element interface was a mistake
> that has persisted into IE8.
> </IE Madness>
>
> Regardless of the getChildren method inconsistency, I don't need that.
> AISB, YAGNI!
>
You are wrong. NWMatcher will never return text or comment nodes in
the result set, so it fixes the problems you mentioned on IE, and
since NWMatcher feature tests that specific problem, any new browser
with the same gEBTN bugs will be fixed too.
NWMatcher is a compliant CSS3 Selector engine, much of the code in
there is to support CSS3 and HTML5 specification including attributes
"case-sensitivity" awarness, document ordered result sets and nested
negation pseudo classes, the cruft there is due to the caching system
and the "select()" method, both of which I added to satisfy current
user requests. The core "match()" method is just 16Kbytes source code.
Thank you for partially reviewing my code, your comments where really
useful, I may try to remove the function decompilation part in the
future if at all possible.
Diego Perini
Garrett Smith
Sounds like a great reason not to use Prototype.
>> XML Namespaced attributes should be avoided. Why would you want to use that?
>>
>
> NWMatcher try to support as much as possible the W3C specifications
> (xml:lang attribute and similar) which are suported by the IE natives.
>
Why on earth do you need to match xml:lang? That would only be supported
by using "getAttribute('xml:lang')" where IE would not interpret a
namespace, but would instead use a nonstandard approach. The colon
character is not valid in attributes.
>>>> Bubbling is fast, can result in smaller, cleaner code, and often
>>>> obviates the perceived need for a "document ready" handler. Examining
>>>> the target on a bubbled event is usually trivial.
>>> Yes bubbling is fast and capturing is faster, both are offered
>>> integrated in an easy set of API (that can be changed) for event
>>> management and are in NWEvents which does not needNWMatcherto be
>>> loaded for simple selectors.
>> Bubbling is available for free without NWEvents. I can't see any reason
>> for wanting to try to add a code to simulate capturing in IE.
>>
>
> Form events do not bubble in IE and other browsers (submit/reset),
> other events do not bubble consistently across browsers, NWEvents
> turns this into a cross-browser technique that allows any event to
> bubble (or be captured).
>
>>>> NWMatcherdoes not seem to provide a cleaner and faster abstraction than
>>>> simply examining the target with tagName and a hasClass function. YAGNI.
>>>> No reason to need it and no reason for the workaround in it.
>>> NWMatcherprimarily provides a "match()" method which still does not
>>> exists in any browser.
>> I am aware of that. I don't need that.
>>
>
> It is OK if you don't need it, assuming nobody else is needing it is a
> big pretention.
>
Really? Please show me where NWMatcher is needed.
Wasn't there something I wrote about being able to solve your problem
with 0 lines of code?
>>> Doing the same with native QSA on Safari /Chrome is 4 to 10 time
>>> slower than withNWMatcher.
>> QuerySelectorAll was, I think, a design mistake inspired by (a)
>> javascript libraries.
>>
>>> If you havent, I suggest you read a bit about the importance of a
>>> "match()" method from this great reading from David Andersson
>>> (Liorean):
>>> http://web-graphics.com/2006/05/12/javascript-and-selectors/
>> I see:
>> | I think they�re currently about to make several design errors that I
>> | would prefer to be corrected before people start implementing the
>> | thing.
>>
>> He goes on to make some good points, Anne van Kesteren did not comment
>> on those in his response. None of the points raised stopped
>> implementations from implementing the thing and none of his ideas got
>> into the API, as Anne published it. What a surprise.
>>
>> http://www.mail-archive.com/public-web...@w3.org/msg00782.html
>>
>> Looks like the last of that one and the reason given:-
>> | Parsing the selector string is will likely be by far the least
>> | expensive part of the match operation.
>> - Maciej totally missed the point.
>>
>> If Selectors had used those ideas, it could have been designed in a way
>> that was (more) useful, but that is fiction.
>>
>
> NWMatcher tries to fill this gap and seems you agrre that the idea was
> a good one.
>
Filling the gap is overkill and not a good idea.
The selectors API had potential that the author did not realize. It was
probably based on the jquery selectors, which used "$", probably
inspired by, and used to trump Prototype.js (pissing match).
Code based on the premise "but it really should work", is best answered
by "just don't do that".
But it should work's:
* document.getElementById in IE < 8
* document.getElementsByName in IE < 8
* "capturing" event phase in IE
* reading a cascaded style in the DOM (like IE's "currentStyle")
I am completely guilty of that last one. Unfortunately, I did not step
back and say "don't do that". I didn't recognize (or did not admit) the
absurdity of it until too long later.
None of those are necessary. The answers to those problems are, in
respective order:
* do not give an element an ID where there is another element that has
the same value for NAME.
* Ditto.
* YAGNI.
* YAGNI. Use computedStyle and provide an adapter for IE.
>> Given the problem you have presented to solve withNWMatcher, I can
>> solve that with the following code:-
>>
>> - which, as you see, is exactly 0 lines.
>>
Still stands. 0 LOC to solve the problem you've presented.
>> The problem of examining a target node is usually trivial. A
>> well-structured semantic page should be easy to navigate using the DOM.
>> I've been using bubbling for years. Checking tagName, id, and className,
>> perhaps other properties is enough. A selectors API is not needed.
>>
>
> I wouldn't rewrite the matching algorithm each time I need a specific
> node, and as kangax already explained sometime we need to combine
> positional (ancestor, descendant) and properties checking (id, class,
> tag).
>
Where did I advocate "rewriting the matching algorithm?"
In most cases, tagName and className are enough. I've said that I don't
know how many times now. By having a few functions that are reliable,
the whole idea of trying to solve every possible "matching" context goes
out the window.
What kangax said, taken out of context, was followed by:-
| Event delegation is great, but then you might want some kind of
| `match` method to determine whether a target element matches selector.
The arguments I have posted are following that. A match method would be
nice, but is unnecessary. It is a lot less code and a lot simpler to use:-
if(target.checked) {
// code here.
}
- then what NWMatcher would do.
>> Imposing arbitrary structural requirements about where an element must
>> exist is makes the code more fragile and more brittle. When IDs are used
>> in the HTML, someone editing the HTML can be expected not to change it
>> without first ascertaining that doing so will not create a bug. I
>> mention this because like xpath, a selectors API makes it easy to fall
>> into this trap of referencing fragments which are arbitrary and whose
>> existence is insignificant or coincidental. Sort of a "non sequitir"
>> code assertion where the code looks for something matching an arbitrary
>> fragment.
>>
>
> By doing the matching manually you will be in the same problem, if the
> structure or the names (id, class) change you will have to review your
> traversal and names checking and act accordingly. If you insert a
> comment node in the wrong place you will fall in the same problem too
> since next/previousSibling has changed.
>
I can use a previousSiblingElement.
<Element Traversal API Design>
The Traversal API decided to call these properties with "Element" as the
second part of the word, not the last. For example:
"previousElementSibling", not "previousSiblingElement". This seems like
a mistake.
We can also see a "childElementCount", but no property for
"childElements". Given that common reason for having a
"childElementCount" would be to iterate over a "childElement"
collection, shouldn't there be one? I mentioned that on the list and
John Resig made mention of that one on his blog. That didn't stop Doug
Schepers from sticking to his API design, which is now a TR.
Only five properties and they're all screwed up.
</Element Traversal API Design>
>> What's worse is that the code required for checking selectors would be
>> checking the attribute values. Attributes are broken in IE. Instead of
>> trying to "make it work", "don't do that" and just use properties. This
>> means the hand-rolled Selectors API goes out the window. YAGNI anyway.
>>
>> There is no reason to add the overhead of anything else to the page.
>> Less code to maintain means less potential for bugs and faster to
>> download. Less is more. The XP pertinent adage: "Do the simplest thing
>> that could possibly work, but not any simpler". We're not getting paid
>> by SLOC.
>>
>> I see where you are coming from with the API. It would be convenient to
>> have that supported by native code, but that is not the case.
>>
>
> Nice to hear you deem "match()" adequate for a browser native
> implementation, it seems Safari/Chrome will be having that in future
> releases.
>
A boolean "matches(selectorText)" method is a neat idea for native code.
If it is implemented widely enough, say, by 2011, then maybe by 2016 we
may be able to use that. A fallback for hand-rolled "matches" is
overkill. A better approach is to script semantic, structured, valid markup.
>> Looking at the code, I think I see a problem in NW.Dom.getChildren:-
>>
>> | getChildren =
>> | function(element) {
>> | // childNodes is slower to loop through because it contains
>> | // text nodes
>> | // empty text nodes could be removed at startup to compensate
>> | // this a bit
>> | return element[NATIVE_CHILDREN] || element.childNodes;
>> | },
>>
>> The children property is inconsistent across the most common browsers.
>> It is best left alone.
>>
>
> There are no problems there, the returned children collection is
> filtered for "nodeType == 1" or "nodeName == tag" afterwards.
>
That can be easily enough demonstrated.
There is no filtering shown in the code above. None. Where is the test
case of NWMatcher.DOM.getChildren?
[snip explanation of children/childNodes]
>>
>> Regardless of the getChildren method inconsistency, I don't need that.
>> AISB, YAGNI!
>>
>
> You are wrong. NWMatcher will never return text or comment nodes in
> the result set, so it fixes the problems you mentioned on IE, and
> since NWMatcher feature tests that specific problem, any new browser
> with the same gEBTN bugs will be fixed too.
>
There are a couple of things wrong with that paragraph.
1) I am *not* wrong. The source code for NW.Dom.getChildren, as posted
above, taken from NWMatcher source on github[2], indicates otherwise.
2) Who mentioned gEBTN? The problem explained was with the "children"
property.
Test Results:-
Firefox 3.0.11:
kids.length = 3
Opera 9.64:
kids.length = 0
IE 7:
kids.length = 1
Test code:
<!doctype html>
<html>
<head>
<title></title>
<script type="text/javascript" src="../../jslib/nwmatcher.js"></script>
</head>
<body>
<p id="t">
<!-- test comment -->
</p>
<script type="text/javascript">
var t = document.getElementById("t");
var kids = NW.Dom.getChildren(t);
document.write("kids.length = " + kids.length);
</script>
</body>
</html>
AISB, NW.DOM.getChildren() will return inconsistent results. You (not I)
touched upon a similar problem in IE with gEBTN. That problem is not so
surprising when it is realized that comments are Elements in IE.
> NWMatcher is a compliant CSS3 Selector engine, much of the code in
> there is to support CSS3 and HTML5 specification including attributes
> "case-sensitivity" awarness, document ordered result sets and nested
> negation pseudo classes, the cruft there is due to the caching system
> and the "select()" method, both of which I added to satisfy current
> user requests. The core "match()" method is just 16Kbytes source code.
>
I don't buy one word of that.
* NWMatcher cannot be CSS3 selector compliant and work in IE <= 7
because attributes are broken in IE. Instead of trying to "make it
work", "don't do that" and just use properties.
* 16k is a lot, but NWMatcher is nearly 50k[2].
* What is the situation you're finding yourself in that you need
"negation pseudo classes"?
Chances are, someone has encountered that problem before and has figured
out a way that does not require matching "negation pseudo classes". It
may be that you have a unique problem. That warrants exposition.
> Thank you for partially reviewing my code, your comments where really
> useful, I may try to remove the function decompilation part in the
> future if at all possible.
NWMatcher isn't something I would ever want or need and so I don't see
much reason to get into the details of code review. The problems with
IE's broken attributes make using attribute selectors a bad choice.
"Popular" libraries may blur the distinction between properties and
attributes but the problem exists nonetheless.
I see also:-
| // WebKit case sensitivity bug with className (when no DOCTYPE)
How about just don't do that?
Nothing can be expected of quirks mode. Ian Hickson trying to
standardize quirks mode does not make it any more reliable or advisable.
Validation is an important part of solving script-related problems,
which is why it is mentioned in: http://jibbering.com/faq/#postCode
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
[2]http://github.com/dperini/nwmatcher/blob/05702074f8949d12f6d757f62d8a92e916062323/src/nwmatcher.js
1448 lines (1296 sloc) 48.79 kb
Diego Perini
I don't have much use myself either, that doesn't mean I have to
constrain my project to my own needs, I have bug tracking tools that I
try to follow and where possible and by specs I try to have it
considered. Is that a problem ?
The "xml:lang" property is mentioned in all the CSS >= 2 specs I have
read and it hasn't changed in the CSS Selectors Level 3, read first
6.3.1 and then follow links to 6.6.3 of latest CSS Selector Level 3
draft March/2009:
http://www.w3.org/TR/css3-selectors/#attribute-selectors
Though you may still say that my implementation is failing in some
way. No problems with that, my objective is learn and improve.
> >>>> Bubbling is fast, can result in smaller, cleaner code, and often
> >>>> obviates the perceived need for a "document ready" handler. Examining
> >>>> the target on a bubbled event is usually trivial.
> >>> Yes bubbling is fast and capturing is faster, both are offered
> >>> integrated in an easy set of API (that can be changed) for event
> >>> management and are in NWEvents which does not needNWMatcherto be
> >>> loaded for simple selectors.
> >> Bubbling is available for free without NWEvents. I can't see any reason
> >> for wanting to try to add a code to simulate capturing in IE.
>
> > Form events do not bubble in IE and other browsers (submit/reset),
> > other events do not bubble consistently across browsers, NWEvents
> > turns this into a cross-browser technique that allows any event to
> > bubble (or be captured).
>
> >>>> NWMatcherdoes not seem to provide a cleaner and faster abstraction than
> >>>> simply examining the target with tagName and a hasClass function. YAGNI.
> >>>> No reason to need it and no reason for the workaround in it.
> >>> NWMatcherprimarily provides a "match()" method which still does not
> >>> exists in any browser.
> >> I am aware of that. I don't need that.
>
> > It is OK if you don't need it, assuming nobody else is needing it is a
> > big pretention.
>
> Really? Please show me where NWMatcher is needed.
>
I would like to do it OT if you have spare time and you really wish !
The code I am going to show already uses delegation with some tricky
and possibly highly populated "trees" in smaller overlay windows; the
task is to replace "manual" delegation spread throughout the code with
a centralized event manager that could handle delegation using CSS
selectors. This is already handled very well since hundred of events
are handled by a few elements that act as events dispatchers (the
bubbling).
Writing English at this "level" is a bit difficult for me but I am
willing to try hard.
> Wasn't there something I wrote about being able to solve your problem
> with 0 lines of code?
>
It is not clear what problem you solve with 0 lines of code ! No lines
of code means no problem, so be real.
As an example I can write:
NW.Event.appendDelegate( "p > a", "click", handler_function ); //
only first link in each paragraph
and I add some needed action to all the links in the page with no need
to wait for an onload event, thus ensuring a cross-browser experience
and an early activated interface. You may question the lengthy
namespace or names, yes the code is free just use yours...
Sure you can write the above snippet of code shorter and better, but
then you write it once and forget about reuse it.
Now suppose those "links" where also changing, pulled in by some http
request, the event will still be there, no need to redeclare nothing.
Add this same technique to some more complex page with several FORMs
and validation as a requirement and you will probably see some benefit
in having all form events also bubble up the document (submit/reset/
focus/blur and more).
> >>> Doing the same with native QSA on Safari /Chrome is 4 to 10 time
> >>> slower than withNWMatcher.
> >> QuerySelectorAll was, I think, a design mistake inspired by (a)
> >> javascript libraries.
>
> >>> If you havent, I suggest you read a bit about the importance of a
> >>> "match()" method from this great reading from David Andersson
> >>> (Liorean):
> >>> http://web-graphics.com/2006/05/12/javascript-and-selectors/
> >> I see:
> >> | I think they’re currently about to make several design errors that I
> >> | would prefer to be corrected before people start implementing the
> >> | thing.
>
> >> He goes on to make some good points, Anne van Kesteren did not comment
> >> on those in his response. None of the points raised stopped
> >> implementations from implementing the thing and none of his ideas got
> >> into the API, as Anne published it. What a surprise.
>
> >> http://www.mail-archive.com/public-web...@w3.org/msg00782.html
>
> >> Looks like the last of that one and the reason given:-
> >> | Parsing the selector string is will likely be by far the least
> >> | expensive part of the match operation.
> >> - Maciej totally missed the point.
>
> >> If Selectors had used those ideas, it could have been designed in a way
> >> that was (more) useful, but that is fiction.
>
> > NWMatcher tries to fill this gap and seems you agrre that the idea was
> > a good one.
>
> Filling the gap is overkill and not a good idea.
>
It was a very good idea for me and for others using it, obviously you
can teach me how to do that in 0 lines I am all ears.
> The selectors API had potential that the author did not realize. It was
> probably based on the jquery selectors, which used "$", probably
> inspired by, and used to trump Prototype.js(pissing match).
>
> Code based on the premise "but it really should work", is best answered
> by "just don't do that".
>
It works, NWMatcher passes the only few test suites available to me
(Prototype and jQuery), if you wish one added please suggest.
I have some test of my own obviously.
> But it should work's:
> * document.getElementById in IE < 8
> * document.getElementsByName in IE < 8
> * "capturing" event phase in IE
> * reading a cascaded style in the DOM (like IE's "currentStyle")
>
> I am completely guilty of that last one. Unfortunately, I did not step
> back and say "don't do that". I didn't recognize (or did not admit) the
> absurdity of it until too long later.
>
> None of those are necessary. The answers to those problems are, in
> respective order:
> * do not give an element an ID where there is another element that has
> the same value for NAME.
> * Ditto.
> * YAGNI.
> * YAGNI. Use computedStyle and provide an adapter for IE.
>
I know elements ID are unique. Thanks.
The IDs are in many case generated by module in the page, we have no
control over uniqueness between module's output but we may solve the
problem by giving different IFRAMEs to each module to ensure that.
> >> Given the problem you have presented to solve withNWMatcher, I can
> >> solve that with the following code:-
>
> >> - which, as you see, is exactly 0 lines.
>
> Still stands. 0 LOC to solve the problem you've presented.
>
Well to achieve that with CSS and HTML in a site one should be
prepared to having to produce and maintain hundred/thousand different
manually edited static pages, we are miles away from that approach,
wasn't scripting introduced to solve that too. Or is there some
restrictions that impose the "just effects" web ? Isn't then jQuery or
APE enough for that ?
I mean there are other markets and other needs, is it so difficult to
realize that ?
> >> The problem of examining a target node is usually trivial. A
> >> well-structured semantic page should be easy to navigate using the DOM.
> >> I've been using bubbling for years. Checking tagName, id, and className,
> >> perhaps other properties is enough. A selectors API is not needed.
>
> > I wouldn't rewrite the matching algorithm each time I need a specific
> > node, and as kangax already explained sometime we need to combine
> > positional (ancestor, descendant) and properties checking (id, class,
> > tag).
>
> Where did I advocate "rewriting the matching algorithm?"
>
Well algorithm was indeed a too big word, I meant the mix of different
conditional comparisons (it, tag, class, perv/next etc) you would have
to do each time the structure of your DOM changes (excluding the 0 LOC
trick).
> In most cases, tagName and className are enough. I've said that I don't
> know how many times now. By having a few functions that are reliable,
> the whole idea of trying to solve every possible "matching" context goes
> out the window.
>
I agree that in MOST cases, surely the majority, this code overhead is
not necessary. What about the other part of the "MOST" cases ?
> What kangax said, taken out of context, was followed by:-
> | Event delegation is great, but then you might want some kind of
> | `match` method to determine whether a target element matches selector.
>
> The arguments I have posted are following that. A match method would be
> nice, but is unnecessary. It is a lot less code and a lot simpler to use:-
>
> if(target.checked) {
> // code here.
>
> }
>
> - then what NWMatcher would do.
>
NWMatcher will parse and compile the passed selector to a
corresponding resolver function in javascript. From what I understand
it's exactly what you do manually, as simple as that, the compiled
function is then invoked and saved for later use, no successive
parsing is done for the same selector to boost performances. I leaved
in a function to see the results of the process for demo purpose in
case you are curious about the outcome, use NW.Dom.compile(selector)
and print the resulting string to the console.
> >> Imposing arbitrary structural requirements about where an element must
> >> exist is makes the code more fragile and more brittle. When IDs are used
> >> in the HTML, someone editing the HTML can be expected not to change it
> >> without first ascertaining that doing so will not create a bug. I
> >> mention this because like xpath, a selectors API makes it easy to fall
> >> into this trap of referencing fragments which are arbitrary and whose
> >> existence is insignificant or coincidental. Sort of a "non sequitir"
> >> code assertion where the code looks for something matching an arbitrary
> >> fragment.
>
> > By doing the matching manually you will be in the same problem, if the
> > structure or the names (id, class) change you will have to review your
> > traversal and names checking and act accordingly. If you insert a
> > comment node in the wrong place you will fall in the same problem too
> > since next/previousSibling has changed.
>
> I can use a previousSiblingElement.
>
Not all browsers have that API extension, only the very latest
browsers have that.
> <Element Traversal API Design>
> The Traversal API decided to call these properties with "Element" as the
> second part of the word, not the last. For example:
> "previousElementSibling", not "previousSiblingElement". This seems like
> a mistake.
>
> We can also see a "childElementCount", but no property for
> "childElements". Given that common reason for having a
> "childElementCount" would be to iterate over a "childElement"
> collection, shouldn't there be one? I mentioned that on the list and
> John Resig made mention of that one on his blog. That didn't stop Doug
> Schepers from sticking to his API design, which is now a TR.
>
> Only five properties and they're all screwed up.
> </Element Traversal API Design>
>
I have heard saying that when QSA happeared first in browsers more
than a year ago, you said yourself QSA was mistakenly designed. Until
this is fixed things like NWMatcher will still bee needed and I am
speaking about the newest and most advanced implementors Webkit/
Chrome, what about IE6/IE7, maybe in a few years. NWMatcher will last
some more time for these reasons be assured.
> >> What's worse is that the code required for checking selectors would be
> >> checking the attribute values. Attributes are broken in IE. Instead of
> >> trying to "make it work", "don't do that" and just use properties. This
> >> means the hand-rolled Selectors API goes out the window. YAGNI anyway.
>
> >> There is no reason to add the overhead of anything else to the page.
> >> Less code to maintain means less potential for bugs and faster to
> >> download. Less is more. The XP pertinent adage: "Do the simplest thing
> >> that could possibly work, but not any simpler". We're not getting paid
> >> by SLOC.
>
> >> I see where you are coming from with the API. It would be convenient to
> >> have that supported by native code, but that is not the case.
>
> > Nice to hear you deem "match()" adequate for a browser native
> > implementation, it seems Safari/Chrome will be having that in future
> > releases.
>
> A boolean "matches(selectorText)" method is a neat idea for native code.
>
Well I implemented that in javascript...why do you have such doubt
then ?
> If it is implemented widely enough, say, by 2011, then maybe by 2016 we
> may be able to use that. A fallback for hand-rolled "matches" is
> overkill. A better approach is to script semantic, structured, valid markup.
>
I really look forward to see that happen too. I am not in an hurry !
Technology can be improved by developers by making it more easy and
simple not by teaching difficult actions or hard to remember
procedures.
> >> Looking at the code, I think I see a problem in NW.Dom.getChildren:-
>
> >> | getChildren =
> >> | function(element) {
> >> | // childNodes is slower to loop through because it contains
> >> | // text nodes
> >> | // empty text nodes could be removed at startup to compensate
> >> | // this a bit
> >> | return element[NATIVE_CHILDREN] || element.childNodes;
> >> | },
>
> >> The children property is inconsistent across the most common browsers.
> >> It is best left alone.
>
> > There are no problems there, the returned children collection is
> > filtered for "nodeType == 1" or "nodeName == tag" afterwards.
>
> That can be easily enough demonstrated.
>
> There is no filtering shown in the code above. None. Where is the test
> case of NWMatcher.DOM.getChildren?
>
This is the relevant code string that is wrapped around during the
function build that does what you are looking for:
// fix for IE gEBTN('*') returning collection with comment
nodes
SKIP_COMMENTS = BUGGY_GEBTN ? 'if(e.nodeType!=1){continue;}' :
'',
Nowhere I said either that the method serves to the purpose you are
trying to give it. You just guessed it !
That may be partly my fault too, by having exposed it as a public
method. ;-)
I was talking about "match()" and "select()", these are the only two
methods meant to be used. Sorry if it is unclear in the code/comments.
> [snip explanation of children/childNodes]
>
>
>
> >> Regardless of the getChildren method inconsistency, I don't need that.
> >> AISB, YAGNI!
>
> > You are wrong. NWMatcher will never return text or comment nodes in
> > the result set, so it fixes the problems you mentioned on IE, and
> > since NWMatcher feature tests that specific problem, any new browser
> > with the same gEBTN bugs will be fixed too.
>
> There are a couple of things wrong with that paragraph.
>
> 1) I am *not* wrong. The source code for NW.Dom.getChildren, as posted
> above, taken from NWMatcher source on github[2], indicates otherwise.
>
As I told I am not trying to have an unified cross-browser
"getChildren" it is an helper used by the compiled functions, I could
have completely avoided having that function independent, it was to
improve speed on IE quickly discarding text nodes.
No, let's see it this way, the getChildren() is to get the fastest
collection available. It didn't improve so incredibly for the records
but there was a gain.
> > NWMatcher is a compliant CSS3 Selector engine, much of the code in
> > there is to support CSS3 and HTML5 specification including attributes
> > "case-sensitivity" awarness, document ordered result sets and nested
> > negation pseudo classes, the cruft there is due to the caching system
> > and the "select()" method, both of which I added to satisfy current
> > user requests. The core "match()" method is just 16Kbytes source code.
>
> I don't buy one word of that.
>
I have never thought it was to be sold. Incentives comes in various
formats !
> * NWMatcher cannot be CSS3 selector compliant and work in IE <= 7
> because attributes are broken in IE. Instead of trying to "make it
> work", "don't do that" and just use properties.
>
Works for me and for the hundreds of tests it passes.
But I agree that the problem you talk about has been greatly
underestimated by several related working groups. Don't blame me or my
code for those errors.
> * 16k is a lot, but NWMatcher is nearly 50k[2].
>
The "match()" method is the length I said, no more than 16kbytes
source code, the rest is for the "select()" method (I have no use for
the "select()" while everybody else uses only it) the caching code and
the type of checks that you said I should have leaved out.-
> * What is the situation you're finding yourself in that you need
> "negation pseudo classes"?
>
Scraping external text content most (hope the term is correct). Also,
in general when the list of things to do is much bigger of the list of
things not to do (while attaching event).
> Chances are, someone has encountered that problem before and has figured
> out a way that does not require matching "negation pseudo classes". It
> may be that you have a unique problem. That warrants exposition.
>
Let's say I want all the elements but not SCRIPTS and or STYLESHEETS
and or OBJECTS/APPLETS...sound familiar and useful as a task ?
However it is also a specification of CSS3, they may be able to give
you other ideas about that in their docs.
> > Thank you for partially reviewing my code, your comments where really
> > useful, I may try to remove the function decompilation part in the
> > future if at all possible.
>
> NWMatcher isn't something I would ever want or need and so I don't see
> much reason to get into the details of code review. The problems with
> IE's broken attributes make using attribute selectors a bad choice.
> "Popular" libraries may blur the distinction between properties and
> attributes but the problem exists nonetheless.
>
Yeah you repeated it a few times, you have no use...I see, I will not
blame you for that.
However I have no errors nor warnings in the console using these
helpers and the results are correct AFAIK.
This should already be a good enough reason to start using them and
try something new.
> I see also:-
> | // WebKit case sensitivity bug with className (when no DOCTYPE)
>
> How about just don't do that?
>
I could, you haven't given me a reason to not do it, but I will
carefully ponder any related/motivated suggestion.
> Nothing can be expected of quirks mode. Ian Hickson trying to
> standardize quirks mode does not make it any more reliable or advisable.
>
It's a shame few follows, rules are easier to follow and doesn't
require big efforts just open minds.
> Validation is an important part of solving script-related problems,
> which is why it is mentioned in:http://jibbering.com/faq/#postCode
>
Validation is a big target both for NWEvents and NWMatcher. You should
try it.
Thank you for scrutinizing. I have to address some of the concerns you
made like remove some public methods to avoid confusing devs.
Diego Perini
Diego Perini
> >> | would prefer to be corrected before people start implementing the
> >> | thing.
>
> >> He goes on to make some good points, Anne van Kesteren did not comment
> >> on those in his response. None of the points raised stopped
> >> implementations from implementing the thing and none of his ideas got
> >> into the API, as Anne published it. What a surprise.
>
> >> http://www.mail-archive.com/public-web...@w3.org/msg00782.html
>
> >> Looks like the last of that one and the reason given:-
> >> | Parsing the selector string is will likely be by far the least
> >> | expensive part of the match operation.
> >> - Maciej totally missed the point.
>
> >> If Selectors had used those ideas, it could have been designed in a way
> >> that was (more) useful, but that is fiction.
>
> > NWMatcher tries to fill this gap and seems you agrre that the idea was
> > a good one.
>
> Filling the gap is overkill and not a good idea.
>
>
> leggi tutto
I went back to check (some) of my statements above just to make sure
sizes and functionality and be able to show.
Online demo/test with the sliced down version of NWMatcher containing
just the needed "match()" method:
http://javascript.nwbox.com/cljs-071809/nwapi/nwapi_test.html
The demo should work on any desktop browser, type some text in the
input boxes or leave them empty to see validation example, click in
the cells or the unordered list items, move the mouse around on the
elements and then look at the console (you can enable strict mode if
you like) everything is passed through lint and shouldn't show any
errors.
You can download a complete archive of all the source used to build
this demo here (with minified and compressed examples):
http://javascript.nwbox.com/cljs-071809/nwapi-demo-cljs.tgz
By dropping support for the "bads" you pointed out completely avoids
using the hated isNative() method, I completely removed the getChildren
() method that could have tricked user too.
No one of the feature/capabilities and fixes are lost, only the "select
()" method and it's dependencies where removed.
NWMatcher match() method = 16Kb source, minimized 8Kb, gzipped 3.456
bytes
NWApi = NWEvents + NWMatcher = 32Kb source, minimized 15Kb, gzipped
5.856 bytes
With the "match()" method is still possible to build a generic "select
()" method if needed at all (also slower).
Thank you for your suggestions, they where mostly appropriated but I
will have to keep also the complete version until this is well
understood, people are still relying on the "select()" (QSA or XPATH)
to achieve this kind of functionality and implementors are still
pondering their ways around. IE browsers are far away, I see Webkit/
Chrome developers being potential implementors for this.
kangax
>> I see where you are coming from with the API. It would be convenient to
>> have that supported by native code, but that is not the case.
>>
>
> Nice to hear you deem "match()" adequate for a browser native
> implementation, it seems Safari/Chrome will be having that in future
> releases.
Is there a public ticket in webkit/chrome bug tracker where this is
being discussed? I wasn't aware of implementations starting to work on
(or considering) `Element#match` addition.
[...]
--
kangax