jquery vs dojo vs yui etc
Joe Nine
state the major flaws of these libraries? I'm not considering using any
of them, I've heard enough here to know how bad they are. I just want a
few article links to keep in my back pocket that I can fire back when
someone suggests we use one of them.
Matt Kruse
> Does anyone have any links to very convincing articles that eloquently
> state the major flaws of these libraries?
A post like this in here is like throwing row meat into a tank of
piranhas.
Enjoy!
Matt Kruse
Garrett Smith
Maybe next week.
David Mark
I've reviewed salient bits of all three in the last six months or so.
Search the archive.
In short, jQuery is terribly inept and unneeded, YUI is terribly
botched and bloated and Dojo is just plain terrible.
Reading the exchanges in their respective developer forums (or on
sites like Hacker News and Stack Overflow) is quite enlightening as
well. Seeing the "experts" (your prospective support staff) in action
should be an eye-opening experience.
In many cases, you shouldn't need to know the technical ins and outs
of what they are discussing. Just look at the quality of the
discourse (try this, try that, show me where it fails, etc.) Look at
how many questions go unresolved. Look how testy they get when told
they are wrong. Look at the aliases. Look at the (deliberately)
goofy pictures. Would you accept advice of any kind (let alone
technical guidance) from these people?
Garrett Smith
> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>> Does anyone have any links to very convincing articles that eloquently
>> state the major flaws of these libraries? I'm not considering using any
>> of them, I've heard enough here to know how bad they are. I just want a
>> few article links to keep in my back pocket that I can fire back when
>> someone suggests we use one of them.
>
> I've reviewed salient bits of all three in the last six months or so.
> Search the archive.
>
> In short, jQuery is terribly inept and unneeded, YUI is terribly
> botched and bloated and Dojo is just plain terrible.
>
Pure opinion. Anybody can say that about anything. Example: Disco sucks.
The design of the Prius is terribly botched. The US Government is just
plain terrible. Easy, right?
A no-nonsense analysis demonstrating major shortcomings is not easy, but
would be valuable.
The article should provide a concise summary of problems, elaborate on
that, with examples, link to any pertinent standards, and finally,
provide advice on what the reader should do instead of using that.
The summary should be something that can be explained simply and should
be understandable by anyone. The exposition should elaborate on that.
For example:
Summary of library X:
* String methods slow
* method M doesn't work consistently in browsers
* silly and useless methods
[elaboration of each point, with examples]
[reasons the bugs can't be simply patched/design analysis]
[alternative]
[Conclusion recapping on problems an alternative.]
A couple of years back I did areview on Prototype.js:
http://dhtmlkitchen.com/?category=/JavaScript/&date=2008/06/17/&entry=Prototype-js-A-Review
In that review, I painfully showed how the library works. Something as
complicated as that should be explained, so that it can be fully
appreciated.
Prototype.js has mostly died out since then.
I would like to see such articles. I would, but I am busy with JSON
stuff and writing a test runner. I will be publishing an article next
week related to the W3C Selectors library, too. I don't have time for
another article.
Dojo is nearly dead, so that one is low hanging fruit. jQuery and YUI
might be good subject matter for changing the industry.
As a final emphasis, the article should emphasize what to do instead.
That is: How to analyze code quality and where to learn about web
scripting. The article should not simply turn the reader away from a one
library, only to leave him directionless or jumping to another library
(as many ex-prototype.js users switched to jQuery).
Garrett
David Mark
> On 6/16/2010 2:35 PM, David Mark wrote:
>
> > On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
> >> Does anyone have any links to very convincing articles that eloquently
> >> state the major flaws of these libraries? I'm not considering using any
> >> of them, I've heard enough here to know how bad they are. I just want a
> >> few article links to keep in my back pocket that I can fire back when
> >> someone suggests we use one of them.
>
> > I've reviewed salient bits of all three in the last six months or so.
> > Search the archive.
>
> > In short, jQuery is terribly inept and unneeded, YUI is terribly
> > botched and bloated and Dojo is just plain terrible.
>
> Pure opinion.
Amnesia flaring up again? :)
There's a tsunami of evidence and demonstration behind my statements
(as you well know). As I said, search the archive.
> Anybody can say that about anything. Example: Disco sucks.
> The design of the Prius is terribly botched. The US Government is just
> plain terrible. Easy, right?
I've done all of the hard work. You yourself were just parroting some
of it recently.
>
> A no-nonsense analysis demonstrating major shortcomings is not easy, but
> would be valuable.
It's been done to death (as you well know).
>
> The article should provide a concise summary of problems, elaborate on
> that, with examples, link to any pertinent standards, and finally,
> provide advice on what the reader should do instead of using that.
That ship has sailed and long since reached its destination.
[...]
>
> A couple of years back I did areview on Prototype.js:http://dhtmlkitchen.com/?category=/JavaScript/&date=2008/06/17/&entry...
I thought that was where this was headed. Well, good for you then.
But drop the laughable, indefensible stance against what I've done
(which towers over your "achievements" in this area).
>
> In that review, I painfully showed how the library works.
Sorry to hear it was painful.
> Something as
> complicated as that should be explained, so that it can be fully
> appreciated.
Yes. Again, done to death at this point. I mean, Prototype?! Could
there be a less relevant example at this juncture?
>
> Prototype.js has mostly died out since then.
Exactly.
>
> I would like to see such articles.
All together: Search the archive.
> I would, but I am busy with JSON
> stuff and writing a test runner.
Great.
> I will be publishing an article next
> week related to the W3C Selectors library, too. I don't have time for
> another article.
Okay. I think you are way late on that one as well.
>
> Dojo is nearly dead, so that one is low hanging fruit.
Yes, I'd like to think I helped kill it. :)
> jQuery and YUI
> might be good subject matter for changing the industry.
You can't stand it, can you? I've already changed the industry.
Where were you?
>
> As a final emphasis, the article should emphasize what to do instead.
We've been over that ad nauseam as well.
> That is: How to analyze code quality and where to learn about web
> scripting.
> The article should not simply turn the reader away from a one
> library, only to leave him directionless or jumping to another library
> (as many ex-prototype.js users switched to jQuery).
>
Your hypothetical article pales in comparison to my somewhat legendary
output in this area. Best of luck with it!
RobG
>
> > On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
> >> Does anyone have any links to very convincing articles that eloquently
> >> state the major flaws of these libraries? I'm not considering using any
> >> of them, I've heard enough here to know how bad they are. I just want a
> >> few article links to keep in my back pocket that I can fire back when
> >> someone suggests we use one of them.
> The summary should be something that can be explained simply and should
> be understandable by anyone. The exposition should elaborate on that.
>
> For example:
>
> Summary of library X:
> * String methods slow
> * method M doesn't work consistently in browsers
> * silly and useless methods
>
> [elaboration of each point, with examples]
>
> [reasons the bugs can't be simply patched/design analysis]
>
> [alternative]
>
> [Conclusion recapping on problems an alternative.]
A discussion of the library architecture and usage patterns with their
pros and cons would also be helpful.
> A couple of years back I did areview on Prototype.js:http://dhtmlkitchen.com/?category=/JavaScript/&date=2008/06/17/&entry...
>
> In that review, I painfully showed how the library works. Something as
> complicated as that should be explained, so that it can be fully
> appreciated.
I'm sure it took quite a bit of time, it would be good to update it.
There does not seem to be mention of the version reviewed (June 2008
=> v 1.6.0.2?).
The section $a toString gave me a bit of a revelation: browser
detection based on the rendering engine ignores differences in the
script engine. There are a number of browser families based on WebKit,
there are two main script engines - Chrome, Maxthon and Android use V8
whereas KDE and Safari use SquirrelFish. There may be others.
> Prototype.js has mostly died out since then.
Would somebody please tell Apple that? Their main web site uses
version 1.6.0.2
[...]
> Dojo is nearly dead, so that one is low hanging fruit. jQuery and YUI
> might be good subject matter for changing the industry.
It should also look at massive frameworks like Qooxdoo, Cappuccino
("...an open source framework that makes it easy to build desktop-
caliber applications that run in a web browser"[1]) and SproutCore
("... an HTML5 application framework for building responsive, desktop-
caliber apps in any modern web browser..."[2]).
1. <URL: http://cappuccino.org/ >
2. <URL: http://www.sproutcore.com/what-is-sproutcore/ >
> As a final emphasis, the article should emphasize what to do instead.
Yes, such as: let the browser do as much work natively as possible,
keep it simple and use scripting only where necessary to add value
(i.e. the antithesis of Qooxdoo, Cappuccino and SproutCore which aim
to completely replace the browser's UI).
--
Rob
Thomas 'PointedEars' Lahn
> Garrett Smith wrote:
>> David Mark wrote:
>> > On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>> >> Does anyone have any links to very convincing articles that eloquently
>> >> state the major flaws of these libraries? I'm not considering using
>> >> any of them, I've heard enough here to know how bad they are. I just
>> >> want a few article links to keep in my back pocket that I can fire
>> >> back when someone suggests we use one of them.
>> >
>> > I've reviewed salient bits of all three in the last six months or so.
>> > Search the archive.
>> >
>> > In short, jQuery is terribly inept and unneeded, YUI is terribly
>> > botched and bloated and Dojo is just plain terrible.
>> Pure opinion.
>
> Amnesia flaring up again? :)
>
> There's a tsunami of evidence and demonstration behind my statements
> (as you well know). As I said, search the archive.
Search it yourself. I must agree that the problem with what is in "the
archive" is that it is unstructured, not to the point, full of useless
sentiments, and on top of it widely unreadable thanks to sloppy formatting
(on your part, despite several requests to do better), if it is available
at all (you know about Google Groups' search flaws, don't you?). It is
unfortunately impractical to find the pearls in the mud that have been
thrown. So much for amnesia.
Therefore, I, too, would welcome an unbiased, unemotional, and theoretically
sound peer review. In fact, not having observed it to date, I have been
considering to try and write one myself when and if I find the time.
Perhaps this is such consuming a task that it requires a step-by-step
approach to be done properly.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Garrett Smith
> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>> On 6/16/2010 2:35 PM, David Mark wrote:
>>
>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>>>> Does anyone have any links to very convincing articles that eloquently
>>>> state the major flaws of these libraries? I'm not considering using any
>>>> of them, I've heard enough here to know how bad they are. I just want a
>>>> few article links to keep in my back pocket that I can fire back when
>>>> someone suggests we use one of them.
>>
Of course, so when somebody -- a recruiter, for example, says, "what's
wrong with the jQuery library?", you can say:
- Poor selector engine
- Non-descriptive method names
- Hard to debug
- long, overloaded methods with too much abstraction
- Poorly degradable
- loosely defined constructs and vague documentation
- Low-quality plugins
- Silly (and futile) things in source, like `isPlainObject`
- Significant and numerous core upgrades that break functionality
- plugins don't work
- documentation doesn't reflect new behavior
(modified list of gripes from a colleague).
>>> I've reviewed salient bits of all three in the last six months or so.
>>> Search the archive.
>>
>>> In short, jQuery is terribly inept and unneeded, YUI is terribly
>>> botched and bloated and Dojo is just plain terrible.
>>
>> Pure opinion.
>
> Amnesia flaring up again? :)
>
> There's a tsunami of evidence and demonstration behind my statements
> (as you well know). As I said, search the archive.
>
The OP asked for "links to very convincing articles". In your response,
I see cynical opinion and no links. That's not even a concise summary of
any one library. It sounds snide, actually. And no urls.
>> Anybody can say that about anything. Example: Disco sucks.
>> The design of the Prius is terribly botched. The US Government is just
>> plain terrible. Easy, right?
>
> I've done all of the hard work. You yourself were just parroting some
> of it recently.
>
That is untrue.
I've have never wanted to copy anything of yours.
>>
>> A no-nonsense analysis demonstrating major shortcomings is not easy, but
>> would be valuable.
>
> It's been done to death (as you well know).
>
URL?
>>
>> The article should provide a concise summary of problems, elaborate on
>> that, with examples, link to any pertinent standards, and finally,
>> provide advice on what the reader should do instead of using that.
>
> That ship has sailed and long since reached its destination.
>
If you are trying to say that an article was published then post a URL
so the OP can see it.
[...]
>> Something as
>> complicated as that should be explained, so that it can be fully
>> appreciated.
>
> Yes. Again, done to death at this point. I mean, Prototype?! Could
> there be a less relevant example at this juncture?
>
One point to be gleaned from that is what sort of change it can affect.
A subtler point is that the mistake I made was not emphasizing enough
about what to do instead. Look how many switched to jQuery.
The review also shows an example outline of how to do a review. It
starts at a very high level with technical *facts*.
| A code review should be objective and should state actual problems.
| Saying "the code is bad" is not a helpful review. Instead, explain
| the problem clearly. If the problem is severe, then say why.
<http://jibbering.com/faq/notes/review/>
I've emphasized these points many times regarding your reviews and I've
noticed improvement, but I think it can still get better.
People will respect you if you follow that.
>>
>> Prototype.js has mostly died out since then.
>
> Exactly.
>
And even a Prototype core developer criticizing Prototype:
http://perfectionkills.com/whats-wrong-with-extending-the-dom/
Now more and more are flocking to jQuery. Great. Well, not really.
[...]
>
>> I will be publishing an article next
>> week related to the W3C Selectors library, too. I don't have time for
>> another article.
>
> Okay. I think you are way late on that one as well.
>
Opinions are funny things. Everybody's got one.
My observations are that many developers are unaware of how selectors work.
I've notice that some foster beliefs that the jQuery "bare words"
proprietary selector syntax is designed to work match attributes instead
of properties. In contrast, the source code of jQuery indicates that it
was designed to select properties.
Further evidence indicates that there may be uncertainty as to whether
or not the jQuery author(s) know what it was designed to do or knew that
it was invalid CSS selector syntax. The documentation says it selects
attributes, the website says it is css3 compliant. Blog entries seem to
be vague and contradictory.
My observation is that developers are confused as to how selectors
really work.
>
> Your hypothetical article pales in comparison to my somewhat legendary
> output in this area. Best of luck with it!
Then post a link to what you feel are your best ones. Let them speak for
themselves and quit boasting about them.
Look:
<http://www.google.com/search?q=jquery+%22code+review%22>
I don't see any jQuery code reviews. Chances are, the OP doesn't either.
I've found:
http://www.doxdesk.com/#u20091116-jquery
- which is funny, but not a serious code review (the author is
knowledgeable and provides humorous insight. He seems to not take jQuery
seriously).
My opinion is that jQuery is taken seriously by so many that it cannot
be just laughed off and it cannot be just called garbage. In order to
effect a change, one must take it head on in a more formal code review.
Talk to the reader as if he's right in front of you; don't insult his
intelligence and don't assume he understands everything you do. Be
concise. Make it understandable at a high level to anyone. Try to see it
from the perspective of the user who llikes it. Try to see it from the
perspective of the author who wrote it and is now stuck with design
decisions -- what can he do? Are they fixable? If so, how? If not, why
not? Parsing selectors - sounds neat, right? Well, the problems with
that are...
[brief introduction]
[summary overview of problems]
[exposition and demonstration of each problem]
[elaboration on design issues]
[alternative]
[conclusion]
Writing something like that is not going to be easy; not something that
can be completed in under a week.
A link to such formal review of jQuery would be useful and valuable.
My prototypejs review was painful, not because I had to go and find
problems, but because I had to communicate them effectively to readers
who liked Prototype.js.
Garrett
Garrett Smith
> On Jun 17, 8:53 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>
>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>>>> Does anyone have any links to very convincing articles that eloquently
>>>> state the major flaws of these libraries? I'm not considering using any
>>>> of them, I've heard enough here to know how bad they are. I just want a
>>>> few article links to keep in my back pocket that I can fire back when
>>>> someone suggests we use one of them.
> [...]
>> The summary should be something that can be explained simply and should
>> be understandable by anyone. The exposition should elaborate on that.
>>
>> For example:
>>
>> Summary of library X:
>> * String methods slow
>> * method M doesn't work consistently in browsers
>> * silly and useless methods
>>
>> [elaboration of each point, with examples]
>>
>> [reasons the bugs can't be simply patched/design analysis]
>>
>> [alternative]
>>
>> [Conclusion recapping on problems an alternative.]
>
> A discussion of the library architecture and usage patterns with their
> pros and cons would also be helpful.
>
>
[...]
> Yes, such as: let the browser do as much work natively as possible,
> keep it simple and use scripting only where necessary to add value
> (i.e. the antithesis of Qooxdoo, Cappuccino and SproutCore which aim
> to completely replace the browser's UI).
Good advice.
However, it touches on a core antipattern of Quooxdoo, Cappuccino and
SproutCore. It's not a new technique.
It would be good for the article to do one of
1) focus entirely on one library
2) focus or a problem that is solved and show how libraries solve it,
with examples from the library, and then show an alternative.
3) focus on an antipattern
I'm going to publish an article next week, after it has been reviewed
and edited (the draft is being reviewed now). The article will cover
some things here, but it is not a formal review, as I have outlined. I'd
really like to see that, and if it is a good one, probably even more
than the article I'm working on.
Garrett
Garrett Smith
Most of the searching on google search (groups search is broken) results
in developersdex and rinocerus and objectmix. Sometimes googlegroups
local versions (korea, etc).
> Therefore, I, too, would welcome an unbiased, unemotional, and theoretically
> sound peer review. In fact, not having observed it to date, I have been
> considering to try and write one myself when and if I find the time.
> Perhaps this is such consuming a task that it requires a step-by-step
> approach to be done properly.
>
16 hours work, one hour per day; just have a quite writing time, two
hours on the weekends. You'll be done in two weeks. Maybe you can
recruit some editorial help from someone.
Garrett
David Mark
wrote:
> David Mark wrote:
> > Garrett Smith wrote:
> >> David Mark wrote:
> >> > On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
> >> >> Does anyone have any links to very convincing articles that eloquently
> >> >> state the major flaws of these libraries? I'm not considering using
> >> >> any of them, I've heard enough here to know how bad they are. I just
> >> >> want a few article links to keep in my back pocket that I can fire
> >> >> back when someone suggests we use one of them.
>
> >> > I've reviewed salient bits of all three in the last six months or so.
> >> > Search the archive.
>
> >> > In short, jQuery is terribly inept and unneeded, YUI is terribly
> >> > botched and bloated and Dojo is just plain terrible.
> >> Pure opinion.
>
> > Amnesia flaring up again? :)
>
> > There's a tsunami of evidence and demonstration behind my statements
> > (as you well know). As I said, search the archive.
>
> Search it yourself.
Why would I do that? After all, I've seen them.
> I must agree that the problem with what is in "the
> archive" is that it is unstructured, not to the point, full of useless
> sentiments, and on top of it widely unreadable thanks to sloppy formatting
> (on your part, despite several requests to do better),
It's odd as you just recently opined that such sloppy formatting as is
found in the reviewed code could hardly be pinned on me.
> if it is available
> at all (you know about Google Groups' search flaws, don't you?).
As I'm sure you know, this group is echoed on numerous Websites other
than GG. A normal Google search can be used when GG's search feature
is going through one of its outages.
> It is
> unfortunately impractical to find the pearls in the mud that have been
> thrown. So much for amnesia.
Utter nonsense. I've dissected jQuery so many times (here and
elsewhere) that complaints often arise over the repetition.
And the recent reviews of Dojo and Qooxdoo were as thorough as they
needed to be. I don't recall you finding fault in them.
>
> Therefore, I, too, would welcome an unbiased, unemotional, and theoretically
> sound peer review.
Of jQuery?!
> In fact, not having observed it to date, I have been
> considering to try and write one myself when and if I find the time.
So join Garrett on the list of people who haven't written reviews of
jQuery or the rest.
> Perhaps this is such consuming a task that it requires a step-by-step
> approach to be done properly.
>
Whatever. Seems like a waste of time at this point (particularly for
jQuery).
David Mark
> On 6/16/2010 4:06 PM, David Mark wrote:
>
> > On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >> On 6/16/2010 2:35 PM, David Mark wrote:
>
> >>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
> >>>> Does anyone have any links to very convincing articles that eloquently
> >>>> state the major flaws of these libraries? I'm not considering using any
> >>>> of them, I've heard enough here to know how bad they are. I just want a
> >>>> few article links to keep in my back pocket that I can fire back when
> >>>> someone suggests we use one of them.
>
> Of course, so when somebody -- a recruiter, for example, says, "what's
> wrong with the jQuery library?", you can say:
I don't often talk to recruiters and when I do, that question does not
come up.
>
> - Poor selector engine
How many times have we been over that?
> - Non-descriptive method names
And that.
> - Hard to debug
Another of my oft-repeated indictments, dating back almost three
years.
> - long, overloaded methods with too much abstraction
And another.
> - Poorly degradable
Still another.
> - loosely defined constructs and vague documentation
Yep.
> - Low-quality plugins
Everyone knows *that*.
> - Silly (and futile) things in source, like `isPlainObject`
LOL. It was isObjectLiteral until I took them to task on it in one of
my many reviews. They changed it soon after (which, as you well know,
is a pattern oft-repeated).
> - Significant and numerous core upgrades that break functionality
You sound like you are covering my greatest hits.
> - plugins don't work
http://www.jibbering.com/faq/notes/posting/#ps1DontWork
And you are repeating yourself as well.
> - documentation doesn't reflect new behavior
Change "new behavior" to "reality" and you've copped another one from
me.
>
> (modified list of gripes from a colleague).
Oh brother. They must be an avid reader.
>
> >>> I've reviewed salient bits of all three in the last six months or so.
> >>> Search the archive.
>
> >>> In short, jQuery is terribly inept and unneeded, YUI is terribly
> >>> botched and bloated and Dojo is just plain terrible.
>
> >> Pure opinion.
>
> > Amnesia flaring up again? :)
>
> > There's a tsunami of evidence and demonstration behind my statements
> > (as you well know). As I said, search the archive.
>
> The OP asked for "links to very convincing articles".
I can read, thanks.
> In your response,
> I see cynical opinion and no links.
You are a repetitious clod, pure and simple.
> That's not even a concise summary of
> any one library.
Of course not. What does "in short" and "search the archive" mean to
you. Your feigning of amnesia (for the last three years) just makes
you a laughingstock.
> It sounds snide, actually. And no urls.
No links? See above.
>
> >> Anybody can say that about anything. Example: Disco sucks.
> >> The design of the Prius is terribly botched. The US Government is just
> >> plain terrible. Easy, right?
>
> > I've done all of the hard work. You yourself were just parroting some
> > of it recently.
>
> That is untrue.
History says otherwise.
>
> I've have never wanted to copy anything of yours.
Then I assume you've done so repeatedly at gunpoint.
>
>
>
> >> A no-nonsense analysis demonstrating major shortcomings is not easy, but
> >> would be valuable.
>
> > It's been done to death (as you well know).
>
> URL?
Groan. See above.
>
>
>
> >> The article should provide a concise summary of problems, elaborate on
> >> that, with examples, link to any pertinent standards, and finally,
> >> provide advice on what the reader should do instead of using that.
>
> > That ship has sailed and long since reached its destination.
>
> If you are trying to say that an article was published then post a URL
> so the OP can see it.
Do you read this stuff before posting?
>
> [...]
>
> >> Something as
> >> complicated as that should be explained, so that it can be fully
> >> appreciated.
>
> > Yes. Again, done to death at this point. I mean, Prototype?! Could
> > there be a less relevant example at this juncture?
>
> One point to be gleaned from that is what sort of change it can affect.
> A subtler point is that the mistake I made was not emphasizing enough
> about what to do instead. Look how many switched to jQuery.
Let's get real. Nobody has ever heard of you or your review of
Prototype. Why don't you put your obvious frustration into something
productive?
>
> The review also shows an example outline of how to do a review.
It's all about you and some review nobody has read, isn't it?
> It
> starts at a very high level with technical *facts*.
You really should read your stuff aloud before hitting the send
button.
>
> | A code review should be objective and should state actual problems.
> | Saying "the code is bad" is not a helpful review. Instead, explain
> | the problem clearly. If the problem is severe, then say why.
>
> <http://jibbering.com/faq/notes/review/>
>
> I've emphasized these points many times regarding your reviews and I've
> noticed improvement, but I think it can still get better.
You assume I've paid the slightest attention to your advice.
>
> People will respect you if you follow that.
Oh piss off. You respect me enough to imitate me years later. It's
quite a compliment, even from a certified loon.
>
>
>
> >> Prototype.js has mostly died out since then.
>
> > Exactly.
>
> And even a Prototype core developer criticizing Prototype:http://perfectionkills.com/whats-wrong-with-extending-the-dom/
You don't see my influence there, do you? Who first pointed out the
IE "unknown" type issue and repeated it endlessly until it seeped into
the public conscience.
>
> Now more and more are flocking to jQuery.
Who conducted that study?!
> Great. Well, not really.
Snide. :)
>
> [...]
>
>
>
> >> I will be publishing an article next
> >> week related to the W3C Selectors library, too. I don't have time for
> >> another article.
>
> > Okay. I think you are way late on that one as well.
>
> Opinions are funny things. Everybody's got one.
And everybody knows full well who spent years detailing the jQuery
follies.
>
> My observations are that many developers are unaware of how selectors work.
I'm sure many are. So what? Many developers can't tie their own
shoes. How is that my fault? It's funny that the gripe used to be
about *too many* jQuery indictments on my part.
>
> I've notice that some foster beliefs that the jQuery "bare words"
> proprietary selector syntax is designed to work match attributes instead
> of properties. In contrast, the source code of jQuery indicates that it
> was designed to select properties.
>
> Further evidence indicates that there may be uncertainty as to whether
> or not the jQuery author(s) know what it was designed to do or knew that
> it was invalid CSS selector syntax.
Long ago published by me. Years later, you want to chime in. What
audience do you think you are playing to anyway? The vast majority of
readers (excluding newcomers) have heard this stuff so many times they
are sick of it (and have said so repeatedly).
> The documentation says it selects
> attributes, the website says it is css3 compliant.
Could there be anything more ludicrous than you pointing out issues
related to jQuery and attributes in June 2010. Go back to around
Halloween 2007 and start reading my posts (particularly those threads
where John Resig popped in to shoot himself in the foot).
And the thing is you know all of this. Have you lost your mind
recently or what?
> Blog entries seem to
> be vague and contradictory.
What blog entries? Resig's? Yes, we've been over them ad nauseam
too.
>
> My observation is that developers are confused as to how selectors
> really work.
You just said that. And I've been saying it for *years*. Published
loads of proofs too. Are you really trying to wish all of that away
now? That road's been plowed. Find another one.
>
>
>
> > Your hypothetical article pales in comparison to my somewhat legendary
> > output in this area. Best of luck with it!
>
> Then post a link to what you feel are your best ones.
No. :)
> Let them speak for
> themselves and quit boasting about them.
Why don't you quit pretending they don't exist? You'd really hit a
new low here.
>
> Look:
> <http://www.google.com/search?q=jquery+%22code+review%22>
>
> I don't see any jQuery code reviews.
Perhaps you don't know how to use a search engine.
> Chances are, the OP doesn't either.
Perhaps he knows better.
>
> I've found:http://www.doxdesk.com/#u20091116-jquery
>
> - which is funny, but not a serious code review (the author is
> knowledgeable and provides humorous insight. He seems to not take jQuery
> seriously).
Who would? It's long since been exposed as a joke. Largely by me.
Get it? Resig sure as hell does. :)
>
> My opinion is that jQuery is taken seriously by so many that it cannot
> be just laughed off and it cannot be just called garbage.
What a ludicrous summary that is.
> In order to
> effect a change, one must take it head on in a more formal code review.
Rubbish. The typical jQuery "programmer" will not be moved (and may
not understand) technical reviews. Look at the avalanche of "retorts"
from that camp related to my reviews. Most seemed to have missed the
boat entirely. A few did take note of course (as you well know).
>
> Talk to the reader as if he's right in front of you; don't insult his
> intelligence and don't assume he understands everything you do.
I have no need to "talk" to anyone about jQuery at this time.
> Be
> concise. Make it understandable at a high level to anyone. Try to see it
> from the perspective of the user who llikes it. Try to see it from the
> perspective of the author who wrote it and is now stuck with design
> decisions -- what can he do? Are they fixable? If so, how? If not, why
> not? Parsing selectors - sounds neat, right? Well, the problems with
> that are...
...well-documented. Largely by me. Where were you (and are you
really posting any of this with a straight face?)
>
> [brief introduction]
>
> [summary overview of problems]
>
> [exposition and demonstration of each problem]
>
> [elaboration on design issues]
>
> [alternative]
>
> [conclusion]
I've concluded you just like wasting my time. What do you get out of
that?
>
> Writing something like that is not going to be easy; not something that
> can be completed in under a week.
Whatever.
>
> A link to such formal review of jQuery would be useful and valuable.
To whom?
>
> My prototypejs review was painful, not because I had to go and find
> problems, but because I had to communicate them effectively to readers
> who liked Prototype.js.
What difference did it make? I'll opine none.
David Mark
And presumably such reprints are unreadable for some reason?
> Sometimes googlegroups
> local versions (korea, etc).
So skip those that aren't in your native language.
>
> > Therefore, I, too, would welcome an unbiased, unemotional, and theoretically
> > sound peer review. In fact, not having observed it to date, I have been
> > considering to try and write one myself when and if I find the time.
> > Perhaps this is such consuming a task that it requires a step-by-step
> > approach to be done properly.
>
> 16 hours work, one hour per day; just have a quite writing time, two
> hours on the weekends.
Where do you come up with this stuff?
> You'll be done in two weeks.
Then you'll only be two and half years plus two weeks too late to be
relevant.
> Maybe you can
> recruit some editorial help from someone.
>
Maybe. Speaking of hours, I want the last hour or so of my life
back. You'll truly outdone yourself this time.
Scott Sauyet
>>>> Joe Nine wrote:
>>>>> Does anyone have any links to very convincing articles that eloquently
> I, too, would welcome an unbiased, unemotional, and theoretically
> sound peer review. In fact, not having observed it to date, I have been
> considering to try and write one myself when and if I find the time.
> Perhaps this is such consuming a task that it requires a step-by-step
> approach to be done properly.
As I'm sure is clear to regulars in this group, I am not entirely in
agreement with the most commonly expressed opinion here that these
general purpose libraries are worthless. I have not actively defended
them much, but I personally find some value in them.
Yet I would also welcome such critiques. I think they could do no
worse than make more public the flaws that we all know exist in these
libraries. They might help improve the libraries or bring forth
better ones.
But, as Garrett said, such critiques would have to be thorough,
detailed, technically savvy but still reader-friendly. Such prose is
not particularly easy to write. I think I can write reasonably well,
and will volunteer to help put such critiques into a clear form if
there is someone who wants to supply the analysis. (And no, David, I
don't want to search the archives to piece it together!)
I would suggest that if people take this up, that it's done one
library at a time. A later collection can discuss them _en masse_ if
desired, but the detailed explanation of the individual libraries
should come first.
Garrett's outline above is a decent start, although I would prefer a
critique that at least starts at a higher level than his Prototype
essay. One about jQuery might start for instance discussing
objections to some of the features that the jQuery community actively
promotes, starting with the "find something, do something" mantra
(questions about inefficiencies, about proliferation of event
handlers, about whether CSS queries are ever the right way to choose
elements, etc.) and perhaps hitting on chaining and the multiple
meanings of the "$" function. But eventually the sorts of details
Garrett exposes for Prototype would be included too.
Although these are critiques, they should be expository writing and
not attempt to persuade users against those particular libraries. The
attitude should be one of, "If you're going to consider this library
you might want to know about these problems," and not, "You should not
bother with this library."
As I said, I'm more than willing to help, although I won't take this
on entirely myself.
--
Scott
David Mark
> Thomas 'PointedEars' Lahn wrote:
> >>>> Joe Nine wrote:
> >>>>> Does anyone have any links to very convincing articles that eloquently
> >>>>> state the major flaws of these libraries? [ ... ]
> > I, too, would welcome an unbiased, unemotional, and theoretically
> > sound peer review. In fact, not having observed it to date, I have been
> > considering to try and write one myself when and if I find the time.
> > Perhaps this is such consuming a task that it requires a step-by-step
> > approach to be done properly.
>
> As I'm sure is clear to regulars in this group, I am not entirely in
> agreement with the most commonly expressed opinion here that these
> general purpose libraries are worthless. I have not actively defended
> them much, but I personally find some value in them.
>
> Yet I would also welcome such critiques. I think they could do no
> worse than make more public the flaws that we all know exist in these
> libraries.
More public? Those who have the capacity to understand the problems
in jQuery should be well aware of them by now.
> They might help improve the libraries or bring forth
> better ones.
They already have brought forth better ones. As for improvement,
there is a slight flaw in your plan. The authors of - for example -
jQuery and Dojo have been directly confronted with their respective
(and often duplicated) failings and dismissed them out of hand (and
out of sheer ignorance apparently).
>
> But, as Garrett said, such critiques would have to be thorough,
> detailed, technically savvy but still reader-friendly.
It's been done every which way.
> Such prose is
> not particularly easy to write. I think I can write reasonably well,
> and will volunteer to help put such critiques into a clear form if
> there is someone who wants to supply the analysis. (And no, David, I
> don't want to search the archives to piece it together!)
Here is a good jumping off point that touches on some of the general
issues with jQuery (and yes, it includes links to articles and
examples, as Garrett knows all too well).
http://www.cinsoft.net/host.html
Here's another that links to an example of jQuery futility:-
http://www.cinsoft.net/size.html
And the parallel threads (here and in the jQuery forum) related to
element dimensions that resulted in the linked example are certainly
hard to miss (each is well over a hundred posts).
>
> I would suggest that if people take this up, that it's done one
> library at a time.
It was. And most of them are yesterday's news at this point.
> A later collection can discuss them _en masse_ if
> desired, but the detailed explanation of the individual libraries
> should come first.
Well, that bit's done (over-done some have said). Written,
aggregated, alternately praised and railed against, sliced, diced,
syndicated, Twittered, Reddited, etc. Those who missed them must have
been living in a vacuum for the past few years.
>
> Garrett's outline above is a decent start, although I would prefer a
> critique that at least starts at a higher level than his Prototype
> essay.
Hmmm. I thought one of his "points" was that he "started at a higher
level" (whatever that meant).
> One about jQuery might start for instance discussing
> objections to some of the features that the jQuery community actively
> promotes, starting with the "find something, do something" mantra
Repeated endlessly to the point where regulars started to complain
about the repetition.
> (questions about inefficiencies, about proliferation of event
> handlers,
That point eventually sunk in for the jQuery authors; unfortunately,
their response was to attempt to can and brand delegation as
"Live" (nd what a disaster that was/is).
> about whether CSS queries are ever the right way to choose
> elements, etc.)
You'll never convince Web designers of that. It's their "in".
> and perhaps hitting on chaining and the multiple
> meanings of the "$" function.
Classics, but nobody cares.
> But eventually the sorts of details
> Garrett exposes for Prototype would be included too.
>
> Although these are critiques, they should be expository writing and
> not attempt to persuade users against those particular libraries.
That would be like writing a critique about 70's models Pintos without
attempting to dissuade drivers from buying them.
> The
> attitude should be one of, "If you're going to consider this library
> you might want to know about these problems," and not, "You should not
> bother with this library."
That would miss the bigger picture. Browser scripting is about
simple, lightweight, context-specific functions (and yes, they should
be re-usable); it is *not* about magic GP libraries that attempt to
solve every problem for everybody. Never has been and never will.
But It's hard to convince newcomers whose experience and expertise are
with other languages. It's harder still to convince Web designers,
many of whom have backgrounds in graphic arts that CSS selectors are
not suitable for DOM traversal.
Best of luck to you though!
Garrett Smith
> On Jun 16, 8:43 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>> On 6/16/2010 4:06 PM, David Mark wrote:
>>
>>> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>> On 6/16/2010 2:35 PM, David Mark wrote:
>>
>>>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>>>>>> Does anyone have any links to very convincing articles that eloquently
>>>>>> state the major flaws of these libraries? I'm not considering using any
>>>>>> of them, I've heard enough here to know how bad they are. I just want a
>>>>>> few article links to keep in my back pocket that I can fire back when
>>>>>> someone suggests we use one of them.
>>
[...]
>>
>>> I've done all of the hard work. You yourself were just parroting some
>>> of it recently.
>>
>> That is untrue.
>
> History says otherwise.
>
>>
>> I've have never wanted to copy anything of yours.
>
> Then I assume you've done so repeatedly at gunpoint.
>
Lets be very clear on this: There is nothing of yours that I have
copied. Ever.
If you believe otherwise, then it's time for you to get very specific
with an example.
[...]
>
> Oh piss off. You respect me enough to imitate me years later. It's
> quite a compliment, even from a certified loon.
>
No, I am not imitating anything of yours. To be frank, you have personal
characteristics that I do not aspire to be likened to.
[...]
>
> And everybody knows full well who spent years detailing the jQuery
> follies.
>
One person did that? And everybody knows who it is? Miss reality any?
You have complained about jQuery for years but not all discussions are
yours; you certainly don't have rights or intellectual ownership over
discussions on jQuery.
[...]
>
> Long ago published by me. Years later, you want to chime in. What
> audience do you think you are playing to anyway? The vast majority of
> readers (excluding newcomers) have heard this stuff so many times they
> are sick of it (and have said so repeatedly).
>
One of the significant differences between you and I is that I am not
trying play any audience. Really. I don't care that nobody uses APE.
The reasons I've heard for being "sick of" your rants is -- and I know
you don't want to hear it but you're asking for it - is that they come
off as being personal (some even say jealous) and that they are badly
organized, poorly formatted, and unfocused.
You bring up good points, but you do so with in an emotional manner and
disorganization, and often ironically claiming how awful jquery is, yet
trying to compete with that, while claiming that you are superior, yet
also saying that your alternative is a parody.
Reading jQuery and fiding bugs is easy. Try to understand the difference
between that and publishing an article that can explain the those
problems to the rest of the world.
[...]
>
> No. :)
>
No links to your best and legendary reviews? That is what the OP is
asking for.
I really don't see what purpose your replies fulfill. It seems to be a
personal issue.
[...]
>
> I have no need to "talk" to anyone about jQuery at this time.
Uh-huh.
[...]
Garrett
Garrett Smith
> Thomas 'PointedEars' Lahn wrote:
>>>>> Joe Nine wrote:
>>>>>> Does anyone have any links to very convincing articles that eloquently
>>>>>> state the major flaws of these libraries? [ ... ]
[...]
> But, as Garrett said, such critiques would have to be thorough,
> detailed, technically savvy but still reader-friendly. Such prose is
> not particularly easy to write. I think I can write reasonably well,
I agree with both of those. It's not easy to write that stuff and yes,
you do write reasonably well.
>
> Garrett's outline above is a decent start, although I would prefer a
> critique that at least starts at a higher level than his Prototype
> essay. One about jQuery might start for instance discussing
> objections to some of the features that the jQuery community actively
> promotes, starting with the "find something, do something" mantra
> (questions about inefficiencies, about proliferation of event
> handlers, about whether CSS queries are ever the right way to choose
> elements, etc.) and perhaps hitting on chaining and the multiple
> meanings of the "$" function. But eventually the sorts of details
> Garrett exposes for Prototype would be included too.
>
The $ function was mentioned in the PrototypeJS review.
| What Does $ Do?
|
| * $ does not have a clearly defined meaning as to what the function
| actually does.
| * The dollar sign is intended to be reserved for machine-generated
| code.
|
| PrototypeJS $ function gets an element or array of elements. Calling
| $ results in a bare minimum of three function calls: $, isString, and
| Element.extend and a maximum of over 135 function calls.
I took a look at the "find something, do something" mantra/pattern here:
http://groups.google.com/group/comp.lang.javascript/msg/6479712b867c30d1?dmode=source
[...]
Garrett
David Mark
> On 6/16/2010 6:29 PM, David Mark wrote:
>
> > On Jun 16, 8:43 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >> On 6/16/2010 4:06 PM, David Mark wrote:
>
> >>> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >>>> On 6/16/2010 2:35 PM, David Mark wrote:
>
> >>>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
> >>>>>> Does anyone have any links to very convincing articles that eloquently
> >>>>>> state the major flaws of these libraries? I'm not considering using any
> >>>>>> of them, I've heard enough here to know how bad they are. I just want a
> >>>>>> few article links to keep in my back pocket that I can fire back when
> >>>>>> someone suggests we use one of them.
>
> [...]
>
>
>
> >>> I've done all of the hard work. You yourself were just parroting some
> >>> of it recently.
>
> >> That is untrue.
>
> > History says otherwise.
>
> >> I've have never wanted to copy anything of yours.
>
> > Then I assume you've done so repeatedly at gunpoint.
>
> Lets be very clear on this: There is nothing of yours that I have
> copied. Ever.
Let's be very clear. You have. Perhaps, for whatever reason, you
don't even realize it.
>
> If you believe otherwise, then it's time for you to get very specific
> with an example.
Haven't we been over *that* enough times? Start with your recent
obsession with queries and attributes vis-a-vis jQuery.
>
> [...]
>
>
>
> > Oh piss off. You respect me enough to imitate me years later. It's
> > quite a compliment, even from a certified loon.
>
> No, I am not imitating anything of yours. To be frank, you have personal
> characteristics that I do not aspire to be likened to.
LOL. You really think you are playing to some imaginary crowd, don't
you? Anyone who has read this group knows you are full of it. Anyone
new to it will find out soon enough.
>
> [...]
>
>
>
> > And everybody knows full well who spent years detailing the jQuery
> > follies.
>
> One person did that? And everybody knows who it is? Miss reality any?
Who is most famous for it? And you are not one to crack about
reality.
>
> You have complained about jQuery for years but not all discussions are
> yours;
Complained?! That's a pretty disingenuous characterization.
> you certainly don't have rights or intellectual ownership over
> discussions on jQuery.
I pretty much invented the art of the jQuery critique though, didn't
I?
>
> [...]
>
>
>
> > Long ago published by me. Years later, you want to chime in. What
> > audience do you think you are playing to anyway? The vast majority of
> > readers (excluding newcomers) have heard this stuff so many times they
> > are sick of it (and have said so repeatedly).
>
> One of the significant differences between you and I is that I am not
> trying play any audience. Really. I don't care that nobody uses APE.
Who said anything about APE? I knew it was coming though.
>
> The reasons I've heard for being "sick of" your rants is -- and I know
> you don't want to hear it but you're asking for it - is that they come
> off as being personal (some even say jealous)
LOL. The original gripe from Resig and co. was "where's your way cool
library". Then when I showed them up, it was "aw, you are just
jealous coz nobody uses your library". Wake up, that was almost three
years ago.
> and that they are badly
> organized, poorly formatted, and unfocused.
Whatever you think of them, they trump your nothingness, don't they?
>
> You bring up good points, but you do so with in an emotional manner and
> disorganization, and often ironically claiming how awful jquery is, yet
> trying to compete with that, while claiming that you are superior, yet
> also saying that your alternative is a parody.
Compete with jQuery? My Library is nothing like jQuery. Modular vs.
Interdependent; a dynamic and well thought-out API vs. a static,
inflexible "$" factory; and a comparable build is smaller, faster and
(as demonstrated ad nauseam) better at queries (the one thing jQuery
claims to do well). Minified it is roughly 1.5x the size, but with
100x the features (it's like jQuery + 100 plug-ins).
And, as you well know, my comment of parody was related to one small
part of it. Just who do you think you are fooling with this tripe?
>
> Reading jQuery and fiding bugs is easy.
Sneering from the sidelines (in a long-empty stadium) is even
easier. :)
> Try to understand the difference
> between that and publishing an article that can explain the those
> problems to the rest of the world.
All I know is that you've done neither. Meanwhile, my patterns have
found their way into all of the "major" libraries. Yours too I'm
sure.
>
> [...]
>
>
>
> > No. :)
>
> No links to your best and legendary reviews? That is what the OP is
> asking for.
And, as is obvious, if you really cared about the OP, you'd have
posted the links. You know damned well where to find them.
>
> I really don't see what purpose your replies fulfill. It seems to be a
> personal issue.
You seem to have personal issues; as of late, you seem desperate to
carve a niche for yourself in the library critique business. I don't
see why you replied to my post other than to call attention to some
unwritten review of yours.
Garrett Smith
So let me get this straight: I reviewed code from jQuery. This bothers
you because you believe that I copied you.
Did I get that right?
[...]
>
> All I know is that you've done neither. Meanwhile, my patterns have
> found their way into all of the "major" libraries. Yours too I'm
> sure.
>
[...]
I've looked for, but found no unit tests. If I'm going to use something,
I want to run tests on it to verify the edge cases.
Garrett
Joe Nine
You weren't wrong. There are too many replies to respond to individually
so I'll do just one here.
Yes I searched and found no links to any convincing well presented
breakdown of what jQuery and dojo's major headline flaws are. I'll be
saving a copy of those listed in here by Garrett as a few arguments to
keep handy.
My main motivation to find a good (few) link(s) are twofold.
One, when turning down a job offer recently I made up various excuses
but I really wanted to add that part of the reason (not a huge part, but
a part) was that jQuery was playing a large role in their projects. I've
seen enough examples of code that's using jQuery on here to know that I
don't want to become a jQuery programmer - it's like it's own new
language with an ugly perl-like syntax. I guess it's one for the
programmers that prefer unix. I'm a windows guy myself and like "classic
syntax" languages. I guess that's why I've never got into complex
regular expressions either.
The other reason is that I overheard someone in my department saying
"perhaps we should use jQuery". I want to be ready with my arguments
against that when/if the time comes. Just being able to quote hearsay
from here won't cut it. Links to concise articles help.
Matěj Cepl
> I guess it's one for the programmers that prefer unix.
Please, don't offend us (Linux|Unix) users. I don't see any relation
between using U*X and distaste for replacing one neatly designed
functional language with some horrible hack pretending to be one.
Matěj
--
Give your heartache to him. (1Pt 5,7; Mt 11:28-30)
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > Garrett Smith wrote:
>> >> David Mark wrote:
>> >> > On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>> >> >> Does anyone have any links to very convincing articles that
>> >> >> eloquently state the major flaws of these libraries? I'm not
>> >> >> considering using any of them, I've heard enough here to know how
>> >> >> bad they are. I just want a few article links to keep in my back
>> >> >> pocket that I can fire back when someone suggests we use one of
>> >> >> them.
>> >> > I've reviewed salient bits of all three in the last six months or
>> >> > so. Search the archive.
>> >> >
>> >> > In short, jQuery is terribly inept and unneeded, YUI is terribly
>> >> > botched and bloated and Dojo is just plain terrible.
>> >> Pure opinion.
>> > Amnesia flaring up again? :)
>> >
>> > There's a tsunami of evidence and demonstration behind my statements
>> > (as you well know). As I said, search the archive.
>> Search it yourself.
>
> Why would I do that?
So that you could think yourself into the position people you want to reach
and realize the difficulties they could have with your "go and search for
yourself" suggestion.
> After all, I've seen them.
You miss the point.
>> I must agree that the problem with what is in "the
>> archive" is that it is unstructured, not to the point, full of useless
>> sentiments, and on top of it widely unreadable thanks to sloppy
>> formatting (on your part, despite several requests to do better),
>
> It's odd as you just recently opined that such sloppy formatting as is
> found in the reviewed code could hardly be pinned on me.
AISB, the issues I have are not primarily with the formatting of the
reviewed code in the reviews. It is with the formatting of the comments
(you) made about them in the context of those reviews.
>> if it is available at all (you know about Google Groups' search flaws,
>> don't you?).
>
> As I'm sure you know, this group is echoed on numerous Websites other
> than GG. A normal Google search can be used when GG's search feature
> is going through one of its outages.
You are missing the point that you want something from your readers (to
think twice about using certain code). It is not logical to assume that
they would go to great lengths to find evidence for that.
>> It is unfortunately impractical to find the pearls in the mud that have
>> been thrown. So much for amnesia.
>
> Utter nonsense.
Hey, that's *my* line!
> I've dissected jQuery so many times (here and
> elsewhere) that complaints often arise over the repetition.
IMHO, complaints are directed more at the way of the review. Since you
cannot assume that previous reviews have been read, the trick is to not show
to the reader in a new review that it annoys you to have to write the same
thing again. After all, they are really not interested in learning *that*.
> And the recent reviews of Dojo and Qooxdoo were as thorough as they
> needed to be.
As they needed to be *for you*. But you must realize that this is not
sufficient to *convince* others.
> I don't recall you finding fault in them.
TLDR, for the most part. Do you realize the problem?
>> Therefore, I, too, would welcome an unbiased, unemotional, and
>> theoretically sound peer review.
>
> Of jQuery?!
Especially of jQuery.
>> In fact, not having observed it to date, I have been
>> considering to try and write one myself when and if I find the time.
>
> So join Garrett on the list of people who haven't written reviews of
> jQuery or the rest.
I might.
>> Perhaps this is such consuming a task that it requires a step-by-step
>> approach to be done properly.
>
> Whatever. Seems like a waste of time at this point (particularly for
> jQuery).
If that is your opinion, you should not be surprised that you do not come
off as very convincing for the most part. For besides technical knowledge
it is convincing people that you need to be good at in order to turn people
that you don't know away from jQuery and the like. And I am sorry to say
that this does not appear to be your forté. I am not saying that it is mine
either, but at least I am basically willing to give it a try. That is where
we apparently differ.
David Mark
No, it's one of your usual purposeful oversimplifications. You copied
the one-off feature test from me too. See, I can generalize too!
IIRC, your comment at the time (as you did this here in public) was
that you were changing your whole library to use it as you previously
just had flags. Go ahead, deny it. I'll dig that one up for
sure. :)
>
> [...]
>
>
>
> > All I know is that you've done neither. Meanwhile, my patterns have
> > found their way into all of the "major" libraries. Yours too I'm
> > sure.
>
> [...]
>
> I've looked for, but found no unit tests. If I'm going to use something,
> I want to run tests on it to verify the edge cases.
You are blind as a bat.
Bwig Zomberi
> I've seen enough examples of code that's using jQuery on here to know
> that I don't want to become a jQuery programmer - it's like it's own new
> language with an ugly perl-like syntax. I guess it's one for the
> programmers that prefer unix. I'm a windows guy myself and like "classic
> syntax" languages. I guess that's why I've never got into complex
> regular expressions either.
Javascript syntax is based on C or Java if you like.
C was first written for Unix, which was written for the most part in C.
jQuery is born ugly. Unix played no part in its birth or parenting.
--
Bwig Zomberi
Thomas 'PointedEars' Lahn
> I've looked for, but found no unit tests. If I'm going to use something,
> I want to run tests on it to verify the edge cases.
What's wrong with JsUnit? <http://www.jsunit.net/>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Joe Nine
> Joe Nine wrote:
>> I've seen enough examples of code that's using jQuery on here to know
>> that I don't want to become a jQuery programmer - it's like it's own new
>> language with an ugly perl-like syntax. I guess it's one for the
>> programmers that prefer unix. I'm a windows guy myself and like "classic
>> syntax" languages. I guess that's why I've never got into complex
>> regular expressions either.
>
> Javascript syntax is based on C or Java if you like.
I know. I imagine everyone here does.
> C was first written for Unix, which was written for the most part in C.
I learned that in class too. I don't see the relevance to anything though.
> jQuery is born ugly. Unix played no part in its birth or parenting.
I doubt anyone thinks it has any relation to unix.
VK
> However, it touches on a core antipattern of Quooxdoo, Cappuccino and
> SproutCore. It's not a new technique.
>
> It would be good for the article to do one of
> 1) focus entirely on one library
> 2) focus or a problem that is solved and show how libraries solve it,
> with examples from the library, and then show an alternative.
> 3) focus on an antipattern
>
> I'm going to publish an article next week, after it has been reviewed
> and edited (the draft is being reviewed now). The article will cover
> some things here, but it is not a formal review, as I have outlined. I'd
> really like to see that, and if it is a good one, probably even more
> than the article I'm working on.
The jealousness is great in this NG, so I am afraid it will just
another vanity fair with "what dork would do like that / what idiot
would code like this??!". I distinctly remember back in 2005-2006,
when the 2nd Browser Wars started, this NG was nearly attacked with
asks to suggests any good library, "please, please, please". The
locals could use it to push *any* programming pattern they like,
literally, so now would be getting the harvest back. Instead the
energy was spend to call sh*t on anyone not willing to write the code
from the scratch. Eventually such demands stopped, people left: for
Prototype.js, MooTools, Dojo etc. And what else was it expected? No
help from clj - no help from anywhere?
For a core library covering coding/DOM trivia the train is pretty much
gone. It is hard but very important to understand. No one gives a damn
how perfect, universal, robust, everlasting a commercial use library
is by design. The only important things are: how long is it on the
market (2years min), how many listed bugs fixed (lesser that 100 means
that at least 20-50 really nasty ones will have to be fixed with your
business loss), how good the support is.
And the last but not least nobody really cares what library is bad and
why. People normally want to know what library is the most usable /
the best and why. If the consensus still is that there is not such
library and the only sane option is to write your own from the scratch
then it is better to stop the discussion right here so not making
another fun out of yourselves. To appreciate the deep of the fun at
the modern time, go say to comp.lang.c++.moderated and declare the
evilness of any library usage starting with STL.
P.S. What about The Javascript Toolbox http://www.javascripttoolbox.com/
by Matt Kruse as a positive starting point?
Joe Nine
> Dne 17.6.2010 09:10, Joe Nine napsal(a):
>> I guess it's one for the programmers that prefer unix.
>
> Please, don't offend us (Linux|Unix) users. I don't see any relation
> between using U*X and distaste for replacing one neatly designed
> functional language with some horrible hack pretending to be one.
Easily offended much?
I'm only pointing out that jQuery takes what is a classic C style syntax
that JavaScript offers and encapsulates it in a cryptic wrapper. When it
comes to cryptic commands you can't dispute that *nix has that going on
at a bash prompt. Seen a complex grep or ls command ? Same applies (as I
mentioned) to regexp commands. I don't like either.
Kenneth Tilton
> Does anyone have any links to very convincing articles that eloquently
> state the major flaws of these libraries? I'm not considering using any
> of them, I've heard enough here to know how bad they are. I just want a
> few article links to keep in my back pocket that I can fire back when
> someone suggests we use one of them.
http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo-part-iii-why-it-rocks.html
That article is about a good library, but the first line has links to
assessments of the three you mentioned.
kt
--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
David Mark
wrote:
> Garrett Smith wrote:
> > I've looked for, but found no unit tests. If I'm going to use something,
> > I want to run tests on it to verify the edge cases.
>
> What's wrong with JsUnit? <http://www.jsunit.net/>
>
I believe he is revisiting his "aw U don't have any unit tests" bit.
In other words, he can't find the ones for My Library.
David Mark
It came in 2007.
>
> For a core library covering coding/DOM trivia the train is pretty much
> gone. It is hard but very important to understand. No one gives a damn
> how perfect, universal, robust, everlasting a commercial use library
> is by design. The only important things are: how long is it on the
> market (2years min), how many listed bugs fixed (lesser that 100 means
> that at least 20-50 really nasty ones will have to be fixed with your
> business loss), how good the support is.
>
> And the last but not least nobody really cares what library is bad and
> why. People normally want to know what library is the most usable /
> the best and why. If the consensus still is that there is not such
> library and the only sane option is to write your own from the scratch
> then it is better to stop the discussion right here so not making
> another fun out of yourselves. To appreciate the deep of the fun at
> the modern time, go say to comp.lang.c++.moderated and declare the
> evilness of any library usage starting with STL.
>
> P.S. What about The Javascript Toolboxhttp://www.javascripttoolbox.com/
> by Matt Kruse as a positive starting point?
Starting point?! Did you miss My Library entirely?
Joe Nine
> Joe Nine wrote:
>> Does anyone have any links to very convincing articles that eloquently
>> state the major flaws of these libraries? I'm not considering using
>> any of them, I've heard enough here to know how bad they are. I just
>> want a few article links to keep in my back pocket that I can fire
>> back when someone suggests we use one of them.
>
> http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo-part-iii-why-it-rocks.html
>
> That article is about a good library, but the first line has links to
> assessments of the three you mentioned.
>
> kt
Thanks for the links. Somewhat wordy articles with way too much talk
about Lisp. I thought Lisp went out of fashion in about 1959 (a year
after it came in). It's another one of those languages where I always
wonder what it's useful for. Back in college, I think Lisp was covered
in just one day and the conclusion was that you'd never have to worry
yourself about it, you won't likely see it again. Why do people hang
onto these obscure languages?
Matt Kruse
> P.S. What about The Javascript Toolboxhttp://www.javascripttoolbox.com/
> by Matt Kruse as a positive starting point?
Eh, some of the stuff there is terribly out-dated and I would write it
very differently now. Some of it still quite solid, IMO (like table
sorting and date manipulation).
I wish I had time to build, maintain, improve, document, and test all
the stuff that I'd like to put up there, but I don't. My goal was to
build it into a toolbox that was a collection of stuff from more
authors than just myself, but again, no time.
The js that I'm currently working with most is http://BetterFacebook.net,
which is a greasemonkey script/firefox add-on (which also works in
Chrome, Safari, and Opera, I've heard) that adds a bunch of
functionality to Facebook. It's a whole different kind of challenge,
and it's refreshing to not have to deal with IE at all. :)
Perhaps some day I will get back to my toolbox...
Matt Kruse
Matt Kruse
> I'm going to publish an article next week, after it has been reviewed
> and edited (the draft is being reviewed now). The article will cover
> some things here, but it is not a formal review, as I have outlined. I'd
> really like to see that, and if it is a good one, probably even more
> than the article I'm working on.
I doubt that any of the qualified people in this group are going to
devote time to such a review. I would love to see a simple wiki where
many of us could contribute to building a comprehensive, well-argued
analysis of jQuery. The pros and cons. Kind of a survey of jQuery.
Put it on its own domain, like jQueryReview.com or something, and
you'll get a decent amount of attention, IMO.
The key would be to have a one-page, printable white paper summarizing
the key arguments. This could be easily printed and brought to a
meeting by anyone who is trying to argue against the use of jQuery.
Then the site could dig deeper into the fine print for anyone who is
interested in a really technical analysis.
Of course, my personal take on jQuery is still a bit different than
many of the "zealots" here. I still use jQuery. For the things I use
it for, I am very happy to have it. But I also have a very good
understanding of its weak points, and I know how to avoid them. It is
a tool, like any other. The best developers have many tools in their
arsenal, and know how to pick the right tools to get a job done. There
is no need, IMO, to throw out jQuery completely when it can be a
useful tool in the right situations and in the hands of someone who
knows what they are doing.
Matt Kruse
David Mark
> On Jun 16, 7:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > I'm going to publish an article next week, after it has been reviewed
> > and edited (the draft is being reviewed now). The article will cover
> > some things here, but it is not a formal review, as I have outlined. I'd
> > really like to see that, and if it is a good one, probably even more
> > than the article I'm working on.
>
> I doubt that any of the qualified people in this group are going to
> devote time to such a review. I would love to see a simple wiki where
> many of us could contribute to building a comprehensive, well-argued
> analysis of jQuery. The pros and cons. Kind of a survey of jQuery.
>
> Put it on its own domain, like jQueryReview.com or something, and
> you'll get a decent amount of attention, IMO.
>
> The key would be to have a one-page, printable white paper summarizing
> the key arguments. This could be easily printed and brought to a
> meeting by anyone who is trying to argue against the use of jQuery.
> Then the site could dig deeper into the fine print for anyone who is
> interested in a really technical analysis.
>
> Of course, my personal take on jQuery is still a bit different than
> many of the "zealots" here.
You understand that the double-quotes are typically used to indicate
sarcasm. Not that I'm arguing with you.
> I still use jQuery.
Yes, we've been over that. :(
> For the things I use
> it for, I am very happy to have it.
I wouldn't claim that.
> But I also have a very good
> understanding of its weak points, and I know how to avoid them.
You're welcome.
> It is
> a tool, like any other.
A very bad tool.
> The best developers have many tools in their
> arsenal, and know how to pick the right tools to get a job done.
And jQuery is never the right tool. It's basically a 70K QSA wrapper
these days. The rest is never-finished nonsense. And yes, I know,
you wrote/write for an IE6-only environment. You couldn't have picked
a worse environment to use such a "tool". And I think you know this
(or I hope you do as we went over the salient issues a hundred times).
> There
> is no need, IMO, to throw out jQuery completely when it can be a
> useful tool in the right situations and in the hands of someone who
> knows what they are doing.
Name one (a situation). And no, you don't know what you are doing.
Going on three years later and that point is quite clear.
David Mark
> Joe Nine wrote:
> > Does anyone have any links to very convincing articles that eloquently
> > state the major flaws of these libraries? I'm not considering using any
> > of them, I've heard enough here to know how bad they are. I just want a
> > few article links to keep in my back pocket that I can fire back when
> > someone suggests we use one of them.
>
>
> That article is about a good library, but the first line has links to
> assessments of the three you mentioned.
We've been over Qooxdoo. In short, it's a bad library.
Matt Kruse
> > But I also have a very good
> > understanding of its weak points, and I know how to avoid them.
> You're welcome.
You've pointed out some. I've discovered many things on my own (things
you would never encounter, since you don't actually use it).
> And jQuery is never the right tool.
The "free market" disagrees with you. At least for now.
> > There
> > is no need, IMO, to throw out jQuery completely when it can be a
> > useful tool in the right situations and in the hands of someone who
> > knows what they are doing.
> Name one (a situation).
I know better than to waste my time arguing specifics with you.
There's no value in trying to convince you of anything.
Matt Kruse
David Mark
Has left the station? You know, it's odd; all of the "majors" have
botched basic attribute manipulation. That's hardly trivia. After
all, DOM stands for Document Object Model. And what are documents
made of? At the "atomic" level? That's right. The train crashed
right after it left.
http://www.cinsoft.net/attributes.html
> It is hard but very important to understand.
And apparently none of the authors of the "major" libraries understand
it at all.
> No one gives a damn
> how perfect, universal, robust, everlasting a commercial use library
> is by design.
That makes no sense at all. The code is transparent and often
obvious. When I see code like:-
function removeAttr(el, name) {
el.removeAttribute(el, name);
}
...as is found in Dojo and jQuery. Well, actually; IIRC, jQuery adds
a mystical incantation to try to compensate for a "mysterious" problem
they have yet to understand (a problem that is well over ten years
old).
function removeAttr(el, name) {
el[name] = '';
el.removeAttribute(el, name);
}
Similarly botched renditions of hasAttribute, setAttribute and (most
importantly for the query engines) getAttribute can be found in:-
- jQuery
- Prototype
- Dojo
- Goog (Closure)
- Qooxdoo
- YUI
- Cappuccino
- etc., etc.
What a spectacular train wreck. And for the last few years, those who
read this group have had these lessons drilled into them (whether they
liked it or not). What possible excuse do the authors of the above
efforts have at this point?
> The only important things are: how long is it on the
> market (2years min),
What?! The longer it has been on the market, presuming it is as
botched as the above libraries and frameworks, the less capable the
authors (at research, reading for comprehension, problem solving,
etc.). Think about it.
> how many listed bugs fixed (lesser that 100 means
> that at least 20-50 really nasty ones will have to be fixed with your
> business loss), how good the support is.
And we know full well about the "support" provided by the "major"
efforts.
>
> And the last but not least nobody really cares what library is bad and
> why.
Then can I presume nobody cares what library is good and why? I guess
nobody cares about anything on your planet. :)
> People normally want to know what library is the most usable /
> the best and why.
And what does "best" imply?
> If the consensus still is that there is not such
> library and the only sane option is to write your own from the scratch
You are the only person here who keeps parroting that "from scratch"
line year after year. It's famously *not* something that is
recommended here. Just as you are famous in your way.
> then it is better to stop the discussion right here so not making
> another fun out of yourselves.
There's no need to make fun of you Veek. Your posts are funny enough
in their own right. And I see you as a tragic figure, dug so deep in
a hole of blunders and misstatements that you have no shot at ever
seeing the light of day again. Give it up.
David Mark
> In article
> <7313e001-78c8-4b17-aa39-72e5a420e...@i28g2000yqa.googlegroups.com>,
> Matt Kruse <m...@thekrusefamily.com> wrote:
>
> [stuff]
>
> After all these posts, I'm none the wiser: what is the problem these
> libraries are trying to solve?
>
That's the problem. They are trying to solve everything for
everybody. Doesn't make sense for scripts that must be downloaded,
does it?
One big "issue" is cross-browser compatibility, which most "solve" by
peering at browsers endlessly and then adding browser sniffs to their
code. They then declare the scripts to be compatible with library X,
Y and Z (current versions only). When the next slew of major browsers
emerge, they go through it all again. That means more downloads for
the developers, more testing and ultimately more downloads (and forced
browser upgrades) for the hapless end-users.
None of it makes any sense, does it? :)
David Mark
> On Jun 17, 9:21 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > But I also have a very good
> > > understanding of its weak points, and I know how to avoid them.
> > You're welcome.
>
> You've pointed out some. I've discovered many things on my own (things
> you would never encounter, since you don't actually use it).
>
> > And jQuery is never the right tool.
>
> The "free market" disagrees with you. At least for now.
Popularity does not indicate the quality of the tools. In fact, in
this case, the people choosing the tools have no clue how to judge
their quality. So it's even less meaningful a metric for JS
libraries, isn't it? Popularity is usually an indicator of lots of
shiny graphics and disingenuous marketing.
>
> > > There
> > > is no need, IMO, to throw out jQuery completely when it can be a
> > > useful tool in the right situations and in the hands of someone who
> > > knows what they are doing.
> > Name one (a situation).
>
> I know better than to waste my time arguing specifics with you.
That's sensible as you've been routed so thoroughly in the past.
> There's no value in trying to convince you of anything.
>
What a lame argument that is. Worse than usual. :(
David Mark
Oops, it's not quite that bad, is it?
el.removeAttribute(name);
Still botched beyond belief though. One freaking line of code (two if
by jQuery). Basic CRUD for documents broken by design (apparently
never to be fixed). You can't make this stuff up. :)
VK
> In article
> <7313e001-78c8-4b17-aa39-72e5a420e...@i28g2000yqa.googlegroups.com>,
> Matt Kruse <m...@thekrusefamily.com> wrote:
>
> [stuff]
>
> After all these posts, I'm none the wiser: what is the problem these
> libraries are trying to solve?
Ever since NN3/IE3 slash, so since it became important to care of more
than one specific platform, the JavaScript libraries are solving these
problem:
1) Provide a reusable subroutines/interfaces for universally frequent
tasks (client-side form pre-validation is the oldest one)
2) To cover with a top level interface different and traditionally
numerous native DOM interfaces discrepancies and bugs of different UA
producers (layer positioning and viewport size calculations among the
oldest one).
3) To add custom methods that was originally considered as non-needed
one by specs producers (getElementsByClassName for a sample).
4) To add a functionality that otherwise requires many ours of
developments and some particular knowledge not universally presented
even among experienced programmers (3D vector graphics and animated 3D
object matrix transformations for SVG/VML for a sample).
5) Rather new one and not so common: adjusting the top level
programming paradigm to emulate some non-JavaScript paradigm with is
more traditional for a given target audience (C/C++ class-like in
Prototype.js for a sample).
Thomas 'PointedEars' Lahn
But the lesson that John Resig hasn't learned from Unices is its paradigm
"one tool for one purpose". It is what makes the (POSIX/Unixoid) shell
maybe a little bit crpytic for newcomers (it isn't really once you've
grasped the basics), but very powerful, without adding needless complexity;
much in contrast to jQuery.
Pointed"f y cn rd ths y mst hv bn sng nx :)"Ears
Jeremy J Starcher
> Pointed"f y cn rd ths y mst hv bn sng nx :)"Ears
If only it was that easy.
I can handle dropping all vowels, but I fear I'll never be able to spell
'umount' or 'creat' properly again.
Jeremy J Starcher
> Pointed"f y cn rd ths y mst hv bn sng nx :)"Ears
If only it was that easy.
David Mark
> On Jun 17, 6:44 pm, Tim Streater <timstrea...@waitrose.com> wrote:
>
> > In article
> > <7313e001-78c8-4b17-aa39-72e5a420e...@i28g2000yqa.googlegroups.com>,
> > Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > [stuff]
>
> > After all these posts, I'm none the wiser: what is the problem these
> > libraries are trying to solve?
>
> Ever since NN3/IE3 slash, so since it became important to care of more
> than one specific platform, the JavaScript libraries are solving these
> problem:
Huh?
>
> 1) Provide a reusable subroutines/interfaces for universally frequent
> tasks (client-side form pre-validation is the oldest one)
Virtually any blob of script is reusable and form validation is not
the primary focus of the "major" libraries.
> 2) To cover with a top level interface different and traditionally
> numerous native DOM interfaces discrepancies and bugs of different UA
> producers
And as the browser have converged, we are left with library
discrepancies and bugs of different library producers.
> (layer positioning and viewport size calculations among the
> oldest one).
LOL. They all botch viewport size.
http://www.cinsoft.net/viewport.asp
> 3) To add custom methods that was originally considered as non-needed
> one by specs producers (getElementsByClassName for a sample).
You sure don't need a library for that function. If you can't write
(and optimize) such a function in five minutes, a library isn't going
to help you.
> 4) To add a functionality that otherwise requires many ours of
> developments and some particular knowledge not universally presented
> even among experienced programmers (3D vector graphics and animated 3D
> object matrix transformations for SVG/VML for a sample).
Those are specialized "libraries", so off the current topic.
> 5) Rather new one and not so common: adjusting the top level
> programming paradigm to emulate some non-JavaScript paradigm with is
> more traditional for a given target audience (C/C++ class-like in
> Prototype.js for a sample).
And those are ill-advised of course.
John G Harris
wrote:
>Joe Nine wrote:
>> Does anyone have any links to very convincing articles that
>>eloquently state the major flaws of these libraries? I'm not
>>considering using any of them, I've heard enough here to know how bad
>>they are. I just want a few article links to keep in my back pocket
>>that I can fire back when someone suggests we use one of them.
>
>http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo-part-iii-why-
>it-rocks.html
He says :
"How good is qooxdoo at layout? When I popped open the Firebug debugger
in FireFox, where by default it begins by seizing application window
real estate, the qooxdoo layout engine handled the downsizing
impeccably, right down to adjusting scroll bars to accurately reflect
the new dimensions."
My javascript library, (that's mine, not My), does that with exactly 0
bytes of javascript ! Gee willikins, I'm a genius !
>That article is about a good library, but the first line has links to
>assessments of the three you mentioned.
Not in my browser, not after telling it to ignore the JS errors.
John
--
John Harris
Matt Kruse
> After all these posts, I'm none the wiser: what is the problem these
> libraries are trying to solve?
The goal of any library/framework/layer/abstraction is to simplify the
solution to one problem, so it can be used as a foundation for solving
a bigger problem.
Browser scripting can be complicated, marred by over a decade of
browser hacks, quirks, bugs, and non-compliant behavior. If a person
is required to understand, solve, and code for all these problems that
have been built up for years, they are unable to focus on bigger
problems.
Imagine if, every time we wanted to make an ajax call in js, we needed
to worry about browser threading, the OS we were on, the network
stack, handling tcp/ip correctly, handling dns, all the way down to
the ethernet layer. It would be an insurmountable problem. Thankfully,
all those layers have been abstracted away for us. We have just a few
concerns to deal with ajax, since we have to solve for a few different
browser conditions and quirks.
Along with all those layers of abstraction comes trade-offs.
Certainly, performance is reduced by each layer. There may be bugs and
quirks in each layer. Our ajax call may fail not because we coded the
js incorrectly, but because a DNS bug caused the lookup to fail. But
there is no way we would ever think of re-writing all these components
to be more technically correct. Even if we knew the faults and knew
how to code them better, it would not be practical. Accepting the
stack of layers under you - the good and the bad - allows you to focus
on higher-level problems.
Now, writing applications for the web has developed to a degree that
authors no longer want to deal with the lower-level problems of
javascript, browsers, the DOM, etc. They may want to just display an
in-page dialog that blocks the rest of the UI, for example. It seems
like a trivial task, but in reality it's a complex problem.
A library simplifies the problem, so instead of having to understand
and solve 100 scripting issues, they now just have to understand a few
API calls. And they can then afford to combine even more complicated
behavior together to create something that would have otherwise been
too complex to create.
Obviously, the library introduces a layer of complexity that comes
with its own problems. It may be less efficient, or may not work in
some browsers, or may have other issues. But these are the trade-offs
for having a large, unmanageable problem reduced to a smaller,
manageable one. Just as there are many trade-offs in the long stack of
abstractions between your js scripting environment and the bits in the
hardware that is driving it all.
Surely, it is up to the developer to decide whether a library is a
good layer of abstraction to introduce. If it solves a great number of
problems and allows them to focus on bigger issues, then that is good.
If it introduces new bugs or incompatibilities or problems, then it's
important for the user to be aware of exactly what they are
sacrificing, and to decide if it's worth it.
Some people are so attached to this specific technology - their ego so
caught up in understanding this layer better than anyone else - that
it's frustrating for them to see anyone "abstract away" their
knowledge. These people fear the day when the js layer is abstracted
away, because then their expertise is no longer needed. They can point
out the faults in specific libraries all day long, but they lack the
vision to see that _every_ layer eventually gets abstracted away. It's
how technology advances.
JS Libraries, as a way to abstract away the problems with browser
scripting, may not be the *best* solution. But it is one solution, and
it works very well for many people. I think it's great to argue for
different ways to abstract away the problem, and pick the option that
is best. But IMO, rejecting the abstraction altogether because of its
shortcomings is short-sighted. Web development will move on without
these detractors. Libraries will be used and improved, because people
don't want to have to deal with the whole nasty, confusing browser
scripting layer. They want it solved, at least to a degree that they
are comfortable with, and presented in a nicer, easier-to-use form.
That's what libraries like jQuery do, and that's why people so
overwhelmingly choose to use them.
Matt Kruse
Jeremy J Starcher
> The js that I'm currently working with most is
> http://BetterFacebook.net, which is a greasemonkey script/firefox add-on
> (which also works in Chrome, Safari, and Opera, I've heard) that adds a
> bunch of functionality to Facebook. It's a whole different kind of
> challenge, and it's refreshing to not have to deal with IE at all. :)
IE7Pro adds a UserScript option to various versions of IE ... and I've
got a "compatibility" option that renders the differences mostly
transparent.
Kenneth Tilton
> Kenneth Tilton wrote:
>> Joe Nine wrote:
>>> Does anyone have any links to very convincing articles that
>>> eloquently state the major flaws of these libraries? I'm not
>>> considering using any of them, I've heard enough here to know how bad
>>> they are. I just want a few article links to keep in my back pocket
>>> that I can fire back when someone suggests we use one of them.
>>
>> http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo-part-iii-why-it-rocks.html
>>
>> That article is about a good library, but the first line has links to
>> assessments of the three you mentioned.
>>
>> kt
>
> Thanks for the links. Somewhat wordy articles with way too much talk
> about Lisp.
Oh, right, I forgot about that bit. But the choice being made was
between JS libraries and I think you'll find that info in there.
> I thought Lisp went out of fashion in about 1959 (a year
> after it came in).
No, it did quite well until the DOD gave up on it ever doing AI, which
was smart. DOD 1980-ish?
> It's another one of those languages where I always
> wonder what it's useful for.
It's a general purpose language like any other, so you can use it for
anything.
> Back in college, I think Lisp was covered
> in just one day and the conclusion was that you'd never have to worry
> yourself about it, you won't likely see it again.
That was good albeit self-fulfilling advice.
> Why do people hang
> onto these obscure languages?
They offer things the popular languages do not.
Aren't you supposed to be shopping JS libraries? Have you looked at
ExtJS? But it's an offshoot of YUI, which is scary.
VK
These are what the libraries are (lesser some particular cases). I am
not clearly sure what point are you trying to make by your comments.
That libraries are not *necessary* for the programming to exist as
such? They are not necessary, it is a convenience tool in any
language.
Joe Nine
> Joe Nine wrote:
>> Kenneth Tilton wrote:
>>> Joe Nine wrote:
>>>> Does anyone have any links to very convincing articles that
>>>> eloquently state the major flaws of these libraries? I'm not
>>>> considering using any of them, I've heard enough here to know how
>>>> bad they are. I just want a few article links to keep in my back
>>>> pocket that I can fire back when someone suggests we use one of them.
>>>
>>> http://smuglispweeny.blogspot.com/2008/12/road-to-qooxdoo-part-iii-why-it-rocks.html
>>>
>>> That article is about a good library, but the first line has links to
>>> assessments of the three you mentioned.
>>>
>>> kt
>>
>> Thanks for the links. Somewhat wordy articles with way too much talk
>> about Lisp.
>> useful for.
>
> It's a general purpose language like any other, so you can use it for
> anything.
Can I download a compiler and use it to create .exe[cutable] files to
run on Windows? Can I use it to build web plugins? Can I embed it into
web pages? Can I use it to write an abstraction layer to display 3D
graphics? I don't think it can do any of these things although I could
be wrong.
>> Back in college, I think Lisp was covered in just one day and the
>> conclusion was that you'd never have to worry yourself about it, you
>> won't likely see it again.
>
> That was good albeit self-fulfilling advice.
>
>> Why do people hang onto these obscure languages?
>
> They offer things the popular languages do not.
Things that people want to do ?
> Aren't you supposed to be shopping JS libraries? Have you looked at
> ExtJS? But it's an offshoot of YUI, which is scary.
Actually quite the opposite. I don't want any JS libraries. They always
offer bloat no matter how well they're written. They always want to do
more than I need. I prefer to write my own code and when appropriate
re-use things I've written before (or someone else has shared on the
web). When I recently had to do some Ajax stuff, I found it a lot easier
writing my own 10-line function than learning how to use something like
jQuery.
Garrett Smith
> On Jun 16, 11:58 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>> On 6/16/2010 8:11 PM, David Mark wrote:
>>
>>
>>
>>
>>
>>> On Jun 16, 10:32 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>> On 6/16/2010 6:29 PM, David Mark wrote:
>>
>>>>> On Jun 16, 8:43 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>>>> On 6/16/2010 4:06 PM, David Mark wrote:
>>
>>>>>>> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>>>>>> On 6/16/2010 2:35 PM, David Mark wrote:
>>
>>>>>>>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> wrote:
>>>>>>>>>> Does anyone have any links to very convincing articles that eloquently
>>>>>>>>>> state the major flaws of these libraries? I'm not considering using any
>>>>>>>>>> of them, I've heard enough here to know how bad they are. I just want a
>>>>>>>>>> few article links to keep in my back pocket that I can fire back when
>>>>>>>>>> someone suggests we use one of them.
>>
>>
>>>>>>> I've done all of the hard work. You yourself were just parroting some
>>>>>>> of it recently.
>>
>>>>>> That is untrue.
>>
>>>>> History says otherwise.
>>
>>>>>> I've have never wanted to copy anything of yours.
>>
>>>>> Then I assume you've done so repeatedly at gunpoint.
>>
>>>> Lets be very clear on this: There is nothing of yours that I have
>>>> copied. Ever.
>>
>>> Let's be very clear. You have. Perhaps, for whatever reason, you
>>> don't even realize it.
>>
>>>> If you believe otherwise, then it's time for you to get very specific
>>>> with an example.
>>
>>> Haven't we been over *that* enough times? Start with your recent
>>> obsession with queries and attributes vis-a-vis jQuery.
>>
>> So let me get this straight: I reviewed code from jQuery. This bothers
>> you because you believe that I copied you.
>>
>> Did I get that right?
>
> No, it's one of your usual purposeful oversimplifications. You copied
No?
You wrote that I copied you by having "obsession with queries and
attributes". What exactly did I do?
http://www.google.com/search?q="attributes+vs+properties"+jquery
http://www.developersdex.com/asp/message.asp?p=2978&r=6837513
I certainly am not going to copy any of the things you wrote there.
> the one-off feature test from me too. See, I can generalize too!
> IIRC, your comment at the time (as you did this here in public) was
> that you were changing your whole library to use it as you previously
> just had flags. Go ahead, deny it. I'll dig that one up for
> sure. :)
>
One thing at a time. Back to your first point about jQuery.
Garrett
Garrett Smith
> Garrett Smith wrote:
>
>> I've looked for, but found no unit tests. If I'm going to use something,
>> I want to run tests on it to verify the edge cases.
>
> What's wrong with JsUnit?<http://www.jsunit.net/>
>
There aren't any JsUnit tests on cinsoft.net, so I assume you are asking
what I think of JsUnit in general.
From memory, last I used JsUnit (over 3 years), my complaints were:
* UI problems. Nested frame layout makes it hard to view source
* Doesn't scale well; large suites, such as those on w3.org, are a
runaway train that can't be stopped (the UI is really bad).
* poor stack trace functionality / reporting
* No dom abstraction layer for dispatching events
* No asynchronous testing features.
Garrett
VK
informational (for now) RFC like "JavaScript Web oriented library
design principles"
http://en.wikipedia.org/wiki/Request_for_Comments
So first state on public what is considered good, what is considered
bad and why. Because many of frequent posters in here are having their
own strong opinions on good and bad. Plus the prevailing dream in here
- as I may conclude - of all more-or-less known libraries disappeared
at once with their authors going to the programming hell :-) As
nothing of it will happen in any close perspective, it would be nice
to take some sufficiently respected document for the approach
principals. I would suggest the W3C letter that ended the 2nd Browser
Wars. It is a nice summary of reasons why W3C failed once again, so it
could be good to produce a RFC that would be of anyone interest
besides its clj authors.
HTML Design Principles
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/
The core point IMO would be:
Do not Reinvent the Wheel
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#do-not-reinvent-the-wheel
Evolution Not Revolution
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#evolution-not-revolution
Priority of Constituencies
http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#priority-of-constituencies
As a side note: no, $ identifier will never be expelled again for that
mysterious "machine generated code only" usage - and any of existing
library in use will not be rewritten to accommodate that ECMA-262
suggestion. That could be as a flag to see people able to any
reasonable compromises at all.
Gregor Kofler
> On Jun 17, 9:21 am, Kenneth Tilton<kentil...@gmail.com> wrote:
[qooxdoo rocks - as usual]
> In short, it's a bad library.
Hmm, do I see your softer side here? ;-)
A library which replaces and rebuilds all kind of (form) elements with
custom lookalikes (but not behavealikes) is crap. Axiomatically - no
matter whether the code is of utmost quality.
Gregor
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> I've looked for, but found no unit tests. If I'm going to use something,
>>> I want to run tests on it to verify the edge cases.
>> What's wrong with JsUnit?<http://www.jsunit.net/>
>
> There aren't any JsUnit tests on cinsoft.net, so I assume you are asking
> what I think of JsUnit in general.
Yes, I misunderstood what you were aiming at.
> From memory, last I used JsUnit (over 3 years), my complaints were:
The master branch at github was last updated 2010-02-18, the latest release
(2.2) was uploaded 2009-11-28. So it might be time for another review.
> * UI problems. Nested frame layout makes it hard to view source
That hasn't changed, but I do not consider it a problem in itself. I have a
source code editor to view and edit the source if it turns out to be
erroneous. What I have a problem with is that the test site of JsUnit 2.2
is apparently not scrollable in Firefox (so I need full screen), but that
could be remedied.
> * Doesn't scale well; large suites, such as those on w3.org, are a
> runaway train that can't be stopped (the UI is really bad).
There is a Stop button, so that appears to have changed in the meanwhile.
> * poor stack trace functionality / reporting
It can only be as good as what the ECMAScript implementation provides. I
think they are doing not bad there. I could even reuse their approach in
providing a stack trace along with my exceptions.
> * No dom abstraction layer for dispatching events
That appears to have changed.
> * No asynchronous testing features.
How do you propose that to be implemented?
Which alternatives to JsUnit are you recommending?
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Joe Nine
Admit it, you've been waiting for weeks for a thread where you can use
the word axiomatically :)
John G Harris
<snip>
>Do not Reinvent the Wheel
<snip>
Reasons for reinventing the wheel :
1 Because lorry tyres are too heavy for bicycles.
2 Because wire frame wheels are too fragile for lorries.
3 Because wire frame wheels were very right for aeroplanes in 1910 (see
any good museum) but no good for jumbo jets.
4 Because wheels are no use for mud; use tracks instead.
5 Because vehicle wheels are far too big and expensive for supermarket
trolleys.
In other words, "Do not Reinvent the Wheel" is more often than not a
substitute for thinking.
John
--
John Harris
VK
> Reasons for reinventing the wheel :
>
> 1 Because lorry tyres are too heavy for bicycles.
> 2 Because wire frame wheels are too fragile for lorries.
> 3 Because wire frame wheels were very right for aeroplanes in 1910 (see
> any good museum) but no good for jumbo jets.
> 4 Because wheels are no use for mud; use tracks instead.
> 5 Because vehicle wheels are far too big and expensive for supermarket
> trolleys.
>
> In other words, "Do not Reinvent the Wheel" is more often than not a
> substitute for thinking.
It is not what reinventing the wheel means in the context which should
be clear from the quotation as given. People don't need to sit on a
wheel for now on, but: people don't need to find another equiradial
shape just because the wheel is already taken.
Kenneth Tilton
Aside from the stuff that requires browser support*, yes, you could be
wrong. Of course you might not be aware that Lisp can call C and be
called back from C.
* If you don't think you are doing Lisp when you are doing JS, you could
be wrong again.
>
>>> Back in college, I think Lisp was covered in just one day and the
>>> conclusion was that you'd never have to worry yourself about it, you
>>> won't likely see it again.
>>
>> That was good albeit self-fulfilling advice.
>>
>>> Why do people hang onto these obscure languages?
>>
>> They offer things the popular languages do not.
>
> Things that people want to do ?
>
>> Aren't you supposed to be shopping JS libraries? Have you looked at
>> ExtJS? But it's an offshoot of YUI, which is scary.
>
> Actually quite the opposite. I don't want any JS libraries. They always
> offer bloat no matter how well they're written. They always want to do
> more than I need. I prefer to write my own code and when appropriate
> re-use things I've written before (or someone else has shared on the
> web). When I recently had to do some Ajax stuff, I found it a lot easier
> writing my own 10-line function than learning how to use something like
> jQuery.
I too like to roll my own wherever possible.
VK
> Aside from the stuff that requires browser support*, yes, you could be
> wrong. Of course you might not be aware that Lisp can call C and be
> called back from C.
In my career I had to extend and to adjust some AutoLISP for AutoCAD
http://en.wikipedia.org/wiki/AutoLISP
and I dare to tell that I never had anything more contre-OOP and
contre-instinctive ever since Sinclair Basic
http://en.wikipedia.org/wiki/Sinclair_BASIC
or *even* before it: but again I might be missing the appropriate mind
set - still my first aim was out to the VBA higher level asap and
where to solve the posed problems. Again, it is a purely personal
experience.
Gregor Kofler
Indeed. Glad it finally happened.
Garrett Smith
> Garrett Smith wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Garrett Smith wrote:
>>>> I've looked for, but found no unit tests. If I'm going to use something,
>>>> I want to run tests on it to verify the edge cases.
>>> What's wrong with JsUnit?<http://www.jsunit.net/>
>>
>> There aren't any JsUnit tests on cinsoft.net, so I assume you are asking
>> what I think of JsUnit in general.
>
> Yes, I misunderstood what you were aiming at.
>
>> From memory, last I used JsUnit (over 3 years), my complaints were:
>
> The master branch at github was last updated 2010-02-18, the latest release
> (2.2) was uploaded 2009-11-28. So it might be time for another review.
>
>> * UI problems. Nested frame layout makes it hard to view source
>
> That hasn't changed, but I do not consider it a problem in itself. I have a
> source code editor to view and edit the source if it turns out to be
> erroneous. What I have a problem with is that the test site of JsUnit 2.2
> is apparently not scrollable in Firefox (so I need full screen), but that
> could be remedied.
>
>> * Doesn't scale well; large suites, such as those on w3.org, are a
>> runaway train that can't be stopped (the UI is really bad).
>
> There is a Stop button, so that appears to have changed in the meanwhile.
>
That actually sounds familiar. However, I do not recall useful stop
functionality.
>> * poor stack trace functionality / reporting
>
> It can only be as good as what the ECMAScript implementation provides. I
> think they are doing not bad there. I could even reuse their approach in
> providing a stack trace along with my exceptions.
>
>> * No dom abstraction layer for dispatching events
>
> That appears to have changed.
>
>> * No asynchronous testing features.
>
> How do you propose that to be implemented?
>
wait and waitForCondition can each use setTimeout.
The test that fires oncomplete when all deferred segments are done and
to know when that happens, it subscribes to the "oncomplete" of each
segment.
This means that tests may complete out of order.
A test is part of a tree structure and has a testableList of deferred
segments (possibly 0 length). A deferred segment is also a Test and when
a deferred segment calls wait, then the deferred segment gets an item in
its testableList; it won't fire oncomplete until is not done.
TestRunner is the root node of the tree. TestRunner can have tests and
suites, but the caller doesn't actually have to create formal
structures, the caller can just add things to the TestRunner.
I explained a little recently in MessageID:
hv3v71$km$1...@news.eternal-september.org
It's a little sloppy right now; I've got some rough spots in it.
> Which alternatives to JsUnit are you recommending?
The most relevant I found at the time I was searching was YUI Test
I've run into too many problems with that. Starting with the author
takes a long time to fix bugs (1 year+). Getting free contributions
accepted to YUI requires you to sign legal documentation that I don't
want to sign.
I have had to patch many things in it, such as relatedTarget not working
properly. The source code shows the problems in code comments and the
author shows how he did not solve them.
/*
* Check to see if relatedTarget has been assigned. Firefox
* versions less than 2.0 don't allow it to be assigned via
* initMouseEvent() and the property is readonly after event
* creation, so in order to keep YAHOO.util.getRelatedTarget()
* working, assign to the IE proprietary toElement property
* for mouseout event and fromElement property for mouseover
* event.
*/
if (relatedTarget && !customEvent.relatedTarget){
if (type == "mouseout"){
customEvent.toElement = relatedTarget;
} else if (type == "mouseover"){
customEvent.fromElement = relatedTarget;
}
}
You can see the test function is tied to the code that is being tested.
The author's comment "in order to keep YAHOO.util.getRelatedTarget()
working, assign to the IE proprietary toElement property"
Mentioning problems to the author is a waste of time; he just either
ignores email or won't fix the bugs.
http://sourceforge.net/tracker/?func=detail&atid=836476&aid=1889966&group_id=165715
Got fixed. Other bugs that didn't were the event simulation req for
Apple Touch Events. I submitted a patch and the reply I got was "please
sign these legal documents so we can use your code for free.". Wow, what
a great way to show appreciation. No thanks, I'll just patch where I
need to and forget about submitting bugs in the future.
The debugging issues in YUI Test are painful. Each dispatched event
calls a very long function -- around one hundred statements or so.
This is a problem when you want to step from dispatching the event
through to the callback.
Given an element "myTargetObject" with a mousedown event handler, the
following test would dispatch that event and then afterwords, the
condition of `a` could be checked. Synth events are not always the same,
so sometimes you want to step into with debugger to see what actually
happens. For example:
testMyEvent : function() {
debugger; // Click 'step over' 47 times after this
Action.mousedown(myTargetObject);
Assert.isTrue(myTargetObject.a, msg);
}
After explaining to the author how to refactor that, he brushed off the
possibility and claimed that the functions must be long and then ignored
all subsequent emails. So again, I wasted time to try to help but got no
appreciation for it. I get the sense that it is more of a public image
type of thing with the author.
I also found that focus and blur events were not implemented, but needed
to be for some cases; that is: Where `focus()` on particular object
would not work for that given case. I can't remember why, maybe it had
to do with onfocusin -- I forgot. I added support for focus and blur
events (which also fire onfocusin and onfocusout).
Other frustrations are the inability to rerun just one particular test
function.
In 2007, I found that YUI Test was attractive. The limitations have
become so burdensome that it is time to move on.
Garrett
Kenneth Tilton
> On Jun 18, 12:38 am, Kenneth Tilton <kentil...@gmail.com> wrote:
>> Aside from the stuff that requires browser support*, yes, you could be
>> wrong. Of course you might not be aware that Lisp can call C and be
>> called back from C.
>
> In my career I had to extend and to adjust some AutoLISP for AutoCAD
> http://en.wikipedia.org/wiki/AutoLISP
What has an AutoCAD embedded language got to do with Lisp?
Please do not answer "the sequence l, i, s, and p.". Hint.
> and I dare to tell that I never had anything more contre-OOP and
> contre-instinctive ever since Sinclair Basic
> http://en.wikipedia.org/wiki/Sinclair_BASIC
> or *even* before it: but again I might be missing the appropriate mind
> set - still my first aim was out to the VBA higher level asap and
> where to solve the posed problems. Again, it is a purely personal
> experience.
Of AutoCAD. Of Lisp you know nothing.
hth, kt
Stefan Weiss
> I submitted a patch and the reply I got was "please
> sign these legal documents so we can use your code for free.". Wow, what
> a great way to show appreciation. No thanks, I'll just patch where I
> need to and forget about submitting bugs in the future.
I don't think it's unreasonable to require patch submitters to waive
their rights to the code. Many of the larger open source projects have
similar policies. They exist to protect the company from malicious
contributors, and from those who change their minds later on. Without
this procedure, you could for example submit someone else's code to the
project, wait until it has been distributed, and then sue or blackmail
them. It also gives Yahoo! the option to change or update the license
later one without having to get approval from each and every
contributor. The Linux kernel is in that situation - the kernel
maintainers couldn't change the license from GPL2 to GPL3 (even if there
was a consensus to do so among the maintainers).
Having a dedicated upload form for patches with a checkbox to that
effect may not be enough; to be legally safe, they'd need to be
reasonably sure of your identity. Smaller projects may opt for a simpler
procedure or just ignore the possible legal consequences, but Yahoo! is
a high profile company with a significant investment in this library.
Imagine that there was a rival company - let's call it "Mondosoft" -
trying to acquire Yahoo!. They could just smuggle in some of their code
bits at a time, and then use scare tactics like "YUI violates 235 of
Mondosoft's patents". It would make for good ammunition in their next
acquisition attempt.
That said, I was in a similar situation as you, twice. Both times I
decided it wasn't worth the hassle to sign and send back their
documents, and in the end didn't submit the patches. So yes, I agree
that the legal safeguards can be a huge motivational hurdle for
potential submitters.
--
stefan
Garrett Smith
> On 18/06/10 01:43, Garrett Smith wrote:
>
> That said, I was in a similar situation as you, twice. Both times I
> decided it wasn't worth the hassle to sign and send back their
> documents, and in the end didn't submit the patches. So yes, I agree
> that the legal safeguards can be a huge motivational hurdle for
> potential submitters.
>
It's not just that. I'm trying to help - FOR FREE - and don't want to be
asked to go through the extra effort to sign legal obstacles to satisfy
some corporate lawyers.
The author can copy the code I wrote, and change it as I suggested, and,
for extra-credit, try and improve on it.
http://yuilibrary.com/projects/yui2/ticket/2528514
Opened last September and I'll bet you that uneaten kipferl that it'll
sit there for at least another 5 months.
This one has been in cue for two years!
http://yuilibrary.com/projects/yui2/ticket/1924108
(yes I'm the reporter there, too).
It might seem like I've got beef with the author -- well, in addition to
the unfixed bugs, ignored emails, yes, I do.
I'm going to make a post about that.
Garrett
Bwig Zomberi
> Bwig Zomberi wrote:
>> Joe Nine wrote:
>>> I've seen enough examples of code that's using jQuery on here to know
>>> that I don't want to become a jQuery programmer - it's like it's own new
>>> language with an ugly perl-like syntax. I guess it's one for the
>>> programmers that prefer unix. I'm a windows guy myself and like "classic
>>> syntax" languages. I guess that's why I've never got into complex
>>> regular expressions either.
>>
>> Javascript syntax is based on C or Java if you like.
>
> I know. I imagine everyone here does.
>
>> C was first written for Unix, which was written for the most part in C.
>
> I learned that in class too. I don't see the relevance to anything though.
>
>> jQuery is born ugly. Unix played no part in its birth or parenting.
>
> I doubt anyone thinks it has any relation to unix.
Good to know that you know. Then why imply Unix/Linux users should be
the ones to like jQuery, when those guys would mostly prefer C or C-like
languages. Classic syntax is a mainstay of many Unix-origin languages -
it is not a Windows-only trait. Difficult syntax is not alien to Windows
- Hungarian notation used in VC++ for example.
--
Bwig Zomberi
Bwig Zomberi
> In article
> <7313e001-78c8-4b17...@i28g2000yqa.googlegroups.com>,
> Matt Kruse<ma...@thekrusefamily.com> wrote:
>
> [stuff]
>
> After all these posts, I'm none the wiser: what is the problem these
> libraries are trying to solve?
>
A single and smaller codebase for users to implement special effects if
sites like Smashing Magazine are to be believed. The libraries are
expected to do the heavy lifting and fix browser issues.
Libraries also seem to provide shorthand for JavaScript. I never got
tired of using document.getElementById or DOM array parsing. In fact, I
feel safe with it.
--
Bwig Zomberi
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Garrett Smith wrote:
>>>>> I've looked for, but found no unit tests. If I'm going to use
>>>>> something, I want to run tests on it to verify the edge cases.
>>>> What's wrong with JsUnit?<http://www.jsunit.net/>
>>> [...]
>>> * No asynchronous testing features.
>> How do you propose that to be implemented?
>
> wait and waitForCondition can each use setTimeout.
> [...]
> I explained a little recently in MessageID:
> hv3v71$km$1...@news.eternal-september.org
Thanks.
>> Which alternatives to JsUnit are you recommending?
>
> The most relevant I found at the time I was searching was YUI Test
>
> I've run into too many problems with that. [...]
> In 2007, I found that YUI Test was attractive. The limitations have
> become so burdensome that it is time to move on.
This reads to me as if you are saying that you do not like several aspects
of JsUnit, but you do not know anything that is better. Would it not be a
good idea to help improve JsUnit then?
Please trim your quotes to the relevant minimum.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Thomas 'PointedEars' Lahn
> Matt Kruse wrote:
>> Tim Streater wrote:
>> > After all these posts, I'm none the wiser: what is the problem these
>> > libraries are trying to solve?
>>
>> The goal of any library/framework/layer/abstraction is to simplify the
>> solution to one problem, so it can be used as a foundation for solving
>> a bigger problem.
>
> [snip]
>
>> JS Libraries, as a way to abstract away the problems with browser
>> scripting, may not be the *best* solution. But it is one solution, and
>> it works very well for many people. I think it's great to argue for
>> different ways to abstract away the problem, and pick the option that
>> is best. But IMO, rejecting the abstraction altogether because of its
>> shortcomings is short-sighted. Web development will move on without
>> these detractors. Libraries will be used and improved, because people
>> don't want to have to deal with the whole nasty, confusing browser
>> scripting layer. They want it solved, at least to a degree that they
>> are comfortable with, and presented in a nicer, easier-to-use form.
>> That's what libraries like jQuery do, and that's why people so
>> overwhelmingly choose to use them.
>
> Mmm, thanks. The concept is clear, I'm not sure whether I buy the
> argument.
Add me. Matt is still not getting that (JS) libraries as a concept are not
the issue, but the people writing them.
If those are clueful, experienced individuals, the library can grow
naturally from practice, evolutional from the general case to the special
one so that one reliable abstraction layer is placed upon another *when
necessary*, and it can become useful for both a single project and several
projects, both for the original authors and other people.
If instead the individual or group of authors are actually clueless
newcomers in the field and/or people with delusions of grandeur, who like to
present themselves as gurus, ninjas, and the like to begin with, the library
they will be writing will end up being bloated, unmaintainable code that
attempts to solve problems that did not need a solution in the first place.
It must fail badly at doing so, and it will create more problems than it
claims to solve. It only takes a few equally unexperienced and naive people
to use it and, from superficial testing, advocate using it to other equally
unexperienced/naive people for it to become a hype, even a cult, then. The
evidence for this can hardly be ignored.
> I've had a brief look at JScript, looks harder than JavaScript to me.
How so? You are involuntarily writing JScript if you are writing
"JavaScript"/"Javascript"/"javascript" for IE/MSHTML, so it can't
be that hard to do.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Matt Kruse
wrote:
> Matt is still not getting that (JS) libraries as a concept are not
> the issue, but the people writing them.
Umm, that's not at all what the mantra has been in here for years.
Over and over and over it has been said by many that general-purpose
javascript libraries are a bad idea.
My point has always been that general-purpose js libraries are a
_must_, and if the people with the skill to write them correctly don't
do so, then someone else will. And other people have. jQuery has lots
of problems. The coding of it and its design and the way the authors
attack problems are all quite poor. But it fills a need.
Even when someone like DM comes along and writes "His Library", he's
missing the point. He may get the technical aspects more correct, but
he lacks the vision and social grace required to make the library
actually useful to most developers. It's like he's created a better
mousetrap, but completely drops the ball on manufacturing, marketing,
and distribution. Whereas something like jQuery suffers from poor
quality, but gets the other stuff right.
Turn on any infomercial and see how ridiculous the product is, yet see
how many people buy it and how rich the creators are. It doesn't
matter how great of a product you create if you can't get it out to
the masses! And if the masses are creating terrible web sites full of
broken script, and this is the problem that DM is trying to address,
then he's doing it wrong. Even though it seems to drive DM crazy, the
truth is that John Resig is a much better salesman, and his product is
beating the pants of DM's "higher quality" product.
I still believe that the way to combat jQuery and to help fix all the
junk that it has spewed on the web is to create a library with a
compatible subset of the jQuery API, and implement it correctly. Then
people can switch over to it easily and comfortably, and get the
benefit of more robust code.
Matt Kruse
Matt Kruse
> To me, JavaScript is a simple enough language that I have no
> problems using it.
Perhaps you just haven't been exposed to all the cross-browser issues
yet? There are tons of quirks, bugs, non-standard behaviors, etc that
you must deal with if you write cross-browser scripts for the web,
where just about any browser may be used.
> But then I'm a programmer.
Aren't most of us here? I've been using javascript since the day it
was released to the public. It still frustrates me sometimes. The
browser implementations, at least. Not so much the language itself.
> I've had a brief look at JScript, looks harder than JavaScript to me.
Hmmm, I'm not sure what this statement really means.
Matt Kruse
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Matt is still not getting that (JS) libraries as a concept are not
>> the issue, but the people writing them.
>
> Umm, that's not at all what the mantra has been in here for years.
> [...]
Yes, it has, and it has been pointed out to you before, even in this thread.
Unfortunately, you have not been paying attention.
HTH
Thomas 'PointedEars' Lahn
> Tim Streater wrote:
>> To me, JavaScript is a simple enough language that I have no
>> problems using it.
>
> Perhaps you just haven't been exposed to all the cross-browser issues
> yet? There are tons of quirks, bugs, non-standard behaviors, etc that
> you must deal with if you write cross-browser scripts for the web,
> where just about any browser may be used.
Cross-browser issues have nothing to do with the programming language.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
Matt Kruse
wrote:
> Matt Kruse wrote:
> > Perhaps you just haven't been exposed to all the cross-browser issues
> > yet? There are tons of quirks, bugs, non-standard behaviors, etc that
> > you must deal with if you write cross-browser scripts for the web,
> > where just about any browser may be used.
> Cross-browser issues have nothing to do with the programming language.
Duh. But the discussion is about general-purpose libraries, whose main
purpose is to smooth over cross-browser issues and add functionality
for web scripting.
Matt Kruse
Johannes Baagoe
> Matt is still not getting that (JS) libraries as a concept are not the
> issue, but the people writing them.
That, exactly, is what bothers me in those discussions : the issue seems
to be *the people* writing those libraries. Technical objections alone
would hardly justify personal smears.
--
Johannes
Thomas 'PointedEars' Lahn
This has (as for me) nothing to do with personal smears. Source code is
written by people, and their knowledge, experience, and personalities define
the quality of the code they can produce. For example, you cannot
reasonably deny that if John Resig's delusions of grandeur would not get in
the way, if he would consider reading peer reviews, in time he could be
writing better code.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Matt Kruse wrote:
>> > Perhaps you just haven't been exposed to all the cross-browser issues
>> > yet? There are tons of quirks, bugs, non-standard behaviors, etc that
>> > you must deal with if you write cross-browser scripts for the web,
>> > where just about any browser may be used.
>> Cross-browser issues have nothing to do with the programming language.
>
> Duh. But the discussion is about general-purpose libraries, whose main
> purpose is to smooth over cross-browser issues and add functionality
> for web scripting.
You have destroyed the context. Duh!
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
Johannes Baagoe
> This has (as for me) nothing to do with personal smears. [...]
> John Resig's delusions of grandeur [...]
I rest my case.
--
Johannes
Thomas 'PointedEars' Lahn
You have no case; you are disregarding the available evidence.
Garrett Smith
> On Jun 18, 7:37 am, Thomas 'PointedEars' Lahn<PointedE...@web.de>
> wrote:
[...]
> I still believe that the way to combat jQuery and to help fix all the
> junk that it has spewed on the web is to create a library with a
> compatible subset of the jQuery API, and implement it correctly. Then
> people can switch over to it easily and comfortably, and get the
> benefit of more robust code.
>
You missed my outline post?
Please see:
MessageID: hvbr3g$q0e$1...@news.eternal-september.org
I'm going to wager you've not even started on following your own advice.
If you had, you probably would have realized that the design of jQuery
has fundamental problems (please see my earlier message).
Why do you think jQuery has had so many issues with upgrades?
Before reimplementing jQuery correctly, you'll first need to define what
"correctly" means.
Documentation for the selectors are a good starting point.
Let us know how far you get with that.
Garrett
Thomas 'PointedEars' Lahn
> Please see:
> MessageID: hvbr3g$q0e$1...@news.eternal-september.org
Please use `news:' URIs as specified in RFC 5538น to refer to postings, here
<news:hvbr3g$q0e$1...@news.eternal-september.org>
so that the posting being referred to can be viewed easily with the majority
of newsreaders.
TIA
PointedEars
___________
น <http://tools.ietf.org/html/rfc5538>
John G Harris
>On Jun 17, 11:27�pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>> Reasons for reinventing the wheel :
>>
>> 1 Because lorry tyres are too heavy for bicycles.
>> 2 Because wire frame wheels are too fragile for lorries.
>> 3 Because wire frame wheels were very right for aeroplanes in 1910 (see
>> any good museum) but no good for jumbo jets.
>> 4 Because wheels are no use for mud; use tracks instead.
>> 5 Because vehicle wheels are far too big and expensive for supermarket
>> trolleys.
>>
>> In other words, "Do not Reinvent the Wheel" is more often than not a
>> substitute for thinking.
>
>It is not what reinventing the wheel means in the context which should
>be clear from the quotation as given. People don't need to sit on a
>wheel for now on, but: people don't need to find another equiradial
>shape just because the wheel is already taken.
According to your definition the inventors of JQuery were reinventing
the wheel, so JQuery should be thrown away.
John
--
John Harris
Matt Kruse
> On 6/18/2010 7:12 AM, Matt Kruse wrote:
> > I still believe that the way to combat jQuery and to help fix all the
> > junk that it has spewed on the web is to create a library with a
> > compatible subset of the jQuery API, and implement it correctly. Then
> > people can switch over to it easily and comfortably, and get the
> > benefit of more robust code.
> You missed my outline post?
> Please see:
I don't see the relevance.
> I'm going to wager you've not even started on following your own advice.
I looked into it at one point. That's what http://MyJQuery.com (which
I own) was going to be. The problem was time and desire on my part.
> If you had, you probably would have realized that the design of jQuery
> has fundamental problems (please see my earlier message).
Obviously. That's why you would change the design. The API would be
changed to not allow so much overloading. Just keep the stuff that is
most common/useful. You would have a reduced set of jQuery
functionality, but it would be robust. It would be sane.
> Why do you think jQuery has had so many issues with upgrades?
Primarily, because the jQuery team doesn't care much about backwards-
compatibility.
> Before reimplementing jQuery correctly, you'll first need to define what
> "correctly" means.
To some degree, yes. But you could begin and define as you go.
> Documentation for the selectors are a good starting point.
Sure, that would be fine. If I were to re-write jQuery, I would keep
Sizzle as-is, even with bugs, and just document the things that won't
work correctly. They are fairly minor, IMO.
> Let us know how far you get with that.
I have no intention of doing so. And thus, the problem. The people
with the skill needed to make a great product rarely have the time or
desire to do so. The less experienced have time, patience, and a lack
of things to work on, and a desire for significance and "fame", and
therefore starting writing the next monolithic library, and it becomes
popular because they have the time to support, market, and evangelize
it. *shrugs*
Matt Kruse
S.T.
> wrote:
>> Matt is still not getting that (JS) libraries as a concept are not
>> the issue, but the people writing them.
>
> Umm, that's not at all what the mantra has been in here for years.
> Over and over and over it has been said by many that general-purpose
> javascript libraries are a bad idea.
>
> My point has always been that general-purpose js libraries are a
> _must_, and if the people with the skill to write them correctly don't
> do so, then someone else will. And other people have. jQuery has lots
> of problems. The coding of it and its design and the way the authors
> attack problems are all quite poor. But it fills a need.
Exactly.
The fact that most CLJ regulars (the vocal ones, at least) can't
comprehend why there's such demand for libraries is the same reason
their critiques of libraries are technically accurate yet largely
ignored. They can't see in context, nor anything less rigid than a
true/false view.
> Even when someone like DM comes along and writes "His Library", he's
> missing the point. He may get the technical aspects more correct, but
> he lacks the vision and social grace required to make the library
> actually useful to most developers. It's like he's created a better
> mousetrap, but completely drops the ball on manufacturing, marketing,
> and distribution. Whereas something like jQuery suffers from poor
> quality, but gets the other stuff right.
DM's script may be solid but the project as a whole is a train wreck. It
wasn't a project developed to solve a problem, rather was a script
written in an attempt to mock other libraries. It was DOA before it saw
daylight.
> Turn on any infomercial and see how ridiculous the product is, yet see
> how many people buy it and how rich the creators are. It doesn't
> matter how great of a product you create if you can't get it out to
> the masses! And if the masses are creating terrible web sites full of
> broken script, and this is the problem that DM is trying to address,
> then he's doing it wrong. Even though it seems to drive DM crazy, the
> truth is that John Resig is a much better salesman, and his product is
> beating the pants of DM's "higher quality" product.
>
> I still believe that the way to combat jQuery and to help fix all the
> junk that it has spewed on the web is to create a library with a
> compatible subset of the jQuery API, and implement it correctly. Then
> people can switch over to it easily and comfortably, and get the
> benefit of more robust code.
You are in a small subset of developers that use jQuery by choice, yet
are also highly critical of it. In fact you might be the only person
I've read that shares those characteristics. Not that there's anything
wrong with that, just a somewhat unique view.
The bulk of jQuery users seem perfectly content with it and the pace of
fixes. Even those who recognize there are some shortcomings (like me)
find the outstanding issues borderline trivial. To "combat jQuery" you'd
need to write a better alternative and convince the user base it's
better. The former is likely far easier than the latter.
I don't think there's a need to 'combat' jQuery and the other libraries.
They will fade away on their own eventually. The major browsers are
*finally* headed in the right direction with standardization. As the
average user's browser improves jQuery's merits will diminish, as will
its usage. When jQuery stops solving a problem, people will stop using
it. A few years, I'd guess.
Off topic, but looks as though jQuery's looking to ease cross-mobile
browser issues next. Mobile remains of little interest to me but should
be interesting to watch their approach.
http://www.flickr.com/photos/jeresig/sets/72157624180070911/
Andrew Poulos
> On 6/18/2010 7:12 AM, Matt Kruse wrote:
>> On Jun 18, 7:37 am, Thomas 'PointedEars' Lahn<PointedE...@web.de>
>> wrote:
>>> Matt is still not getting that (JS) libraries as a concept are not
>>> the issue, but the people writing them.
>>
>> Umm, that's not at all what the mantra has been in here for years.
>> Over and over and over it has been said by many that general-purpose
>> javascript libraries are a bad idea.
>>
>> My point has always been that general-purpose js libraries are a
>> _must_, and if the people with the skill to write them correctly don't
>> do so, then someone else will. And other people have. jQuery has lots
>> of problems. The coding of it and its design and the way the authors
>> attack problems are all quite poor. But it fills a need.
>
> Exactly.
Exactly wrong.
> The fact that most CLJ regulars (the vocal ones, at least) can't
> comprehend why there's such demand for libraries is the same reason
> their critiques of libraries are technically accurate yet largely
> ignored. They can't see in context, nor anything less rigid than a
> true/false view.
There's only a demand because people take on javascript projects that
are beyond their skill level.
>> Even when someone like DM comes along and writes "His Library", he's
>> missing the point. He may get the technical aspects more correct, but
>> he lacks the vision and social grace required to make the library
>> actually useful to most developers. It's like he's created a better
>> mousetrap, but completely drops the ball on manufacturing, marketing,
>> and distribution. Whereas something like jQuery suffers from poor
>> quality, but gets the other stuff right.
>
> DM's script may be solid but the project as a whole is a train wreck. It
> wasn't a project developed to solve a problem, rather was a script
> written in an attempt to mock other libraries. It was DOA before it saw
> daylight.
DM's library has had little objective criticism and to call it DOA when
its usage is clearly growing shows how much you know about it.
Why don't you just admit that you have stopped trying to discredit DM as
a person and are now trying to discredit his library both of which you
apparently know little about.
>> Turn on any infomercial and see how ridiculous the product is, yet see
>> how many people buy it and how rich the creators are. It doesn't
>> matter how great of a product you create if you can't get it out to
>> the masses! And if the masses are creating terrible web sites full of
>> broken script, and this is the problem that DM is trying to address,
>> then he's doing it wrong. Even though it seems to drive DM crazy, the
>> truth is that John Resig is a much better salesman, and his product is
>> beating the pants of DM's "higher quality" product.
First you state that the number or users is inversely proportional to
the quality of the product then you state that jQuery is used by a very
much larger number of people. And this, you seem to believe, is a reason
for the rest of us non-believers to use jQuery as well.
>> I still believe that the way to combat jQuery and to help fix all the
>> junk that it has spewed on the web is to create a library with a
>> compatible subset of the jQuery API, and implement it correctly. Then
>> people can switch over to it easily and comfortably, and get the
>> benefit of more robust code.
>
> You are in a small subset of developers that use jQuery by choice, yet
> are also highly critical of it. In fact you might be the only person
> I've read that shares those characteristics. Not that there's anything
> wrong with that, just a somewhat unique view.
>
> The bulk of jQuery users seem perfectly content with it and the pace of
> fixes. Even those who recognize there are some shortcomings (like me)
> find the outstanding issues borderline trivial. To "combat jQuery" you'd
> need to write a better alternative and convince the user base it's
> better. The former is likely far easier than the latter.
To "combat jQuery" managers need to hire developers who are skilled in
JavaScript.
> I don't think there's a need to 'combat' jQuery and the other libraries.
> They will fade away on their own eventually. The major browsers are
> *finally* headed in the right direction with standardization. As the
> average user's browser improves jQuery's merits will diminish, as will
> its usage. When jQuery stops solving a problem, people will stop using
> it. A few years, I'd guess.
Sorry, what direction is the "right direction". Standardising on H.264
for video or an open source codec?
> Off topic, but looks as though jQuery's looking to ease cross-mobile
> browser issues next. Mobile remains of little interest to me but should
> be interesting to watch their approach.
>
> http://www.flickr.com/photos/jeresig/sets/72157624180070911/
Test on a number of devices then claim it works almost everywhere.
Andrew Poulos
Scott Sauyet
> [in response to Matt Kruse]
> You are in a small subset of developers that use jQuery by choice, yet
> are also highly critical of it. In fact you might be the only person
> I've read that shares those characteristics. Not that there's anything
> wrong with that, just a somewhat unique view.
You can put me in that category as well. I find that JQuery often
simplifies my development, but I recognize many flaws in it and would
love to see something more solid come along to take it's place. But
those need to be libraries that I would feel comfortable handing off
to a client to continue with, which leaves out, for instance, My
Library.
At the moment, JQuery seems the best of a fairly bad bunch. But I
really don't want to skip a library altogether. Yes, I trust my own
skills enough to believe I could do everything that's done in those
libraries, but I really don't want to spend the time. And I don't
think it's *that* bad.
-- Scott
Garrett Smith
> On Jun 18, 12:34 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>> On 6/18/2010 7:12 AM, Matt Kruse wrote:
>>> I still believe that the way to combat jQuery and to help fix all the
>>> junk that it has spewed on the web is to create a library with a
>>> compatible subset of the jQuery API, and implement it correctly. Then
>>> people can switch over to it easily and comfortably, and get the
>>> benefit of more robust code.
>> You missed my outline post?
>> Please see:
>> MessageID: hvbr3g$q0...@news.eternal-september.org
>
> I don't see the relevance.
>
It seems like you believe that there are technical problems that ccan be
fixed and do not agree that the problems with jQuery come from the
initial API design. That's what my other post was getting at.
[...]
>
>> Why do you think jQuery has had so many issues with upgrades?
>
> Primarily, because the jQuery team doesn't care much about backwards-
> compatibility.
>
OK. I believe that complexity and loosely defined methods were reasons.
>> Before reimplementing jQuery correctly, you'll first need to define what
>> "correctly" means.
>
> To some degree, yes. But you could begin and define as you go.
>
Sure, if you realized previously unforeseen problems and complexity in
the process.
>> Documentation for the selectors are a good starting point.
>
> Sure, that would be fine. If I were to re-write jQuery, I would keep
> Sizzle as-is, even with bugs, and just document the things that won't
> work correctly. They are fairly minor, IMO.
>
How much have you looked into it?
>> Let us know how far you get with that.
>
> I have no intention of doing so. And thus, the problem. The people
> with the skill needed to make a great product rarely have the time or
> desire to do so. The less experienced have time, patience, and a lack
> of things to work on, and a desire for significance and "fame", and
> therefore starting writing the next monolithic library, and it becomes
> popular because they have the time to support, market, and evangelize
> it. *shrugs*
Well, time yes, but desire, too. What good is a large user base?
Garrett
Andrew Poulos
Make up your mind is it "fairly bad" or not "that bad".
Andrew Poulos
S.T.
>> The fact that most CLJ regulars (the vocal ones, at least) can't
>> comprehend why there's such demand for libraries is the same reason
>> their critiques of libraries are technically accurate yet largely
>> ignored. They can't see in context, nor anything less rigid than a
>> true/false view.
>
> There's only a demand because people take on javascript projects that
> are beyond their skill level.
This is always what I suspected a portion of the animosity was based on.
A fear that opening up DOM manipulation and AJAX to the masses cheapens
a particular skill set.
>>> Even when someone like DM comes along and writes "His Library", he's
>>> missing the point. He may get the technical aspects more correct, but
>>> he lacks the vision and social grace required to make the library
>>> actually useful to most developers. It's like he's created a better
>>> mousetrap, but completely drops the ball on manufacturing, marketing,
>>> and distribution. Whereas something like jQuery suffers from poor
>>> quality, but gets the other stuff right.
>>
>> DM's script may be solid but the project as a whole is a train wreck. It
>> wasn't a project developed to solve a problem, rather was a script
>> written in an attempt to mock other libraries. It was DOA before it saw
>> daylight.
>
> DM's library has had little objective criticism and to call it DOA when
> its usage is clearly growing shows how much you know about it.
Huh? What indicators show its "clearly growing"? Aside from David's 14
posts, mostly replying to himself, the "support group" shows five posts
from two authors so far this month. Not exactly a booming community.
I've never actually *seen* 'My Library' in use on a live site. Have you?
Tough to gauge growth rates when the benchmarks hold steady at zero.
Until something suggests otherwise I'll stand by my conclusion the
project is dead, and always was dead, as the result of largely
non-technical factors.
> Why don't you just admit that you have stopped trying to discredit DM as
> a person and are now trying to discredit his library both of which you
> apparently know little about.
I know David Mark's online persona is that of an asshat. That's about
all I know about DM. Maybe he's a stand-up rational guy in the real
world. I have no idea.
If you think there's something more involved here, like I'm in the midst
of a several-year mission to discredit a javascript library and it's
author, running to various online forums constantly posting the same
arguments over and over and over... well, those sorts of actions would
border on lunacy.
I might pop in an occasional CLJ thread and voice my opinion, but that's
it. Nothing more elaborate going on. You can relax.
Matt Kruse
> It seems like you believe that there are technical problems that ccan be
> fixed and do not agree that the problems with jQuery come from the
> initial API design. That's what my other post was getting at.
There are multiple problems of different types, including:
1. Algorthm: Some problems are simply solved in the wrong manner,
giving incorrect or inconsistent results
2. API: Overloaded functions should be split into multiple functions,
or in many cases just trashed. Complicated API should be simplified.
3. Design: Some of the goals of the core lib are too lofty and cannot
be adequately accomplished, and should be trashed.
4. Syntax: The source is unnecessarily obfuscated and could be much
more readable.
> >> Documentation for the selectors are a good starting point.
> > Sure, that would be fine. If I were to re-write jQuery, I would keep
> > Sizzle as-is, even with bugs, and just document the things that won't
> > work correctly. They are fairly minor, IMO.
> How much have you looked into it?
Quite a bit. Nearly as much as DM, I suppose.
> What good is a large user base?
A large user base is helpful because it brings out many situations and
conditions that could not be predicted or found by a small development
group. Even the best, most experienced js developers can't keep track
of all the browser quirks and bugs out there. If the goal of a js
library is to work well in many environments and situations, it's
great to be exposed to thousands of different contexts that you may
have never thought of. It will make the code more robust.
I know that in many things I've built, I thought it worked fine until
a small portion of users complained about something. Then I learned of
a whole new way of thinking, or a whole new context, and I could
further generalize my code.
Matt Kruse