JS framework

[David Mark]

[snip]

Good call

Good what? You find it odd that I would disparage a browser sniffing
script? Really?

 

[Garrett Smith]

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.

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]

Of all of the projects that used Dojo, none of the teams were satisfied
with the application's performance.

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?

I have greater disinterest in animal abuse than I do in Dojo.
Regardless, betting is irrelevant in matters of science.
Whatever.


He's made some contributions to APE, too!

LOL. That's your problem.

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.

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]

[...]


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.

Or this one?


Huh again. What are we talking about here?


So what?


Whatever.

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.

You popped a tent for John Resig again. You can put that away now.

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.

[...]

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 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 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


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?

My point (that you missed) was Dojo isn't helping. It is large.

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.

You popped a tent for John Resig again. You can put that away now.



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?

[...]

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


If it makes you feel better, I'm for it.

Makes me feel better? Who asked you?

"powers that be" is pathetic.

How so? I suggest you stop trying to irritate me.

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]

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]

That is really encouraging to hear, whats the ETA of the next version?

Later this summer I think.

 

[David Mark]

David Mark wrote:

[...]

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

I'm quite surprised he showed you a link a month ago. Hadn't really
done anything at that point.

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.)

 

[David Mark]

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.

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.

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.)

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?

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?

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.

Why?

Just because.

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.

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.

 

[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

 

[David Mark]

David Mark wrote: [...]
- 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.

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.

Agreed.

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.)

[...]

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.

[...]

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.

[...]

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.

Sounds good.

It's going to be very good.

 

[RobG]

Ivan S pisze:


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.

 

[Garrett Smith]

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.

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.

Garrett

 

[Garrett Smith]

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.


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 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...87777935ed05d6bb74d7722a/src/nwmatcher.js#L44

Garrett

 

[RobG]

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("dd").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;
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'));

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?

 

[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.

 

[Thomas 'PointedEars' Lahn]

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,
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.

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("dd").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