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.

On Jun 16, 1:34=A0pm, Joe Nine <j...@yahoo.com> wrote:
> 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

On 6/16/2010 11:34 AM, 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.

Maybe next week.

On Jun 16, 2:34=A0pm, 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.

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?

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

On Jun 16, 6:53=A0pm, 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> =A0wrote:
> >> Does anyone have any links to very convincing articles that eloquently
> >> state the major flaws of these libraries? I'm not considering using an=
y
> >> 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=3D/JavaScript/&date=3D2008/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!

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.


> 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

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.  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$8300dec7@news.demon.co.uk>

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:

- 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

On 6/16/2010 5:14 PM, RobG wrote:
> 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

On 6/16/2010 5:25 PM, 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.  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.
>

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

On Jun 16, 8:25=A0pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> David Mark wrote:
> > Garrett Smith wrote:
> >> David Mark wrote:
> >> > On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> =A0wrote:
> >> >> Does anyone have any links to very convincing articles that eloquen=
tly
> >> >> 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 jus=
t
> >> >> 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? =A0:)
>
> > There's a tsunami of evidence and demonstration behind my statements
> > (as you well know). =A0As 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 formattin=
g
> (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. =A0So 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 theoretica=
lly
> 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. =A0

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

On Jun 16, 8:43=A0pm, 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> =A0wrote:
> >> On 6/16/2010 2:35 PM, David Mark wrote:
>
> >>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> =A0 =A0wrote:
> >>>> Does anyone have any links to very convincing articles that eloquent=
ly
> >>>> 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 wan=
t a
> >>>> few article links to keep in my back pocket that I can fire back whe=
n
> >>>> 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.

> =A0 =A0- 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.

> =A0 =A0 - plugins don't work

http://www.jibbering.com/faq/notes/posting/#ps1DontWork

And you are repeating yourself as well.

> =A0 =A0 - 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? =A0:)
>
> > There's a tsunami of evidence and demonstration behind my statements
> > (as you well know). =A0As 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. =A0You yourself were just parroting som=
e
> > 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, b=
ut
> >> 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. =A0Again, done to death at this point. =A0I mean, Prototype?! =A0C=
ould
> > 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://perfecti=
onkills.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. =A0I 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 wor=
k.

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. =A0Best 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=3Djquery+%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.

On Jun 16, 8:55=A0pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> On 6/16/2010 5:25 PM, Thomas 'PointedEars' Lahn wrote:
>
>
>
>
>
> > David Mark wrote:
>
> >> Garrett Smith wrote:
> >>> David Mark wrote:
> >>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> =A0 wrote:
> >>>>> Does anyone have any links to very convincing articles that eloquen=
tly
> >>>>> 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 jus=
t
> >>>>> 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? =A0:)
>
> >> There's a tsunami of evidence and demonstration behind my statements
> >> (as you well know). =A0As I said, search the archive.
>
> > Search it yourself. =A0I must agree that the problem with what is in "t=
he
> > archive" is that it is unstructured, not to the point, full of useless
> > sentiments, and on top of it widely unreadable thanks to sloppy formatt=
ing
> > (on your part, despite several requests to do better), if it is availab=
le
> > at all (you know about Google Groups' search flaws, don't you?). =A0It =
is
> > unfortunately impractical to find the pearls in the mud that have been
> > thrown. =A0So much for amnesia.
>
> Most of the searching on google search (groups search is broken) results
> in developersdex and rinocerus and objectmix.

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 theoreti=
cally
> > sound peer review. =A0In fact, not having observed it to date, I have b=
een
> > 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.

Thomas 'PointedEars' Lahn wrote:
>>>> Joe Nine wrote:
>>>>> Does anyone have any links to very convincing articles that eloquentl=
y
>>>>> state the major flaws of these libraries? [ ... ]
> I, too, would welcome an unbiased, unemotional, and theoretically
> sound peer review. =A0In fact, not having observed it to date, I have bee=
n
> considering to try and write one myself when and if I find the time. =A0
> 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

On Jun 16, 9:56=A0pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> Thomas 'PointedEars' Lahn wrote:
> >>>> Joe Nine wrote:
> >>>>> Does anyone have any links to very convincing articles that eloquen=
tly
> >>>>> state the major flaws of these libraries? [ ... ]
> > I, too, would welcome an unbiased, unemotional, and theoretically
> > sound peer review. =A0In fact, not having observed it to date, I have b=
een
> > considering to try and write one myself when and if I find the time. =
=A0
> > 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. =A0I have not actively defended
> them much, but I personally find some value in them.
>
> Yet I would also welcome such critiques. =A0I 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. =A0I 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. =A0(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!

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.

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

On 6/16/2010 6:56 PM, Scott Sauyet wrote:
> 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

On Jun 16, 10:32=A0pm, 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> =A0wrote:
> >> On 6/16/2010 4:06 PM, David Mark wrote:
>
> >>> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> =A0 =A0wrot=
e:
> >>>> On 6/16/2010 2:35 PM, David Mark wrote:
>
> >>>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> =A0 =A0 =A0wrote:
> >>>>>> Does anyone have any links to very convincing articles that eloque=
ntly
> >>>>>> state the major flaws of these libraries? I'm not considering usin=
g any
> >>>>>> of them, I've heard enough here to know how bad they are. I just w=
ant a
> >>>>>> few article links to keep in my back pocket that I can fire back w=
hen
> >>>>>> someone suggests we use one of them.
>
> [...]
>
>
>
> >>> I've done all of the hard work. =A0You yourself were just parroting s=
ome
> >>> 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. =A0You respect me enough to imitate me years later. =A0It'=
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. =A0Years later, you want to chime in. =A0What
> > audience do you think you are playing to anyway? =A0The vast majority o=
f
> > 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. =A0:)
>
> 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.

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?

[...]

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

Matt Kruse wrote:
> On Jun 16, 1: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?
> 
> A post like this in here is like throwing row meat into a tank of
> piranhas.
> 
> Enjoy!
> 
> Matt Kruse

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.

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.

Matěj

-- 
Give your heartache to him. (1Pt 5,7; Mt 11:28-30)

David Mark wrote:

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


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$8300dec7@news.demon.co.uk>

On Jun 16, 11:58=A0pm, 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> =A0wrote:
> >> On 6/16/2010 6:29 PM, David Mark wrote:
>
> >>> On Jun 16, 8:43 pm, Garrett Smith<dhtmlkitc...@gmail.com> =A0 =A0wrot=
e:
> >>>> On 6/16/2010 4:06 PM, David Mark wrote:
>
> >>>>> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...@gmail.com> =A0 =A0 =
=A0wrote:
> >>>>>> On 6/16/2010 2:35 PM, David Mark wrote:
>
> >>>>>>> On Jun 16, 2:34 pm, Joe Nine<j...@yahoo.com> =A0 =A0 =A0 =A0wrote=
:
> >>>>>>>> Does anyone have any links to very convincing articles that eloq=
uently
> >>>>>>>> state the major flaws of these libraries? I'm not considering us=
ing 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. =A0You 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. =A0You have. =A0Perhaps, 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? =A0Start 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
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. =A0Meanwhile, my patterns have
> > found their way into all of the "major" libraries. =A0Yours 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.

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.

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

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


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

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.

Matěj Cepl wrote:
> 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.

On Jun 17, 4:52=A0am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> 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 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

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jun 17, 8:24=A0am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
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? =A0<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.

On Jun 17, 9:18=A0am, VK <schools_r...@yahoo.com> wrote:
> On Jun 17, 4:52=A0am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > 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?

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?

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

On Jun 17, 8:18=A0am, VK <schools_r...@yahoo.com> wrote:
> 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

On Jun 16, 7:52=A0pm, 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. 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

On Jun 17, 10:09=A0am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jun 16, 7:52=A0pm, 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.

On Jun 17, 9:21=A0am, Kenneth Tilton <kentil...@gmail.com> 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-wh...
>
> 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.

On Jun 17, 9:21=A0am, 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.

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

On Jun 17, 9:18=A0am, VK <schools_r...@yahoo.com> wrote:
> On Jun 17, 4:52=A0am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > 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.

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] =3D '';
  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.

In article 
<7313e001-78c8-4b17-aa39-72e5a420eb2c@i28g2000yqa.googlegroups.com>,
 Matt Kruse <matt@thekrusefamily.com> wrote:

[stuff]

After all these posts, I'm none the wiser: what is the problem these 
libraries are trying to solve?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On Jun 17, 10:44=A0am, Tim Streater <timstrea...@waitrose.com> wrote:
> In article
> <7313e001-78c8-4b17-aa39-72e5a420e...@i28g2000yqa.googlegroups.com>,
> =A0Matt 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?  :)

On Jun 17, 10:37=A0am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jun 17, 9:21=A0am, 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.  :(

On Jun 17, 10:38=A0am, David Mark <dmark.cins...@gmail.com> wrote:
> On Jun 17, 9:18=A0am, VK <schools_r...@yahoo.com> wrote:
>
>
>
> > On Jun 17, 4:52=A0am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > > 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.
>
> Has left the station? =A0You know, it's odd; all of the "majors" have
> botched basic attribute manipulation. =A0That's hardly trivia. =A0After
> all, DOM stands for Document Object Model. =A0And what are documents
> made of? =A0At the "atomic" level? =A0That's right. =A0The 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. =A0The code is transparent and often
> obvious. =A0When I see code like:-
>
> function removeAttr(el, name) {
> =A0 el.removeAttribute(el, name);

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

On Jun 17, 6:44=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article
> <7313e001-78c8-4b17-aa39-72e5a420e...@i28g2000yqa.googlegroups.com>,
> =A0Matt 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).

Joe Nine wrote:

> Matěj Cepl wrote:
>> 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.

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
-- 
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$8300dec7@news.demon.co.uk>

On Thu, 17 Jun 2010 17:15:06 +0200, Thomas 'PointedEars' Lahn wrote:

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

On Thu, 17 Jun 2010 17:15:06 +0200, Thomas 'PointedEars' Lahn wrote:

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

On Jun 17, 11:04=A0am, VK <schools_r...@yahoo.com> wrote:
> On Jun 17, 6:44=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
>
> > In article
> > <7313e001-78c8-4b17-aa39-72e5a420e...@i28g2000yqa.googlegroups.com>,
> > =A0Matt 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.

On Thu, 17 Jun 2010 at 09:21:30, in comp.lang.javascript, 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

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

On Jun 17, 9:44=A0am, Tim Streater <timstrea...@waitrose.com> 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.

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

On Thu, 17 Jun 2010 07:02:25 -0700, Matt Kruse wrote:

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

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.

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.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jun 17, 7:23=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> > 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. =A0They 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. =A0If 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.

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.

Kenneth Tilton wrote:
> 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.
>> 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.

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.

On 6/17/2010 3:58 AM, David Mark wrote:
> 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

On 6/17/2010 5:24 AM, 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.

 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

Maybe the most logical preliminary step would be to make an
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.

Am 2010-06-17 16:21, David Mark meinte:
> 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


-- 
http://www.gregorkofler.com

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.

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

Gregor Kofler wrote:
> Am 2010-06-17 16:21, David Mark meinte:
>> 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.

Admit it, you've been waiting for weeks for a thread where you can use 
the word axiomatically :)

In article 
<1793b977-8483-466d-840a-5e16da6a2e2d@z10g2000yqb.googlegroups.com>,
 David Mark <dmark.cinsoft@gmail.com> wrote:

> On Jun 17, 10:44�am, 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?
> >
> 
> 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?  :)

Just as well that what I'm doing involves one browser and one platform. 
So I can stick to JavaScript and not worry about it.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On Thu, 17 Jun 2010 at 09:46:25, in comp.lang.javascript, VK wrote:

   <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

On Jun 17, 11:27=A0pm, 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.

Joe Nine wrote:
> Kenneth Tilton wrote:
>> 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.
>>> 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.
> 
> 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.

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.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jun 18, 12:38=A0am, 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
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.

In article 
<a00651fa-403c-4153-9a75-2f12a4519e5b@f7g2000vbl.googlegroups.com>,
 Matt Kruse <matt@thekrusefamily.com> wrote:

> On Jun 17, 9:44�am, Tim Streater <timstrea...@waitrose.com> 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. To me, JavaScript is a simple enough language that I have no 
problems using it. But then I'm a programmer. Ten years ago a guy in our 
group came to me and said "I'm leaving, you get this project now" and 
gave me a 30 minutes intro to HTML, JavaScript, PHP, and mysql, of which 
I'd heard something about the first and the last, and knew nothing at 
all about the middle two (not even the names). Luckily the most recent 
language I'd used (ten years before *that*, I'd moved into networking in 
the interim) was C, so it wasn't too hard. Everything else I've picked 
up from the web, text books, and occasional loitering around NGs.

I've had a brief look at JScript, looks harder than JavaScript to me.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Am 2010-06-17 19:50, Joe Nine meinte:
> Gregor Kofler wrote:
>> Am 2010-06-17 16:21, David Mark meinte:
>>> 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.
>
> Admit it, you've been waiting for weeks for a thread where you can use
> the word axiomatically :)

Indeed. Glad it finally happened.




-- 
http://www.gregorkofler.com

On 6/17/2010 10:31 AM, 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/>
>>
>> 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

VK wrote:
> 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


-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On 18/06/10 01:43, Garrett Smith wrote:
> 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

On 6/17/2010 10:47 PM, Stefan Weiss wrote:
> 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

Joe Nine wrote:
> 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

Tim Streater wrote:
> In article
> <7313e001-78c8-4b17-aa39-72e5a420eb2c@i28g2000yqa.googlegroups.com>,
>   Matt Kruse<matt@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

Garrett Smith wrote:

> 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

Tim Streater wrote:

> 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$8300dec7@news.demon.co.uk>

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.

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

On Jun 17, 4:19 pm, Tim Streater <timstrea...@waitrose.com> 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.

> 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

Matt Kruse wrote:

> 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

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$8300dec7@news.demon.co.uk>

Matt Kruse wrote:

> 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$8300dec7@news.demon.co.uk> (2004)

On Jun 18, 9:51 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
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

Thomas 'PointedEars' Lahn :

> Matt is still not getting that (JS) libraries as a concept are not the
> issue, but the people writing them.

That, exactly, is what bothers me in those discussions : the issue seems
to be *the people* writing those libraries. Technical objections alone
would hardly justify personal smears.

-- 
Johannes

Johannes Baagoe wrote:

> Thomas 'PointedEars' Lahn :
>> Matt is still not getting that (JS) libraries as a concept are not the
>> issue, but the people writing them.
> 
> That, exactly, is what bothers me in those discussions : the issue seems
> to be *the people* writing those libraries. Technical objections alone
> would hardly justify personal smears.

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.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

Matt Kruse wrote:

> 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

Thomas 'PointedEars' Lahn :

> This has (as for me) nothing to do with personal smears. [...]
> John Resig's delusions of grandeur [...]

I rest my case.

-- 
Johannes

Johannes Baagoe wrote:

> Thomas 'PointedEars' Lahn :
>> This has (as for me) nothing to do with personal smears. [...]
>> John Resig's delusions of grandeur [...]
> 
> I rest my case.

You have no case; you are disregarding the available evidence.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

In article 
<71177ac8-c30c-4bae-b705-89950522e7cf@y11g2000yqm.googlegroups.com>,
 Matt Kruse <matt@thekrusefamily.com> wrote:

> On Jun 17, 4:19 pm, Tim Streater <timstrea...@waitrose.com> 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? 

This is certainly true.

> There are tons of quirks, bugs, non-standard behaviors, etc that
> you must deal with if you write cross-browser scripts for the web,

but I'm not.

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

Well, I guess I came to it rather later. I was out of programming and 
working on wide area networks for most of the 90s.

> > I've had a brief look at JScript, looks harder than JavaScript to me.
> 
> Hmmm, I'm not sure what this statement really means.

As I said, it was very brief. Just came away with the feeling that 
having avoided perl why would I want to use JScript?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

In article <timstreater-FA743D.17011818062010@news.individual.net>,
 Tim Streater <timstreater@waitrose.com> wrote:

> As I said, it was very brief. Just came away with the feeling that 
> having avoided perl why would I want to use JScript?

Ah sorry - I probably meant JQuery.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On 6/18/2010 7:12 AM, Matt Kruse wrote:
> 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

Garrett Smith wrote:

> Please see:
> MessageID: hvbr3g$q0e$1@news.eternal-september.org

Please use `news:' URIs as specified in RFC 4438 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
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

Garrett Smith wrote:

> 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>
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

On Thu, 17 Jun 2010 at 13:29:16, in comp.lang.javascript, VK wrote:
>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

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.

> 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

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.

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/

On 19/06/2010 9:40 AM, S.T. wrote:
> 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

"S.T." wrote:
> [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

On 2010-06-18 01:54 PM, Matt Kruse wrote:
> 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

On 19/06/2010 12:57 PM, Scott Sauyet wrote:
> "S.T." wrote:
>> [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.

Make up your mind is it "fairly bad" or not "that bad".

Andrew Poulos

On 6/18/2010 7:18 PM, Andrew Poulos wrote:

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

In article <4c1fb241$0$22151$742ec2ed@news.sonic.net>,
 "S.T." <anon@anon.com> wrote:

> On 6/18/2010 7:18 PM, Andrew Poulos wrote:
> 
> >> 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.

Anyone who has enough brain cells to understand DOM manipulation and 
AJAX is going to understand JavaScript.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On Jun 18, 10:24 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> 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

On Jun 22, 4:40 am, "S.T." <a...@anon.com> wrote:
> On 6/18/2010 7:18 PM, Andrew Poulos wrote:
>
> >> 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.

Perhaps you are reflecting your own fears, as far as I know that has
never been used as justification for criticism of various libraries in
this group.

More to the point is that the publishers of various libraries say that
they remove the various quirks of cross-browser scripting, yet only
appear to do so for a small number of current browsers. Anyone with an
"unsupported" browser may be left unable to access on-line resources
for no reason other than the site developer's choice of development
tools.

A fundamental principle of the WWW is that it provides universal
access to information regardless of user agent or platform. Developing
sites that only work in a small number of browsers is the antithesis
of that ideal.

It is also very difficult to get library authors to improve their
products - how long did it take jQuery to ditch browser sniffing? How
many of the current crop continue to do it? Even the supposed champion
of web devices, Apple, uses browser sniffing on their MobileMe site to
*prevent* access by their own web-enabled products such as iPhone and
iPodTouch. I expect it's because the site is based on a couple of
script libraries (like spoutcore and prototype.js) and is so bloated
that it is unusable on a typical web-enabled phone or similar device.

There are companies like Sencha with their massive ext.js framework
who are pushing a library for touch devices that is over 200KB
minified. It is full of useless functions like:

    isPrimitive : function(v) {
        return Ext.isString(v) || Ext.isNumber(v) || Ext.isBoolean(v);
    },

   ...

    isNumber : function(v) {
        return Object.prototype.toString.apply(v) === '[object
Number]' && isFinite(v);
    },

    isString : function(v) {
        return Object.prototype.toString.apply(v) === '[object
String]';
    },

so passing a String or Number object to isPrimitive() returns true.
Why are such functions considered necessary at all? In what
circumstance will isNumber or isString be better than using typeof?
Why coerce a primitive to an Object to find out if it's a primitive?
Why two function calls when none is necessary? What do the inclusion
of such functions, and their use within the library, tell you about
the architecture and mindset of the authors? These functions are pure
ECMAScript, anyone with a basic understanding of the language should
be able to see their silliness.

Javascript libraries and frameworks are promoted as making web
development easier. A consequence of their adoption is bloated, slow
and limited sites that work only for those with the latest and
greatest devices and software and high-speed access to the web. The
developers who use them trumpet the fact that they can knock up a site
in no time at all, forgetting that for a good number of their
prospective visitors the site so produced is dysfunctional. When
alerted to that, they respond that they don't care about 0.1% of
traffic (or some other fictional number), it's not important in "the
real world". They also ignore the fact that if a visitor finds a site
dysfunctional, they are unlikely to report it and will simply go
elsewhere. The lack of complaints is often held up as evidence that no
one is having difficulty, a further demonstration of the cluelessness
of the author.

The alternative to large, bloated libraries and obese frameworks like
Cappuccino and Qooxdoo are small, concise libraries built to provide
sufficient functionality and no more. That is the line that has been
promoted here for many years, it has never been seriously challenged.
The only opposing argument has been that not everyone has the skill to
develop or collect such a library. But somehow such people *are*
sufficiently skilled to select a library or framework instead.

Go figure.


--
Rob

On 2010-06-21 05:04 PM, RobG wrote:
> On Jun 22, 4:40 am, "S.T."<a...@anon.com>  wrote:
>> On 6/18/2010 7:18 PM, Andrew Poulos wrote:
>>
>>>> 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.
>
> Perhaps you are reflecting your own fears, as far as I know that has
> never been used as justification for criticism of various libraries in
> this group.
>
> More to the point is that the publishers of various libraries say that
> they remove the various quirks of cross-browser scripting, yet only
> appear to do so for a small number of current browsers. Anyone with an
> "unsupported" browser may be left unable to access on-line resources
> for no reason other than the site developer's choice of development
> tools.
>
> A fundamental principle of the WWW is that it provides universal
> access to information regardless of user agent or platform. Developing
> sites that only work in a small number of browsers is the antithesis
> of that ideal.
>

"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 in Technology Review, July 1996

> It is also very difficult to get library authors to improve their
> products - how long did it take jQuery to ditch browser sniffing? How

The initial design was based around browser detection. Later on, it was 
retrofitted with feature tests.

Apple, Yahoo, and Google still use browser detection. The IEBlog 
mentioned how the content GMail sends to clients varies:
<http://blogs.msdn.com/b/ie/archive/2010/04/26/feedback-on-the-ie9-platform-preview.aspx>

> many of the current crop continue to do it? Even the supposed champion
> of web devices, Apple, uses browser sniffing on their MobileMe site to
> *prevent* access by their own web-enabled products such as iPhone and
> iPodTouch. I expect it's because the site is based on a couple of
> script libraries (like spoutcore and prototype.js) and is so bloated
> that it is unusable on a typical web-enabled phone or similar device.
>

Massive waste of effort.

All the energy that went into developing those frameworks, yet the 
functionality Apple needs is not all that complicated.

> There are companies like Sencha with their massive ext.js framework
> who are pushing a library for touch devices that is over 200KB
> minified. It is full of useless functions like:
>
>      isPrimitive : function(v) {
>          return Ext.isString(v) || Ext.isNumber(v) || Ext.isBoolean(v);
>      },
>
>     ...
>
>      isNumber : function(v) {
>          return Object.prototype.toString.apply(v) === '[object
> Number]'&&  isFinite(v);
>      },
>

That returns true for both number objects and primitive numbers.

>      isString : function(v) {
>          return Object.prototype.toString.apply(v) === '[object
> String]';
>      },
>

Returnds true for String objects and string values.

Typical typechecking antipattern stuff.

Of course with Ext, they don't use closures much. If they did, they 
could save a private variable as:

var _toString = Object.prototype.toString;
return{
   isNumber : function(v) {
     _toString.call(v) == "[object Number]";
   }
};

> so passing a String or Number object to isPrimitive() returns true.

What about null and undefined? They're not primitives to Ext-js 
developers or what?

> Why are such functions considered necessary at all? In what

Wher type checking functions are used, it is usually indicative of bad 
design. Most often, they are used for fake overloading strategies.

> circumstance will isNumber or isString be better than using typeof?

Probably the circumstance where the developers get tired of repeating 
typeof checks and

> Why coerce a primitive to an Object to find out if it's a primitive?

Obviosly coercing an object to a primitive does not tell you if it is a 
primitive, and if you don't know what it is, then this function won't 
tell you.

Pretty useless and futile, isn't it?

[...]


> Javascript libraries and frameworks are promoted as making web
> development easier. A consequence of their adoption is bloated, slow
> and limited sites that work only for those with the latest and
> greatest devices and software and high-speed access to the web. The
> developers who use them trumpet the fact that they can knock up a site
> in no time at all, forgetting that for a good number of their
> prospective visitors the site so produced is dysfunctional. When
> alerted to that, they respond that they don't care about 0.1% of
> traffic (or some other fictional number), it's not important in "the
> real world". They also ignore the fact that if a visitor finds a site
> dysfunctional, they are unlikely to report it and will simply go
> elsewhere. The lack of complaints is often held up as evidence that no
> one is having difficulty, a further demonstration of the cluelessness
> of the author.
>

Right, all the classic arguments. I always get a kick out of the line 
"hardly any of our customers use that browser." It would seem obvious 
that a user would not return to a site if it didn't work.

That's also what I like about IE9 coming out. I just wish it didn't have 
compatibility mode. I really want to see all those badly written sites 
break. The easiest way for the companies to learn the consequences of 
hiring such "developers" is for the projets to fail. Then they'll start 
figuring on different strategies and hire people who know how to develop 
cross-browser sites.

The other consequence to javascript libraries is at the other end of the 
stick. Self-promotion, hidden in the guise of generosity, often 
harmfully imparts bad practices and even lies to a very large number of 
unqualified web developers who don't read specs. These guys won't know 
when a blog is full of it or if a library he's been told was great 
actually isn't.

When these so-called experts censor their blog comments and hide any 
correction, they help promote themselves fraudulently. They do this to 
fool all of the dummies who won't ever read usenet into believing in 
them. In the process, they hurt the web by promoting misconceptions 
instead of the truth that it needs. In the worst case, they react 
personally, as has happened to me a few times. They may even slander the 
correct person's character. It's really easy to do that, too, because we 
all know someone who will do anything to try and "win" a fight and call 
names, etc. It's a likely and believable characteristic so switching "he 
corrected me" to "he insulted me" comes off as believable, especially 
from one of those so-called experts.

Library teams tend to involve a lot more marketing than just blogs. They 
hire paid designers. Cappucino did. The APE knockoff did, too. jQuery 
has even PR team! PR, for code. So much effort goes into marketing and 
the result is that it fools all the fools, just as can be expected.

As a user, I've found that reporting UI bugs to a site doesn't go over 
well. In many cases, the company will deny the bug and in some cases 
they either blame me or take offense. Ironically, such reactions are 
about the worst they could possibly do for themselves. The best thing 
would be to try and understand what it is that the user was expecting 
and where that expectation was not met. Next would be to look into why. 
Own your mistakes and get more respect.

It's easy to complain to each other and much more difficult to reach out 
to the rest of the web by writing and publishing such things.

There should be no reason for JS Conferences to be full of BS. There 
should be no GWT or Google Closure library. There should never ever have 
been a Dojo and Ajaxian promoting jQuery is one of the worst things that 
they have done for my industry.

Part of why I wrote the code guidelines and code reviews documents is 
that people need to see good code reviews on these things.

http://jibbering.com/faq/notes/code-guidelines/
http://jibbering.com/faq/notes/review/

> The alternative to large, bloated libraries and obese frameworks like
> Cappuccino and Qooxdoo are small, concise libraries built to provide
> sufficient functionality and no more. That is the line that has been
> promoted here for many years, it has never been seriously challenged.
> The only opposing argument has been that not everyone has the skill to
> develop or collect such a library. But somehow such people *are*
> sufficiently skilled to select a library or framework instead.
>

Another argument that has been given is that there isn't enough time to 
develop a reusable code base.

A good set of reusable abstractions (a library) saves time.

The popular libraries today have such crazy designs that they provide 
counter evidence to that argument. Then again, most wouldn't know any 
better anyway.

Garrett

Garrett Smith :

> "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 in Technology Review, July 1996

That is all nice and good, but should I wait till everybody has caught
up with Google Chrome before I publish things like these?

http://baagoe.com/en/RandomMusings/hash/avalanche.xhtml

It is not a matter of using proprietary extensions - I don't do that
as a rule, although that page is not valid XHTML, since it contains SVG.

It is simply that to the best of my knowledge, no other javascript engine 
is fast enough for the task. On my platform (Ubuntu), Firefox nearly 
chokes, Opera isn't much better, and I expect IE won't perform well on 
Windows, either (I can't test, not being a Microsoft customer). Safari 
might be all right, if I understand its workings rightly.

-- 
Johannes

On 2010-06-21 10:28 PM, Johannes Baagoe wrote:
> Garrett Smith :
>
>> "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 in Technology Review, July 1996
>
> That is all nice and good, but should I wait till everybody has caught
> up with Google Chrome before I publish things like these?
>
> http://baagoe.com/en/RandomMusings/hash/avalanche.xhtml
>

No, that's a test page.

There were plenty of sites that failed on Opera 10 beta user agent 
string because it had "10" in it and seeing that, determined that the 
site cannot work.

Unsupported browser pages were popular in the late 90s. Recently Robert 
Sayre made blog post that used some of those old, nostalgic icons.

<http://blog.mozilla.com/rob-sayre/2010/06/04/check-out-these-html5-demos/>

This was in response to the recent example of the Apple "HTML 5" demos, 
which turned out to be using browser detection to determine "unsupported 
browsers".

> It is not a matter of using proprietary extensions - I don't do that
> as a rule, although that page is not valid XHTML, since it contains SVG.
>
> It is simply that to the best of my knowledge, no other javascript engine
> is fast enough for the task. On my platform (Ubuntu), Firefox nearly
> chokes, Opera isn't much better, and I expect IE won't perform well on
> Windows, either (I can't test, not being a Microsoft customer). Safari
> might be all right, if I understand its workings rightly.
>

It was fast on Firefox 3.6.3. I'm scared to try IE but I'll try Opera...

No freeze, completed in a few secs. I'm using Windows 7 on a 3yr old 
decent laptop.

Garrett

Garrett Smith :
> Johannes Baagoe :

>> http://baagoe.com/en/RandomMusings/hash/avalanche.xhtml

>> On my platform (Ubuntu), Firefox nearly chokes, Opera isn't much
>> better, and I expect IE won't perform well on Windows, either
>> (I can't test, not being a Microsoft customer).

> It was fast on Firefox 3.6.3. I'm scared to try IE but I'll try
> Opera...

> No freeze, completed in a few secs. I'm using Windows 7 on a 3yr
> old decent laptop.

Weird. On mine, both Opera 10.01 and Firefox 3.6.3 take a few seconds
not to complete, but simply to display the first snapshot - that is
1 % of completion. Chromium 5.0.375.70 completes in about 20 seconds.

-- 
Johannes

Dne 22.6.2010 10:49, Johannes Baagoe napsal(a):
> Weird. On mine, both Opera 10.01 and Firefox 3.6.3 take a few seconds
> not to complete, but simply to display the first snapshot - that is
> 1 % of completion. Chromium 5.0.375.70 completes in about 20 seconds.

RHEL 6beta, chromium-6.0.417.0-1.20100526svn48276.el6.x86_64
and firefox-3.6.4-7.el6.x86_64 ... firefox is slower (like 2 or 3 times 
slower, not worse) but finishes in all dignity.

Matěj

-- 
A woman without a man is like a fish without a bicycle.
Therefore, a man without a woman is like a bicycle without
a fish.

On 2010-06-21 01:43 PM, Matt Kruse wrote:
> On Jun 18, 10:24 pm, Garrett Smith<dhtmlkitc...@gmail.com>  wrote:
>> 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
>

Well yeah, starting with queries are broken. That's like the core of it. 
Fixing the query engine requires defining what it should do in the first 
place, which brings up the subject of attributes.

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

I've read where you previously wrote that the issues could be fixed and 
improved while still maintaining the same API. That's what they've gone 
after, it seems.

> 4. Syntax: The source is unnecessarily obfuscated and could be much
> more readable.
>

I agree with all of that.

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

Keeping Sizzle as-is sounds like a really bad idea to me.

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

That sounds right. More people using it in different contexts will find 
bugs.

Then again, why's jQuery like it is? jQuery has thousands of users. Look 
at the query selector for five seconds. Well, you did, so OK, 10 seconds.

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

I see your point. Code reviews help. Using the abstraction more helps.

I can see the motivation to improve on jQuery, I mean, if you can help a 
company avoid some of the problems they're having, that's great, right?

As attractive as that might sound at this point, there are design 
decisions that should have been avoided from the start. The design of 
the query engine, for starters. Some of the fundamental problems, in 
particular, the selector engine, cannot very well be fixed.

I see that YUI has copied some of these problems and has added to that 
its own problems, sometimes blowing up, other times returning every 
element in the document. What sort of low-level abstraction is that? 
Does it solve cross browser issues or does it cause them?

Javascript library authors tend to publish things as solutions to "other 
peoples'" problems, as sort of "crowd pleasers," rather than creating 
abstractions that solve real problems. There is a certain fundamental 
joy in publishing something that everybody likes and that's great, but 
it can result in a public API and if it's got problems, you're stuck 
with them.

Garrett

On Jun 21, 2:40=A0pm, "S.T." <a...@anon.com> wrote:
> On 6/18/2010 7:18 PM, Andrew Poulos wrote:
>
> >> 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 sa=
w
> >> 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"?

The fact that since I started promoting it (about six months ago),
people have started using it.

> Aside from David's 14
> posts, mostly replying to himself, the "support group" shows five posts
> from two authors so far this month.

It's not a "support group", but a general discussion group.  Some
months it is busy, some months it isn't.  Perhaps the recent lack of
posts indicates users are content with the offering as it is.

And "replying to myself" indicates adding additional thoughts to a
previous announcement (e.g. IE 9 fixing a bug).

> Not exactly a booming community.

And you are not exactly making sense.  What makes you think that
everyone who downloads the script(s) posts messages to the discussion
group?

>
> I've never actually *seen* 'My Library' in use on a live site.

So what?

> Have you?

Yes.

> Tough to gauge growth rates when the benchmarks hold steady at zero.

Tour observations are not benchmarks.

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

It is certainly not dead.  I'm the only one who can declare such a
state.  As for "always was dead", I've said for years that you
shouldn't need to use any GP library (including mine).  Recently I
have decided to do (very limited) promotion as I am tired of seeing
far inferior libraries plastered all over the Web.  Clearly the masses
are going to use something and it shouldn't be jQuery, Prototype, etc.

And I shouldn't have to sell you code (a la John Resig) anyway. Your
"arguments" are centered on the idea that my code is superior but you
won't use it because I refuse to produce flashy informercials to ram
it down your throat.  Your ADHD is not my problem.

>
> > Why don't you just admit that you have stopped trying to discredit DM a=
s
> > 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 your idiotic "opinion".  The fact is that lots of GP library
authors are pissed off at me because I have pointed out numerous
shortcomings in their efforts over the course of several years.  You
are simply parroting them from the cozy confines of an anonymous
posting account.  In other words, you have no persona at all.

> That's about
> all I know about DM.

Which is absolutely nothing.

> Maybe he's a stand-up rational guy in the real
> world. I have no idea.

Exactly.  No ideas, but plenty of free time to speculate about things
you know nothing about.

>
> 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 have no idea what you are doing (or where you are doing it).  You
don't even have a name.  Your initials do seem to repeat the same
"arguments" here though.  Any time I point out flaws in "major"
libraries, I know serial apologists like Matt Kruse and yourself will
pop up out of nowhere to cluck about how I "don't get it".  Rest
assured, I get it.  What I don't understand is why you try so hard to
obscure the real issues and confuse those who truly don't get it.

On Jun 18, 11:06=A0am, Johannes Baagoe <baa...@baagoe.com> wrote:
> Thomas 'PointedEars' Lahn :
>
> > Matt is still not getting that (JS) libraries as a concept are not the
> > issue, but the people writing them.
>
> That, exactly, is what bothers me in those discussions : the issue seems
> to be *the people* writing those libraries. Technical objections alone
> would hardly justify personal smears.
>

When choosing a script, the relative proficiency of the author(s) is
certainly relevant.

On Jun 18, 10:57=A0pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> "S.T." wrote:
> > [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.

The category of those who abdicate responsibility for cross-browser
scripting to the jQuery authors (of all people), despite being told
repeatedly of their collective incompetence?

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

It only allow creates the illusion of simplifying your development.
Odd that you can't see that after all of the related discussions.

And why do you need something to take its place?  It's a 70K QSA
wrapper.  As we've been over repeatedly, CSS selector queries are
highly ill-advised and there aren't many "supported" browsers left
that lack QSA anyway.  What's left to replace?  A ham-fisted API that
is completely inappropriate for browser scripting?

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

That makes no sense at all.  You'd feel comfortable handing off a
script that you know is full of holes?  And unlike jQuery, the code in
My Library is relatively easy to follow.  So what's your point?  If
the client Googles the name they won't find tons of gushing blog posts
and bad examples?

>
> At the moment, JQuery seems the best of a fairly bad bunch.

And what seems to indicate that?  Like the rest, it calls QSA (with
very little in the way of feature testing) and hands off to a proven
mess of unfinished nonsense in the event of an error.

http://www.cinsoft.net/slickspeed.html

But, of course, you've already seen that.  IIRC, your position was
that the demonstrably execrable results were somehow my fault for
"trying to break it".  :(

> But I
> really don't want to skip a library altogether.

Why?  Cross-browser scripting is relatively easy these days, making
jQuery and the like antiquated notions.  By far, they create more
problems than they solve.

> 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 therein lies the problem.  If you would stop and think about it,
you would realize that you don't need most of what is in those
libraries, not to mention the fact that those libraries have failed
miserably (over the course several years) at their shared goal.  They
are selling both problems and (very bad) solutions.  Using them over
and over leaves you with no solutions of your own, which is your own
fault.

> And I don't
> think it's *that* bad.
>

Software either works or it doesn't.  Software authors have talent or
they don't.  Some apologists like to point to Windows as a product
that is not "that bad", but still pervasive.  Of course, the
difference between a completely transparent 70K script and an OS
should be apparent.

What has jQuery done for you, other than leave you short of time and
code and therefore perpetually dependent on it?  And what will you do
when new browsers shed more light on its appalling inferences?  Go
back and "upgrade" all of your clients to a new jQuery and hope that
it all works out?  Seems like a hard way to go, particularly in light
of the ongoing education of the script's authors and their penchant
for breaking compatibility (with browsers as well as their own
scripts).  Assuming the applications don't fall apart (something that
will take new rounds of QA testing to determine), do your clients then
need to post disclaimers about the new jQuery breaking anything
released since last year?  And will the end-users even know what to
make of such a disclaimer?

In stark contrast, I didn't have to alter a single line to accommodate
IE 8, FF 3, Safari 4, Chrome, Opera 9.5, Opera 10, Opera 10.5, etc.
And I recently tried out the Build Test page in the IE 9 "preview" and
everything worked in both HTML and XHTML DOM's.  Furthermore, my users
(as well as participants in this group) have tried it in all sorts of
mobile devices (from brand new to ancient), game consoles, etc.
without issue.

That doesn't mean it is perfect (it isn't), just demonstrably superior
to the "major" libraries, each of which has required frantic efforts
to "keep up" with just the latest versions of a handful of modern
desktop browsers (in their default configurations) and left a trail of
broken browsers behind them (e.g. Opera 9.x, FF2, etc.)  To this date,
none of them have come close to "solving" IE 6 and 7, which are
largely the same and by far the most used browsers of the last
decade.  Recently, they've taken to calling for a "ban" on those
browsers (despite the obvious futility and IE7's persistence in IE8)
as a substitute "solution".

I have recently fixed bugs for ancient browsers that the other
libraries couldn't support if they wanted to and that gives me
confidence that the script will run in browsers that I haven't heard
of or have never tested (including those that haven't been invented
yet).  None of the fixes involved browser-specific code and most were
trivial (e.g. one line to fix an FF1.0 issue, two lines to fix NN4,
another line to fix Opera 6, etc.)  I had never bothered to look at
such browsers and clearly didn't write perfect feature detection/
testing for every conceivable environment.  But plugging the holes
didn't have the slightest effect on the code's size, performance or
the compatibility with the more recent browsers.

Why should such a contrast exist?  Because, relatively speaking, the
authors of jQuery, Prototype, YUI, Dojo, Qooxdoo, SproutCore,
Cappucinno, Closure, etc. haven't got the slightest idea what they are
doing.  Over the years, overwhelming evidence has been published (here
and elsewhere) to prove this fact beyond any reasonable doubt.  The
only people who fail to grasp this are those who lack a basic
understanding of the subject and those who are completely out to lunch
(e.g. VK).  Even the authors of some of these libraries have woken up
of late and decided to scrap their previous efforts and start over
(e.g. Prototype).  And to address a previous "point" made earlier in
this interminable thread, stating such is not a "personal smear".  I
mean, would you buy an English-language book by an author with a
demonstrably shaky grasp of the English language?  By the same token,
you shouldn't abdicate responsibility for browser scripting to
author(s) with a demonstrably shaky grasp of Javascript and its
interaction with browsers.

Unsurprisingly, I have clients who have been using custom builds of My
Library for years without issue.  Still more use context-specific
scripts that continue to perform properly, despite the lack of any
sort of GP library.  Others simply write (or IM) when they find
themselves stuck (and perhaps leaning towards using a bad script) and
invariably I talk them down by suggesting a solution that avoids the
problem.  That's how professional browser scripting is supposed to
work.  It requires experience, thinking and yes, actually writing code
rather than piggy-backing on top of popular junk found on the Web.  On
the other hand, selling lifetime subscriptions to dubious open source
projects is about as unprofessional as it gets.  In many cases it is
downright fraudulent.

On 15/07/10 08:34, David Mark wrote:
> On Jun 18, 10:57 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
>> "S.T." wrote:
>> > [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.

And me, as of 1-2 months ago. I hadn't used jQuery before, but this
time, it made sense (see below).

>> 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.
> 
> It only allow creates the illusion of simplifying your development.

No, it really did simplify the development, and it saved me a day of
work. Here's the case story: a relatively simple website which didn't
use a lot of JavaScript at all. I was hired to write the server-side
framework (user management, dynamic content, CMS) and some HTML
templates. Unfortunately, the customer turned out to be very demanding,
and their change requests were managed badly, so that the project was
already *way* behind schedule. I was only a subcontractor with a fixed
fee, and had badly misjudged the amount of work for this project. Any
more time spent on it would have cost me even more money. Then it turned
out that the customer wanted Lightbox on every page (this was also
included in the demo version, but I had forgotten about it). There's no
way I'm going to include Prototype.js in any of my projects, so I went
looking for an alternative. Believe it or not, the first place I went
was your site, to check if your library had a plugin for this, but it
didn't. So I was faced with the choice of developing it myself
(including all the flashy animations and fade effects the customer
expected), or using one of the myriad Lightbox clones out there. The
best clone I found was a jQuery plugin. I gave it a shot and it worked
very well. It may have all the drawbacks that jQuery brings with it, but
in this case, I didn't care anymore. They wanted Lightbox, I gave them
Slimbox2, and didn't look back.

I'm not a fan of jQuery by any means, and I know its weak points well
enough. In this case, however, it did save me a lot of work.

So there. I'm now officially among the fallen ones.


-- 
stefan

On Jul 15, 1:43 pm, Stefan Weiss wrote:
> On 15/07/10 08:34, David Mark wrote:
>> On Jun 18, 10:57 pm, Scott Sauyet wrote:
<snip>
>>> 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.
>
>> It only allow creates the illusion of simplifying your development.
>
> No, it really did simplify the development, and it saved me a day
> of work. Here's the case story: a relatively simple website which
> didn't use a lot of JavaScript    ...    Lightbox clones out there.
> The best clone I found was a jQuery plugin. I gave it a shot and
> it worked very well. It may have all the drawbacks that jQuery
> brings with it, but in this case, I didn't care anymore. They
> wanted Lightbox, I gave them Slimbox2, and didn't look back.
>
> I'm not a fan of jQuery by any means, and I know its weak points
> well enough. In this case, however, it did save me a lot of work.
<snip>

Doesn't that story boil down to 'JQuery allowed me to take the money
and run'?

Richard.

On Jul 15, 8:23=A0am, Richard Cornford <Rich...@litotes.demon.co.uk>
wrote:
> Doesn't that story boil down to 'JQuery allowed me to take the money
> and run'?

You seem to imply that that is a bad thing :)

Matt Kruse

On 15/07/10 15:23, Richard Cornford wrote:
> On Jul 15, 1:43 pm, Stefan Weiss wrote:
>> No, it really did simplify the development, and it saved me a day
>> of work. Here's the case story: a relatively simple website which
>> didn't use a lot of JavaScript    ...    Lightbox clones out there.
>> The best clone I found was a jQuery plugin. I gave it a shot and
>> it worked very well. It may have all the drawbacks that jQuery
>> brings with it, but in this case, I didn't care anymore. They
>> wanted Lightbox, I gave them Slimbox2, and didn't look back.
>>
>> I'm not a fan of jQuery by any means, and I know its weak points
>> well enough. In this case, however, it did save me a lot of work.
> <snip>
> 
> Doesn't that story boil down to 'JQuery allowed me to take the money
> and run'?

I suppose you could see it that way, if you assume the jQuery + Slimbox
combination is going to cause trouble in the future, but Prototype.js +
script.aculo.us + Lightbox (the customer's original request) would be
stable. From my point of view, this replacement was already a (minor)
improvement I was not obligated to do.

In other circumstances, I would probably have bitten the bullet and
created a Lightbox replacement myself. In this particular case, they'd
already got 4 times the work they should have for my fixed fee (which
they still haven't paid, by the way). As a result, leaving them with
jQuery doesn't pose a big moral problem for me. You can't expect me to
add an additional day of work in this environment, just to save them the
trouble of uploading a new jQuery version every couple of years.

I did hesitate, and I did look for alternatives for over an hour. The
next time I have to make this decision, hopefully with a fairer
contract, I might go ahead and create a stand-alone Lightbox clone. The
ones I've seen were much, much worse than the jQuery one.

One more thing. I am a JS developer (among other things), and I am able
to create these things if I want to. Other people, including many web
designers and amateur bloggers, webmasters, etc, don't have that
experience. They can either use the best existing script they can find,
or do without the functionality of Lightbox & co. I have no problem
whatsoever when these people are using jQuery and its plugins. It
enables them to do things they otherwise couldn't. The moral dilemma I
was facing does not apply to them.


-- 
stefan

I see really no discussion of the (de)merits of MooTools in this
topic, a library that I have found to be very useful over the years. I
see attribute getter/setter methods consistently criticized, and for
good reason in that they typically offer little. I think that
MooTools' implementation of "get" and "set" for Element is otherwise
in that it is intended to allow for an intermediary layer of element
data "storage," although in my own code that use case is infrequent.

Thomas

Am 2010-07-15 16:17, Stefan Weiss meinte:

> One more thing. I am a JS developer (among other things), and I am able
> to create these things if I want to. Other people, including many web
> designers and amateur bloggers, webmasters, etc, don't have that
> experience. They can either use the best existing script they can find,

....or leave it to someone experienced in those things.


-- 
http://www.gregorkofler.com

On 2010-07-15 07:31 AM, Thomas Allen wrote:
> I see really no discussion of the (de)merits of MooTools in this
> topic, a library that I have found to be very useful over the years. I

It is generally a very good idea to review the source code for any third 
party javascript library.

With the dynamic nature of javascript the dynamic nature of the web, and 
web browsers, a script may have problems that are not immediately 
apparent. It may have errors but they not necessarily be seen either 
immediately or ever.

> see attribute getter/setter methods consistently criticized, and for
> good reason in that they typically offer little. I think that
> MooTools' implementation of "get" and "set" for Element is otherwise
> in that it is intended to allow for an intermediary layer of element
> data "storage," although in my own code that use case is infrequent.
>
Discussions of problems of MooTools have included problems such as:
  * unrelated inferences / browser sniffing, including using nonstandard 
Gecko-only etBoxObjectFor (which they deprecated)
  * modification DOM prototypes and other host objects; use of expandos
  * needless interdependency/tight coupling
  * The dollar function (meaningless)

Some of these things were discussed in "MooTools: An Objective Look".

See also:
[1] <http://jibbering.com/faq/notes/detect-browser/>
[2] <http://perfectionkills.com/whats-wrong-with-extending-the-dom/>
-- 
Garrett

David Mark wrote:
> Scott Sauyet wrote:
>> "S.T." wrote:
>>> [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.
>
> The category of those who abdicate responsibility for cross-browser
> scripting to the jQuery authors (of all people), despite being told
> repeatedly of their collective incompetence?

No, you must have misread.  I was discussing the category of people
who use their clients' and employers' resources wisely, using tools
that work well for the environments those clients care about, people
who understand enough about browser-scripting to do the work
themselves but choose to use a library that substantially speeds up
certain parts of the job, people who make up their own minds about the
competence of their tools and the authors of those tools.


>> 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.
>
> It only allow creates the illusion of simplifying your development.
> Odd that you can't see that after all of the related discussions.

No.  In fact, it does simplify my development.  Odd that you think you
can see over my shoulders from way back there.  Are you really as
arrogant as you come across?


> And why do you need something to take its place? =A0It's a 70K QSA
> wrapper. =A0As we've been over repeatedly, CSS selector queries are
> highly ill-advised and there aren't many "supported" browsers left
> that lack QSA anyway. =A0What's left to replace? =A0A ham-fisted API that
> is completely inappropriate for browser scripting?

As we've been over repeatedly, CSS-selectors are often the very best
tools for the job.  And I know that you've read enough of jQuery's
source to realize that the selectors engine is probably 15% - 20% of
the total.



>> 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.
>
> That makes no sense at all. =A0You'd feel comfortable handing off a
> script that you know is full of holes?

No.  I am willing to hand off code that I know is not perfect, if I
can comfortably describe its limitations and flaws, and if it works
reliably.  What I'm not comfortable doing is handing off code that I
think the client cannot fix themselves or for which they cannot find
simple help fixing.  I'm afraid right now that any clients I have who
do not have the expertise to fix things themselves would not get
helpful responses from the minimal community around My Library.

 =A0
>                                         And unlike jQuery, the code in
> My Library is relatively easy to follow. =A0So what's your point? =A0If
> the client Googles the name they won't find tons of gushing blog posts
> and bad examples?

No, that doesn't bother me much.  Frankly, it's you and the attitude
you display here that prevents me from even considering suggesting My
Library to any clients.


>> At the moment, JQuery seems the best of a fairly bad bunch.
>
> And what seems to indicate that? =A0Like the rest, it calls QSA (with
> very little in the way of feature testing) and hands off to a proven
> mess of unfinished nonsense in the event of an error.
>
> http://www.cinsoft.net/slickspeed.html
>
> But, of course, you've already seen that. =A0IIRC, your position was
> that the demonstrably execrable results were somehow my fault for
> "trying to break it". =A0:(

I'm afraid you don't recall correctly.  My position was simply that
you were misusing the speed test as a conformance test,
misrepresenting the other libraries thoroughly in the process.


>> But I really don't want to skip a library altogether.
>
> Why? =A0Cross-browser scripting is relatively easy these days, making
> jQuery and the like antiquated notions. =A0By far, they create more
> problems than they solve.

They haven't for me or my clients.


>> 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 therein lies the problem. =A0If you would stop and think about it,
> you would realize that you don't need most of what is in those
> libraries, not to mention the fact that those libraries have failed
> miserably (over the course several years) at their shared goal. =A0They
> are selling both problems and (very bad) solutions. =A0Using them over
> and over leaves you with no solutions of your own, which is your own
> fault.

I've written table-striping code for when I can't add the "odd"
classes on the server.  I've written several different version of such
code.  It's not at all difficult to write.  But including that code in
my build and adding whatever calls are needed to apply it is more
difficult than doing this:

    $("#myTable tbody tr:odd").addClass("odd");

Moreover if I decide I want to apply it to a certain class of tables
instead, I don't need to ensure that I can collect them by class name
and then run a loop over the bunch.  I can do this instead:

    $("table.zebra tbody tr:odd").addClass("odd");

I don't have to want to use all the code that jQuery supplies, just
enough of it that it's worth my time dealing with its flaws.


>> And I don't think it's *that* bad.
>
> Software either works or it doesn't. =A0

Software either meets your needs or it doesn't.

Doesn't it annoy you when posters come here complaining just that
their script "doesn't work?"  We need to know what they expect before
we can tell for ourselves that it doesn't work.  The same holds true
for libraries.  What I expect out of them is clearly something less
than what you expect.  So you shouldn't use them, clearly.  But your
evangelizing against them has really not convinced me that these
libraries are inherently flawed.


> Software authors have talent or they don't.

Do you think Donald Knuth never wrote any bad code?  Was Edsger
Dijkstra's code so perfect that no one would ever find a flaw in it?
Talent is only part of the story.  It's important, but there is more
to well-built software, especially software built by a community.


>=A0Some apologists like to point to Windows as a product
> that is not "that bad", but still pervasive. =A0Of course, the
> difference between a completely transparent 70K script and an OS
> should be apparent.

It seems apparent to me, but in a manner that belies the rest of your
argument.  Which do you think you should trust more, a reasonably
small script that you can understand in detail with some concentrated
effort, whose flaws you can detail for yourself efficiently -- or a
50+-million lines-of-code behemoth that you can only treat as a black
box?


> What has jQuery done for you, other than leave you short of time and
> code and therefore perpetually dependent on it? =A0

I think it might do that for script kiddies.  But for competent
developers, it's just a collection of short-cuts for things they could
do themselves if they really wanted to.

I do a lot of work in Java.  And years ago I wrote logging systems to
fit my needs.  They were better adapted to exactly what we wanted to
do than any general-purpose logging library ever could be.  But I
would probably never write one again, because the general-purpose
libraries have gotten so useful, and they work well-enough for my
needs, and they come without several weeks worth of development.

> [too much more for me to respond to right now.]

--
Scott

Stefan Weiss wrote:
> On 15/07/10 15:23, Richard Cornford wrote:
>> On Jul 15, 1:43 pm, Stefan Weiss wrote:
>>> No, it really did simplify the development, and it saved me
>>> a day of work. Here's the case story: a relatively simple
>>> website which didn't use a lot of JavaScript    ...    Lightbox
>>> clones out there. The best clone I found was a jQuery plugin.
>>> I gave it a shot and it worked very well. It may have all the
>>> drawbacks that jQuery brings with it, but in this case, I
>>> didn't care anymore. They wanted Lightbox, I gave them Slimbox2,
>>> and didn't look back.
>>>
>>> I'm not a fan of jQuery by any means, and I know its weak points
>>> well enough. In this case, however, it did save me a lot of work.
>> <snip>
>>
>> Doesn't that story boil down to 'JQuery allowed me to take the
>> money and run'?
>
> I suppose you could see it that way,

Particularly as I tend towards the cynical.

> if you assume the jQuery + Slimbox combination is going to cause
> trouble in the future, but Prototype.js + script.aculo.us +
> Lightbox (the customer's original request) would be
> stable.

The 'if' supposes that those were the only two alternatives.

> From my point of view, this replacement was already a (minor)
> improvement I was not obligated to do.
>
> In other circumstances, I would probably have bitten the bullet
> and created a Lightbox replacement myself. In this particular
> case, they'd already got 4 times the work they should have for
> my fixed fee (which they still haven't paid, by the way).

Sometimes there are client who get what they deserve. Unfortunately 
there are also clients who do not deserve what they get.

> As a
> result, leaving them with jQuery doesn't pose a big moral problem
> for me. You can't expect me to add an additional day of work in
> this environment, just to save them the trouble of uploading a
> new jQuery version every couple of years.

The "trouble" isn't just uploading a new JQuery version every couple of 
years, it is uploading a new JQuery version and then doing a full 
regression test of the functionality of the whole site, and then fixing 
anything that may have been broken by non-back-compatible changes in 
JQuery (and that may not be necessary every couple of years, but instead 
following a first update rapidly followed three or four similar cycles 
as bugfix releases rapidly follow a major version release (based on 
previous releases)). Of course formal (or even effective) QA/regression 
testing is nearly unheard of in general web development so its implied 
expense is avoided, and in return the expense is experienced in the 
negative impact of non fully functional websites going unnoticed for 
indeterminate periods of time and not achieving whatever they were 
intended to achieve during that time.

> I did hesitate, and I did look for alternatives for over an
> hour. The next time I have to make this decision, hopefully
> with a fairer contract, I might go ahead and create a
> stand-alone Lightbox clone. The ones I've seen were much,
> much worse than the jQuery one.
>
> One more thing. I am a JS developer (among other things), and I
> am able to create these things if I want to. Other people,
> including many web designers

Does "web designers" mean (effectively) graphical designers working 
on/producing websites? (as distinct from 'web developers' responsible 
for code/application architecture design, UI interaction design, 
database design (in relation to websites), server configuration design, 
and so on.)

> and amateur bloggers, webmasters, etc, don't have that
> experience.

No, they (mostly) do not. That is not an unexpected situation as 
realistically most people do not have experience in most (more than 
slightly) specialised things. Generally that is not a problem as 
(effectively) we sell our own specialised experience in order to 
purchase the experience (or products of the experience) we need/want of 
others. And faced with a lack of experience/knowledge in an area most 
people are happier (and probably better off) purchasing that experience 
than trying to do it themselves.

Almost nobody, for example, would contemplate making their own china, 
even though it would not be at all physically difficult to do so (at 
least using available fabrication techniques that do not include 
throwing posts on a potter's wheel).

One of the things that is gained with experience is an understanding of 
consequences. An inexperienced individual setting about making their own 
china (from the previous example) may not appreciate the harmful/toxic 
characteristics of the materials they would be working with. The toxic 
characteristics of lead were first identified early in the (British) 
industrial revolution when a study into why some Staffordshire pottery 
workers were dying unusually early (at a time when life expectancy was 
already relatively short) found a direct correlation with those workers 
handling (inhaling/ingesting) while lead powder. Ironically, when the 
lead handling had been improved to reduce the associated risks those 
workers only gained an extra couple of years of life before they died 
from the Silicosis caused by years of inhaling clay dust (thus revealing 
the second hazard in the pottery industry). The colorants used in 
pottery (especially the brighter, low temperature, colors) tend to be 
more or less toxic metals (e.g. Cobalt, Cadmium) (Uranium was used to 
produce a bright yellow during the early part of the 20th Century, but 
that been banned for obvious reasons).

There are questions of appropriateness; a lead based low temperature 
(900-1100 degrees centigrade is low in pottery terms) glaze colored with 
Cadmium is acceptable on a decorative vase, but on the inside of a dish 
used for cooking in an oven it becomes a health hazard. Then there are 
the technical considerations, such as glaze "fit" where the relative 
expansion/contraction with temperature of the clay body and the glaze 
are calculated (and the glaze composition designed). Structural strength 
is improved if the glaze has a slight compressing effect on the clay it 
surrounds, but too much and the glaze will craze. Reverse the 'fit' and 
the resulting pot will be structurally week, and taken too far the glaze 
can crack the underlying clay leading to an sudden extreme failure. 
Obviously this has more significance in the context of cooking vessels 
than decorative or tableware, as they will experience more 
extreme/frequent fluctuations in temperature throughout their lives.

So the inexperienced can easily make their own china, but they risk 
doing significant harm to themselves in the process, and could create 
something that is hazardous to use and unacceptably short lived. There 
is much to be said for understanding the consequences of actions, 
particularly in terms of avoiding the bad ones.

> They can either use the best existing script they can find,
> or do without the functionality of Lightbox & co. I have no
> problem whatsoever when these people are using jQuery and
> its plugins. It enables them to do things they otherwise
> couldn't. The moral dilemma I was facing does not apply to
> them.

A different moral dilemma might apply to them. Granted, if you are 
talking about a complete armature doing what they like to please 
themselves then any consequences (good or bad) fall only on them. But as 
soon as someone is acting in the role of 'client' is involved the 
consequences of design decisions are no longer local. Yet without the 
experience that would have informed the 'designer' about what 
consequences were likely to follow from particular design decisions no 
anticipation can be exercised, and negative consequences cannot be 
avoided. Which doesn't mean that there necessarily will be negative 
consequences, everything may be just fine, but the point is that the 
inexperienced designer will not know one way or the other.

It is the professional's responsibility (even duty) to know. It is for 
their knowledge and experience that clients hire them. In allowing the 
inexperienced to achieve things they could not otherwise (which they 
demonstrably do) things like JQuery (not to single out JQuery as any 
'copy-n-paste' script 'collection' can have exactly the same effect) 
also allow inexperienced individuals to put themselves across as having 
the professional knowledge and experience that clients/employers are 
looking for, and to a large extend get away with it. There is dubious 
morality in this latter possibility.

Now it could be argued that 'getting away with it' is enough; that in 
many cases the real professional in the same circumstances would do no 
more than get the same widget to work the same way on the same page. And 
judging only by results that may often be the case. However, what the 
experience of the real professional brings is the overview of the bigger 
picture; the perception of permutations, the consideration of 
alternatives, the anticipation of consequences (and the rest of a very 
long list). Even when what ends up being done is identical there is a 
huge defence in why it is being done; in one case because it is the 
right thing to do (based on informed judgment) and in the other because 
it is the only thing that can be done. (And, of course, 'getting away 
with it' can be a short term thing in the cases where the real 
professional would have done something else.)

Reading this group for any extended period reveals a parade of design 
decisions made in ignorance having negative consequences. One humorous 
story (from around 2004) is of an individual who come here looking for 
help on something or another in relation to a site he had created that 
was heavily dependent on opening pop-up browser windows. He was asked 
about the wisdom of this design, and particularly about how it would get 
along with the (exponentially increasing, at the time) use of pop-up 
blockers. His response was that pop-up blocking could not be an issue 
for the site because it had a 'feedback' form and that zero feedback had 
been received relating to non-functional pop-ups. But then closer 
examination revealed that this 'feedback' form opened in a pop-up 
window, designing away the possibility of ever receiving feedback form a 
user with a pop-up blocker running. The designer's inability to 
anticipate pop-up blocking (pretty much a pre-requisite for designing a 
site that depends on pop-ups) effectively generated its own 
self-reinforcing feedback; the absence of complaints justified the 
design, while the design prevented the recite of those complaints. The 
result would have been a site that was effetely unusable for an 
increasing proportioning of its visitors, with whatever consequences for 
the site's owners that could be expected to have (the site would be 
becoming less effective and doing whatever it had been created to do).

Just yesterday I encountered what was probably another example of this 
on a site that I use fairly frequently. It was my first visit to the 
site since its UI had been redesigned (and AJAXed) and as I logged out I 
noticed IE 8 show that strip at the top that announces that it has 
blocked a pop-up. Ah, I thought, that is going to be survey about what I 
think of the new UI, and as I wanted to tell them that they had rendered 
it significantly slower, more clunky and expended the number of clicks 
between me and what I actually wanted to do (figuring that they would 
only have tested it locally and be under the impression that they had 
somehow improved the site with AJAX), I used the 'allow the pop-up' 
option. IE then re-loads the page in its 'pop-ups allowed' state, but of 
course, being AJAXed, the site has lost its context and no longer thinks 
it is my first visit to the new UI, and so no longer wants to show me 
the survey pop-up. A cynic might think that the designers of the new 
AJAXed UI had done that deliberately in order to avoid the survey 
generating negative feedback, but, on the principle that you should 
never attribute to malice anything that can be explanted by ignorance, I 
concluded that web developers responsible where too inexperienced to 
have taken into account the (default) behaviour of IE 8 with regard to 
pop-ups.

Kenneth Tilton recently demonstrated a similar inexperience based 
short-sightedness in his 'this site is a train wreck' warring; where 
everything on the screen is put there by javascript, including the 
warring that things may not work correctly, then when the javascript 
doesn't work correctly the odds are pretty good that the warning will 
not be shown. The path of the reasoning is obvious, but you have to be a 
little more experienced in the field in order to take the first step.

Richard. 

Richard Cornford wrote:
> Kenneth Tilton recently demonstrated a similar inexperience based 
> short-sightedness in his 'this site is a train wreck' warring; where 
> everything on the screen is put there by javascript, including the 
> warring that things may not work correctly, then when the javascript 
> doesn't work correctly the odds are pretty good that the warning will 
> not be shown. The path of the reasoning is obvious, but you have to be a 
> little more experienced in the field in order to take the first step.

Yeah, I am really worried about people who have JS turned off during 
this stage of development when I am just running the site to keep my 
morale up and sharing with programmers who might be interested in 
driving qooxdoo from lisp. Not.

Hell, I am not even worried about the template Algebra hints sometimes 
failing to locate the operands they try to lift from the problem at 
hand, so the hints can be that much easier to connect with the problem.

That comes soon, tho, because my port of a full-blown desktop app to the 
Web (http://teamalgebra.com/) is going so well (thanks to qooxdoo: 
http://qooxdoo.org/) that in a week or two I will want to share it with 
normal people vs Lisp/javascript geeks.

Speaking of which, any lisp/js geek who gets curious about my 
lisp/qooxdoo library and checks it out without having javascript turned 
on -- um, I think I'm OK with the probable outcome.

As for this group bravely standing up for clients in the face of 
scurrilous thieving lying consultants who rip themm off by using a JS 
library, um, I /am/ the client. When I do have clients they ask me to 
check out different libraries they themselves have come across, and one 
explicitly encouraged me to use a /big/ library like Dojo instead of a 
small one like jQuery so I would not be re-inventing the wheel.

Tilton's Law: Solve the right problem. In this case, if the problem is 
that a JS library has a bug, the solution is to fix the bug, not burn 
the library and have every programmer who wants to put up a web page 
spend five years learning HTML and CSS and browser variability.

That's actually rather obvious, so it's fun seeing the alpha males 
around this NG forever arguing against it. Using a little FUD to keep 
those billing rates up, are we? Best of luck, these are tough times.

kt









> 
> Richard.


-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Kenneth Tilton wrote:
> Richard Cornford wrote:
>> Kenneth Tilton recently demonstrated a similar inexperience
>> based short-sightedness in his 'this site is a train wreck'
>> warring; where everything on the screen is put there by
>> javascript, including the warring that things may not work
>> correctly, then when the javascript doesn't work correctly
>> the odds are pretty good that the warning will not be shown.
>> The path of the reasoning is obvious, but you have to be a little 
>> more experienced in the field in order to take the
>> first step.
>
> Yeah, I am really worried about people who have JS turned off
> during this stage of development when I am just running the
> site to keep my morale up and sharing with programmers who
> might be interested in driving qooxdoo from lisp. Not.

"When the javascript doesn't work correctly" necessitates javascript's 
being enabled, else the javascript does not work at all. Remember that 
your page throws an exception as it loads, which means its initial state 
is not as designed (unless it was designed by a lunatic). So whatever 
happens after that has already become uncertain.

<snip>
> Tilton's Law: Solve the right problem. In this case, if the
> problem is that a JS library has a bug, the solution is to
> fix the bug, not burn the library and have every programmer
> who wants to put up a web page spend five years learning HTML
> and CSS and browser variability.
<snip>

Or the difference between javascript not working correctly (in the sense 
of 'not as designed/intended', but rather just as programmed) and 
javascript being disabled.

It is interesting to observe that since my comments that their SELECT 
element imitations were flawed in that they would drop the list box out 
of the viewport of the browser window (rendering the contents 
inaccessible/unusable) qooxdoo have added some position checking code 
that moves the list into the viewport and puts up scrollbars when 
necessary. They haven't quite got this right yet as there are 
circumstances where if the control is partly obscured off the edge of 
the viewport the contents jump to move the control into the viewport 
(not a bad idea in itself). Unfortunately the calculations for the 
size/position of the list box happen before this jump, so when the jump 
happens it can push the edge of the list box back off the viewport, 
rendering parts of its content (and likely one scrollbar handle) 
inaccessible again.

When I originally commented on this deficiency in their SELECT elements 
I noted that adding the code to fully reproduce the facilities that the 
browser would have provided was going to slow things down, and this is 
what I found with the new version. Viewing the qooxdoo demos on a 
machine with a 3.2GHz quad core processor the drop-boxes were appearing 
fractionally before I re-clicked the button, assuming that I had either 
missed or not clicked 'hard enough'(to trigger the switch) the first 
time.  The effect was sluggish to the point of being unsatisfying, and 
is going to be problematic on a 2Ghz processor (or anything less 
powerful, which includes a good proportion of laptops and netbooks these 
days). Presumably qooxdoo are still hoping that Moore's law will speed 
up the general environment before they have finished getting all of the 
normal HTML facilities working properly in their UI code.

Richard. 

On 2010-07-16 07:40 AM, Richard Cornford wrote:
> Stefan Weiss wrote:
>> On 15/07/10 15:23, Richard Cornford wrote:
>>> On Jul 15, 1:43 pm, Stefan Weiss wrote:
>>>> No, it really did simplify the development, and it saved me
>>>> a day of work. Here's the case story: a relatively simple
>>>> website which didn't use a lot of JavaScript ... Lightbox
>>>> clones out there. The best clone I found was a jQuery plugin.
>>>> I gave it a shot and it worked very well. It may have all the
>>>> drawbacks that jQuery brings with it, but in this case, I
>>>> didn't care anymore. They wanted Lightbox, I gave them Slimbox2,
>>>> and didn't look back.
>>>>
>>>> I'm not a fan of jQuery by any means, and I know its weak points
>>>> well enough. In this case, however, it did save me a lot of work.
>>> <snip>
>>>
>>> Doesn't that story boil down to 'JQuery allowed me to take the
>>> money and run'?
>>
>> I suppose you could see it that way,
>
> Particularly as I tend towards the cynical.
>
>> if you assume the jQuery + Slimbox combination is going to cause
>> trouble in the future, but Prototype.js + script.aculo.us +
>> Lightbox (the customer's original request) would be
>> stable.
>
> The 'if' supposes that those were the only two alternatives.
>
>> From my point of view, this replacement was already a (minor)
>> improvement I was not obligated to do.
>>
>> In other circumstances, I would probably have bitten the bullet
>> and created a Lightbox replacement myself. In this particular
>> case, they'd already got 4 times the work they should have for
>> my fixed fee (which they still haven't paid, by the way).
>
> Sometimes there are client who get what they deserve. Unfortunately
> there are also clients who do not deserve what they get.
>
>> As a
>> result, leaving them with jQuery doesn't pose a big moral problem
>> for me. You can't expect me to add an additional day of work in
>> this environment, just to save them the trouble of uploading a
>> new jQuery version every couple of years.
>
> The "trouble" isn't just uploading a new JQuery version every couple of
> years, it is uploading a new JQuery version and then doing a full
> regression test of the functionality of the whole site, and then fixing
> anything that may have been broken by non-back-compatible changes in
> JQuery (and that may not be necessary every couple of years, but instead
> following a first update rapidly followed three or four similar cycles
> as bugfix releases rapidly follow a major version release (based on
> previous releases)). Of course formal (or even effective) QA/regression
> testing is nearly unheard of in general web development so its implied
> expense is avoided, and in return the expense is experienced in the
> negative impact of non fully functional websites going unnoticed for
> indeterminate periods of time and not achieving whatever they were
> intended to achieve during that time.
>
>> I did hesitate, and I did look for alternatives for over an
>> hour. The next time I have to make this decision, hopefully
>> with a fairer contract, I might go ahead and create a
>> stand-alone Lightbox clone. The ones I've seen were much,
>> much worse than the jQuery one.
>>
>> One more thing. I am a JS developer (among other things), and I
>> am able to create these things if I want to. Other people,
>> including many web designers
>
> Does "web designers" mean (effectively) graphical designers working
> on/producing websites? (as distinct from 'web developers' responsible
> for code/application architecture design, UI interaction design,
> database design (in relation to websites), server configuration design,
> and so on.)
>
>> and amateur bloggers, webmasters, etc, don't have that
>> experience.
>
> No, they (mostly) do not. That is not an unexpected situation as
> realistically most people do not have experience in most (more than
> slightly) specialised things. Generally that is not a problem as
> (effectively) we sell our own specialised experience in order to
> purchase the experience (or products of the experience) we need/want of
> others. And faced with a lack of experience/knowledge in an area most
> people are happier (and probably better off) purchasing that experience
> than trying to do it themselves.
>
> Almost nobody, for example, would contemplate making their own china,
> even though it would not be at all physically difficult to do so (at
> least using available fabrication techniques that do not include
> throwing posts on a potter's wheel).

There are many interesting things to do in the world and many of them 
are also dangerous.

[...]

>
> So the inexperienced can easily make their own china, but they risk
> doing significant harm to themselves in the process, and could create
> something that is hazardous to use and unacceptably short lived. There
> is much to be said for understanding the consequences of actions,
> particularly in terms of avoiding the bad ones.
>


>> They can either use the best existing script they can find,
>> or do without the functionality of Lightbox & co. I have no
>> problem whatsoever when these people are using jQuery and
>> its plugins. It enables them to do things they otherwise
>> couldn't. The moral dilemma I was facing does not apply to
>> them.
>
> A different moral dilemma might apply to them. Granted, if you are
> talking about a complete armature doing what they like to please
> themselves then any consequences (good or bad) fall only on them. But as
> soon as someone is acting in the role of 'client' is involved the
> consequences of design decisions are no longer local. Yet without the
> experience that would have informed the 'designer' about what
> consequences were likely to follow from particular design decisions no
> anticipation can be exercised, and negative consequences cannot be
> avoided. Which doesn't mean that there necessarily will be negative
> consequences, everything may be just fine, but the point is that the
> inexperienced designer will not know one way or the other.
>

Experience without knowledge isn't much use. I would say there are 
posters of this NG that are more experienced than I am (I base this on 
having read their stories of Netscape 3, etc), yet these same posters 
still post up code examples that seems to me to be in very poor 
judgment, using conditional comments to identify which browser might 
support attachEvent, etc.

I was interviewed about two years ago by a senior front end engineer 
with 15 years experience. The first and only technical question was to 
build a rich text editor. He asked me to start with a TEXTAREA, and so I 
wrote that HTML on the whiteboard. I suspected that he was going to fall 
into the trap of trying to add HTML to the textarea's value and sure 
enough, he did just that. We proceeded for probably not much more than a 
minute when I mentioned that setting the TEXTAREA's `value` property to 
have '<' and '>' characters would result in those characters being 
rendered as text. I think I may have dropped that as a question, as "how 
are you going to get '<b>' to be parsed?

I assume that he realized the problem because he ended that question 
right there and the interview finished soon thereafter. The rest of the 
interview revolved around Ext-js.

Another type of thoughtless experience is copying.

A third type of thoughtless experience is outright bs. Recall the 
example of the "enterprise level" jQuery developer who was using a 
namespacing technique which was nothing more than a useless call to 
`Function.prototype.apply` and did not create any namespace.

There is no substitute for knowledge [Deming]. Blindly copying the wrong 
thing does not improve the situation and although it may result in a 
desirable outcome (as you point out below), it is only by limited luck.

Recommend reading (for anyone reading this message): Carefully review 
each of Deming's 14 points listed on Wikipedia and for each point, 
consider how it applies to software development. You may find it 
enlightening:

<URL: http://en.wikipedia.org/wiki/W._Edwards_Deming>

[...]

> Just yesterday I encountered what was probably another example of this
> on a site that I use fairly frequently. It was my first visit to the
> site since its UI had been redesigned (and AJAXed) and as I logged out I
> noticed IE 8 show that strip at the top that announces that it has
> blocked a pop-up. Ah, I thought, that is going to be survey about what I
> think of the new UI, and as I wanted to tell them that they had rendered
> it significantly slower, more clunky and expended the number of clicks
> between me and what I actually wanted to do (figuring that they would
> only have tested it locally and be under the impression that they had
> somehow improved the site with AJAX), I used the 'allow the pop-up'
> option. IE then re-loads the page in its 'pop-ups allowed' state, but of
> course, being AJAXed, the site has lost its context and no longer thinks
> it is my first visit to the new UI, and so no longer wants to show me
> the survey pop-up. A cynic might think that the designers of the new
> AJAXed UI had done that deliberately in order to avoid the survey
> generating negative feedback, but, on the principle that you should
> never attribute to malice anything that can be explanted by ignorance, I
> concluded that web developers responsible where too inexperienced to
> have taken into account the (default) behaviour of IE 8 with regard to
> pop-ups.
>

That seems out of touch. Surveys aren't a big part of the user story. 
Like help (F1), these don't get top priority in testing and I've worked 
at out-of-touch companies that had such surveys along with 
foreseeresults, and omniture. They employed these because they were out 
of touch with the end user, did not have user stories (!) and were 
probably required to show some sort of accountability to the parent 
company (eBay). It is a public site I worked on and need not be 
mentioned here (it is embarrassing, but was well-paid).

The problem with the survey is that when the site has problems like 
that, the user may just move along to the next site, unless he feels 
like being helpful.

Instead, it is better build a user experience design that lets the user 
get done what he wants easily.
-- 
Garrett

In article <i1rkkj$lj0$1@news.eternal-september.org>,
 Garrett Smith <dhtmlkitchen@gmail.com> wrote:


> That seems out of touch. Surveys aren't a big part of the user story. 
> Like help (F1), these don't get top priority in testing and I've worked 
> at out-of-touch companies that had such surveys along with 
> foreseeresults, and omniture. They employed these because they were out 
> of touch with the end user, ...

What makes anyone think that F1 is Help? Or that "you can add this link 
to your favorites (sic) by typing ctrl-d" or whatever it is? The former 
applies to nothing on my computer and the latter to only one out of five 
browsers I have.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On 17/07/10 09:03, Garrett Smith wrote:
> On 2010-07-16 07:40 AM, Richard Cornford wrote:
>> Stefan Weiss wrote:
>>> One more thing. I am a JS developer (among other things), and I
>>> am able to create these things if I want to. Other people,
>>> including many web designers
>>
>> Does "web designers" mean (effectively) graphical designers working
>> on/producing websites? (as distinct from 'web developers' responsible
>> for code/application architecture design, UI interaction design,
>> database design (in relation to websites), server configuration design,
>> and so on.)
>>
>>> and amateur bloggers, webmasters, etc, don't have that
>>> experience.
>>
>> No, they (mostly) do not. That is not an unexpected situation as
>> realistically most people do not have experience in most (more than
>> slightly) specialised things. Generally that is not a problem as
>> (effectively) we sell our own specialised experience in order to
>> purchase the experience (or products of the experience) we need/want of
>> others. And faced with a lack of experience/knowledge in an area most
>> people are happier (and probably better off) purchasing that experience
>> than trying to do it themselves.
>>
>> Almost nobody, for example, would contemplate making their own china,
>> even though it would not be at all physically difficult to do so (at
>> least using available fabrication techniques that do not include
>> throwing posts on a potter's wheel).
> 
> There are many interesting things to do in the world and many of them 
> are also dangerous.

The (snipped) story about the dangers of home-made china, while
interesting, is not a very good analogy to what amateurs are doing on
the web. At the very least, the analogy grossly exaggerates the
consequences: build your own china, and people can die from lead
poisoning; use a substandard script you copied from somewhere, and your
homepage could break for a certain percentage of visitors.

I realize that this is going to be a minority opinion in a technically
oriented group such as this, but I still think that everybody - even the
most clueless newcomers - should be allowed, and even encouraged, to
play on the web any way they like. Let them use huge animated GIFs,
background sounds, <blink> tags, UA sniffing, jQuery or any other JS
library, let them proclaim that "this site is best viewed with
{browser}", etc. Anything to get them interested and give them a sense
of achievement. Some will become fascinated enough that they'll
eventually learn how to do it right. Other's will not.

I'm firmly convinced that the low barrier of entry, combined with the
openness of the basic technologies is what allowed the Web to become
widely accepted and grow to what we see today. Had it been necessary to
hire a professional to build a homepage, none of this would have happened.

The low barrier of entry has its downsides, of course. Fred (to use a
random name) looks at the source code of a document, decides to try this
out for himself, writes 'alert("Hello, world")', and is delighted with
the result. Three days later Fred's applying for a job as a JavaScript
developer. At the time, there isn't any useful certification process or
formal training which can be used to decide if Fred really knows what
he's talking about. I know that some companies use certifications to
screen applicants, but that's a very bad practice, IMO. Many of the most
talented people I've met are self trained. I've also seen some of those
certifications and heard some enlightening anecdotes about how to get
them in a few days, provided you know the right people or are willing to
invest some cash. The technology is too new and moves too fast for these
types of indicators to work. This leaves us with a gazillion
web/software "developers" and even so-called "engineers", and no
objective way to tell what that means. If he's got a nice homepage, and
the interviewer doesn't know the right questions to ask, Fred may even
get the job. And maybe he'll even grow into it, who knows.

These are not the people I'm competing with. As far as I'm concerned,
they're playing a completely different game. I don't offer "scripting"
or "web design" or "programming". I'm hired for my experience, past
successful projects, my network of colleagues with different special
areas, the infrastructure I can supply, and my ability to talk to both
customers and colleages in a friendly and professional manner. But the
main difference to people like Fred is experience. I wrote my first
program at 13. In the past 11 years, after dropping out of university, I
have worked with many different OSs, on different hardware
architectures, in very different organizational environments, used
different languages (computer and natural), different frameworks and
paradigms, alone or in teams, client side and server side, etc. This
gives me a perspective that newcomers cannot possibly have, and that
experience goes into my hourly rate (the project mentioned earlier
notwithstanding). After hiring 2-3 Freds, customers usually want to "do
it right this time" and hire an expert.

>> There is much to be said for understanding the consequences of 
>> actions, particularly in terms of avoiding the bad ones.

Absolutely.

>> A different moral dilemma might apply to them. Granted, if you are
>> talking about a complete armature doing what they like to please
>> themselves then any consequences (good or bad) fall only on them. But as
>> soon as someone is acting in the role of 'client' is involved the
>> consequences of design decisions are no longer local.

Everybody starts at square one. I'm not particularly proud of the work I
did 12 years ago. Looking back at that time, I certainly wasn't
qualified for some of the tasks I was given, but that was at the height
of the dot-com bubble, and companies were desperate to hire just about
anybody who knew what a computer looked like. So I got to work on real
projects. I don't see any other way for newcomers to get hands-on
experience. Of course, they should be honest and not inflate their own
abilities, or call themselves "gurus" or "ninjas" after a year or two.
Or ever ;-)

> I was interviewed about two years ago by a senior front end engineer 
> with 15 years experience. The first and only technical question was to 
> build a rich text editor.

Write a rich text editor from scratch? Did he want that with or without
a flight simulator plugin? What an odd thing to ask as a demonstration
from a job applicant.

(quote reordered)
> Experience without knowledge isn't much use.
....
> There is no substitute for knowledge [Deming].

I respectfully disagree (with you and Prof. Deming). Knowledge can be
acquired in a short time, if necessary, but experience can't. Deming
died before information systems like the web made it trivially easy to
retrieve required facts from online references. For example, I often
don't remember the exact name or order of arguments for a method, but I
know from experience that such a method exists, and that I can look it
up when I need it. If I can't find the required information, I know
(again, from experience) where I can ask questions and how to formulate
them. There's a German expression which unfortunately can't be directly
translated into English: "Fachidiot". The word describes a person who is
an expert in a limited area, but ignorant about everything outside his
field of expertise. Such a person would have a lot of knowledge about
his area, but _experience_ goes further than that. It implies that
you've seen things fail when you thought that was "impossible", it
implies that you've learned how to deal with difficult co-workers, and
it also implies that you can judge the consequences of your
implementation on systems outside of your own area. For example, from a
JS point of view, that would include issues relating to server-side
proxies, security, network problems, version control, and even
psychology: an experienced person will have heard about ways to improve
the user perception of a piece of software, and the best way to
formulate error messages. A knowledgable newcomer will still have to
learn these things.


-- 
stefan

On Sat, 17 Jul 2010 at 13:13:21, in comp.lang.javascript, Tim Streater
wrote:

  <snip>
>What makes anyone think that F1 is Help?
  <snip>

Once upon a time, when IBM made Personal Computers, they invented a
design standard for Graphical User Interfaces. It said, for instance,
that the menu bar had File at the left hand end and Help at the right
hand end. And it said that F1 is the Help key, preferably context
sensitive.

This standard became so common that people still assume that F1 will be
the Help key, and they are often right.

  John
-- 
John Harris

In article 
<g77VLEHICeQMFws6@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD>,
 John G Harris <john@nospam.demon.co.uk> wrote:

> On Sat, 17 Jul 2010 at 13:13:21, in comp.lang.javascript, Tim Streater
> wrote:
> 
>   <snip>
> >What makes anyone think that F1 is Help?
>   <snip>
> 
> Once upon a time, when IBM made Personal Computers, they invented a
> design standard for Graphical User Interfaces. It said, for instance,
> that the menu bar had File at the left hand end

Really? Before Apple did it? When was this then?

> and Help at the right hand end. And it said that F1 is the Help key,
> preferably context sensitive.
> 
> This standard became so common that people still assume that F1 will be
> the Help key, and they are often right.

Even if they are "often" right, that's still no reason for things like 
"Press F1 for Help" or "Press CTRL-D to add to favorites" (sic) to 
appear on websites, and such website-creators should be smacked.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On Sat, 17 Jul 2010 18:44:41 +0100, Tim Streater wrote:

> In article
> <g77VLEHICeQMFws6@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD>,
>  John G Harris <john@nospam.demon.co.uk> wrote:
> 
>> On Sat, 17 Jul 2010 at 13:13:21, in comp.lang.javascript, Tim Streater
>> wrote:
>> 
>>   <snip>
>> >What makes anyone think that F1 is Help?
>>   <snip>
>> 
>> Once upon a time, when IBM made Personal Computers, they invented a
>> design standard for Graphical User Interfaces. It said, for instance,
>> that the menu bar had File at the left hand end
> 
> Really? Before Apple did it? When was this then?

Oh yes.  [File] on the left hand end was common long before Apple.  You 
*do* realize that we used computers long before they had graphics, don't 
you?  Text screens that still used a 'quasi GUI' by drawing 3D effects 
and shadows ....

I can't swear to it ... but it seems like Turbo Pascal for the CP/M 
machines had a 'file' drop down in the left corner and I do have a word 
processor for my Sol/Helios machine (running PT-DOS on an 8080 S100 bus) 
that has 'File' in the correct place.

The next oldest machine I have prints direct to paper, so we won't count 
that.

In article <M8m0o.18682$cO.11612@newsfe09.iad>,
 Jeremy J Starcher <r3jjs@yahoo.com> wrote:

> On Sat, 17 Jul 2010 18:44:41 +0100, Tim Streater wrote:
> 
> > In article
> > <g77VLEHICeQMFws6@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD>,
> >  John G Harris <john@nospam.demon.co.uk> wrote:
> > 
> >> On Sat, 17 Jul 2010 at 13:13:21, in comp.lang.javascript, Tim Streater
> >> wrote:
> >> 
> >>   <snip>
> >> >What makes anyone think that F1 is Help?
> >>   <snip>
> >> 
> >> Once upon a time, when IBM made Personal Computers, they invented a
> >> design standard for Graphical User Interfaces. It said, for instance,
> >> that the menu bar had File at the left hand end
> > 
> > Really? Before Apple did it? When was this then?
> 
> Oh yes.  [File] on the left hand end was common long before Apple.  You 
> *do* realize that we used computers long before they had graphics, don't 
> you?

:-)

First computer I saw was a KDF9 in 1963. First one I programmed was an 
Elliott 803 in 1965. I used Newton's method to calculate square roots 
and learnt about precision in floating point arithmetic, how you better 
not test for equality.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Jeremy J Starcher <r3jjs@yahoo.com> writes:

> I can't swear to it ... but it seems like Turbo Pascal for the CP/M 
> machines had a 'file' drop down in the left corner

Don't know about the CP/M version, but Turbo Pascal for DOS certainly
had the kind of character-based "gui" you're referring to. And yes, it
had all the "usual" menus - File and Edit at the left, and Help on the
right.

sherm--

-- 
Sherm Pendley                <www.shermpendley.com>
                             <www.camelbones.org>
Cocoa Developer

On Jul 16, 1:03=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:

> When I do have clients they ask me to
> check out different libraries they themselves have come across, and one
> explicitly encouraged me to use a /big/ library like Dojo instead of a
> small one like jQuery so I would not be re-inventing the wheel.

You've certainly got fools for clients.  :)  In the case of Dojo, the
"wheels" they invented are non-starters (think square).  That's why
they are constantly trying to re-invent themselves.  Like Prototype,
I've heard they have plans to scrap most of what has come before and
build a new "Dojo" from the ground up.  Which raises the question of
what is a "Dojo" or a "Prototype"?  AFAICT, they are simply brand
names that are largely synonymous with futility.

>
> Tilton's Law: Solve the right problem.

Oh brother.

> In this case, if the problem is
> that a JS library has a bug, the solution is to fix the bug, not burn
> the library and have every programmer who wants to put up a web page
> spend five years learning HTML and CSS and browser variability.

There are so many things wrong with that, I don't know where to
start.  For one, JS is intended and best-used for enhancing HTML and
CSS.  It's not a substitute.  And "browser variability" is no big deal
these days (provided authors do not attempt to solve every conceivable
problem for everybody).  Yes, the GP library authors fail to get this
basic concept, so they perpetually make browser cross-scripting look
much harder than it is.  It's not the browsers; it's *them*.  If they
weren't trying to do way more than is needed for any given site or
application (i.e. design a monolithic do-everything JS library), they
wouldn't have so many problems.  Can't fix their mindsets, so the only
alternative is to warn beginners to avoid their ill-conceived
products.

Furthermore, I've done more charity work in this area than anybody and
it is typically unappreciated by needy library authors who very
quickly grow confused and irritable and dismiss suggestions as less
than constructive.  Then, a year or two later, something clicks and
they announce to the world that *they* have figured it out (see John
Resig and the case of jQuery's UA sniffing).  And in the interim,
thousands more blissfully download defective versions, polluting the
Web with garbage code that somebody will eventually have to clean up.

>
> That's actually rather obvious, so it's fun seeing the alpha males
> around this NG forever arguing against it.

Arguing against what?

> Using a little FUD to keep
> those billing rates up, are we? Best of luck, these are tough times.
>

FUD?  That's what the displaced Java developers behind Dojo were
saying back around 2007.  They didn't listen to their critics, didn't
learn from their mistakes and just look at them today (going back to
the drawing board).  I have clients who tried Dojo at some point and
I've heard the horror stories.  I'm sure most of them wish they had
never listened to parrots like you.  FUD, squawk!  Re-inventing the
wheel!  Write from scratch; write from scratch; assembly language;
snark; ivory tower; tweet!  Use Dojo.  Who's a pretty boy?  :)

And as for high billing rates, those are a welcome side effect of mass
ignorance and impotence in this area.  The fewer competent JS
developers, the better.  ;)

David Mark wrote:
> Kenneth Tilton wrote:
>> Using a little FUD to keep
>> those billing rates up, are we? Best of luck, these are tough times.
>
> FUD? =A0That's what the displaced Java developers behind Dojo were
> saying back around 2007.

Is that true, Dojo was written by people who thought in Java?  It
would explain a lot.

  -- Scott

On Jul 17, 4:04=A0pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> David Mark wrote:
> > Kenneth Tilton wrote:
> >> Using a little FUD to keep
> >> those billing rates up, are we? Best of luck, these are tough times.
>
> > FUD? =A0That's what the displaced Java developers behind Dojo were
> > saying back around 2007.
>
> Is that true, Dojo was written by people who thought in Java? =A0It
> would explain a lot.
>

Yep and it does indeed.  Avoid like the plague.  :)

On 2010-07-17 08:59 AM, Stefan Weiss wrote:
> On 17/07/10 09:03, Garrett Smith wrote:
>> On 2010-07-16 07:40 AM, Richard Cornford wrote:
>>> Stefan Weiss wrote:
>>>> One more thing. I am a JS developer (among other things), and I
>>>> am able to create these things if I want to. Other people,
>>>> including many web designers
>>>
>>> Does "web designers" mean (effectively) graphical designers working
>>> on/producing websites? (as distinct from 'web developers' responsible
>>> for code/application architecture design, UI interaction design,
>>> database design (in relation to websites), server configuration design,
>>> and so on.)
>>>
>>>> and amateur bloggers, webmasters, etc, don't have that
>>>> experience.
>>>
>>> No, they (mostly) do not. That is not an unexpected situation as
>>> realistically most people do not have experience in most (more than
>>> slightly) specialised things. Generally that is not a problem as
>>> (effectively) we sell our own specialised experience in order to
>>> purchase the experience (or products of the experience) we need/want of
>>> others. And faced with a lack of experience/knowledge in an area most
>>> people are happier (and probably better off) purchasing that experience
>>> than trying to do it themselves.
>>>
>>> Almost nobody, for example, would contemplate making their own china,
>>> even though it would not be at all physically difficult to do so (at
>>> least using available fabrication techniques that do not include
>>> throwing posts on a potter's wheel).
>>
>> There are many interesting things to do in the world and many of them
>> are also dangerous.
>
> The (snipped) story about the dangers of home-made china, while
> interesting, is not a very good analogy to what amateurs are doing on
> the web. At the very least, the analogy grossly exaggerates the
> consequences: build your own china, and people can die from lead
> poisoning; use a substandard script you copied from somewhere, and your
> homepage could break for a certain percentage of visitors.
>
> I realize that this is going to be a minority opinion in a technically
> oriented group such as this, but I still think that everybody - even the
> most clueless newcomers - should be allowed, and even encouraged, to
> play on the web any way they like. Let them use huge animated GIFs,
> background sounds,<blink>  tags, UA sniffing, jQuery or any other JS
> library, let them proclaim that "this site is best viewed with
> {browser}", etc. Anything to get them interested and give them a sense
> of achievement. Some will become fascinated enough that they'll
> eventually learn how to do it right. Other's will not.
>
> I'm firmly convinced that the low barrier of entry, combined with the
> openness of the basic technologies is what allowed the Web to become
> widely accepted and grow to what we see today. Had it been necessary to
> hire a professional to build a homepage, none of this would have happened.
>
> The low barrier of entry has its downsides, of course. Fred (to use a
> random name) looks at the source code of a document, decides to try this
> out for himself, writes 'alert("Hello, world")', and is delighted with
> the result. Three days later Fred's applying for a job as a JavaScript
> developer. At the time, there isn't any useful certification process or
> formal training which can be used to decide if Fred really knows what
> he's talking about. I know that some companies use certifications to
> screen applicants, but that's a very bad practice, IMO. Many of the most
> talented people I've met are self trained. I've also seen some of those
> certifications and heard some enlightening anecdotes about how to get
> them in a few days, provided you know the right people or are willing to
> invest some cash. The technology is too new and moves too fast for these
> types of indicators to work. This leaves us with a gazillion
> web/software "developers" and even so-called "engineers", and no
> objective way to tell what that means. If he's got a nice homepage, and
> the interviewer doesn't know the right questions to ask, Fred may even
> get the job. And maybe he'll even grow into it, who knows.
>

Lack of skill is a fundamental cause of problems with the web. 
Hallvord's blog covers many such examples.

I have interviewed at two design firms where I was brouht into a sort of 
"demo" meeting room where I was asked to pull some URIs of things I've 
worked on on the big monitor. "What a stupid idea," I thought, while 
obliging their requests, showing various widgets I've made and sites 
that I have worked on; including those whose code is so embarrassingly 
bad that I won't even mention them here, yet the clients were impressed 
with that awful code. They seem to have observed those works as 
resembling something of competence, they did not look at any of the 
source code to see that they were a total disaster, which is what I do, 
and had done prior to regretfully taking one of the admittedly well-paid 
jobs.

> These are not the people I'm competing with. As far as I'm concerned,
> they're playing a completely different game. I don't offer "scripting"
> or "web design" or "programming". I'm hired for my experience, past
> successful projects, my network of colleagues with different special
> areas, the infrastructure I can supply, and my ability to talk to both
> customers and colleages in a friendly and professional manner. But the
> main difference to people like Fred is experience. I wrote my first
> program at 13. In the past 11 years, after dropping out of university, I
> have worked with many different OSs, on different hardware
> architectures, in very different organizational environments, used
> different languages (computer and natural), different frameworks and
> paradigms, alone or in teams, client side and server side, etc. This
> gives me a perspective that newcomers cannot possibly have, and that
> experience goes into my hourly rate (the project mentioned earlier
> notwithstanding). After hiring 2-3 Freds, customers usually want to "do
> it right this time" and hire an expert.
>
>>> There is much to be said for understanding the consequences of
>>> actions, particularly in terms of avoiding the bad ones.
>
> Absolutely.

While that is true, if the understanding is actually a misperception of 
consequences, then a false principle has been created and will be 
misapplied in the future.

What it really boils down to is knowledge.

>
>>> A different moral dilemma might apply to them. Granted, if you are
>>> talking about a complete armature doing what they like to please
>>> themselves then any consequences (good or bad) fall only on them. But as
>>> soon as someone is acting in the role of 'client' is involved the
>>> consequences of design decisions are no longer local.
>
> Everybody starts at square one. I'm not particularly proud of the work I
> did 12 years ago. Looking back at that time, I certainly wasn't
> qualified for some of the tasks I was given, but that was at the height
> of the dot-com bubble, and companies were desperate to hire just about
> anybody who knew what a computer looked like. So I got to work on real
> projects. I don't see any other way for newcomers to get hands-on
> experience. Of course, they should be honest and not inflate their own
> abilities, or call themselves "gurus" or "ninjas" after a year or two.
> Or ever ;-)
>

These terms, "ninja" and "guru", are applicable to acts of mysticism. 
Individuals employing what Richard likes to term "mystical incantations" 
don't really understand what they are doing but get a result and may 
apply a post hoc thesis which may or may not be correct. To the observer 
who understands nothing, the outcome of the result cannot be explained 
and so the programmer providing not providing an explanation of the 
outcome is irrelevant.

A consequence of producing an inexplicable result is that those who 
create such results can be named as "ninja" or "guru" -- entirely 
meaningless terms that come with a negative connotation to a very 
limited number of individuals (myself included).

>> I was interviewed about two years ago by a senior front end engineer
>> with 15 years experience. The first and only technical question was to
>> build a rich text editor.
>
> Write a rich text editor from scratch? Did he want that with or without
> a flight simulator plugin? What an odd thing to ask as a demonstration
> from a job applicant.
>
> (quote reordered)
>> Experience without knowledge isn't much use.
> ...
>> There is no substitute for knowledge [Deming].
>
> I respectfully disagree (with you and Prof. Deming). Knowledge can be
> acquired in a short time, if necessary, but experience can't. Deming
> died before information systems like the web made it trivially easy to
> retrieve required facts from online references. For example, I often
> don't remember the exact name or order of arguments for a method, but I
> know from experience that such a method exists, and that I can look it
> up when I need it. If I can't find the required information, I know
> (again, from experience) where I can ask questions and how to formulate
> them. There's a German expression which unfortunately can't be directly
> translated into English: "Fachidiot". The word describes a person who is
> an expert in a limited area, but ignorant about everything outside his
> field of expertise. Such a person would have a lot of knowledge about
> his area, but _experience_ goes further than that. It implies that
> you've seen things fail when you thought that was "impossible", it
> implies that you've learned how to deal with difficult co-workers, and
> it also implies that you can judge the consequences of your
> implementation on systems outside of your own area. For example, from a
> JS point of view, that would include issues relating to server-side
> proxies, security, network problems, version control, and even
> psychology: an experienced person will have heard about ways to improve
> the user perception of a piece of software, and the best way to
> formulate error messages. A knowledgable newcomer will still have to
> learn these things.
>
>
That newcomer is missing knowledge.

That newcomer may continue about the way he has done things all along 
with varying degrees of success. He may do so for many years and may 
gain experience in doing these things without being able to explain 
them. This describes an individual who is experienced but lacks knowledge.

The difference between an individual who can explain something vs one 
who cannot explain comes down to knowledge and understanding. As was 
demonstrated in my interview with the senior front end engineer, 
experience was not a substitute for knowledge.

An experienced developer may, for example, formulate a solution which 
works based on trying to replicate what worked in the past and may enjoy 
varying degrees of success with this.

An example of this is seen in the opening lines to Sencha:

| window.undefined = window.undefined;

Another is in dojo:
dojo.isArray = function(it) {
   return it&&(it instanceof Array||typeof it=="array");
};

The authors of Ext-js and dojo may have more experience than I do. What 
does that say when they continue to publish code that shows a lack of 
knowledge?

Code may be obscurely written, have an unrecognized flaw that applies 
exclusively to the situation (perhaps only in an uncommon case), provide 
a workaround to something irrelevant, contain misleading or obsolete 
comments, be mostly irrelevant, and can be full of bugs that exist in 
code paths that are untested but never reached. The same code may also 
fulfill the requirements.

The author is of such code may be overlooking important considerations 
of code quality including clarity, efficiency, extensibility, etc.

Sufficient criteria for the assessment of front end skill has not been 
formally established. You, I, and Cornford all have seem to have 
expressed that to some degree.

A precursor to making assessments of front end skill is the ability to 
make assessments of the quality of front end code. For that, I have been 
working on the code guidelines document.

<http://jibbering.com/faq/notes/code-guidelines/>

This document can be improved and I would like more feedback on it.

One thing that I have wanted to change is the "Avoid modifying objects 
you don't own. ". While that is a nice trite phrase, it doesn't cover 
the aspects of defining cohesive objects.

"Define cohesive objects" is better but that does not imply that doing 
the opposite is wrong.

"Avoid interdependencies" is better and expounding on host object in 
that section is still appropriate, however some interdependencies make 
sense, so I can't say I'm satisfied with that, either.
-- 
Garrett

On Jul 17, 9:41=A0pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:

[...]

>
> An example of this is seen in the opening lines to Sencha:
>
> | window.undefined =3D window.undefined;

Yes, I can't believe that breakthrough "HTML5 framework" opened with
that old groaner.

>
> Another is in dojo:
> dojo.isArray =3D function(it) {
> =A0 =A0return it&&(it instanceof Array||typeof it=3D=3D"array");
>
> };

Is that *still* there?!  If so, there is truly no hope for them.
IIRC, I explained to one James Burke that it was gobbledygook (and why
that was the case) and he asked me to show him a browser where it
"fails".  :)

If the only justification for a line of code is that it appears to get
the right result, then that line of code has no place in a production
system.  You've got to have at least some semblance of an idea of
*why* it should be expected to work.

For very good reason, programming has never been about mindless
observation.  Rather it is about understanding abstractions.  Testing
programs does involve observation, but only to confirm that there were
no misunderstandings.  And in this business, a thousand positive test
results do not mean the code will work everywhere.  That's where
experience and a knowledge of history come into play.

>
> The authors of Ext-js and dojo may have more experience than I do.

No, they are mostly Ajax-era greenhorns.  Have you seen ExtJS?  Er,
Ext-js.  Or was it Ext JS?  Whatever.  Maybe the name change wasn't
such a bad idea after all (other than breaking a million Google search
results of course).  :)

> What
> does that say when they continue to publish code that shows a lack of
> knowledge?

That they are ignorant.  No news there.  The usual "excuse" is that
they don't have time to learn.  You've got to wonder why so many
developers are keen to use their scripts.  Oh wait...  We are talking
about Dojo and ExtJS after all.  Of course, jQuery is just as
mystically silly and, inexplicably, Prototype was once popular.  Then
there's MooTools...

Somebody asked me recently whether there was any framework I *do*
like.  They asked in a nice enough way, but I could sense their
implication that I was a serial doubter.  Of course, I asked them "a
framework for what?"  The answer was: well, something like Dojo or YUI
or jQuery...  In other words, something that makes outrageous false
claims about making browser scripting accessible to the masses.

>
> Code may be obscurely written, have an unrecognized flaw that applies
> exclusively to the situation (perhaps only in an uncommon case), provide
> a workaround to something irrelevant, contain misleading or obsolete
> comments, be mostly irrelevant, and can be full of bugs that exist in
> code paths that are untested but never reached. The same code may also
> fulfill the requirements.

Hence, "show me where it fails" is the rallying cry for incompetent JS
developers.  Show them anything but the latest versions of three or
four major desktop browsers (in their default configurations) and they
assert that they don't "care" about those cases.  Of course, it's
insanity to project the cares of deluded Web developers onto the
general public (who just want working documents).

>
> The author is of such code may be overlooking important considerations
> of code quality including clarity, efficiency, extensibility, etc.

....competence, sanity, etc.

>
> Sufficient criteria for the assessment of front end skill has not been
> formally established. You, I, and Cornford all have seem to have
> expressed that to some degree.

Then there are things like Dojo.  I think most can agree that it does
not demonstrate skill on the part of its developers.  Delusions yes,
proficiency no.

>
> A precursor to making assessments of front end skill is the ability to
> make assessments of the quality of front end code.

That much is clear.  :)

> For that, I have been
> working on the code guidelines document.
>
> <http://jibbering.com/faq/notes/code-guidelines/>

I think I skimmed it at some point.

>
> This document can be improved and I would like more feedback on it.
>
> One thing that I have wanted to change is the "Avoid modifying objects
> you don't own. ". While that is a nice trite phrase, it doesn't cover
> the aspects of defining cohesive objects.

I think it gets the point across.  It's very easy to by accident (or
in haste).

>
> "Define cohesive objects" is better but that does not imply that doing
> the opposite is wrong.

In contrast, I don't know what that means; so the first one is
definitely better.

>
> "Avoid interdependencies" is better

But something else altogether.

> and expounding on host object in
> that section is still appropriate, however some interdependencies make
> sense, so I can't say I'm satisfied with that, either.

Well, you can't satisfy everybody.  :)

On 2010-07-17 05:13 AM, Tim Streater wrote:
> In article <i1rkkj$lj0$1@news.eternal-september.org>,
> Garrett Smith <dhtmlkitchen@gmail.com> wrote:
>
>
>> That seems out of touch. Surveys aren't a big part of the user story.
>> Like help (F1), these don't get top priority in testing and I've
>> worked at out-of-touch companies that had such surveys along with
>> foreseeresults, and omniture. They employed these because they were
>> out of touch with the end user, ...
>
> What makes anyone think that F1 is Help? Or that "you can add this link
> to your favorites (sic) by typing ctrl-d" or whatever it is? The former
> applies to nothing on my computer and the latter to only one out of five
> browsers I have.
>

Well, sure, F1 might not be help, ctrl + D might not be a bookmark, 
backspace might perform scrolling, navigation, or nothing at all.

Those things depends on the app. The point I was trying to make, and 
what Richard's popup feedback survey example showed, was that such 
features may not be as well tested as the rest of the application.

Additionally help is often a failed user experience. When the user gets 
to that point, it can often be considered a problem. User usually does 
not want to launch help. Help takes time to launch and use. Even if it 
is only 10 seconds, that is still a lot of time for the user. Help also 
changes context and focus of what he was doing and might not even have 
the answer for what he's trying to get done.

Things such as as "help" or "surveys" tend to be not as well-tested. 
They are sometimes irrelevant and may be an indication that the 
application developers are out of touch.

This is generally the case with foreseeresults, which opens windows in 
popups (that can fail), asks questions that are irrelevant (if the user 
ever sees them) using marketing lingo. They rely on cookies to determine 
if the customer has been provided with the survey and since that can 
fail, the user can get the same survey again and again.

Any company that uses foreseeresults is clearly out and using 
foreseeresults won't help change that.

Sorry if that was too long-winded. In short, F1 could be anything and 
web surveys and help are usually indicators of a company that is out of 
touch with the user.
-- 
Garrett

David Mark wrote:
> On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
>> David Mark wrote:
>>> Kenneth Tilton wrote:
>>>> Using a little FUD to keep
>>>> those billing rates up, are we? Best of luck, these are tough times.
>>> FUD?  That's what the displaced Java developers behind Dojo were
>>> saying back around 2007.
>> Is that true, Dojo was written by people who thought in Java?  It
>> would explain a lot.
>>
> 
> Yep and it does indeed.  Avoid like the plague.  :)
> 

I agree. And we would be in de facto agreement over JS libraries were it 
not for qooxdoo (and possibly the proprietary library I gather qooxdoo 
was modelled after). Most JS libraries are bad beyond salvation by 
bugfix. But engineering is like that: eventually someone gets it right.

One thing they got right is hiding HTML/CSS so a new generation of 
developers need not mess with those. ie, The library is not an 
additional learning curve, it replaces several.

Until I see a widget set like qooxdoo's and other things like the 
messaging mechanism and their databinding mechanism and their 
sophisticated layout API in some raw HTML/CSS library, I'll be using 
qooxdoo.

And I am an NIH kinda developer, preferring to roll my own rather than 
sort through someone else's mess in the time I could develop my own.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 18, 11:57=A0am, Kenneth Tilton <kentil...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> >> David Mark wrote:
> >>> Kenneth Tilton wrote:
> >>>> Using a little FUD to keep
> >>>> those billing rates up, are we? Best of luck, these are tough times.
> >>> FUD? =A0That's what the displaced Java developers behind Dojo were
> >>> saying back around 2007.
> >> Is that true, Dojo was written by people who thought in Java? =A0It
> >> would explain a lot.
>
> > Yep and it does indeed. =A0Avoid like the plague. =A0:)
>
> I agree. And we would be in de facto agreement over JS libraries were it
> not for qooxdoo (and possibly the proprietary library I gather qooxdoo
> was modelled after).

And it is likely not a coincidence that you have hitched your wagon to
qooxdoo's star. Perhaps you have a special place in your psyche for
that one?

http://en.wikipedia.org/wiki/Cognitive_dissonance

> Most JS libraries are bad beyond salvation by
> bugfix.

That's 100% correct.  Most developers realize that trying to solve
every problem for every conceivable context is the wrong approach.
Scripts must be downloaded, JS is single-threaded, etc.  Logic says
that context-specific scripts are needed to make non-trivial scripts
download and execute fast enough.  Furthermore, solving every problem
for every *browser* is virtually impossible, so it is necessary to
design around some problems, which you can't do if the stated goal is
to tackle everything at once.

So it follows that working on such projects is left to inexperienced
and/or hopelessly deluded developers who clearly have no shot at
making such omnipotent designs a reality.  They carry on year after
year, giving up on last year's browsers and redirecting their efforts
to the latest in a never-ending quest to do the impossible.  They are
cheered on by have-nots (typically non-programmers or fellow
greenhorns) who desperately want to develop cross-browser scripts, but
require a magical solution to handle every conceivable cross-browser
issue for them.  Inevitably, with time and experience, rational
developers realize that the "anti-library zealots" were right all
along.

> But engineering is like that: eventually someone gets it right.

You don't seem to understand the basic concept, which is that the
library authors are chasing an ill-advised and untenable goal.  You
can never get a wrong design right.  :)

And seeing as IE6 came out around the turn of the century, it is not
2010 and none of the "major" efforts (presumably with armies of
developers behind them) haven't gotten close to getting that browser
"right".  Same for IE7.  The inevitable "solution" is for them to
throw in the towel (which many are now advocating).  Doesn't that tell
you something?

Furthemore, the major browsers (the only ones these efforts seek to
"fix") have been converging for years (recently and most dramatically
illustrated by the preview of IE 9) further reducing the need for
monolithic libraries to "smooth over" the ever-decreasing differences.

As for widget frameworks, they are invariably built atop incompetently-
written libraries, so can be dismissed out of hand.  And as HTML5
creeps in to the picture, they will become increasingly less
attractive (who needs a qooxdoo date picker if the browser has one
built-in?)

Predictably there are already "HTML5 frameworks" popping up, even
before the recommendation is finalized.  And predictably they are
taking the usual approach of ignoring built-in degradation mechanisms
(which they can't can and brand) in favor of dubious hacks (e.g.
browser sniffing).

>
> One thing they got right is hiding HTML/CSS so a new generation of
> developers need not mess with those.

As you've been told repeatedly, "hiding" HTML/CSS means short-
circuiting built-in browser behavior (e.g. layout) and then trying to
rebuild it all with (single-threaded) scripts.  That's obviously
folly.

One pervasive example is the "CSS reset" which wipes out default
styles and then tries to build an "ideal" set that will be appropriate
for every agent.  That clearly makes no sense as default styles are
chosen by browser developers to suit specific environments (e.g.
desktop, phone, tablet).

Another much-maligned practice is sizing everything with pixel units,
which breaks accessibility.  For example, the text zooming feature in
IE breaks completely.  The framework developers know this, but
typically argue that the user should simply use the general zoom
feature and stop getting in the way of their quest to control every
aspect of the browser.  Of course, zooming *everything* causes
horizontal scroll bars, which futher impairs readability.

In reality, they are simply trying to compensate for their ill-advised
GP scripts which are predictably overwhelmed by the diversity of
browsers.  Then there is the antiquated notion that every document
must look exactly the same in every browser (when in fact the goal
should be to leverage each agent as best as possible without breaking
accessibility).

Also, qooxdoo does not have a monopoly on such ill-advised and
overbearing strategies (see ExtJS, Cappuccino, etc.)  The authors of
these scripts just don't get it.  Either that or they refuse to get it
as that would get in the way of book sales.

> ie, The library is not an
> additional learning curve, it replaces several.

It certainly is an additional learning curve and it (sort of) replaces
many built-in and standard features that you could have gotten for
free with dubious and ever-shifting scripts that cost dearly in terms
of performance and usability.  In short you are learning the wrong
things.

>
> Until I see a widget set like qooxdoo's and other things like the
> messaging mechanism and their databinding mechanism and their
> sophisticated layout API in some raw HTML/CSS library, I'll be using
> qooxdoo.

The widgets are slow, bloated, over-engineered junk and nothing you
are writing needs the overkill of messaging and data-binding
mechanisms.  As for the "sophisticated" layout API, it is demonstrably
less sophisticated (and far less useful) than the built-in mechanisms
it aspires to replace.  And these pipe dreams come at a price that is
prohibitive (as evidenced by your recent "train wreck" example).

>
> And I am an NIH kinda developer, preferring to roll my own rather than
> sort through someone else's mess in the time I could develop my own.
>

In the time you've spent sorting through qooxdoo (with no end in
sight), you could have learned how to leverge the browser's built-in
layout engine, XHR, etc. to create your algebra application in
something far less than 1MB.  Also, unlike qooxdoo, those represent
marketable skills.  ;)

David Mark wrote:
> On Jul 18, 11:57 am, Kenneth Tilton <kentil...@gmail.com> wrote:
>> David Mark wrote:
>>> On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> Kenneth Tilton wrote:
>>>>>> Using a little FUD to keep
>>>>>> those billing rates up, are we? Best of luck, these are tough times.
>>>>> FUD?  That's what the displaced Java developers behind Dojo were
>>>>> saying back around 2007.
>>>> Is that true, Dojo was written by people who thought in Java?  It
>>>> would explain a lot.
>>> Yep and it does indeed.  Avoid like the plague.  :)
>> I agree. And we would be in de facto agreement over JS libraries were it
>> not for qooxdoo (and possibly the proprietary library I gather qooxdoo
>> was modelled after).
> 
> And it is likely not a coincidence that you have hitched your wagon to
> qooxdoo's star. Perhaps you have a special place in your psyche for
> that one?
> 
> http://en.wikipedia.org/wiki/Cognitive_dissonance
> 
>> Most JS libraries are bad beyond salvation by
>> bugfix.
> 
> That's 100% correct.  Most developers realize that trying to solve
> every problem for every conceivable context is the wrong approach.

See straw. See man. See straw man.

> Scripts must be downloaded, JS is single-threaded, etc.  Logic says
> that context-specific scripts are needed to make non-trivial scripts
> download and execute fast enough.  Furthermore, solving every problem
> for every *browser* is virtually impossible, so it is necessary to
> design around some problems, which you can't do if the stated goal is
> to tackle everything at once.
> 
> So it follows that working on such projects is left to inexperienced
> and/or hopelessly deluded developers who clearly have no shot at
> making such omnipotent designs a reality.  They carry on year after
> year, giving up on last year's browsers and redirecting their efforts
> to the latest in a never-ending quest to do the impossible.  They are
> cheered on by have-nots (typically non-programmers or fellow
> greenhorns) who desperately want to develop cross-browser scripts, but
> require a magical solution to handle every conceivable cross-browser
> issue for them.  Inevitably, with time and experience, rational
> developers realize that the "anti-library zealots" were right all
> along.
> 
>> But engineering is like that: eventually someone gets it right.
> 
> You don't seem to understand the basic concept, which is that the
> library authors are chasing an ill-advised and untenable goal.  You
> can never get a wrong design right.  :)

Nonsense. You think you can work around browser variability, ergo anyone 
can. QED. If you think you are so blessed by the hand of G*d that no one 
else can achieve what you have, then that includes me so if you don't 
mind I'll get to work with these mortals over here.

> 
> And seeing as IE6 came out around the turn of the century, it is not
> 2010 and none of the "major" efforts (presumably with armies of
> developers behind them) haven't gotten close to getting that browser
> "right".  Same for IE7.  The inevitable "solution" is for them to
> throw in the towel (which many are now advocating).  Doesn't that tell
> you something?
> 
> Furthemore, the major browsers (the only ones these efforts seek to
> "fix") have been converging for years (recently and most dramatically
> illustrated by the preview of IE 9) further reducing the need for
> monolithic libraries to "smooth over" the ever-decreasing differences.

I am sorry, but you are being dense: I want to work on this:

     http://teamalgebra.com/

Not "how to program the web". Do you have one spare neuron to get that?

<sigh>


> 
> As for widget frameworks, they are invariably built atop incompetently-
> written libraries, so can be dismissed out of hand.

You keep making things up to defend your disappearing employability, and 
I'll keep responding: I have dug into their code to understand and/or 
fix stuff. It is quite solid (and I almost never like OP code.)

In case you are wondering, yes, I am a better programmer than you: I 
know because I do not make things up to generate work.

>  And as HTML5
> creeps in to the picture, they will become increasingly less
> attractive (who needs a qooxdoo date picker if the browser has one
> built-in?)
> 
> Predictably there are already "HTML5 frameworks" popping up, even
> before the recommendation is finalized.  And predictably they are
> taking the usual approach of ignoring built-in degradation mechanisms
> (which they can't can and brand) in favor of dubious hacks (e.g.
> browser sniffing).
> 
>> One thing they got right is hiding HTML/CSS so a new generation of
>> developers need not mess with those.
> 
> As you've been told repeatedly, "hiding" HTML/CSS means short-
> circuiting built-in browser behavior (e.g. layout) and then trying to
> rebuild it all with (single-threaded) scripts.  That's obviously
> folly.

It works great. I know that kills you, but we should draw the truth into 
this thread at some point.

> 
> One pervasive example is the "CSS reset" which wipes out default
> styles and then tries to build an "ideal" set that will be appropriate
> for every agent.  That clearly makes no sense as default styles are
> chosen by browser developers to suit specific environments (e.g.
> desktop, phone, tablet).
> 
> Another much-maligned practice is sizing everything with pixel units,
> which breaks accessibility.  For example, the text zooming feature in
> IE breaks completely.  The framework developers know this, but
> typically argue that the user should simply use the general zoom
> feature and stop getting in the way of their quest to control every
> aspect of the browser.  Of course, zooming *everything* causes
> horizontal scroll bars, which futher impairs readability.
> 
> In reality, they are simply trying to compensate for their ill-advised
> GP scripts which are predictably overwhelmed by the diversity of
> browsers.  Then there is the antiquated notion that every document
> must look exactly the same in every browser (when in fact the goal
> should be to leverage each agent as best as possible without breaking
> accessibility).
> 
> Also, qooxdoo does not have a monopoly on such ill-advised and
> overbearing strategies (see ExtJS, Cappuccino, etc.)  The authors of
> these scripts just don't get it.  Either that or they refuse to get it
> as that would get in the way of book sales.
> 
>> ie, The library is not an
>> additional learning curve, it replaces several.
> 
> It certainly is an additional learning curve and it (sort of) replaces
> many built-in and standard features that you could have gotten for
> free with dubious and ever-shifting scripts that cost dearly in terms
> of performance and usability.  In short you are learning the wrong
> things.

What on earth makes you think I was not messing with raw HTML/CSS before 
trying JS libraries? I have seen the enemy, and it is not me.

> 
>> Until I see a widget set like qooxdoo's and other things like the
>> messaging mechanism and their databinding mechanism and their
>> sophisticated layout API in some raw HTML/CSS library, I'll be using
>> qooxdoo.
> 
> The widgets are slow, bloated, over-engineered junk and nothing you
> are writing needs the overkill of messaging and data-binding
> mechanisms.

Just keep saying that. Bush got us into Iraq with that approach, so you 
have a good shot.

>  As for the "sophisticated" layout API, it is demonstrably
> less sophisticated (and far less useful) than the built-in mechanisms
> it aspires to replace.

Oh, I see you have never used them.

>  And these pipe dreams come at a price that is
> prohibitive (as evidenced by your recent "train wreck" example).

It's kinda sad when someone of your supposed intellect and expertise 
tries a cheap shot like that. A moment of silence for your self-respect.

> 
>> And I am an NIH kinda developer, preferring to roll my own rather than
>> sort through someone else's mess in the time I could develop my own.
>>
> 
> In the time you've spent sorting through qooxdoo (with no end in
> sight), you could have learned how to leverge the browser's built-in
> layout engine, XHR, etc. to create your algebra application in
> something far less than 1MB.  Also, unlike qooxdoo, those represent
> marketable skills.  ;)

I am not a web application developer, I am changing the way kids 
experience Algebra: http://teamalgebra.com/

ie, You just don't get it, or you do not want to: you want to obsess all 
day over MTML/CSS/browser variability. Good for you! But if you want the 
attention of us working on higher-order problems, you have to produce 
something that competes with qooxdoo.

But I think you know that by now. I sure hope you know that by now.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 18, 6:53=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 18, 11:57 am, Kenneth Tilton <kentil...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> >>>> David Mark wrote:
> >>>>> Kenneth Tilton wrote:
> >>>>>> Using a little FUD to keep
> >>>>>> those billing rates up, are we? Best of luck, these are tough time=
s.
> >>>>> FUD? =A0That's what the displaced Java developers behind Dojo were
> >>>>> saying back around 2007.
> >>>> Is that true, Dojo was written by people who thought in Java? =A0It
> >>>> would explain a lot.
> >>> Yep and it does indeed. =A0Avoid like the plague. =A0:)
> >> I agree. And we would be in de facto agreement over JS libraries were =
it
> >> not for qooxdoo (and possibly the proprietary library I gather qooxdoo
> >> was modelled after).
>
> > And it is likely not a coincidence that you have hitched your wagon to
> > qooxdoo's star. Perhaps you have a special place in your psyche for
> > that one?
>
> >http://en.wikipedia.org/wiki/Cognitive_dissonance
>
> >> Most JS libraries are bad beyond salvation by
> >> bugfix.
>
> > That's 100% correct. =A0Most developers realize that trying to solve
> > every problem for every conceivable context is the wrong approach.
>
> See straw. See man. See straw man.
>

See the loveli lakes.

>
>
> > Scripts must be downloaded, JS is single-threaded, etc. =A0Logic says
> > that context-specific scripts are needed to make non-trivial scripts
> > download and execute fast enough. =A0Furthermore, solving every problem
> > for every *browser* is virtually impossible, so it is necessary to
> > design around some problems, which you can't do if the stated goal is
> > to tackle everything at once.
>
> > So it follows that working on such projects is left to inexperienced
> > and/or hopelessly deluded developers who clearly have no shot at
> > making such omnipotent designs a reality. =A0They carry on year after
> > year, giving up on last year's browsers and redirecting their efforts
> > to the latest in a never-ending quest to do the impossible. =A0They are
> > cheered on by have-nots (typically non-programmers or fellow
> > greenhorns) who desperately want to develop cross-browser scripts, but
> > require a magical solution to handle every conceivable cross-browser
> > issue for them. =A0Inevitably, with time and experience, rational
> > developers realize that the "anti-library zealots" were right all
> > along.
>
> >> But engineering is like that: eventually someone gets it right.
>
> > You don't seem to understand the basic concept, which is that the
> > library authors are chasing an ill-advised and untenable goal. =A0You
> > can never get a wrong design right. =A0:)
>
> Nonsense. You think you can work around browser variability, ergo anyone
> can. QED.

Certainly I can better than most (as should be evident by now).  As
for *anyone*, in the context of a general-purpose do-everything
framework, I'm going to have to disagree.  As evidence, we have
roughly five years of jQuery, Prototype, Dojo, etc. and not one of
them has come close to "solving" IE6, which predates their existence
by about five years.  Do the math.  And I'm not talking about obscure
bugs and minor mistakes, but well-known issues and blunders so obvious
they practically jump off the screen.

> If you think you are so blessed by the hand of G*d that no one
> else can achieve what you have, then that includes me so if you don't
> mind I'll get to work with these mortals over here.

The wonderful telephone system.

>
>
>
> > And seeing as IE6 came out around the turn of the century, it is not
> > 2010 and none of the "major" efforts (presumably with armies of
> > developers behind them) haven't gotten close to getting that browser
> > "right". =A0Same for IE7. =A0The inevitable "solution" is for them to
> > throw in the towel (which many are now advocating). =A0Doesn't that tel=
l
> > you something?
>
> > Furthemore, the major browsers (the only ones these efforts seek to
> > "fix") have been converging for years (recently and most dramatically
> > illustrated by the preview of IE 9) further reducing the need for
> > monolithic libraries to "smooth over" the ever-decreasing differences.
>
> I am sorry, but you are being dense: I want to work on this:
>
> =A0 =A0 =A0http://teamalgebra.com/

Then work on it.  But don't blame me when your chosen monolith
explodes.  I warned you (as did many others).

>
> Not "how to program the web". Do you have one spare neuron to get that?

A moose once bit my sister...

>
> <sigh>
>
>
>
> > As for widget frameworks, they are invariably built atop incompetently-
> > written libraries, so can be dismissed out of hand.
>
> You keep making things up to defend your disappearing employability, and
> I'll keep responding: I have dug into their code to understand and/or
> fix stuff. It is quite solid (and I almost never like OP code.)

More like you keep making things up to prop up your disappearing self-
image.  And the more deluded clods out there the better.  Eventually
omebody has to clean up their messes.  ;)

>
> In case you are wondering, yes, I am a better programmer than you: I
> know because I do not make things up to generate work.

Mynd you, moose bites Kan be pretti nasti...


>
>
>
>
>
> > =A0And as HTML5
> > creeps in to the picture, they will become increasingly less
> > attractive (who needs a qooxdoo date picker if the browser has one
> > built-in?)
>
> > Predictably there are already "HTML5 frameworks" popping up, even
> > before the recommendation is finalized. =A0And predictably they are
> > taking the usual approach of ignoring built-in degradation mechanisms
> > (which they can't can and brand) in favor of dubious hacks (e.g.
> > browser sniffing).
>
> >> One thing they got right is hiding HTML/CSS so a new generation of
> >> developers need not mess with those.
>
> > As you've been told repeatedly, "hiding" HTML/CSS means short-
> > circuiting built-in browser behavior (e.g. layout) and then trying to
> > rebuild it all with (single-threaded) scripts. =A0That's obviously
> > folly.
>
> It works great. I know that kills you, but we should draw the truth into
> this thread at some point.

"It works great" is a bit vague for a technical discussion.  And
coming from the engineer of one of the worst train wrecks ever
reported...

>
>
>
>
>
> > One pervasive example is the "CSS reset" which wipes out default
> > styles and then tries to build an "ideal" set that will be appropriate
> > for every agent. =A0That clearly makes no sense as default styles are
> > chosen by browser developers to suit specific environments (e.g.
> > desktop, phone, tablet).
>
> > Another much-maligned practice is sizing everything with pixel units,
> > which breaks accessibility. =A0For example, the text zooming feature in
> > IE breaks completely. =A0The framework developers know this, but
> > typically argue that the user should simply use the general zoom
> > feature and stop getting in the way of their quest to control every
> > aspect of the browser. =A0Of course, zooming *everything* causes
> > horizontal scroll bars, which futher impairs readability.
>
> > In reality, they are simply trying to compensate for their ill-advised
> > GP scripts which are predictably overwhelmed by the diversity of
> > browsers. =A0Then there is the antiquated notion that every document
> > must look exactly the same in every browser (when in fact the goal
> > should be to leverage each agent as best as possible without breaking
> > accessibility).
>
> > Also, qooxdoo does not have a monopoly on such ill-advised and
> > overbearing strategies (see ExtJS, Cappuccino, etc.) =A0The authors of
> > these scripts just don't get it. =A0Either that or they refuse to get i=
t
> > as that would get in the way of book sales.
>
> >> ie, The library is not an
> >> additional learning curve, it replaces several.
>
> > It certainly is an additional learning curve and it (sort of) replaces
> > many built-in and standard features that you could have gotten for
> > free with dubious and ever-shifting scripts that cost dearly in terms
> > of performance and usability. =A0In short you are learning the wrong
> > things.
>
> What on earth makes you think I was not messing with raw HTML/CSS before
> trying JS libraries? I have seen the enemy, and it is not me.

Again with the "raw HTML" reference.  What does that even mean?  And
I'm sure you were messing up HTML/CSS long before you started messing
up JS.  Is that supposed to be a defense?

>
>
>
> >> Until I see a widget set like qooxdoo's and other things like the
> >> messaging mechanism and their databinding mechanism and their
> >> sophisticated layout API in some raw HTML/CSS library, I'll be using
> >> qooxdoo.
>
> > The widgets are slow, bloated, over-engineered junk and nothing you
> > are writing needs the overkill of messaging and data-binding
> > mechanisms.
>
> Just keep saying that. Bush got us into Iraq with that approach, so you
> have a good shot.

I know I'll regret asking this, but what approach?  And what am I
supposed to be aiming at?

>
> > =A0As for the "sophisticated" layout API, it is demonstrably
> > less sophisticated (and far less useful) than the built-in mechanisms
> > it aspires to replace.
>
> Oh, I see you have never used them.

I don't need to use them to see that they are useless.

>
> > =A0And these pipe dreams come at a price that is
> > prohibitive (as evidenced by your recent "train wreck" example).
>
> It's kinda sad when someone of your supposed intellect and expertise
> tries a cheap shot like that. A moment of silence for your self-respect.

You are the one who labeled it a "train wreck", remember?  I'm just
pointing out the irony that you seem to have been emboldened by the
experience.

>
>
>
> >> And I am an NIH kinda developer, preferring to roll my own rather than
> >> sort through someone else's mess in the time I could develop my own.
>
> > In the time you've spent sorting through qooxdoo (with no end in
> > sight), you could have learned how to leverge the browser's built-in
> > layout engine, XHR, etc. to create your algebra application in
> > something far less than 1MB. =A0Also, unlike qooxdoo, those represent
> > marketable skills. =A0;)
>
> I am not a web application developer, I am changing the way kids
> experience Algebra:http://teamalgebra.com/

Kids are notoriously impatient.  I predict your application is going
to drop dead.

>
> ie, You just don't get it, or you do not want to: you want to obsess all
> day over MTML/CSS/browser variability. Good for you!

Do you read these ravings before you post them?  You come off like a
babbling psychotic.

> But if you want the
> attention of us working on higher-order problems, you have to produce
> something that competes with qooxdoo.

I could do very well without your attention, thanks.

>
> But I think you know that by now. I sure hope you know that by now.
>

Best of luck with your "higher-order" problems!  :)

In article <4c4385f1$0$22522$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:


> I am not a web application developer, I am changing the way kids 
> experience Algebra: http://teamalgebra.com/

1) What's with the non-standard scroll-bars?

2) What's with all the keys with nothing on them in the typing tutorial?

Firefox shows fewer blank keys than Safari but not many.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

David Mark wrote:
> On Jul 18, 6:53 pm, Kenneth Tilton <kentil...@gmail.com> wrote:

>>>  And these pipe dreams come at a price that is
>>> prohibitive (as evidenced by your recent "train wreck" example).
>> It's kinda sad when someone of your supposed intellect and expertise
>> tries a cheap shot like that. A moment of silence for your self-respect.
> 
> You are the one who labeled it a "train wreck", remember?  I'm just
> pointing out the irony that you seem to have been emboldened by the
> experience.

Yeah, I did, in reference to the ongoing development on my end. So it's 
a cheap shot to present that as qooxdoo being a problem, given that I 
was at the same time raving about qooxdoo (and linking to non-rave 
experiences with other JS libraries).

I'll give you the benefit of the doubt that you lost that context.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Tim Streater wrote:
> In article <4c4385f1$0$22522$607ed4bc@cv.net>,
> Kenneth Tilton <kentilton@gmail.com> wrote:
> 
> 
>> I am not a web application developer, I am changing the way kids 
>> experience Algebra: http://teamalgebra.com/
> 
> 1) What's with the non-standard scroll-bars?

Define "standard".

> 
> 2) What's with all the keys with nothing on them in the typing tutorial?
> 
> Firefox shows fewer blank keys than Safari but not many.
> 

That's where I do raw HTML/CSS. :)

The keys are rendered by HTML generated by jsMath. I have an outstanding 
issue I hope to defer in re the positioning done by jsMath, and if that 
is in play the keys are being rendered outside the buttons. Or it could 
be something to do with you likely not having jsMath fonts installed.

That said, I just checked FF, Chrome, and Safari on Windows and Mac and 
Ubuntu, with and without installed jsMath fonts on the Mac, cannot recreate.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Tim Streater wrote:
> In article <4c4385f1$0$22522$607ed4bc@cv.net>,
> Kenneth Tilton <kentilton@gmail.com> wrote:
> 
> 
>> I am not a web application developer, I am changing the way kids 
>> experience Algebra: http://teamalgebra.com/
> 
> 1) What's with the non-standard scroll-bars?
> 
> 2) What's with all the keys with nothing on them in the typing tutorial?
> 
> Firefox shows fewer blank keys than Safari but not many.
> 

btw, if you click on any yellow area (it should turn white) and type the 
keys: E = m c 2 does E=mc^2 appear? OK, or mostly off the top? If you 
then click on a different yellow area does the formula shift vertically?

btw #2: Thx for the report.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

In article <4c449409$0$5008$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:

> Tim Streater wrote:
> > In article <4c4385f1$0$22522$607ed4bc@cv.net>,
> > Kenneth Tilton <kentilton@gmail.com> wrote:
> > 
> > 
> >> I am not a web application developer, I am changing the way kids 
> >> experience Algebra: http://teamalgebra.com/
> > 
> > 1) What's with the non-standard scroll-bars?
> > 
> > 2) What's with all the keys with nothing on them in the typing tutorial?
> > 
> > Firefox shows fewer blank keys than Safari but not many.
> > 
> 
> btw, if you click on any yellow area (it should turn white) and type the 
> keys: E = m c 2 does E=mc^2 appear? OK, or mostly off the top?

Looks OK in Safari 5.0 Mac.

> If you then click on a different yellow area does the formula
> shift vertically?

No.

> btw #2: Thx for the report.

np.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

In article <4c44933b$0$7594$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:

> Tim Streater wrote:
> > In article <4c4385f1$0$22522$607ed4bc@cv.net>,
> > Kenneth Tilton <kentilton@gmail.com> wrote:
> > 
> > 
> >> I am not a web application developer, I am changing the way kids 
> >> experience Algebra: http://teamalgebra.com/
> > 
> > 1) What's with the non-standard scroll-bars?
> 
> Define "standard".

As provided by the host OS.

> > 2) What's with all the keys with nothing on them in the typing tutorial?
> > 
> > Firefox shows fewer blank keys than Safari but not many.
> > 
> 
> That's where I do raw HTML/CSS. :)
> 
> The keys are rendered by HTML generated by jsMath. I have an outstanding 
> issue I hope to defer in re the positioning done by jsMath, and if that 
> is in play the keys are being rendered outside the buttons. Or it could 
> be something to do with you likely not having jsMath fonts installed.

Whatever they may be :-)

> That said, I just checked FF, Chrome, and Safari on Windows and Mac and 
> Ubuntu, with and without installed jsMath fonts on the Mac, cannot recreate.

I'll see if I can e-mail you a screenshot and I'll try those other 
browsers.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Tim Streater wrote:
> In article <4c44933b$0$7594$607ed4bc@cv.net>,
> Kenneth Tilton <kentilton@gmail.com> wrote:
> 
>> Tim Streater wrote:
>> > In article <4c4385f1$0$22522$607ed4bc@cv.net>,
>> > Kenneth Tilton <kentilton@gmail.com> wrote:
>> > > >> I am not a web application developer, I am changing the way 
>> kids >> experience Algebra: http://teamalgebra.com/
>> > > 1) What's with the non-standard scroll-bars?
>>
>> Define "standard".
> 
> As provided by the host OS.
> 
>> > 2) What's with all the keys with nothing on them in the typing 
>> tutorial?
>> > > Firefox shows fewer blank keys than Safari but not many.
>> >
>> That's where I do raw HTML/CSS. :)
>>
>> The keys are rendered by HTML generated by jsMath. I have an 
>> outstanding issue I hope to defer in re the positioning done by 
>> jsMath, and if that is in play the keys are being rendered outside the 
>> buttons. Or it could be something to do with you likely not having 
>> jsMath fonts installed.
> 
> Whatever they may be :-)

http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html

Sposed to be faster/prettier with those installed.

I dragged them out of Mac Fonts folder, restarted, reset Safari, still 
OK. I bet you are timing out waiting for the fallback image fonts. Just 
now they all came up blank and a good 750ms later got filled in.

kt

> 
>> That said, I just checked FF, Chrome, and Safari on Windows and Mac 
>> and Ubuntu, with and without installed jsMath fonts on the Mac, cannot 
>> recreate.
> 
> I'll see if I can e-mail you a screenshot and I'll try those other 
> browsers.
> 




-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 19, 1:41=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 18, 6:53 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> >>> =A0And these pipe dreams come at a price that is
> >>> prohibitive (as evidenced by your recent "train wreck" example).
> >> It's kinda sad when someone of your supposed intellect and expertise
> >> tries a cheap shot like that. A moment of silence for your self-respec=
t.
>
> > You are the one who labeled it a "train wreck", remember? =A0I'm just
> > pointing out the irony that you seem to have been emboldened by the
> > experience.
>
> Yeah, I did, in reference to the ongoing development on my end.

Yes.  Seems appropriate.

> So it's
> a cheap shot to present that as qooxdoo being a problem, given that I
> was at the same time raving about qooxdoo (and linking to non-rave
> experiences with other JS libraries).

Except that it's been well-established that qooxdoo was the root of
your woes.  Your "ravings" notwithstanding.

David Mark wrote:
> On Jul 19, 1:41 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> David Mark wrote:
>>> On Jul 18, 6:53 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>>>>>  And these pipe dreams come at a price that is
>>>>> prohibitive (as evidenced by your recent "train wreck" example).
>>>> It's kinda sad when someone of your supposed intellect and expertise
>>>> tries a cheap shot like that. A moment of silence for your self-respect.
>>> You are the one who labeled it a "train wreck", remember?  I'm just
>>> pointing out the irony that you seem to have been emboldened by the
>>> experience.
>> Yeah, I did, in reference to the ongoing development on my end.
> 
> Yes.  Seems appropriate.
> 
>> So it's
>> a cheap shot to present that as qooxdoo being a problem, given that I
>> was at the same time raving about qooxdoo (and linking to non-rave
>> experiences with other JS libraries).
> 
> Except that it's been well-established that qooxdoo was the root of
> your woes.  Your "ravings" notwithstanding.

Well so much for giving people the benefit of the doubt. :)

I'll prove you wrong when I have my next release ready and need an 
excuse to post again. Adding persistence now so kids can "level up" in 
Algebra and save their work.

Here's the DB I am using: http://www.franz.com/agraph/allegrograph/

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 19, 4:34=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 19, 1:41 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> >> David Mark wrote:
> >>> On Jul 18, 6:53 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> >>>>> =A0And these pipe dreams come at a price that is
> >>>>> prohibitive (as evidenced by your recent "train wreck" example).
> >>>> It's kinda sad when someone of your supposed intellect and expertise
> >>>> tries a cheap shot like that. A moment of silence for your self-resp=
ect.
> >>> You are the one who labeled it a "train wreck", remember? =A0I'm just
> >>> pointing out the irony that you seem to have been emboldened by the
> >>> experience.
> >> Yeah, I did, in reference to the ongoing development on my end.
>
> > Yes. =A0Seems appropriate.
>
> >> So it's
> >> a cheap shot to present that as qooxdoo being a problem, given that I
> >> was at the same time raving about qooxdoo (and linking to non-rave
> >> experiences with other JS libraries).
>
> > Except that it's been well-established that qooxdoo was the root of
> > your woes. =A0Your "ravings" notwithstanding.
>
> Well so much for giving people the benefit of the doubt. :)

So much for assuming you can understand reason.  :(

>
> I'll prove you wrong when I have my next release ready and need an
> excuse to post again.

ISTM you are never short of excuses.

David Mark wrote:
> On Jul 19, 4:34 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> I'll prove you wrong when I have my next release ready and need an
>> excuse to post again.
> 
> ISTM you are never short of excuses.

Don't sell yourself short: you are the wind beneath my spam.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Kenneth Tilton <kentilton@gmail.com> writes:
> Tim Streater wrote:
>> Kenneth Tilton <kentilton@gmail.com> wrote:
>>> Tim Streater wrote:
>>> > Kenneth Tilton <kentilton@gmail.com> wrote:

>>> >> experience Algebra: http://teamalgebra.com/

>>> > 2) What's with all the keys with nothing on them in the typing
>>> tutorial?

>>> buttons. Or it could be something to do with you likely not having
>>> jsMath fonts installed.

>> Whatever they may be :-)

> http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html
> Sposed to be faster/prettier with those installed.

Don't expect everybody to have every possible font installed.
Whenever a site needs some specific font, it should say so on the front
page and provide a download link.

-- 
Jukka Lahtinen

Jukka Lahtinen wrote:
> Kenneth Tilton <kentilton@gmail.com> writes:
>> Tim Streater wrote:
>>> Kenneth Tilton <kentilton@gmail.com> wrote:
>>>> Tim Streater wrote:
>>>>> Kenneth Tilton <kentilton@gmail.com> wrote:
> 
>>>>>> experience Algebra: http://teamalgebra.com/
> 
>>>>> 2) What's with all the keys with nothing on them in the typing
>>>> tutorial?
> 
>>>> buttons. Or it could be something to do with you likely not having
>>>> jsMath fonts installed.
> 
>>> Whatever they may be :-)
> 
>> http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html
>> Sposed to be faster/prettier with those installed.
> 
> Don't expect everybody to have every possible font installed.
> Whenever a site needs some specific font, it should say so on the front
> page and provide a download link.
> 

Right. I said "Sposed to be" deliberately: looks good and goes fast 
without them.

Agreed: adding "link to fonts for serious users" to do list, but I am 
working under the assumption that users will not have the fonts installed.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Bad news: Qooxdoo/Lisp looking better/faster all the time:

    http://teamalgebra.com/

1. Registering can be ignored for now. It will be needed to do Missions, 
but that's not ready yet. Recovering login does not work yet (forgot to 
remove that option).

2. Should load faster. Curious how folks far from US east coast do.

3. If you do register, your info will be stored using AllegroGraph!

4. qooxdoo continues to rock, as does qooxlisp. I could file a bug or 
rfe against qooxdoo every four hours, but so far it's superficial stuff 
easily worked around at the cost of some UI elegance. (You'll laugh if 
you try tabbing through the fields of the registration form.

5. Enjoy. And tell your Algebra teacher friends I am looking for local 
schools interested in being guinea pigs.

kt


-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 20, 5:44=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> Bad news: Qooxdoo/Lisp looking better/faster all the time:

Bad news for whom?

>
> =A0 =A0http://teamalgebra.com/

The initial script it downloads is still over one *million* bytes.
Oddly enough, it seems to go back to the server constantly during user
interaction.

>
> 1. Registering can be ignored for now.

No worries there.  :)

> It will be needed to do Missions,
> but that's not ready yet. Recovering login does not work yet (forgot to
> remove that option).
>
> 2. Should load faster. Curious how folks far from US east coast do.

I'm near there and have a fairly speedy broadband connection, yet it
took several seconds to progress past the white screen stage.

>
> 3. If you do register, your info will be stored using AllegroGraph!

Great.  What the hell is that?

>
> 4. qooxdoo continues to rock, as does qooxlisp.

Groan.  You misspelled suck.

> I could file a bug or
> rfe against qooxdoo every four hours, but so far it's superficial stuff
> easily worked around at the cost of some UI elegance. (You'll laugh if
> you try tabbing through the fields of the registration form.

Or cry perhaps.

>
> 5. Enjoy. And tell your Algebra teacher friends I am looking for local
> schools interested in being guinea pigs.
>

If you do, they likely won't remain friends. :(

It's interesting that qooxdoo eschewed the browsers' built-in
scrolling mechanisms and tried to build the same functionality with
script.  They failed miserably as I can't scroll by clicking the
mousewheel and then moving the mouse.  Furthermore, resizing the
window to the point where the tabs' content overflows does not produce
any scroll bars, so basic usability is ruined.  And why?  Do you think
those gray-ish scroll bars are more aesthetically pleasing than those
provided by the browsers?  I don't.  Were you concerned they would
clash with your all-gray color scheme?  :)

And do you really think that any of this mess will be accessible to
handicapped students?  It's ironic that your overweight application is
all tabs and (fake) form controls.  FYI there is nothing to creating a
"tabstrip" widget and real form controls are infinitely preferable to
your washed out looking phonies.  Why do you think your keyboard
navigation is such a mess?  Zooming in eventually displays some sort
of scrolling interface for the tabs, but not the content.  This is
backwards.  Widgets should not have any need to respond to changes in
the zoom factor, but the page content should certainly be able to be
scrolled (which it would automatically if you hadn't used an ill-
advised "layout" script instead of HTML).

Also that picture on the "Community" tab (which does nothing) looks
like Big Boy after a crash diet and a week-long bender.  He appears to
be pan-handling too.  On the "Notebook" tab (also bereft of meaningful
content), he appears to have sobered up and snapped back into his
normal pose, but it seems he lost his giant hamburger.  :)

http://melindaschwakhofer.files.wordpress.com/2008/02/bigboy.jpg

I suppose you are trolling for feedback.  My message, which you should
pass along to the qooxdoo people is: what's wrong with you?

David Mark wrote:
> On Jul 20, 5:44 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> Bad news: Qooxdoo/Lisp looking better/faster all the time:
> 
> Bad news for whom?

Your skill set sleeps with the fishes. I recommend bartending school. 
Proof: I know next to nothing about html/css and am no qooxdoo guru and 
look at this:

    http://teamalgebra.com/

Done in ten weeks, most of those part-time/weekends-only. Now look at this:

    http://www.cinsoft.net/mylib-builder.asp

Checkboxes, the universal widget?

QED.

> 
>>    http://teamalgebra.com/
> 
> The initial script it downloads is still over one *million* bytes.

That's *eight million* bits!! Loads in less than three seconds on the 
east coast. Now open gimp or open office /on your frickin desktop/ and 
you'll have time for a run to Starbuck's.

Google needs to open fast, not an Algebra study site.

> Oddly enough, it seems to go back to the server constantly during user
> interaction.

Oddly enough, that's the frickin idea if you noticed a word I have 
written. Check out the qooxlisp wiki pages:

    http://wiki.github.com/kennytilton/qooxlisp/

I know I have to linked to those before, what I do not know is how well 
you can read. The idea is to program in one language in one IDE and 
almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exists.

That said, I could reduce the size of each round-trip by taking an hour 
or two to create some pre-fab qooxdoo classes expressing the boilerplate 
I am shipping over, but the thing is so fast now I'll get to that after 
I get the "leveling-up thru Algebra" thing going.

I understand you have no idea what I am talking about because you do not 
know qooxdoo has some nice syntax for creating a higher-level way of 
authoring JS classes:

    http://qooxdoo.org/documentation/1.1/oo_introduction

When you need a break from coding assembly language all day, you should 
check it out.

> 
>> 1. Registering can be ignored for now.
> 
> No worries there.  :)

Careful, it won't be free forever and early registrants will be 
grandfathered in.

> 
>> It will be needed to do Missions,
>> but that's not ready yet. Recovering login does not work yet (forgot to
>> remove that option).
>>
>> 2. Should load faster. Curious how folks far from US east coast do.
> 
> I'm near there and have a fairly speedy broadband connection, yet it
> took several seconds to progress past the white screen stage.

Gasp! Now start up gimp or open office or any number of desktop apps. 
(sigh). 8 billion bits over the web is many times faster.

> 
>> 3. If you do register, your info will be stored using AllegroGraph!
> 
> Great.  What the hell is that?

      http://en.wikipedia.org/wiki/Graph_database

Built into the Lisp environment I use. I was using S3 but that is too 
slow/expensive for small amounts of data my app stores.

The graph db is a seriously better model for storing data.


> 
>> 4. qooxdoo continues to rock, as does qooxlisp.
> 
> Groan.  You misspelled suck.
> 
>> I could file a bug or
>> rfe against qooxdoo every four hours, but so far it's superficial stuff
>> easily worked around at the cost of some UI elegance. (You'll laugh if
>> you try tabbing through the fields of the registration form.
> 
> Or cry perhaps.
> 
>> 5. Enjoy. And tell your Algebra teacher friends I am looking for local
>> schools interested in being guinea pigs.
>>
> 
> If you do, they likely won't remain friends. :(
> 
> It's interesting that qooxdoo eschewed the browsers' built-in
> scrolling mechanisms and tried to build the same functionality with
> script.  They failed miserably as I can't scroll by clicking the
> mousewheel and then moving the mouse. 

Oh grow up and file an RFE (or contrib it).

> Furthermore, resizing the
> window to the point where the tabs' content overflows does not produce
> any scroll bars, so basic usability is ruined.  And why?

Because I did not wrap everything in scrollers. Sue me.

>  Do you think
> those gray-ish scroll bars are more aesthetically pleasing than those
> provided by the browsers?  I don't.

Yes, delivering an environment where kids can positively enjoy 
hand-to-hand battle with the arch nemesis Algebra relies on how the 
scroll bars look. Your instinct for the relevant dazzles.

>  Were you concerned they would
> clash with your all-gray color scheme?  :)

Have you forgotten what I did with color? You should be thanking me. 
btw, the author of this page need not rag on anyone over graphic design:

  http://www.cinsoft.net/mylib.html


> 
> And do you really think that any of this mess will be accessible to
> handicapped students? 

See bottom of barrel. See Mark. See Mark scrape.

> It's ironic that your overweight application is
> all tabs and (fake) form controls.  FYI there is nothing to creating a
> "tabstrip" widget and real form controls are infinitely preferable to
> your washed out looking phonies.  Why do you think your keyboard
> navigation is such a mess?  Zooming in eventually displays some sort
> of scrolling interface for the tabs, but not the content.  This is
> backwards.  Widgets should not have any need to respond to changes in
> the zoom factor, but the page content should certainly be able to be
> scrolled (which it would automatically if you hadn't used an ill-
> advised "layout" script instead of HTML).
> 
> Also that picture on the "Community" tab (which does nothing) looks
> like Big Boy after a crash diet and a week-long bender.  He appears to
> be pan-handling too.  On the "Notebook" tab (also bereft of meaningful
> content), he appears to have sobered up and snapped back into his
> normal pose, but it seems he lost his giant hamburger.  :)
> 
> http://melindaschwakhofer.files.wordpress.com/2008/02/bigboy.jpg
> 
> I suppose you are trolling for feedback.  My message, which you should
> pass along to the qooxdoo people is: what's wrong with you?

Shouldn't you be more forthright in disclosing your massive conflict of 
interest as a competitor of qooxdoo?

Meanwhile: "Starting this summer, cinsoft.net will be the home of 
Cinsoft, a startup that will provide world-class browser scripting 
solutions and professional support for My Library (as well as /any/ 
other Javascript library or framework)."

Including qooxdoo? You whore!

Best of luck with Cinsoft.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 20, 10:01=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 20, 5:44 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> >> Bad news: Qooxdoo/Lisp looking better/faster all the time:
>
> > Bad news for whom?
>
> Your skill set sleeps with the fishes. I recommend bartending school.

Let me see if I get this straight.  Somebody like *you* can compete
with me in the area of front-end development.  Is that really what you
meant to say?

> Proof: I know next to nothing about html/css and am no qooxdoo guru and
> look at this:
>
> =A0 =A0http://teamalgebra.com/

I saw it.  Suffice to say, I'm less than impressed.  Be fair, it's a
load of crap.

>
> Done in ten weeks, most of those part-time/weekends-only.

I could write that stupid framework you are using in ten weeks.  ;)

> Now look at this:
>
> =A0 =A0http://www.cinsoft.net/mylib-builder.asp

Yes, that's the builder form for My Library.

>
> Checkboxes, the universal widget?

For representing on or off?  Yes.  Are you proud of yourself for using
phony checkboxes in lieu of real ones?

>
> QED.

I'm afraid I didn't follow your "logic".

>
>
>
> >> =A0 =A0http://teamalgebra.com/
>
> > The initial script it downloads is still over one *million* bytes.
>
> That's *eight million* bits!! Loads in less than three seconds on the
> east coast.

Didn't for me and I am not far from there.  Maybe this stuff is a bit
more complicated than you think.

> Now open gimp or open office /on your frickin desktop/ and
> you'll have time for a run to Starbuck's.

Ah, I see.  Now you turn your sword on desktop software?  I'm sure
they are as worried as I am.  :)

>
> Google needs to open fast, not an Algebra study site.

All together: everything is relative!

>
> > Oddly enough, it seems to go back to the server constantly during user
> > interaction.
>
> Oddly enough, that's the frickin idea if you noticed a word I have
> written.

My point is that it is odd that it takes a million byte script to load
and then still has to go back and forth to the server constantly.
Seems like the worst of both worlds.  :(

> Check out the qooxlisp wiki pages:
>
> =A0 =A0http://wiki.github.com/kennytilton/qooxlisp/

No thanks!

>
> I know I have to linked to those before, what I do not know is how well
> you can read.

You linking and me reading don't typically go together.  I made an
exception for your app, which was funny.  Now I get the impression
that you were serious with that thing. (?)

> The idea is to program in one language in one IDE and
> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exis=
ts.

That's *the* idea?

>
> That said, I could reduce the size of each round-trip by taking an hour
> or two to create some pre-fab qooxdoo classes expressing the boilerplate
> I am shipping over, but the thing is so fast now I'll get to that after
> I get the "leveling-up thru Algebra" thing going.

It's always some lame excuse.

>
> I understand you have no idea what I am talking about because you do not
> know qooxdoo has some nice syntax for creating a higher-level way of
> authoring JS classes:

Of course, there are no such thing as JS classes.

>
> =A0 =A0http://qooxdoo.org/documentation/1.1/oo_introduction

Not reading it.  See how that works?

>
> When you need a break from coding assembly language all day, you should
> check it out.

Kennywannacracker?

>
>
>
> >> 1. Registering can be ignored for now.
>
> > No worries there. =A0:)
>
> Careful, it won't be free forever and early registrants will be
> grandfathered in.

I'll take my chances.  And what the hell makes you think I need to
learn algebra?  From you of all people?!

>
>
>
> >> It will be needed to do Missions,
> >> but that's not ready yet. Recovering login does not work yet (forgot t=
o
> >> remove that option).
>
> >> 2. Should load faster. Curious how folks far from US east coast do.
>
> > I'm near there and have a fairly speedy broadband connection, yet it
> > took several seconds to progress past the white screen stage.
>
> Gasp! Now start up gimp or open office or any number of desktop apps.
> (sigh). 8 billion bits over the web is many times faster.

You aren't competing with desktop apps.

>
>
>
> >> 3. If you do register, your info will be stored using AllegroGraph!
>
> > Great. =A0What the hell is that?
>
> =A0 =A0 =A0http://en.wikipedia.org/wiki/Graph_database

Another link I'll never follow.

>
> Built into the Lisp environment I use. I was using S3 but that is too
> slow/expensive for small amounts of data my app stores.

I find all of this fascinating.

>
> The graph db is a seriously better model for storing data.

Do tell.

>
>
>
>
>
>
>
> >> 4. qooxdoo continues to rock, as does qooxlisp.
>
> > Groan. =A0You misspelled suck.
>
> >> I could file a bug or
> >> rfe against qooxdoo every four hours, but so far it's superficial stuf=
f
> >> easily worked around at the cost of some UI elegance. (You'll laugh if
> >> you try tabbing through the fields of the registration form.
>
> > Or cry perhaps.
>
> >> 5. Enjoy. And tell your Algebra teacher friends I am looking for local
> >> schools interested in being guinea pigs.
>
> > If you do, they likely won't remain friends. :(
>
> > It's interesting that qooxdoo eschewed the browsers' built-in
> > scrolling mechanisms and tried to build the same functionality with
> > script. =A0They failed miserably as I can't scroll by clicking the
> > mousewheel and then moving the mouse.
>
> Oh grow up and file an RFE (or contrib it).

I see.  The reason that the framework that I told you not to use is a
failure is because I am childish.  And there's likely no way to fix
the problem I described anyway.

>
> > Furthermore, resizing the
> > window to the point where the tabs' content overflows does not produce
> > any scroll bars, so basic usability is ruined. =A0And why?
>
> Because I did not wrap everything in scrollers. Sue me.

I just might.

>
> > =A0Do you think
> > those gray-ish scroll bars are more aesthetically pleasing than those
> > provided by the browsers? =A0I don't.
>
> Yes, delivering an environment where kids can positively enjoy
> hand-to-hand battle with the arch nemesis Algebra relies on how the
> scroll bars look. Your instinct for the relevant dazzles.

You misstate.  My "quibble" is that it wiped out the built-in scroll
bars that come free with every browser and replaced them with nothing.

>
> > =A0Were you concerned they would
> > clash with your all-gray color scheme? =A0:)
>
> Have you forgotten what I did with color?

I suppose.

>  You should be thanking me.

Thanks so much for several good laughs.  I'm convinced you are some
sort of surrealist performance artist.

Thanks for all of the plugs though.  :)

> btw, the author of this page need not rag on anyone over graphic design:
>
> =A0http://www.cinsoft.net/mylib.html

What graphic design?  Some user sent in the logo.  I never felt the
need for a logo at all as I don't believe in trying to razzle dazzle
people into using a completely transparent script.  Misdirection is
just not my thing.

>
>
>
> > And do you really think that any of this mess will be accessible to
> > handicapped students?
>
> See bottom of barrel. See Mark. See Mark scrape.

Ah, you don't care about handicapped students and consider them the
bottom of the barrel.  Misfits, unworthy of your precious attention?
Is that the idea?

>
>
>
> > It's ironic that your overweight application is
> > all tabs and (fake) form controls. =A0FYI there is nothing to creating =
a
> > "tabstrip" widget and real form controls are infinitely preferable to
> > your washed out looking phonies. =A0Why do you think your keyboard
> > navigation is such a mess? =A0Zooming in eventually displays some sort
> > of scrolling interface for the tabs, but not the content. =A0This is
> > backwards. =A0Widgets should not have any need to respond to changes in
> > the zoom factor, but the page content should certainly be able to be
> > scrolled (which it would automatically if you hadn't used an ill-
> > advised "layout" script instead of HTML).
>
> > Also that picture on the "Community" tab (which does nothing) looks
> > like Big Boy after a crash diet and a week-long bender. =A0He appears t=
o
> > be pan-handling too. =A0On the "Notebook" tab (also bereft of meaningfu=
l
> > content), he appears to have sobered up and snapped back into his
> > normal pose, but it seems he lost his giant hamburger. =A0:)
>
> >http://melindaschwakhofer.files.wordpress.com/2008/02/bigboy.jpg
>
> > I suppose you are trolling for feedback. =A0My message, which you shoul=
d
> > pass along to the qooxdoo people is: what's wrong with you?
>
> Shouldn't you be more forthright in disclosing your massive conflict of
> interest as a competitor of qooxdoo?

Ah, I see.  It's the old "he is just jealous" ploy.  Well, my library
is free and I couldn't care less how many people use it.  I don't have
to pay for "9 full-time engineers" to keep it up (or try to anyway) so
why should I care?

>
> Meanwhile: "Starting this summer, cinsoft.net will be the home of
> Cinsoft, a startup that will provide world-class browser scripting
> solutions and professional support for My Library (as well as /any/
> other Javascript library or framework)."
>
> Including qooxdoo? You whore!

Specially and emphatically *not* qooxdoo.  If you use that you are
SOL.  :)

And what the hell is wrong with helping people that find themselves
saddled with junk code.  Am I the bad guy for making money off that?
Aren't the people who gave them the junk code to blame?

>
> Best of luck with Cinsoft.

Don't need it.

On Jul 21, 12:01 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> David Mark wrote:
[...]
> > Oddly enough, it seems to go back to the server constantly during user
> > interaction.
>
> Oddly enough, that's the frickin idea

It seems to me that you are using qooxdoo purely for presentation in
the client. Apparently you think it's massive bulk is required in
order to present a tabbed interface and do XHR.

Suppose you slim your application down to the following components:

1. HTML and CSS interface
2. XHR to the server to do the algebra stuff
3. math.js to do the client rendering.

The XHR stuff takes less than 100 lines of code - there are a zillon
small AJAX libraries around, you could do worse than Matt Kruse's
AjaxRequest library:
<URL: http://www.ajaxtoolbox.com/request/ >

Next time look for s simple, extensible interface in plain HTML and
CSS. Tab have been done in HTML and CSS with minimal script for over a
decade, they can be done with no script at all.

Here's a small, simple tutorial:
<URL: http://www.htmldog.com/articles/tabs/ >

A web search will show lots of examples of creating extensible tabs
with a small amount of HTML, CSS and script. Your pages are pretty
static so it should be a snap to create them without any javascript
library at all.

Editable text areas have been done for ages too, though I think what
you are doing is very simple - capture keystrokes, send them to the
server, then send back stuff to put in the "editable" area.

Incidentally, if Firefox users have the "Search for text when I start
typing" preference checked, it plays havoc with your interface because
Firefox doesn't see it as an editable area and starts capturing
keystrokes.


> if you noticed a word I have
> written. Check out the qooxlisp wiki pages:
>
>    http://wiki.github.com/kennytilton/qooxlisp/

So you are happy about writing in Lisp to generate javascript, good
for you. Maybe someone in a Lisp group cares, but the relevant part
here is the generated javascript - how it came into being is almost
entirely irrelevant.

Your use of qooxdoo is essentially as crutch to generate the client
UI. There are many alternatives, a more popular one is to do the work
on the server and send generated HTML to the client. It tends to be
much faster and more robust.


> I know I have to linked to those before, what I do not know is how well
> you can read. The idea is to program in one language in one IDE and
> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exists.

That's been tried many, many times before and strangely those IDEs
haven't taken over the world. They likely fail for much the same
reasons general purpose javascript libraries fail - one is that if you
try to please everyone, you end up pleasing no one.

Their main use seems to be programmers who know one language well but
need to write programs in another (in your case, Lisp -> HTML and
CSS). However the generated code is not as good as that written in the
target language to start with - natural selection takes care of the
rest of the story.

All the time and effort you've spend learning qooxdoo might well have
been much better spent learning a bit of HTML and CSS - the actual
javascript part seems to be minimal.

> That said, I could reduce the size of each round-trip by taking an hour
> or two to create some pre-fab qooxdoo classes expressing the boilerplate
> I am shipping over, but the thing is so fast now I'll get to that after
> I get the "leveling-up thru Algebra" thing going.

I don't think the amount of data being transmitted is the issue, it's
the number of requests. There's a certain overhead that you can never
reduce so the speed of the application is limited to the speed of an
XHR request, and you have very little control over that.

The fix for that is to run your algebra program on the client. If you
care to rewrite it in javascript, it may be of interest.


--
Rob

On Jul 21, 6:02=A0am, RobG <rg...@iinet.net.au> wrote:
> On Jul 21, 12:01 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>
> > David Mark wrote:
> [...]
> > > Oddly enough, it seems to go back to the server constantly during use=
r
> > > interaction.
>
> > Oddly enough, that's the frickin idea
>
> It seems to me that you are using qooxdoo purely for presentation in
> the client. Apparently you think it's massive bulk is required in
> order to present a tabbed interface and do XHR.
>
> Suppose you slim your application down to the following components:
>
> 1. HTML and CSS interface
> 2. XHR to the server to do the algebra stuff
> 3. math.js to do the client rendering.
>
> The XHR stuff takes less than 100 lines of code - there are a zillon
> small AJAX libraries around, you could do worse than Matt Kruse's
> AjaxRequest library:
> <URL:http://www.ajaxtoolbox.com/request/>
>
> Next time look for s simple, extensible interface in plain HTML and
> CSS. Tab have been done in HTML and CSS with minimal script for over a
> decade, they can be done with no script at all.
>
> Here's a small, simple tutorial:
> <URL:http://www.htmldog.com/articles/tabs/>
>
> A web search will show lots of examples of creating extensible tabs
> with a small amount of HTML, CSS and script. Your pages are pretty
> static so it should be a snap to create them without any javascript
> library at all.
>
> Editable text areas have been done for ages too, though I think what
> you are doing is very simple - capture keystrokes, send them to the
> server, then send back stuff to put in the "editable" area.
>
> Incidentally, if Firefox users have the "Search for text when I start
> typing" preference checked, it plays havoc with your interface because
> Firefox doesn't see it as an editable area and starts capturing
> keystrokes.
>
> > if you noticed a word I have
> > written. Check out the qooxlisp wiki pages:
>
> > =A0 =A0http://wiki.github.com/kennytilton/qooxlisp/
>
> So you are happy about writing in Lisp to generate javascript, good
> for you. Maybe someone in a Lisp group cares, but the relevant part
> here is the generated javascript - how it came into being is almost
> entirely irrelevant.
>
> Your use of qooxdoo is essentially as crutch to generate the client
> UI. There are many alternatives, a more popular one is to do the work
> on the server and send generated HTML to the client. It tends to be
> much faster and more robust.
>
> > I know I have to linked to those before, what I do not know is how well
> > you can read. The idea is to program in one language in one IDE and
> > almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even ex=
ists.
>
> That's been tried many, many times before and strangely those IDEs
> haven't taken over the world. They likely fail for much the same
> reasons general purpose javascript libraries fail - one is that if you
> try to please everyone, you end up pleasing no one.
>
> Their main use seems to be programmers who know one language well but
> need to write programs in another (in your case, Lisp -> HTML and
> CSS). However the generated code is not as good as that written in the
> target language to start with - natural selection takes care of the
> rest of the story.
>
> All the time and effort you've spend learning qooxdoo might well have
> been much better spent learning a bit of HTML and CSS - the actual
> javascript part seems to be minimal.
>
> > That said, I could reduce the size of each round-trip by taking an hour
> > or two to create some pre-fab qooxdoo classes expressing the boilerplat=
e
> > I am shipping over, but the thing is so fast now I'll get to that after
> > I get the "leveling-up thru Algebra" thing going.
>
> I don't think the amount of data being transmitted is the issue, it's
> the number of requests. There's a certain overhead that you can never
> reduce so the speed of the application is limited to the speed of an
> XHR request, and you have very little control over that.
>
> The fix for that is to run your algebra program on the client. If you
> care to rewrite it in javascript, it may be of interest.

Kenny, screw qooxdoo! Lispers have had the Parenscript library - a
Lisp-to-js compiler - for a long time. If it were extended with a
built-in, XHR-based server callback mechanism and maybe a minimally
intrusive widget set, it would really rock! It would be a library in
the vein of GWT, but with much less boilerplate. If only I had the
time... :(

Alessio

RobG wrote:
> On Jul 21, 12:01 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> David Mark wrote:
> [...]
>>> Oddly enough, it seems to go back to the server constantly during user
>>> interaction.
>> Oddly enough, that's the frickin idea
> 
> It seems to me that you are using qooxdoo purely for presentation in
> the client. Apparently you think it's massive bulk is required in
> order to present a tabbed interface and do XHR.
> 
> Suppose you slim your application down to the following components:

Sorry, but what problem of /mine/ are you trying to solve? I appreciate 
all the links, but it means months more work and I am wondering why I 
would do that.

> 
> 1. HTML and CSS interface
> 2. XHR to the server to do the algebra stuff
> 3. math.js to do the client rendering.
> 
> The XHR stuff takes less than 100 lines of code - there are a zillon
> small AJAX libraries around, you could do worse than Matt Kruse's
> AjaxRequest library:
> <URL: http://www.ajaxtoolbox.com/request/ >
> 
> Next time look for s simple, extensible interface in plain HTML and
> CSS. Tab have been done in HTML and CSS with minimal script for over a
> decade, they can be done with no script at all.
> 
> Here's a small, simple tutorial:
> <URL: http://www.htmldog.com/articles/tabs/ >
> 
> A web search will show lots of examples of creating extensible tabs
> with a small amount of HTML, CSS and script. Your pages are pretty
> static so it should be a snap to create them without any javascript
> library at all.

My pages are static? I think you stopped at the typing tutorial.

> 
> Editable text areas have been done for ages too, though I think what
> you are doing is very simple - capture keystrokes, send them to the
> server, then send back stuff to put in the "editable" area.
> 
> Incidentally, if Firefox users have the "Search for text when I start
> typing" preference checked, it plays havoc with your interface because
> Firefox doesn't see it as an editable area and starts capturing
> keystrokes.

You see that happening? Ah, I limited calling preventDefault to 
backspace for some reason. Putting it back to all keystrokes until I 
remember the reason.

Firefox needs to lose that option, btw.

> 
> 
>> if you noticed a word I have
>> written. Check out the qooxlisp wiki pages:
>>
>>    http://wiki.github.com/kennytilton/qooxlisp/
> 
> So you are happy about writing in Lisp to generate javascript, good
> for you. Maybe someone in a Lisp group cares, but the relevant part
> here is the generated javascript - how it came into being is almost
> entirely irrelevant.
> 
> Your use of qooxdoo is essentially as crutch to generate the client
> UI. There are many alternatives, a more popular one is to do the work
> on the server and send generated HTML to the client. It tends to be
> much faster and more robust.

It seems fast enough. Robust? qooxdoo is an active and steadily 
advancing library worked on by better web developers than I, how am I 
going to do better work than them?

> 
> 
>> I know I have to linked to those before, what I do not know is how well
>> you can read. The idea is to program in one language in one IDE and
>> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exists.
> 
> That's been tried many, many times before and strangely those IDEs
> haven't taken over the world. They likely fail for much the same
> reasons general purpose javascript libraries fail - one is that if you
> try to please everyone, you end up pleasing no one.

They are doing fine, actually, tho the desktop per se not so much.

> 
> Their main use seems to be programmers who know one language well but
> need to write programs in another (in your case, Lisp -> HTML and
> CSS). However the generated code is not as good as that written in the
> target language to start with - natural selection takes care of the
> rest of the story.

Right, and I should be programming in assembler instead of Lisp. Except 
compilers eventually started writing better assembler.

> 
> All the time and effort you've spend learning qooxdoo might well have
> been much better spent learning a bit of HTML and CSS - the actual
> javascript part seems to be minimal.

And later you suggest I rewrite the whole thing in JS.

I am sure I would have done better with Mr. Mark's library than with 
Dojo or anything else other than qooxdoo, but I have done an in-depth 
survey of these things (which usually includes raw HTML/CSS) and I 
actually understand pretty well how much faster I can develop a web app 
using qooxdoo vs raw HTML/CSS.

> 
>> That said, I could reduce the size of each round-trip by taking an hour
>> or two to create some pre-fab qooxdoo classes expressing the boilerplate
>> I am shipping over, but the thing is so fast now I'll get to that after
>> I get the "leveling-up thru Algebra" thing going.
> 
> I don't think the amount of data being transmitted is the issue, it's
> the number of requests. There's a certain overhead that you can never
> reduce so the speed of the application is limited to the speed of an
> XHR request, and you have very little control over that.

Sounds like a theoretical objection not supported by experience. I would 
not still be going down this path if performance did not look so good, 
and I have not even focused much on performance yet.

> 
> The fix for that is to run your algebra program on the client. If you
> care to rewrite it in javascript, it may be of interest.

You want me to port 80kloc of a high-level language like Lisp to a toy 
language like JS? How big will the client be then? And how many motnhs 
would that take?

To solve what problem? Remember, this group defines "Using a library" as 
a problem, but only this group.

kt


-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 21, 3:14=A0pm, Kenneth Tilton <kentil...@gmail.com> wrote:
[snip]
>
> > Incidentally, if Firefox users have the "Search for text when I start
> > typing" preference checked, it plays havoc with your interface because
> > Firefox doesn't see it as an editable area and starts capturing
> > keystrokes.
>
> You see that happening? Ah, I limited calling preventDefault to
> backspace for some reason. Putting it back to all keystrokes until I
> remember the reason.
>
> Firefox needs to lose that option, btw.

Too bad you don't control Firefox development... it's the web,
baby! ;)

>
> >> if you noticed a word I have
> >> written. Check out the qooxlisp wiki pages:
>
> >> =A0 =A0http://wiki.github.com/kennytilton/qooxlisp/
>
> > So you are happy about writing in Lisp to generate javascript, good
> > for you. Maybe someone in a Lisp group cares, but the relevant part
> > here is the generated javascript - how it came into being is almost
> > entirely irrelevant.
>
> > Your use of qooxdoo is essentially as crutch to generate the client
> > UI. There are many alternatives, a more popular one is to do the work
> > on the server and send generated HTML to the client. It tends to be
> > much faster and more robust.
>
> It seems fast enough. Robust? qooxdoo is an active and steadily
> advancing library worked on by better web developers than I, how am I
> going to do better work than them?
>
>
>
> >> I know I have to linked to those before, what I do not know is how wel=
l
> >> you can read. The idea is to program in one language in one IDE and
> >> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even e=
xists.
>
> > That's been tried many, many times before and strangely those IDEs
> > haven't taken over the world. They likely fail for much the same
> > reasons general purpose javascript libraries fail - one is that if you
> > try to please everyone, you end up pleasing no one.
>
> They are doing fine, actually, tho the desktop per se not so much.
>
>
>
> > Their main use seems to be programmers who know one language well but
> > need to write programs in another (in your case, Lisp -> HTML and
> > CSS). However the generated code is not as good as that written in the
> > target language to start with - natural selection takes care of the
> > rest of the story.
>
> Right, and I should be programming in assembler instead of Lisp. Except
> compilers eventually started writing better assembler.
>
>
>
> > All the time and effort you've spend learning qooxdoo might well have
> > been much better spent learning a bit of HTML and CSS - the actual
> > javascript part seems to be minimal.
>
> And later you suggest I rewrite the whole thing in JS.
>
> I am sure I would have done better with Mr. Mark's library than with
> Dojo or anything else other than qooxdoo, but I have done an in-depth
> survey of these things (which usually includes raw HTML/CSS) and I
> actually understand pretty well how much faster I can develop a web app
> using qooxdoo vs raw HTML/CSS.
>

Oh, I think we finally nailed down the problem/misconception. I don't
think anybody is saying that raw HTML/CSS/JavaScript is faster to
develop than qooxdoo; rather that the end result is generally poorer
with qooxdoo than with the "lower-level" approach.

>
> >> That said, I could reduce the size of each round-trip by taking an hou=
r
> >> or two to create some pre-fab qooxdoo classes expressing the boilerpla=
te
> >> I am shipping over, but the thing is so fast now I'll get to that afte=
r
> >> I get the "leveling-up thru Algebra" thing going.
>
> > I don't think the amount of data being transmitted is the issue, it's
> > the number of requests. There's a certain overhead that you can never
> > reduce so the speed of the application is limited to the speed of an
> > XHR request, and you have very little control over that.
>
> Sounds like a theoretical objection not supported by experience. I would
> not still be going down this path if performance did not look so good,
> and I have not even focused much on performance yet.
>
>
>
> > The fix for that is to run your algebra program on the client. If you
> > care to rewrite it in javascript, it may be of interest.
>
> You want me to port 80kloc of a high-level language like Lisp to a toy
> language like JS? How big will the client be then? And how many motnhs
> would that take?

JS is much less of a toy language than most people think (and I'm a
Lisper, too). And you'd not need to port the whole application; just
move to the client stuff that pertains there, like formula editing,
while leaving other stuff on the server (e.g. the problem solving
logic).

> To solve what problem? Remember, this group defines "Using a library" as
> a problem, but only this group.

Not any library, but a certain class of libraries.

Alessio

In article <4c46f2e3$0$31286$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:

> RobG wrote:

> > The fix for that is to run your algebra program on the client. If you
> > care to rewrite it in javascript, it may be of interest.
> 
> You want me to port 80kloc of a high-level language like Lisp to a toy 
> language like JS? How big will the client be then? And how many motnhs 
> would that take?

Now now, no need to sneer. I've just finished writing an e-mail client 
using JS (13k lines) for the front-end, PHP (7k lines) for the backend. 
No JS libraries in sight and my ajax routine is just 20 lines long.

I looked at Lisp in 1968 and decided I didn't like it - it didn't appear 
to relate to anything.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Alessio Stalla wrote:
> Kenny, screw qooxdoo! Lispers have had the Parenscript library - a
> Lisp-to-js compiler - for a long time. 

Writing the JS glue hardly calls for Parenscript, and with the glue we 
Just Write Lisp. P/s is not all that hot, anyway.

> If it were extended with a
> built-in, XHR-based server callback mechanism and maybe a minimally
> intrusive widget set, it would really rock! It would be a library in
> the vein of GWT, but with much less boilerplate. If only I had the
> time... :(

Now it is time to ask a Lisper: what problem are you trying to solve? 
Qooxlisp is the ideal solution for RIAs: a great HLL (Common Lisp) and a 
great JS framework.

I'll team up with Mr Mark on a lighter weight Cells/HTML solution for 
simpler web pages down the road.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 21, 4:42=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article <4c46f2e3$0$31286$607ed...@cv.net>,
> =A0Kenneth Tilton <kentil...@gmail.com> wrote:
>
> > RobG wrote:
> > > The fix for that is to run your algebra program on the client. If you
> > > care to rewrite it in javascript, it may be of interest.
>
> > You want me to port 80kloc of a high-level language like Lisp to a toy
> > language like JS? How big will the client be then? And how many motnhs
> > would that take?
>
> Now now, no need to sneer. I've just finished writing an e-mail client
> using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
> No JS libraries in sight and my ajax routine is just 20 lines long.
>
> I looked at Lisp in 1968 and decided I didn't like it - it didn't appear
> to relate to anything.

Kenny was very wrong in calling JS a toy language, but you're also
wrong if you consider Lisp today as it was in 1968. It would be like
comparing Ruby with Pascal :)

Lisp generating JS could bring very high-level constructs to JS
without the need of a huge library like qooxdoo. For example, you
could use macros to define functions which automagically invoke remote
services with XHR, without coding them by hand.

(defun-remote foo (args))

function foo(args, callback) {
   ... xhr(args, callback) ...
}

(defun bar ()
  (do-stuff)
  (foo 1 2 3)
  (do-other-stuff))

function bar() {
  doStuff();
  foo(1, 2, 3, function() { doOtherStuff(); });
}

you can get the idea.

Alessio

In article 
<f7253284-7fc1-47d8-bca3-b3aeca686ec7@k39g2000yqb.googlegroups.com>,
 Alessio Stalla <alessiostalla@gmail.com> wrote:

> On Jul 21, 4:42�pm, Tim Streater <timstrea...@waitrose.com> wrote:
> > In article <4c46f2e3$0$31286$607ed...@cv.net>,
> > �Kenneth Tilton <kentil...@gmail.com> wrote:
> >
> > > RobG wrote:
> > > > The fix for that is to run your algebra program on the client. If you
> > > > care to rewrite it in javascript, it may be of interest.
> >
> > > You want me to port 80kloc of a high-level language like Lisp to a toy
> > > language like JS? How big will the client be then? And how many motnhs
> > > would that take?
> >
> > Now now, no need to sneer. I've just finished writing an e-mail client
> > using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
> > No JS libraries in sight and my ajax routine is just 20 lines long.
> >
> > I looked at Lisp in 1968 and decided I didn't like it - it didn't appear
> > to relate to anything.
> 
> Kenny was very wrong in calling JS a toy language, but you're also
> wrong if you consider Lisp today as it was in 1968. It would be like
> comparing Ruby with Pascal :)

Oh quite possibly. But then I didn't like Pascal with its SESE model 
either.

> Lisp generating JS could bring very high-level constructs to JS
> without the need of a huge library like qooxdoo. For example, you
> could use macros to define functions which automagically invoke remote
> services with XHR, without coding them by hand.
> 
> (defun-remote foo (args))
> 
> function foo(args, callback) {
>    ... xhr(args, callback) ...
> }
> 
> (defun bar ()
>   (do-stuff)
>   (foo 1 2 3)
>   (do-other-stuff))
> 
> function bar() {
>   doStuff();
>   foo(1, 2, 3, function() { doOtherStuff(); });
> }
> 
> you can get the idea.

Hmmm I must be missing something. Isn't this what functions are supposed 
to be for? And I'm not keen on macros (except when using assembler - see 
Metasym). After I discovered that C macros knew nothing about C, I stuck 
to using the C preprocessor for simple substitutions of the:

#define wiggy 3

variety.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Alessio Stalla wrote:
> On Jul 21, 3:14 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> [snip]
>>> Incidentally, if Firefox users have the "Search for text when I start
>>> typing" preference checked, it plays havoc with your interface because
>>> Firefox doesn't see it as an editable area and starts capturing
>>> keystrokes.
>> You see that happening? Ah, I limited calling preventDefault to
>> backspace for some reason. Putting it back to all keystrokes until I
>> remember the reason.
>>
>> Firefox needs to lose that option, btw.
> 
> Too bad you don't control Firefox development...

That is actually true of all software.

> it's the web,
> baby! ;)

Nice that qooxdoo had a trivial workaround. Hint.

> Oh, I think we finally nailed down the problem/misconception. I don't
> think anybody is saying that raw HTML/CSS/JavaScript is faster to
> develop than qooxdoo; rather that the end result is generally poorer
> with qooxdoo than with the "lower-level" approach.

Once I can handle HTML and CSS and browser variability as well as the 
qooxdoo team. Does anyone else detect a loop in this discussion?

btw, I think we finally nailed down the source of our disagreement: I am 
not just pissing around on Usenet spouting crap, I am trying to build an 
RIA. Need some spam here: http://teamalgebra.com/

> JS is much less of a toy language than most people think (and I'm a
> Lisper, too).

It has some nice qualities, but it is still a toy language.

> And you'd not need to port the whole application; just
> move to the client stuff that pertains there, like formula editing,
> while leaving other stuff on the server (e.g. the problem solving
> logic).

Un-hunh. I have about six month's savings before I go under, excuse me 
if I go with Worse Is Better instead of trying to mollify The Savages of 
comp.lang.javascript by porting things to a crummy language for no reason.

kt

* Credit to gavino (IYRC).

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Tim Streater wrote:
> In article <4c46f2e3$0$31286$607ed4bc@cv.net>,
> Kenneth Tilton <kentilton@gmail.com> wrote:
> 
>> RobG wrote:
> 
>> > The fix for that is to run your algebra program on the client. If you
>> > care to rewrite it in javascript, it may be of interest.
>>
>> You want me to port 80kloc of a high-level language like Lisp to a toy 
>> language like JS? How big will the client be then? And how many motnhs 
>> would that take?
> 
> Now now, no need to sneer.

I know that sounds like a put-down, but it really is not. JS has many of 
the best qualities of Lisp. When I say it is a toy language, I mean it 
just does not go very far (and I am not sure it should). Don't get me 
wrong, I am thrilled that JS is the de facto standard client HLL.

> I've just finished writing an e-mail client 
> using JS (13k lines) for the front-end, PHP (7k lines) for the backend. 
> No JS libraries in sight and my ajax routine is just 20 lines long.

Nice. What did the 13k lines translate to in download size?

> 
> I looked at Lisp in 1968 and decided I didn't like it - it didn't appear 
> to relate to anything.
> 

Lisp in 1968 was pretty weird, but the seed of greatness (code as data) 
was there. From that has grown Common Lisp, a redwood of a language. 
Ironically damned (like qooxdoo) for its size. More here on why it is 
time to look again:

http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html

It's been 42 years, you know. 42...coincidence? I don't think so. btw, I 
too had to be dragged back to Lisp: My road:

http://smuglispweeny.blogspot.com/2008/02/my-road-to-lisp.html

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

In article <4c471b81$0$5011$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:

> Once I can handle HTML and CSS and browser variability as well as the 
> qooxdoo team. Does anyone else detect a loop in this discussion?

If you write standard code there *is* no variability, not these days. My 
app works pretty identically in five browsers (except IE, fortunately I 
have no access to a copy of that, neither do I want one).

I did find some variability or actual failures initially, but guess 
what, it was essentially all my fault. Safari is a bit more tolerant of 
mistakes than some, so the other browsers highlighted typos, missing 
declarations, old-style usages. I spent an hour or fixing that and 
everything is peachy.

And you're still using non-standard scroll-bars, thus preventing me from 
having both arrows at each end of the scroll bar.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Tim Streater wrote:
> In article 
> <f7253284-7fc1-47d8-bca3-b3aeca686ec7@k39g2000yqb.googlegroups.com>,
> Alessio Stalla <alessiostalla@gmail.com> wrote:
> 
>> On Jul 21, 4:42�pm, Tim Streater <timstrea...@waitrose.com> wrote:
>> > In article <4c46f2e3$0$31286$607ed...@cv.net>,
>> > �Kenneth Tilton <kentil...@gmail.com> wrote:
>> >
>> > > RobG wrote:
>> > > > The fix for that is to run your algebra program on the client. 
>> If you
>> > > > care to rewrite it in javascript, it may be of interest.
>> >
>> > > You want me to port 80kloc of a high-level language like Lisp to a 
>> toy
>> > > language like JS? How big will the client be then? And how many 
>> motnhs
>> > > would that take?
>> >
>> > Now now, no need to sneer. I've just finished writing an e-mail client
>> > using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
>> > No JS libraries in sight and my ajax routine is just 20 lines long.
>> >
>> > I looked at Lisp in 1968 and decided I didn't like it - it didn't 
>> appear
>> > to relate to anything.
>>
>> Kenny was very wrong in calling JS a toy language, but you're also
>> wrong if you consider Lisp today as it was in 1968. It would be like
>> comparing Ruby with Pascal :)
> 
> Oh quite possibly. But then I didn't like Pascal with its SESE model 
> either.
> 
>> Lisp generating JS could bring very high-level constructs to JS
>> without the need of a huge library like qooxdoo. For example, you
>> could use macros to define functions which automagically invoke remote
>> services with XHR, without coding them by hand.
>>
>> (defun-remote foo (args))
>>
>> function foo(args, callback) {
>>    ... xhr(args, callback) ...
>> }
>>
>> (defun bar ()
>>   (do-stuff)
>>   (foo 1 2 3)
>>   (do-other-stuff))
>>
>> function bar() {
>>   doStuff();
>>   foo(1, 2, 3, function() { doOtherStuff(); });
>> }
>>
>> you can get the idea.
> 
> Hmmm I must be missing something. Isn't this what functions are supposed 
> to be for?

Many a Lisper makes the mistake of using macros where functions would 
suffice, ie, yes, macros and fucntions both hide details and often a 
macro hides no more than could a function hence should be eschewed.

Mr. Graham explains it better than anyone:
    http://www.paulgraham.com/onlisp.html


> And I'm not keen on macros (except when using assembler - see 
> Metasym). After I discovered that C macros knew nothing about C, I stuck 
> to using the C preprocessor for simple substitutions of the:
> 
> #define wiggy 3
> 
> variety.
> 

I did OK with the C preprocessor, I just used a lot of parentheses and 
braces and stuff. One great five-day bug, tho.

C macros and Lisp macros have in common the word "macro". Nuff said.

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

In article <4c471da1$0$5009$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:

> Tim Streater wrote:
> > In article <4c46f2e3$0$31286$607ed4bc@cv.net>,
> > Kenneth Tilton <kentilton@gmail.com> wrote:
> > 
> >> RobG wrote:
> > 
> >> > The fix for that is to run your algebra program on the client. If you
> >> > care to rewrite it in javascript, it may be of interest.
> >>
> >> You want me to port 80kloc of a high-level language like Lisp to a toy 
> >> language like JS? How big will the client be then? And how many motnhs 
> >> would that take?
> > 
> > Now now, no need to sneer.
> 
> I know that sounds like a put-down, but it really is not. JS has many of 
> the best qualities of Lisp. When I say it is a toy language, I mean it 
> just does not go very far (and I am not sure it should). Don't get me 
> wrong, I am thrilled that JS is the de facto standard client HLL.
> 
> > I've just finished writing an e-mail client 
> > using JS (13k lines) for the front-end, PHP (7k lines) for the backend. 
> > No JS libraries in sight and my ajax routine is just 20 lines long.
> 
> Nice. What did the 13k lines translate to in download size?

Well its not all downloaded at once, but 5.7k lines translates to 
215kbytes. Safari's profiler tells me it takes 23msec to download. 
Initialising the whole app with 10 mailboxes open takes about 4 secs 
elapsed (of course Safari has to be running first, as does apache).

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On Jul 21, 11:22=A0am, Tim Streater <timstrea...@waitrose.com> wrote:
> If you write standard code there *is* no variability, not these days. My
> app works pretty identically in five browsers (except IE, fortunately I
> have no access to a copy of that, neither do I want one).

Problems are easier to solve when you ignore the trouble-makers ;)

For those who still contend with IE6, writing js for webapps is still
a messy proposition, made easier with prudent use of libraries.

Matt Kruse

In article 
<d095b85e-ff93-4dbf-ac03-5c77be19a21b@t10g2000yqg.googlegroups.com>,
 Matt Kruse <matt@thekrusefamily.com> wrote:

> On Jul 21, 11:22�am, Tim Streater <timstrea...@waitrose.com> wrote:
> > If you write standard code there *is* no variability, not these days. My
> > app works pretty identically in five browsers (except IE, fortunately I
> > have no access to a copy of that, neither do I want one).
> 
> Problems are easier to solve when you ignore the trouble-makers ;)
> 
> For those who still contend with IE6, writing js for webapps is still
> a messy proposition, made easier with prudent use of libraries.

Well you have my sympathy. I work at home, on a Mac. And - it's all a 
*hobby*, as I'm retired now. So I decided my tools are going to be 
JavaScript, PHP, and SQLite, all of which are free on this platform 
along with apache. I was curious to see whether it would be possible to 
duplicate those features of Eudora that appeal to me using this toolset. 
I was expecting to hit show-stopping roadblocks at every turn, but 
rather to my surprise after 18 months I have a useable app, even to the 
extent of creating an installer for it.

It's not perfect but it's now what I use full-time for email.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

Tim Streater wrote:
> In article <4c471da1$0$5009$607ed4bc@cv.net>,
> Kenneth Tilton <kentilton@gmail.com> wrote:
> 
>> Tim Streater wrote:

>> > I've just finished writing an e-mail client > using JS (13k lines) 
>> for the front-end, PHP (7k lines) for the backend. > No JS libraries 
>> in sight and my ajax routine is just 20 lines long.
>>
>> Nice. What did the 13k lines translate to in download size?
> 
> Well its not all downloaded at once, but 5.7k lines translates to 
> 215kbytes.

Yikes. These yobbos will kill me if I port ten times that to JS, which 
could be fifty times that by the time all the Lisp macros get expanded. 
And my investor (me) will kill me if I spend three months on a port. I 
think the math editor better stay in Lisp on the server.

Naysayers in re that need to remember that Algebra students are 
generally not entering equations at 60 wpm.

We'll see, but so far it looks like a no-brainer. As I said, I have not 
yet begun to optimize.

So are the buttons appearing OK now that each typing example gets loaded 
separately? http://teamalgebra.com/

Hmmh, I have to figure out how to give diff tabs their own url. Anyone 
here know how to do that with qooxdoo? :)

kt


-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 21, 12:55=A0pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jul 21, 11:22=A0am, Tim Streater <timstrea...@waitrose.com> wrote:
>
> > If you write standard code there *is* no variability, not these days. M=
y
> > app works pretty identically in five browsers (except IE, fortunately I
> > have no access to a copy of that, neither do I want one).
>
> Problems are easier to solve when you ignore the trouble-makers ;)

Users (and their agents) cannot be considered "trouble-makers" by
professionals.  You have to play the hand you are dealt.  The recent
trend of "not caring" about whatever browsers you can't handle is
ridiculous as end-users don't care what you don't care about.

>
> For those who still contend with IE6, writing js for webapps is still
> a messy proposition,

No it isn't.  IE6 is very much like IE7 (and IE8 can mimic IE7 fairly
closely).  And as IE6 has been out since the turn of the century,
professional developers should know how to deal with it by now.

> made easier with prudent use of libraries.

Unless you are referring to my library, how backwards can you get?
The "major" libraries are notorious for their failures in IE6, so how
can they possibly help?  Why do you think most library authors have
given up on trying to "solve" that browser?  They tried for years and
never got close, so now they want to wish it out of existence.  :(

In article <4c473391$0$4996$607ed4bc@cv.net>,
 Kenneth Tilton <kentilton@gmail.com> wrote:

> Tim Streater wrote:
> > In article <4c471da1$0$5009$607ed4bc@cv.net>,
> > Kenneth Tilton <kentilton@gmail.com> wrote:
> > 
> >> Tim Streater wrote:
> 
> >> > I've just finished writing an e-mail client > using JS (13k lines) 
> >> for the front-end, PHP (7k lines) for the backend. > No JS libraries 
> >> in sight and my ajax routine is just 20 lines long.
> >>
> >> Nice. What did the 13k lines translate to in download size?
> > 
> > Well its not all downloaded at once, but 5.7k lines translates to 
> > 215kbytes.
> 
> Yikes. These yobbos will kill me if I port ten times that to JS, which 
> could be fifty times that by the time all the Lisp macros get expanded. 
> And my investor (me) will kill me if I spend three months on a port. I 
> think the math editor better stay in Lisp on the server.
> 
> Naysayers in re that need to remember that Algebra students are 
> generally not entering equations at 60 wpm.
> 
> We'll see, but so far it looks like a no-brainer. As I said, I have not 
> yet begun to optimize.
> 
> So are the buttons appearing OK now that each typing example gets loaded 
> separately? http://teamalgebra.com/

Nope.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On 21 Lug, 17:48, Tim Streater <timstrea...@waitrose.com> wrote:
> In article
> <f7253284-7fc1-47d8-bca3-b3aeca686...@k39g2000yqb.googlegroups.com>,
> =A0Alessio Stalla <alessiosta...@gmail.com> wrote:
>
>
>
> > On Jul 21, 4:42=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
> > > In article <4c46f2e3$0$31286$607ed...@cv.net>,
> > > =A0Kenneth Tilton <kentil...@gmail.com> wrote:
>
> > > > RobG wrote:
> > > > > The fix for that is to run your algebra program on the client. If=
 you
> > > > > care to rewrite it in javascript, it may be of interest.
>
> > > > You want me to port 80kloc of a high-level language like Lisp to a =
toy
> > > > language like JS? How big will the client be then? And how many mot=
nhs
> > > > would that take?
>
> > > Now now, no need to sneer. I've just finished writing an e-mail clien=
t
> > > using JS (13k lines) for the front-end, PHP (7k lines) for the backen=
d.
> > > No JS libraries in sight and my ajax routine is just 20 lines long.
>
> > > I looked at Lisp in 1968 and decided I didn't like it - it didn't app=
ear
> > > to relate to anything.
>
> > Kenny was very wrong in calling JS a toy language, but you're also
> > wrong if you consider Lisp today as it was in 1968. It would be like
> > comparing Ruby with Pascal :)
>
> Oh quite possibly. But then I didn't like Pascal with its SESE model
> either.
>
>
>
> > Lisp generating JS could bring very high-level constructs to JS
> > without the need of a huge library like qooxdoo. For example, you
> > could use macros to define functions which automagically invoke remote
> > services with XHR, without coding them by hand.
>
> > (defun-remote foo (args))
>
> > function foo(args, callback) {
> > =A0 =A0... xhr(args, callback) ...
> > }
>
> > (defun bar ()
> > =A0 (do-stuff)
> > =A0 (foo 1 2 3)
> > =A0 (do-other-stuff))
>
> > function bar() {
> > =A0 doStuff();
> > =A0 foo(1, 2, 3, function() { doOtherStuff(); });
> > }
>
> > you can get the idea.
>
> Hmmm I must be missing something. Isn't this what functions are supposed
> to be for?

Macros are about source code transformations at compile-time. You
can't do that with functions.
In the fictional example I posted, a piece of code like:

doStuff();
callSomeFunctionOnTheServer(1, 2, 3);
doOtherStuff();

got translated to:

doStuff();
callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); });

i.e. from plain imperative style to asynch XHR callback-driven style.
Only a macro can do that.

> And I'm not keen on macros (except when using assembler - see
> Metasym). After I discovered that C macros knew nothing about C, I stuck
> to using the C preprocessor for simple substitutions of the:
>
> #define wiggy 3
>
> variety.

Lisp macros know Lisp, and are written in Lisp. C macros are little
more than text substitutions.

Alessio

In article 
<67d9e6e5-0640-437a-ada3-26598707c1b9@c10g2000yqi.googlegroups.com>,
 Alessio Stalla <alessiostalla@gmail.com> wrote:


> > Hmmm I must be missing something. Isn't this what functions are supposed
> > to be for?
> 
> Macros are about source code transformations at compile-time.

I'm really not sure I want to do that.

> You can't do that with functions.
> In the fictional example I posted, a piece of code like:
> 
> doStuff();
> callSomeFunctionOnTheServer(1, 2, 3);
> doOtherStuff();
> 
> got translated to:
> 
> doStuff();
> callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); });

In my JS, a call to my 20-line ajax function looks like:

ajax ("some-script.php", data-string-for-script, someCallbackFunction);

arg 1 is a PHP script to do some work for my app and return results
arg 2 is an argument string of values for the script in the form:
    arg1=value&arg2=value
arg3 is a JS function that will be given the script's results later and 
will process them.

So I'm already doing that in JS.


Hmmm, perhaps a different fictional example might show the point better.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

On 21 Lug, 21:47, Tim Streater <timstrea...@waitrose.com> wrote:
> In article
> <67d9e6e5-0640-437a-ada3-26598707c...@c10g2000yqi.googlegroups.com>,
> =A0Alessio Stalla <alessiosta...@gmail.com> wrote:
>
> > > Hmmm I must be missing something. Isn't this what functions are suppo=
sed
> > > to be for?
>
> > Macros are about source code transformations at compile-time.
>
> I'm really not sure I want to do that.

As Kenny said, Lispers sometimes want *too much* to do that ;)

> > You can't do that with functions.
> > In the fictional example I posted, a piece of code like:
>
> > doStuff();
> > callSomeFunctionOnTheServer(1, 2, 3);
> > doOtherStuff();
>
> > got translated to:
>
> > doStuff();
> > callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); });
>
> In my JS, a call to my 20-line ajax function looks like:
>
> ajax ("some-script.php", data-string-for-script, someCallbackFunction);
>
> arg 1 is a PHP script to do some work for my app and return results
> arg 2 is an argument string of values for the script in the form:
>     arg1=3Dvalue&arg2=3Dvalue
> arg3 is a JS function that will be given the script's results later and
> will process them.
>
> So I'm already doing that in JS.

You're doing it manually. You could program the compiler to translate
imperative code to callback-driven code, making it appear as if XHR
calls were regular synchronous function calls when they're really not.
E.g.

withSynchrXHR {
  stuff();
  ajax(...);
  moreStuff();
  ajax(...);
  evenMoreStuff();
}

gets translated to

ajax(..., function() {
            moreStuff();
            ajax(..., function() {
                        evenMoreStuff(); });
          });

just a rough sketch, not taking into account return values, error
conditions, ...

> Hmmm, perhaps a different fictional example might show the point better.

Another, simpler example, again in JS syntax rather than Lisp syntax:

ajaxFunction foo(args) { code }

translated to

function foo(phpScript, args) {
  ajax(phpScript, args, function() { code });
}

and macros for defining classes if you want to turn JavaScript into a
class-based OO language, macros for representing DOM subtrees
literally in source code, there are many examples.

Cheers,
Alessio

On Jul 21, 12:55=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> > made easier with prudent use of libraries.
> Unless you are referring to my library, how backwards can you get?
> The "major" libraries are notorious for their failures in IE6, so how
> can they possibly help?

All these years, and you still haven't grasped the simple point...

A library may work well in IE6 for, let's say, 80% of problems that
the library may try to solve. It may work only partially on 15%, and
fail miserably on the remaining 5%.

Take advantage of the 80% of features that work just fine, and use the
library. Don't try to use the library on the remaining 20% of features
that they have coded incorrectly or that, for whatever reason, don't
work.

Any reasonable person would understand that strategy, IMO. Because we
do it all the time with other things. Almost no tool gets everything
right. Successful people know how to identify which parts of which
tools should be used, and then use them. Not throw them out because
they fail to solve 100% of all conceivable problems that they may
encounter.

Matt Kruse

On Jul 21, 4:31=A0pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jul 21, 12:55=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > made easier with prudent use of libraries.
> > Unless you are referring to my library, how backwards can you get?
> > The "major" libraries are notorious for their failures in IE6, so how
> > can they possibly help?
>
> All these years, and you still haven't grasped the simple point...

That's my line.  You have no point.  Instead you advocate using "the
libraries" as if they are some sort of magical solution for
everything.

>
> A library may work well in IE6 for, let's say, 80% of problems that
> the library may try to solve.

That would be well short of a passing grade.

> It may work only partially on 15%, and
> fail miserably on the remaining 5%.

Which means it is far more trouble than it's worth.  They change
constantly, remember?  So you whatever library quirks you memorized
yesterday may be invalidated today or tomorrow.

>
> Take advantage of the 80% of features that work just fine, and use the
> library.

Do you realize how silly you sound?  Use "the library"?  What
library?  Are all libraries good and anyone who points out otherwise
"anti-library" (and therefore bad).  It is too bad that all of the
"major" efforts (by virtue of the fact that they try ill-advisedly to
solve every problem for every context) are such garbage.

> Don't try to use the library on the remaining 20% of features
> that they have coded incorrectly or that, for whatever reason, don't
> work.

Do you see the gaping hole in your logic?  You don't know what the
80/20 split will be, do you?  Certainly not from one day to the next.
It's worse than dealing with browsers.  Just admit it.

>
> Any reasonable person would understand that strategy, IMO.

Nope.  Any reasonable person can see the fallacy in your proposals.

> Because we
> do it all the time with other things.

You do what all the time with other things?  And what makes you think
that everything you do outside of browser scripting applies to browser
scripting?  The very idea is ludicrous.

> Almost no tool gets everything
> right.

For God's sake.  That's why you don't use tools that try to do
*everything*.  That's also why reasonable and experienced developers
don't waste their time on such folly, leaving the efforts to the B
team.  Get it?

> Successful people know how to identify which parts of which
> tools should be used, and then use them.

But you are equating success with doing the impossible.  It's been
demonstrated repeatedly that neither you, John Resig or virtually
anyone else related to that jQuery project has a clue which parts
should be used and which parts are botched beyond belief.  You are
simply clinging to the notion that you can use CSS selector queries
for everything and end up with production quality code.  Face it, you
can't.  And even if you could, jQuery's query engine is demonstrably
broken in more ways than you could ever keep tabs on.

> Not throw them out because
> they fail to solve 100% of all conceivable problems that they may
> encounter.
>

You've been spouting that nonsense for years.  You started out saying
that jQuery was a really good "cross-browser" script.  Then you
wavered and said it was actually fairly bad, but "good enough" for
you.  And all along, you've been playing this waiting game waiting for
Resig and co. to "eventually get it right", despite the fact that
their goal is untenable and unneeded.

On Jul 21, 3:48=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
> > It may work only partially on 15%, and
> > fail miserably on the remaining 5%.
> Which means it is far more trouble than it's worth. =A0

Non sequitur. Your leap to such a conclusion is unwarranted.

> Do you realize how silly you sound? =A0Use "the library"? =A0What
> library?

Whichever one you identify as being good enough to use, obviously.

>=A0Are all libraries good and anyone who points out otherwise
> "anti-library" (and therefore bad).

Of course not. Some analysis is necessary to determine which libraries
are suitable.

> =A0It is too bad that all of the
> "major" efforts (by virtue of the fact that they try ill-advisedly to
> solve every problem for every context) are such garbage.

I don't think they try to solve every context. For example, jQuery
doesn't support animations in IE in quirks mode. For stupid reasons,
actually, and my patched version has no such limitation. But they
certainly do limit the context.

> > Don't try to use the library on the remaining 20% of features
> > that they have coded incorrectly or that, for whatever reason, don't
> > work.
> Do you see the gaping hole in your logic? =A0You don't know what the
> 80/20 split will be, do you?

Not until you do some analysis on your library of choice, no.

> > Any reasonable person would understand that strategy, IMO.
> Nope. =A0Any reasonable person can see the fallacy in your proposals.

I think the general public of developers are pretty reasonable, and
they agree with me, IMO. I don't think the few hard-core zealots here
define "reasonable".

> > Because we
> > do it all the time with other things.
> You do what all the time with other things?

Use imperfect tools for the things they are good at, and avoid using
them for the things they are not good at.

I just used a microwave to heat up leftovers. I would never use it to
cook a pizza. That doesn't mean microwaves are a complete failure. It
means they are good at some things, bad at others. Despite the fact
that people try to make pizzas that cook well in microwaves! (they
don't)

> =A0And what makes you think
> that everything you do outside of browser scripting applies to browser
> scripting? =A0The very idea is ludicrous.

It seems to be the norm for most things. I see no reason not to apply
it to browser scripting also, unless there are good reasons not to.
You've not offered any.

> > Almost no tool gets everything
> > right.
> For God's sake. =A0That's why you don't use tools that try to do
> *everything*.

Like "My Library"?

> > Successful people know how to identify which parts of which
> > tools should be used, and then use them.
> But you are equating success with doing the impossible. =A0It's been
> demonstrated repeatedly that neither you, John Resig or virtually
> anyone else related to that jQuery project has a clue which parts
> should be used and which parts are botched beyond belief.

My experience shows otherwise. jQuery sucks at some things, and causes
great frustration sometimes. It's also been extremely useful in a
number of projects and proven its value with faster development, more
consistent code across a team of developers, less maintenance, and
better performance. I'm not sure why you think you have any argument
to the contrary of my experience and many others.

> =A0You are
> simply clinging to the notion that you can use CSS selector queries
> for everything and end up with production quality code.

Am I?

>=A0And even if you could, jQuery's query engine is demonstrably
> broken in more ways than you could ever keep tabs on.

Yet it consistently performs perfectly well for every task I throw at
it. Amazing, eh?

Same old broken record with you, David.

Matt Kruse
http://BetterFacebook.net  <-- Blatant advertisement for my current
pet project

On Jul 21, 5:25=A0pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Jul 21, 3:48=A0pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > It may work only partially on 15%, and
> > > fail miserably on the remaining 5%.
> > Which means it is far more trouble than it's worth. =A0
>
> Non sequitur. Your leap to such a conclusion is unwarranted.

Oh shut up.  How's that for warranted?  :)

>
> > Do you realize how silly you sound? =A0Use "the library"? =A0What
> > library?
>
> Whichever one you identify as being good enough to use, obviously.

But you are clearly incapable of making such an identification.

>
> >=A0Are all libraries good and anyone who points out otherwise
> > "anti-library" (and therefore bad).
>
> Of course not. Some analysis is necessary to determine which libraries
> are suitable.

Yet, you talk in black and white terms of "the libraries" and "anti-
library zealots".

>
> > =A0It is too bad that all of the
> > "major" efforts (by virtue of the fact that they try ill-advisedly to
> > solve every problem for every context) are such garbage.
>
> I don't think they try to solve every context.

Of course they do.  They have no specific goal other than to "fix" JS
and browsers.

> For example, jQuery
> doesn't support animations in IE in quirks mode.

Much to their chagrin.  I'm well aware of their "punt" on that issue.
They do a lot of that, but they don't advertise such things.  And
those are not design considerations but failings.

> For stupid reasons,
> actually, and my patched version has no such limitation.

Haven't you figured it out by now?  Patching jQuery will only lead to
more "upgrade" issues.  You'll have enough trouble with all of the
hacks, patches, workarounds, etc. that they add to try to satisfy the
umpteen million other people clinging to the library.  Professionals
don't rely on such things for reasons that should be obvious at this
point.  Hell, they should have been obvious three years ago.

> But they
> certainly do limit the context.

No.  Failing to do something; having to be told that you failed and
then refusing to even try to fix the problem is not "limiting the
context".  In other words, they didn't sit down at the beginning and
say "we won't bother with animations in quirks mode".  It wasn't part
of the "design" of jQuery for that to happen.

>
> > > Don't try to use the library on the remaining 20% of features
> > > that they have coded incorrectly or that, for whatever reason, don't
> > > work.
> > Do you see the gaping hole in your logic? =A0You don't know what the
> > 80/20 split will be, do you?
>
> Not until you do some analysis on your library of choice, no.

That's pretty funny.  Think of how many times I've posted
demonstrations of basic problems in jQuery that you didn't know
about.  Your analysis must have been somewhat lacking.  In fact, the
first time you started up about jQuery in here, you claimed it didn't
use browser sniffing.  Then you changed your tune to there was a
little in there, but only where "needed".  Then when confronted with
the source code, which was indeed teeming with unneeded browser
sniffing, you became a defender of browser sniffing (using the same
old non-arguments about SELECT's bleeding through in IE, Flash
problems, etc.)  Finally, confronted with Resig's humiliating attempts
to defend his code, you started pushing him to change the browser
sniffing.  That's not analysis (well, not yours anyway).  And we've
seen numerous, similar examples since then.  The most recent was
probably the ridiculous selectedIndex "problem", for which you
proposed an equally ludicrous solution.  And yes, I gave you the real
solution and you tried to get Resig to accept it, but he didn't get it
at all.  See the pattern?  That was about the point where you started
railing against their problem-solving ability (parroting me
basically).  Again, not analysis.  Being ignorant and then told about
something by the very people who "don't get it" (in your words) and
only *then* trying to address problems does not constitute anything
but failures on your part.  Ironically, you'd have remained oblivious
to at least some of these failures if it were not for *me*.  Still
think I don't get it?  :)

>
> > > Any reasonable person would understand that strategy, IMO.
> > Nope. =A0Any reasonable person can see the fallacy in your proposals.
>
> I think the general public of developers are pretty reasonable, and
> they agree with me, IMO.

The general public of developers?  You mean Web developers right?  In
what way are Web developers "pretty reasonable" (as opposed to off the
reservation?)  And they agree with you on *what*?  You don't have any
original ideas, remember?

> I don't think the few hard-core zealots here
> define "reasonable".

There it is.

>
> > > Because we
> > > do it all the time with other things.
> > You do what all the time with other things?
>
> Use imperfect tools for the things they are good at, and avoid using
> them for the things they are not good at.

It's been thoroughly explained that you can't use something for what
it's good (and avoid using it for things it is bad at) at if you don't
know (in advance) what the tool is good at and what it is bad at?
Your oversimplifications are truly painful in light of your
tribulations of the last few years.  Which version of jQuery are you
up to?  How are its queries doing in relation to the previous
version?  Worse or better?

>
> I just used a microwave to heat up leftovers.

Things tight?  :)

> I would never use it to
> cook a pizza. That doesn't mean microwaves are a complete failure.

Child-like oversimplifications are your trademark.  Do you really
think they belong in a technical group though?

> It
> means they are good at some things, bad at others. Despite the fact
> that people try to make pizzas that cook well in microwaves! (they
> don't)

Folksy.  Again, this is a technical group, not a PTA meeting.

>
> > =A0And what makes you think
> > that everything you do outside of browser scripting applies to browser
> > scripting? =A0The very idea is ludicrous.
>
> It seems to be the norm for most things. I see no reason not to apply
> it to browser scripting also, unless there are good reasons not to.
> You've not offered any.

Appeal to loonies.

>
> > > Almost no tool gets everything
> > > right.
> > For God's sake. =A0That's why you don't use tools that try to do
> > *everything*.
>
> Like "My Library"?

As a whole, very much so, though as it is modular rather than tangled
up in interdependencies...  And why do I have to keep repeating the
same things to you year after year?  Is it amneaia or are you simply
playing to some perceived audience?  If newcomers are unfamiliar with
your broken record imitations, they'll figure you out soon enough
(perhaps with help from the archive).

>
> > > Successful people know how to identify which parts of which
> > > tools should be used, and then use them.
> > But you are equating success with doing the impossible. =A0It's been
> > demonstrated repeatedly that neither you, John Resig or virtually
> > anyone else related to that jQuery project has a clue which parts
> > should be used and which parts are botched beyond belief.
>
> My experience shows otherwise.

In what way?  ISTM that it shows just the opposite, as detailed in
this group over the course of years.

> jQuery sucks at some things, and causes
> great frustration sometimes.

Yes, which you could have avoided by not using jQuery in the first
place.  The browsers really aren't that bad these days.  And back when
they were, jQuery was never close to bridging the gaps.

> It's also been extremely useful in a
> number of projects and proven its value with faster development, more
> consistent code across a team of developers, less maintenance, and
> better performance.

As for saving time, you could have done that with any code re-use
strategy.  Of course, you likely have little code of your own due to
your perpetual reliance on John Resig's.  See the problem?  Same for
consistency.

Less maintenance is laughable in regard to jQuery.  You had to sit on
some old version (1.2?) for years, despute its many well-documented
problems, simply because the next version was wildly incompatible (a
recurring pattern with that project).

And as for performance, who are you trying to kid?  Better implies a
comparison.  Just what imagined entity does jQuery outperform?

> I'm not sure why you think you have any argument
> to the contrary of my experience and many others.

I've seen you and countless others going around in circles for years.
Get a load of the posts in the jQuery "support" forums.  If these
people think they are having a good experience, then I wonder what it
is they are comparing it to.  Perhaps they have nothing to compare it
to.  Then again, maybe they tried their hand at cross-browser
scripting years ago and gave up.  Either way, it's not a comparison
rooted in reality (especially not today).

>
> > =A0You are
> > simply clinging to the notion that you can use CSS selector queries
> > for everything and end up with production quality code.
>
> Am I?

Yes, you are.  That's what jQuery is (a query engine).  Or are you
really in love with the illogical and ham-fisted API?  That's hard to
imagine, even for you.  Maybe you like the chaining?  :)

>
> >=A0And even if you could, jQuery's query engine is demonstrably
> > broken in more ways than you could ever keep tabs on.
>
> Yet it consistently performs perfectly well for every task I throw at
> it. Amazing, eh?

Not really.  You are simply deluded.

>
> Same old broken record with you, David.

Again, my line.

Kenneth Tilton wrote:

> So are the buttons appearing OK now that each typing example gets loaded 
> separately? http://teamalgebra.com/

I've tried it with Opera. When trying to register, I didn't fill out each
field and it says "Login error: Please fixFORM-FIELD98737". That's a very
useful information :-)

Some other things I noticed:

- I can't use any key above my numbers (German keyboard), e.g. "/" or "("
doesn't work and "=" is on "*"

- Backspace deletes always two characters

- cut, copy and paste to and from the input field doesn't work

- when I press repeated times the square root, the input field doesn't
size, so I see only the upper part of it anymore

- sometimes the text for the buttons in the traing center is not readable
(e.g. "Cle..." and "O..."), but sometimes the whole text is visible

- in the Typing Tutorial, it is a green vertical bar, not a red vertical
bar

In general I think it is not a good idea trying to make a GUI application
in a web browser. If you don't want the user to install a program, you
could use Flash, which works the same in all browsers on all platforms.

But maybe better, if the user has no flash, would be a simple HTML
interface without JavaScript, e.g. entering expressions in basic
programming syntax, like sqrt(1/3)<10*x. This would work even for visually
impaired users, too. I guess your current application is useless for blind
users.

You can explain the syntax with some examples, and it has the advantage
that the user can use this syntax later for programming or spreadsheets,
too. Then you can use simple text forms, which works with all browsers,
even very old or strange ones without Flash and JavaScript, e.g. on some
mobile phones. On post, generate a nice image of the expression on server
side and send it back to the browser, if you like.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Jul 22, 12:25=A0am, Frank Buss <f...@frank-buss.de> wrote:
> Kenneth Tilton wrote:
> > So are the buttons appearing OK now that each typing example gets loade=
d
> > separately?http://teamalgebra.com/
>
> I've tried it with Opera. When trying to register, I didn't fill out each
> field and it says "Login error: Please fixFORM-FIELD98737". That's a very
> useful information :-)
>
> Some other things I noticed:
>
> - I can't use any key above my numbers (German keyboard), e.g. "/" or "("
> doesn't work and "=3D" is on "*"
>
> - Backspace deletes always two characters

Well, either KooksDo or Kenny botched the keyboard handling.

>
> - cut, copy and paste to and from the input field doesn't work

Unsurprising from what I've heard of the input scheme.

>
> - when I press repeated times the square root, the input field doesn't
> size, so I see only the upper part of it anymore

Yes, there are loads of layout problems that would never happen if
layout were left to the browser.  Again, predictable (and what's worse
predicted).

>
> - sometimes the text for the buttons in the traing center is not readable
> (e.g. "Cle..." and "O..."), but sometimes the whole text is visible

Yes, browsers wouldn't likely make the same mistake.

>
> - in the Typing Tutorial, it is a green vertical bar, not a red vertical
> bar
>
> In general I think it is not a good idea trying to make a GUI application
> in a web browser.

It's very doable if you know what you are doing (and has been for well
over a decade).  More to the point, it's not a good idea to try to
make GUI applications with frameworks designed and implemented by
relative neophytes.  ;)

> If you don't want the user to install a program, you
> could use Flash, which works the same in all browsers on all platforms.

I would advise against that.  Flash is the wave of the past.

>
> But maybe better, if the user has no flash, would be a simple HTML
> interface without JavaScript, e.g. entering expressions in basic
> programming syntax, like sqrt(1/3)<10*x. This would work even for visuall=
y
> impaired users, too.

Exactly, but Kenny doesn't like "raw HTML" for some reason (likely
because he's never bothered to learn it).

> I guess your current application is useless for blind
> users.

No question there.  But Kenny stated something to the effect that
handicapped students were the "bottom of the barrel".  I took that to
mean that he considers such children unworthy of his efforts.

See Kenny squirm.  :)

>
> You can explain the syntax with some examples, and it has the advantage
> that the user can use this syntax later for programming or spreadsheets,
> too. Then you can use simple text forms, which works with all browsers,
> even very old or strange ones without Flash and JavaScript, e.g. on some
> mobile phones. On post, generate a nice image of the expression on server
> side and send it back to the browser, if you like.

What a great idea!  Unfortunately, similar proposals were dismissed
out of hand.  Something about assembly language and trolls.  :)

On Jul 21, 11:14 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> RobG wrote:
> > On Jul 21, 12:01 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> >> David Mark wrote:
> > [...]
> >>> Oddly enough, it seems to go back to the server constantly during user
> >>> interaction.
> >> Oddly enough, that's the frickin idea
>
> > It seems to me that you are using qooxdoo purely for presentation in
> > the client. Apparently you think it's massive bulk is required in
> > order to present a tabbed interface and do XHR.
>
> > Suppose you slim your application down to the following components:
>
> Sorry, but what problem of /mine/ are you trying to solve?

You are using a javascript library to cure your lack of knowledge of
HTML and CSS. You don't need to learn a lot about those technologies
to build your site. Had you invested the same amount of time and
effort learning them instead of qooxdoo, you may have a much more
efficient and accessible site.

> I appreciate
> all the links, but it means months more work and I am wondering why I
> would do that.

It's not months, hours maybe. As for why, see above.

[...]
> > A web search will show lots of examples of creating extensible tabs
> > with a small amount of HTML, CSS and script. Your pages are pretty
> > static so it should be a snap to create them without any javascript
> > library at all.
>
> My pages are static? I think you stopped at the typing tutorial.

I said *pretty* static, meaning they could be achieved largely using
static markup. Right now, of the 9 tabs, 5 do nothing so I can't
comment on those. One is a simple login tab (that should display
instantly but takes at least 3 seconds, even when going back to it
after it's been previously visible),  the other 3 only work if I
laboriously enter keystrokes very slowly and wait for the display to
update.

The interface is still very buggy, I can only judge by what I see.

Incidentally, on the login screen, if you check the "New User" button
more inputs are displayed (after about a 2 second display). In IE 6,
checking "Returning User" doesn't go back to the login and password
version (it does in Firefox, after a couple more seconds...).

In the typing tutor, the first button after "Press these keys" is
nested inside 5 span elements inside 27 div elements, 14 of which are
inside the tab. You think that isn't inefficient? Each div has a large
amount of inline styling, a lot using -moz so there's some browser
detection going on here.


[...]
> > Incidentally, if Firefox users have the "Search for text when I start
> > typing" preference checked, it plays havoc with your interface because
> > Firefox doesn't see it as an editable area and starts capturing
> > keystrokes.
>
> You see that happening? Ah, I limited calling preventDefault to
> backspace for some reason. Putting it back to all keystrokes until I
> remember the reason.
>
> Firefox needs to lose that option, btw.

No, you need to deal with it. It's a great option, I don't think it
will go away soon.


[...]
> > Your use of qooxdoo is essentially as crutch to generate the client
> > UI. There are many alternatives, a more popular one is to do the work
> > on the server and send generated HTML to the client. It tends to be
> > much faster and more robust.
>
> It seems fast enough.

Not to me, it is very slow. I'm comparing it to other commercial sites
that I use, such as banking or share trading, that have complex script-
driven dynamic UIs (I'm not commenting on the quality of the UI, just
that they are *much* snappier and do a lot of dynamic modification of
the page).

> Robust? qooxdoo is an active and steadily
> advancing library worked on by better web developers than I, how am I
> going to do better work than them?

Their work isn't that great, I think you'd be surprised at how easy it
is to do what you are doing without qooxdoo. And if your site is an
example, it isn't robust at all, it is very easy to break the UI. Of
course you'll say you aren't finished yet, but you're saying it's
simple to knock up the site yet you're having lots of UI issues (that
you seem to write off as either "I'm not finished yet" or "I don't
believe you").


> >> I know I have to linked to those before, what I do not know is how well
> >> you can read. The idea is to program in one language in one IDE and
> >> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exists.
>
> > That's been tried many, many times before and strangely those IDEs
> > haven't taken over the world. They likely fail for much the same
> > reasons general purpose javascript libraries fail - one is that if you
> > try to please everyone, you end up pleasing no one.
>
> They are doing fine, actually, tho the desktop per se not so much.

There will always be some around, maybe one day there'll be one worth
using (for web pages). Cappuccino is doing so well on Apple's MobileMe
site that they use browser sniffing to *prevent* their own mobile
devices from accessing the site.


> > Their main use seems to be programmers who know one language well but
> > need to write programs in another (in your case, Lisp -> HTML and
> > CSS). However the generated code is not as good as that written in the
> > target language to start with - natural selection takes care of the
> > rest of the story.
>
> Right, and I should be programming in assembler instead of Lisp. Except
> compilers eventually started writing better assembler.

If you insist on misrepresenting my argument then there's not much
point in continuing. To paraphrase, yet again, you likely would have a
better site had you spent the same amount of time learning HTML and
CSS as learning qooxdoo. And you would have avoided the issues
associated with that "framework".

I don't think you can seriously compare learning HTML the equivalent
of learning assembler.


> > All the time and effort you've spend learning qooxdoo might well have
> > been much better spent learning a bit of HTML and CSS - the actual
> > javascript part seems to be minimal.
>
> And later you suggest I rewrite the whole thing in JS.

No, I didn't. I would never contemplate that.


> I am sure I would have done better with Mr. Mark's library than with
> Dojo or anything else other than qooxdoo,

I'm not pushing MyLibrary, I'll let you judge it on it's merits.

> but I have done an in-depth
> survey of these things (which usually includes raw HTML/CSS) and I
> actually understand pretty well how much faster I can develop a web app
> using qooxdoo vs raw HTML/CSS.

Because you went looking for a framework to control from LISP, so
that's what you found.


> >> That said, I could reduce the size of each round-trip by taking an hour
> >> or two to create some pre-fab qooxdoo classes expressing the boilerplate
> >> I am shipping over, but the thing is so fast now I'll get to that after
> >> I get the "leveling-up thru Algebra" thing going.
>
> > I don't think the amount of data being transmitted is the issue, it's
> > the number of requests. There's a certain overhead that you can never
> > reduce so the speed of the application is limited to the speed of an
> > XHR request, and you have very little control over that.
>
> Sounds like a theoretical objection not supported by experience.

The experience of your site? It is positively slothful.

> I would
> not still be going down this path if performance did not look so good,
> and I have not even focused much on performance yet.

The performance is really, really slow. I have never experienced it
before because no site I know of has tried an XHR on every keystroke
(for obvious reasons). You don't have to have built many web sites to
know that an HTTP request takes a certain amount of time that is
beyond your control and may take a very long time based on completely
external factors, to do one on every keystroke is ridiculous.


> > The fix for that is to run your algebra program on the client. If you
> > care to rewrite it in javascript, it may be of interest.
>
> You want me to port 80kloc of a high-level language like Lisp to a toy
> language like JS? How big will the client be then? And how many motnhs
> would that take?

Javascript isn't a toy language - it's a bit like C in that respect.
The basic language is small and simple but you can build very large
and powerful applications using it. Richard Cornford has built
applications running to over 100,000 lines of code, perhaps you should
ask him whether it's a toy language.

Anyway, I had no idea how big your server component is, nor how big it
would be if ported to ECMAScript (since the clever part would likely
only need ECMAScript). DM's library is about 8,000 lines of code (with
comments and unminified) and minifies to about 80kB apparently.

I'm sure if you think about it you can work out how to modularise the
application and move bits to the client to reduce the use of XHR.


> To solve what problem? Remember, this group defines "Using a library" as
> a problem, but only this group.

You're nearly there... This group doesn't define using *any* library
as a problem, only the badly written ones. In fact it promotes the use
of *good* libraries - there should rarely be a need to write
everything from scratch.


--
Rob

On Jul 22, 2:18=A0am, RobG <rg...@iinet.net.au> wrote:
[...]

> DM's library is about 8,000 lines of code (with
> comments and unminified) and minifies to about 80kB apparently.

I expect you are thinking of the example build that I use of varies
demos.  It is not the full build, but just the bits that were
necessary for the Examples page.  I should really use smaller builds
for other demos (e.g. the Touch add-on).

JFTR, at the moment, the full build is 140K+ minified (and as Kangax
recently mentioned to me, could me somewhat smaller if I removed the
repeated var statements).  For comparison with "major" libraries that
blare about their compressed sizes, it's 48K after GZIP.  :)

On Jul 22, 2:18=A0am, RobG <rg...@iinet.net.au> wrote:

[...]

>
> In the typing tutor, the first button after "Press these keys" is
> nested inside 5 span elements inside 27 div elements, 14 of which are
> inside the tab.

Dear God.  All in the name of making everything look identical to the
pixel in every browser/platform.  Of course, that's impossible to do,
not to mention a backwards strategy (see CSS resets).

> You think that isn't inefficient? Each div has a large
> amount of inline styling, a lot using -moz so there's some browser
> detection going on here.
>

Oh brother.  That sounds like some frameworks I know.  It's bad enough
that these zealots create massive, slow, complicated blobs of script
that step all over the browser, but they invariably deliver
"replacements" that are so mind-bogglingly incompetent they insult the
user's sensibilities (assuming they have any).

I suppose the people behind these things understand that their
prospective users will likely "test" their demos in one of the latest
versions of major desktop browsers on a newer PC with a very fast
broadband connection.  They preach the message that things change so
fast with browsers that it's required to constantly rewrite, re-
download and re-test and re-deploy large blobs of complicated JS.
And, as for older versions or browsers they've never heard of (or
dismissed), the answer is apparently to pretend they don't exist (or
call for their them to be banned).

And, of course, browser sniffing doesn't just hinder end-users; it
makes it virtually impossible to stress-test scripts off the beaten
path (which is usually characterized as "wasting time" or trying to be
"perfect").  But clearly such concerns are mostly dismissed by Web
developers as evidenced by the fact that many sites (even major
concerns like Google) throw exceptions (or fail to work properly) in
the latest versions of the handful of browsers they do "spend time"
observing.  Given such a carefree attitude, such futile results are
predictable.

Kenneth Tilton :

> 5. Enjoy. And tell your Algebra teacher friends I am looking for local
> schools interested in being guinea pigs.

Enjoy ?!? Well, make it work for a start. And I'm not talking about the 
thousands of errors or undefined properties in the javascript console. 
I'm talking about the "exercices", most of them are giving a totally 
wrong answer.

Let's test it, the first one I tried :

Simplify : 45 / 2 - 5 / 10

Simplest form : 45 / 4

Really ??? Damn, I asssume I'll suck at math forever.

Time for me to definitly give up on trying this algebra spam, it doesn't 
deserve any more seconds of my precious time.

-- 
laurent

Matt Kruse wrote:
> On Jul 21, 12:55 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> made easier with prudent use of libraries.
>> Unless you are referring to my library, how backwards can you get?
>> The "major" libraries are notorious for their failures in IE6, so how
>> can they possibly help?
> 
> All these years, and you still haven't grasped the simple point...
> 
> A library may work well in IE6 for, let's say, 80% of problems that
> the library may try to solve. It may work only partially on 15%, and
> fail miserably on the remaining 5%.
> 
> Take advantage of the 80% of features that work just fine, and use the
> library. Don't try to use the library on the remaining 20% of features
> that they have coded incorrectly or that, for whatever reason, don't
> work.
> 
> Any reasonable person would understand that strategy, IMO. Because we
> do it all the time with other things. Almost no tool gets everything
> right. Successful people know how to identify which parts of which
> tools should be used, and then use them. Not throw them out because
> they fail to solve 100% of all conceivable problems that they may
> encounter.

Right. You can always tell people Actually Using Computers from people 
just spouting on Usenet. The former balance what a library offers 
against what it costs and make a decision and get on with building their 
apps, dealing with problems as they come up without much fuss, including 
even just not using some problematic bit.

A good example was qooxdoo. My evaluation involved using a datagrid, a 
component we would be using for everything it seems. The qooxdoo one had 
  a flaw (since cured) causing it to ask the server the same question so 
many times (for no reason) it killed performance. But I already like 
qooxdoo so I dug into the code to see what was up, and the code was 
really nice, making the thing easy to fix. Then I had a datagrid faster 
than even bare-bones ones I had tried as well as a lot of confidence in 
qooxdoo.

Keep the eye on the prize: building the app.

kt



-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

Frank Buss wrote:
> Kenneth Tilton wrote:
> 
>> So are the buttons appearing OK now that each typing example gets loaded 
>> separately? http://teamalgebra.com/
> 
> I've tried it with Opera.


> When trying to register, I didn't fill out each
> field and it says "Login error: Please fixFORM-FIELD98737". That's a very
> useful information :-)

Nice, eh? That's all been cleaned up and recovery now works (on my dev 
version). As soon as I enable the handling of simultaneous login (a 
no-no) I will install.

> 
> Some other things I noticed:
> 
> - I can't use any key above my numbers (German keyboard), e.g. "/" or "("
> doesn't work and "=" is on "*"

Hmmm. I imagine there is someway to tell Windows to do "German 
keyboard"? And I think I see I need to work a little harder on 
understanding qooxdoo key events.

> 
> - Backspace deletes always two characters
> 
> - cut, copy and paste to and from the input field doesn't work
> 

You mean a math input field? I do OK with the fields from the 
login/registration page.

> - when I press repeated times the square root, the input field doesn't
> size, so I see only the upper part of it anymore

I need to spend prolly a full day or two on extending jsMath to announce 
the DOM dimensions after the html has been generated, and then I will be 
able to do much better on things like this. I have a hard-coded kludge 
in there as a stopgap, and I am thinking I never looked much at the root 
symbols.

> 
> - sometimes the text for the buttons in the traing center is not readable
> (e.g. "Cle..." and "O..."), but sometimes the whole text is visible

Weird.

> 
> - in the Typing Tutorial, it is a green vertical bar, not a red vertical
> bar

That's why I never document anything -- it never keeps up!

> 
> In general I think it is not a good idea trying to make a GUI application
> in a web browser. If you don't want the user to install a program, 

....I do not, nor do I want to mess with multiple operating systems.

> ...you
> could use Flash, which works the same in all browsers on all platforms.
> 
> But maybe better, if the user has no flash, would be a simple HTML
> interface without JavaScript, e.g. entering expressions in basic
> programming syntax, like sqrt(1/3)<10*x. 
> This would work even for visually
> impaired users, too. I guess your current application is useless for blind
> users.
> 
> You can explain the syntax with some examples, and it has the advantage
> that the user can use this syntax later for programming or spreadsheets,
> too. Then you can use simple text forms, which works with all browsers,
> even very old or strange ones without Flash and JavaScript, e.g. on some
> mobile phones. On post, generate a nice image of the expression on server
> side and send it back to the browser, if you like.
> 


The audience is thirteen year-olds who already hate math. They will not 
be able to cope with ascii math.

Thx for the detailed report!

kt


-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 22, 11:37=A0am, Laurent vilday <mok...@mokhet.com> wrote:
> Kenneth Tilton :
>
> > 5. Enjoy. And tell your Algebra teacher friends I am looking for local
> > schools interested in being guinea pigs.
>
> Enjoy ?!? Well, make it work for a start. And I'm not talking about the
> thousands of errors or undefined properties in the javascript console.

Hmmm.  As bad as it was, I didn't see thousands of errors.  Strict
mode warnings?  The one about undefined properties is a waste of log
space.

Laurent vilday wrote:
> Kenneth Tilton :
> 
>> 5. Enjoy. And tell your Algebra teacher friends I am looking for local
>> schools interested in being guinea pigs.
> 
> Enjoy ?!? Well, make it work for a start. And I'm not talking about the 
> thousands of errors or undefined properties in the javascript console. 
> I'm talking about the "exercices", most of them are giving a totally 
> wrong answer.
> 
> Let's test it, the first one I tried :
> 
> Simplify : 45 / 2 - 5 / 10
> 
> Simplest form : 45 / 4
> 
> Really ??? Damn, I asssume I'll suck at math forever.

Really ??? I got "Ah, bad luck." I tried messing up the instructions by 
telling it I was solving and factoring and it still rejected 45/4.

That was in the Freestyle tab. I don't think you were in the training 
center cuz I do not see it generating that type of problem.

Over in the training center when I have the tutor solve a problem it 
does OK. I have a regression test mechanism that does a thousand 
training center problems at random spread over each category and that 
ran three times without failing recently.

> 
> Time for me to definitly give up on trying this algebra spam, it doesn't 
> deserve any more seconds of my precious time.
> 

I feel the same about your problem reports. :)

kt

-- 
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself." 
Macworld

On Jul 15, 5:21=A0pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> David Mark wrote:
> > Scott Sauyet wrote:
> >> "S.T." wrote:
> >>> [in response to Matt Kruse]
> >>> You are in a small subset of developers that use jQuery by choice, ye=
t
> >>> 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 anythin=
g
> >>> wrong with that, just a somewhat unique view.
>
> >> You can put me in that category as well.
>
> > The category of those who abdicate responsibility for cross-browser
> > scripting to the jQuery authors (of all people), despite being told
> > repeatedly of their collective incompetence?
>
> No, you must have misread.

It is a very rare case where I misread (and this is not one of them).

> I was discussing the category of people
> who use their clients' and employers' resources wisely,

That would be the "category of people" who "wisely" use a dubious 70K
script that has been proven to be incompetently written and
maintained.

> using tools

There's that word again.

http://farm4.static.flickr.com/3211/2347642183_91247aa0c8_o.jpg

> that work well for the environments those clients care about,

You mean that break in last year's browsers, barely "work" in a
handful of today's browsers, are too bloated for mobile devices and
are a good bet to break in next year's browsers, requiring costly
"upgrades" and reboots of QA testing.  And, of course, the clients
rarely understand any of this.  You are supposed to be the "wise"
expert steering them clear of costly junk code.

> people
> who understand enough about browser-scripting to do the work
> themselves

That's a crock (and completely irrelevant).  The client doesn't care
what you think you can or cannot do.  They care what you *actually* do
with their money.  And saying you could have done things in competent
fashion but didn't raises serious questions about your integrity.

> but choose to use a library that substantially speeds up
> certain parts of the job,

As we've been over about a million times, the "speed up" is an
illusion.  It may save you a few minutes in the present, but these
"savings" are borrowed against future losses.

> people who make up their own minds about the
> competence of their tools and the authors of those tools.

Everyone should make up their own minds.  The information is out
there.  What you do with that informations sheds light on your mindset
and reasoning ability (or lack thereof).

>
> >> 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.
>
> > It only allow creates the illusion of simplifying your development.
> > Odd that you can't see that after all of the related discussions.
>
> No. =A0In fact, it does simplify my development.

See above.  The long-term costs and benefits are far more complicated
than you make them out to be.

> Odd that you think you
> can see over my shoulders from way back there.

Way back where?  I'm so far ahead of you that you've disappeared over
the horizon.

> Are you really as
> arrogant as you come across?

It's easy to come off as arrogant in an industry teeming with cargo
cults and pseudo-intellectual apologists.

>
> > And why do you need something to take its place? =A0It's a 70K QSA
> > wrapper. =A0As we've been over repeatedly, CSS selector queries are
> > highly ill-advised and there aren't many "supported" browsers left
> > that lack QSA anyway. =A0What's left to replace? =A0A ham-fisted API th=
at
> > is completely inappropriate for browser scripting?
>
> As we've been over repeatedly, CSS-selectors are often the very best
> tools for the job.

You must not have been paying attention during those discussions.  CSS
selector queries are virtually *never* the "best tools" for the job.
This is particularly true when using demonstrably faulty
implementations (as would be expected).  jQuery is a prime example.

> And I know that you've read enough of jQuery's
> source to realize that the selectors engine is probably 15% - 20% of
> the total.

I don't know where you came up with that figure.  The whole thing is
tangled up with selectors and all of it is highly dubious.  From the
event handling to the silly animations, it is all junk code (and has
been shown to be such so many times that arguing anything else
indicates madness.

>
> >> 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.
>
> > That makes no sense at all. =A0You'd feel comfortable handing off a
> > script that you know is full of holes?
>
> No. =A0I am willing to hand off code that I know is not perfect,

The pigeonholing of code as "perfect" or "not perfect" is a disturbing
trend.  Such oversimplifications have no place in programming.

> if I
> can comfortably describe its limitations and flaws,

But you can't.  You've demonstrated repeatedly that you have no clue
(see also Matt Kruse).  And the crap changes constantly anyway, so
whatever land mines you've mapped out today may well change position
tomorrow.

> and if it works
> reliably.

jQuery does not work reliably in any sense of the word.

> What I'm not comfortable doing is handing off code that I
> think the client cannot fix themselves or for which they cannot find
> simple help fixing.

The goal is to hand off code that will not *need* fixing.  Handing off
something that you *know* is broken in numerous ways is clearly
contrary to that goal.

> I'm afraid right now that any clients I have who
> do not have the expertise to fix things themselves would not get
> helpful responses from the minimal community around My Library.

That's a worthless argument and assumes that the only two choices are
jQuery and My Library.  Furthermore, quantity doesn't trump quality.
Most people who have questions about My Library get help straight from
*me*, not fellow pattern rearrangers.

>
> =A0=A0
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 And unlike jQuery, the code in
> > My Library is relatively easy to follow. =A0So what's your point? =A0If
> > the client Googles the name they won't find tons of gushing blog posts
> > and bad examples?
>
> No, that doesn't bother me much. =A0Frankly, it's you and the attitude
> you display here that prevents me from even considering suggesting My
> Library to any clients.

Then you admit that you allow your own feelings (however misguided) to
influence the critical decisions you must make on behalf of your
clients or employer?  That's not how business works.  Companies
couldn't care less about your feelings.  They care about how many
times they have to re-download jQuery and re-test their applications,
how many end-users are needlessly excluded due to dubious decisions,
etc.

>
> >> At the moment, JQuery seems the best of a fairly bad bunch.
>
> > And what seems to indicate that? =A0Like the rest, it calls QSA (with
> > very little in the way of feature testing) and hands off to a proven
> > mess of unfinished nonsense in the event of an error.
>
> >http://www.cinsoft.net/slickspeed.html
>
> > But, of course, you've already seen that. =A0IIRC, your position was
> > that the demonstrably execrable results were somehow my fault for
> > "trying to breakit". =A0:(
>
> I'm afraid you don't recall correctly.

I'm afraid I do.

> My position was simply that
> you were misusing the speed test as a conformance test,

So, let me get this straight.  Because the test in question measures
both speed as well as conformance, its results on the latter must be
dismissed out of hand.  It compares a wide variety of query engines
and their ability to retrieve the correct results.  The presence of
almost random results and exceptions across the board (save for my two
columns of course), varying from one browser to the next is of no use
to you because of the word "speed" in the title?

> misrepresenting the other libraries thoroughly in the process.

I misrepresented nothing.  You tried to sieze on the fact that one of
the columns was jQuery 1.21 (though in reality it turned out to be
1.26).  As was explained to you at the time, that was the last version
of jQuery that did not use QSA.  The code that newer versions of
jQuery (featured in adjacent columns) fall back on when QSA fails is
very similar to the code found in 1.26 and therefore similar results
can be expected when those versions are used with browsers that do not
feature QSA.  Furthermore, it's been demonstrated ad nauseam that this
code is highly incompatible with QSA rendering the decision to layer
the two as ridiculous as most other aspects of the jQuery design.

The tests are mostly basic selectors that all of the "major" libraries
claimed to support.  You had some problem that I added additional
selectors not found in the "standard" Slickspeed tests (of which there
is no standard rendition).  And as was noted at the top of the page,
several of the selector categories (e.g. nth-child) were newly added
features to My Library.  So, like some scheming child you went back
and dug up an old version of My Library that had no code to figure
such selectors (and made no claims to feature such code), cooked up
your own "test" that predictably failed for the selectors that had no
support.  Somehow you equated that with the failings of the others,
despite the fact that they always claimed to support those selectors
and had code in place to attempt to do so.  That was the
misrepresentation you remembered and it was clearly yours alone.  As I
noted at the time, I'd never seen such an ignorant (and transparent)
display and you were clearly trying to smoke-screen the results that
exposed your own bad decisions.

>
> >> But I really don't want to skip a library altogether.
>
> > Why? =A0Cross-browser scripting is relatively easy these days, making
> > jQuery and the like antiquated notions. =A0By far, they create more
> > problems than they solve.
>
> They haven't for me or my clients.

The thing is, when clients realize they've been had by overconfident
rookies with puffed up resumes, they don't call back and they aren't
likely to keep them in the loop regarding efforts to fix the problems
they introduced.  No news can be bad news in this business.

>
> >> 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 therein lies the problem. =A0If you would stop and think about it,
> > you would realize that you don't need most of what is in those
> > libraries, not to mention the fact that those libraries have failed
> > miserably (over the course several years) at their shared goal. =A0They
> > are selling both problems and (very bad) solutions. =A0Using them over
> > and over leaves you with no solutions of your own, which is your own
> > fault.
>
> I've written table-striping code for when I can't add the "odd"
> classes on the server.

You like to talk about what you've done.  I don't see it as relevant.

> I've written several different version of such
> code.

Yes.

> It's not at all difficult to write.

Of course it isn't difficult to set the class of alternating rows in a
table.

> But including that code in
> my build and adding whatever calls are needed to apply it is more
> difficult than doing this:
>
> =A0 =A0 $("#myTable tbody tr:odd").addClass("odd");

Same bogus argument.  Even if it were more difficult, taking the easy
way out to save a few minutes is not the hallmark of a competent
professional.  Feeding that monstrosity into some QSA/jQuery stack is
pure lunacy.  I rip such code out of projects on an almost daily
basis.

>
> Moreover if I decide I want to apply it to a certain class of tables
> instead, I don't need to ensure that I can collect them by class name
> and then run a loop over the bunch. =A0I can do this instead:
>
> =A0 =A0 $("table.zebra tbody tr:odd").addClass("odd");

Yeah, thanks for the lesson queries and chaining.  :)

>
> I don't have to want to use all the code that jQuery supplies, just
> enough of it that it's worth my time dealing with its flaws.

You can't be a little bit pregnant and using a large, monolithic
library when you only "need" a fraction of its features is the classic
script kiddie mistake.

>
> >> And I don't think it's *that* bad.
>
> > Software either works or it doesn't. =A0
>
> Software either meets your needs or it doesn't.

Your perceived needs are irrelevant.  And your clients needs are never
served well by dropping jQuery into a project.

>
> Doesn't it annoy you when posters come here complaining just that
> their script "doesn't work?"

Yes it does.

> We need to know what they expect before
> we can tell for ourselves that it doesn't work.

Yes.

> The same holds true
> for libraries.

In terms of logic, you just took a sharp turn right off a cliff.  You
clearly don't know much about how jQuery works (or doesn't) and what
little you do know you seem to dismiss as irrelevant (e.g. miscounts
and exceptions documented in the context of "speed tests" don't
count).

> What I expect out of them is clearly something less
> than what you expect.

Clearly.

> So you shouldn't use them, clearly.

Obviously I don't.  I barely use my own library.

> But your
> evangelizing against them has really not convinced me that these
> libraries are inherently flawed.

Then you are too thick to be trying to write cross-browser scripts.

>
> > Software authors have talent or they don't.
>
> Do you think Donald Knuth never wrote any bad code? =A0Was Edsger
> Dijkstra's code so perfect that no one would ever find a flaw in it?

That's irrelevant.

> Talent is only part of the story.

Well, for example, the authors of jQuery have not demonstrated much in
the way of talent for the sort of problem-solving required to write a
cross-browser script.  That's a huge part of that story.

> It's important, but there is more
> to well-built software, especially software built by a community.

Results are results.  All of this babbling about "it takes a village"
when the software is miscounting and throwing exceptions (among many
other things) is ridiculous.  The village in question is obviously
full of idiots.

>
> >=A0Some apologists like to point to Windows as a product
> > that is not "that bad", but still pervasive. =A0Of course, the
> > difference between a completely transparent 70K script and an OS
> > should be apparent.
>
> It seems apparent to me, but in a manner that belies the rest of your
> argument. =A0Which do you think you should trust more, a reasonably
> small script that you can understand in detail with some concentrated
> effort, whose flaws you can detail for yourself efficiently -- or a
> 50+-million lines-of-code behemoth that you can only treat as a black
> box?

You aren't making any sense in context.  My argument is that you can't
compare operating systems (which you are pretty much stuck with) with
dubious blobs of JS (which are 100% transparent and avoidable).

>
> > What has jQuery done for you, other than leave you short of time and
> > code and therefore perpetually dependent on it? =A0
>
> I think it might do that for script kiddies.

You are the worst sort of script kiddie, disguised as an intellectual.

> But for competent
> developers, it's just a collection of short-cuts for things they could
> do themselves if they really wanted to.

Competent developers don't use jQuery.  They don't even consider it.
And therein lies the rub (for you).  You don't want to admit that
you've made incompetent decisions, so you babble on about
"misrepresentations" and "communities" and whatnot.  It's disgusting.

>
> I do a lot of work in Java.

So did the Dojo nuts.  It's a rare individual who makes the transition
to browser scripting.

> And years ago I wrote logging systems to
> fit my needs.

So?

> They were better adapted to exactly what we wanted to
> do than any general-purpose logging library ever could be. =A0But I
> would probably never write one again, because the general-purpose
> libraries have gotten so useful, and they work well-enough for my
> needs, and they come without several weeks worth of development.

Java is not browser scripting.  The typical Java developer doesn't get
that it takes far more discipline to use a "toy" language to script
browsers, so they try to go about it like they were writing Java
applets.  It doesn't work (see Dojo).

>
> > [too much more for me to respond to right now.]
>

This was more than enough, thanks.

On 17 June, 08:10, Joe Nine <j...@yahoo.com> wrote:
> it's like it's own new
> language

Talking of language, possessive its has no apostrophe (see:
http://groups.google.co.uk/group/alt.possessive.its.has.no.apostrophe)

We started a project last week. JQuery was, as usual, mentioned both in 
functional and technical specs in an attempt to reuse some older bits of 
code and, supposedly, ease the job for everyone.

I was ready to accept this as I don't feel confident enough to start a 
project at my day job all with my limited skills.

There is a carrousel at the bottom of the page. After a while looking 
for a suitable JQuery-related plugin/tutorial I settled down for one 
which had the exact same features as we had planned and that we had used 
previously. After reviewing the code I had a bizarre impression: all the 
dollar signs seemed completely useless.

It actually took me less than 10 mn to transform this heavily JQuery 
reliant script into a straight "raw" script without adding more than a 
couple of lines. JQuery was used only to query DOM elements by ID and 
move around a couple of those elements. Every

$('#id').method();

was readily replaceable by a

var foo = d.getElementById('id'); // "cached" early on
foo.bar = 'value';

or some similarly simple code.

In 10 mn I was able to remove entirely any dependency on JQuery from the 
whole project. That's 70 Kb less, and that's good for everyone involved 
: lighter, faster, more compatible, more reliable, more readable...

Now, I don't want to fall in the trap of becoming too confident over 
such a small win but shit, but it doen't feel that hard to learn to 
write real "JavaScript" for simple tasks like that.

On Jul 16, 7:21 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
[...]
> I've written table-striping code for when I can't add the "odd"
> classes on the server.  I've written several different version of such
> code.  It's not at all difficult to write.  But including that code in
> my build and adding whatever calls are needed to apply it is more
> difficult than doing this:
>
>     $("#myTable tbody tr:odd").addClass("odd");

Presuming this is a task you've done often, you should be re-using a
simple function that should not be re-written every time. So the
alternative is something like:

    stripeTable(tableId, oddClass[, evenClass]);

Damn, that is so much more difficult.

> Moreover if I decide I want to apply it to a certain class of tables
> instead, I don't need to ensure that I can collect them by class name
> and then run a loop over the bunch.  I can do this instead:
>
>     $("table.zebra tbody tr:odd").addClass("odd");

Extending the functionality of the stripeTable function (once) to
support selecting tables by class, or to accept an array of tables to
stripe, is trivial too. e.g.

  stripeTable(getByClass(className), oddClass[, evenClass]);

The examples suggest someone who uses jQuery because they don't want
to maintain their own (or a development team's) library of proven
code. Such libraries require effort to develop, support and maintain,
but the payback is worth it.


--
Rob

On 8/5/2010 4:54 PM, RobG wrote:

> The examples suggest someone who uses jQuery because they don't want
> to maintain their own (or a development team's) library of proven
> code. Such libraries require effort to develop, support and maintain,
> but the payback is worth it.

So you agree JS libraries are generally a good idea... you just think 
every developer should write and maintain their own.

The jQuery project should be scrapped and replaced by tens of thousands 
of individually developed and maintained general purpose DOM/Ajax 
libraries. Perhaps hundreds of thousands. Each one slowly expanded over 
time as a developer comes to realize he/she would find value in another 
bit of reusable functionality in his arsenal.

Genius!

On 2010-07-17 07:12 PM, David Mark wrote:
> On Jul 17, 9:41 pm, Garrett Smith<dhtmlkitc...@gmail.com>  wrote:
>

[...]
>> One thing that I have wanted to change is the "Avoid modifying objects
>> you don't own. ". While that is a nice trite phrase, it doesn't cover
>> the aspects of defining cohesive objects.
>
> I think it gets the point across.  It's very easy to by accident (or
> in haste).
>

Which point?

>>
>> "Define cohesive objects" is better but that does not imply that doing
>> the opposite is wrong.
>
> In contrast, I don't know what that means; so the first one is
> definitely better.
>

Any programmer should know what cohesion is. Google is your friend.

The reason "don't modify objects you don't own" isn't enough is that, 
say, Joe Coder creates and ADT* Menu and puts that in Menu.js, then he 
creates an ADT FlyMenu and puts that in FlyMenu.js. So far so good. Then 
he realizes that for FlyMenu, the show behavior needs to be different, 
and so within FlyMenu.js, he modifies Menu.js. This creates a coupling 
so that when FlyMenu is used, it works, but when Menu is used and 
FlyMenu.js is on the same page, Menu doesn't work the same.

According to code guidelines doc, that's allowable.

So clearly, the "don't modify object's you don't own" is not enough. The 
concept of a person owning an object is irrelevant to the code. What 
matters is how the objects communicate, not who their respective authors 
or "owners" may be.


* (ADT in this paradigm means a constructor + associated prototype, plus 
possibly a few functions hidden in a closure).

>>
>> "Avoid interdependencies" is better
>
> But something else altogether.
>
Not entirely. I like this. "Avoid" is good here because it doesn't say 
"don't ever create a dependency."
-- 
Garrett

On 2010-07-14 09:58 PM, David Mark wrote:
> On Jun 18, 11:06 am, Johannes Baagoe<baa...@baagoe.com>  wrote:
>> Thomas 'PointedEars' Lahn :
>>
>>> Matt is still not getting that (JS) libraries as a concept are not the
>>> issue, but the people writing them.
>>
>> That, exactly, is what bothers me in those discussions : the issue seems
>> to be *the people* writing those libraries. Technical objections alone
>> would hardly justify personal smears.
>>
>
> When choosing a script, the relative proficiency of the author(s) is
> certainly relevant.

The code itself is what matters.

Though it might make you angry, in the case of an author such as 
yourself, I can see why some might make an exception to that.

It was also once claimed that you threatened to sue John Resig while he 
was in the midst of publicly discussing porting over your tests. if that 
is true, then I can see why one in John Resig's position would want to 
avoid using your code.
-- 
Garrett

On 7/08/2010 10:01 AM, Garrett Smith wrote:
> On 2010-07-14 09:58 PM, David Mark wrote:
>> On Jun 18, 11:06 am, Johannes Baagoe<baa...@baagoe.com> wrote:
>>> Thomas 'PointedEars' Lahn :
>>>
>>>> Matt is still not getting that (JS) libraries as a concept are not the
>>>> issue, but the people writing them.
>>>
>>> That, exactly, is what bothers me in those discussions : the issue seems
>>> to be *the people* writing those libraries. Technical objections alone
>>> would hardly justify personal smears.
>>>
>> When choosing a script, the relative proficiency of the author(s) is
>> certainly relevant.
>
> The code itself is what matters.

That are implies that incompetent authors can and do write "good" code.

Andrew Poulos

On 2010-08-06 11:35 PM, Andrew Poulos wrote:
> On 7/08/2010 10:01 AM, Garrett Smith wrote:
>> On 2010-07-14 09:58 PM, David Mark wrote:
>>> On Jun 18, 11:06 am, Johannes Baagoe<baa...@baagoe.com> wrote:
>>>> Thomas 'PointedEars' Lahn :
>>>>
>>>>> Matt is still not getting that (JS) libraries as a concept are not the
>>>>> issue, but the people writing them.
>>>>
>>>> That, exactly, is what bothers me in those discussions : the issue
>>>> seems
>>>> to be *the people* writing those libraries. Technical objections alone
>>>> would hardly justify personal smears.
>>>>
>>> When choosing a script, the relative proficiency of the author(s) is
>>> certainly relevant.
>>
>> The code itself is what matters.
>
> That are implies that incompetent authors can and do write "good" code.
>

I'd be more likely to trust code from a source I know is reliable but 
when it comes to assessing the code, the code alone should be assessed.

And if it's not good code, then the mistakes can be pointed out so the 
author can learn from them.
-- 
Garrett

On Aug 7, 2:18=A0am, "S.T." <a...@anon.com> wrote:
> On 8/5/2010 4:54 PM, RobG wrote:
>
> > The examples suggest someone who uses jQuery because they don't want
> > to maintain their own (or a development team's) library of proven
> > code. Such libraries require effort to develop, support and maintain,
> > but the payback is worth it.
>
> So you agree JS libraries are generally a good idea...

Where a library is a repository of reusable code, yes.


> you just think
> every developer should write and maintain their own.

Why not? Developers would learn a lot by developing their own
libraries as a professional development exercise and for potential use
for small jobs where a larger library is not required.


> The jQuery project should be scrapped

Preferably it will be replaced by one or more competent libraries that
are used for projects where such a libraries are beneficial.


--
Rob

On Fri, 6 Aug 2010 at 09:18:01, in comp.lang.javascript, S.T. wrote:

  <snip>
>So you agree JS libraries are generally a good idea...

If they are competent.


>you just think every developer should write and maintain their own.

If they can't find a competent one, or can't find one that does just
what's needed without extra unused bloat.


>The jQuery project should be scrapped

Yup! My ISP uses jQuery. It isn't compatible with my up to date IE8.


>and replaced by tens of thousands of individually developed and
>maintained general purpose DOM/Ajax libraries.
  <snip>

You seem to be having trouble thinking straight. (Hint : there are more
than two choices.)

  John
-- 
John Harris

On Aug 6, 12:18=A0pm, "S.T." <a...@anon.com> wrote:
> On 8/5/2010 4:54 PM, RobG wrote:
>
> > The examples suggest someone who uses jQuery because they don't want
> > to maintain their own (or a development team's) library of proven
> > code. Such libraries require effort to develop, support and maintain,
> > but the payback is worth it.
>
> So you agree JS libraries are generally a good idea...

Virtually any re-usable bit of code written in JS could be (and often
is) called a "library".  Thus the term is generally meaningless.

> you just think
> every developer should write and maintain their own.

No, that's the old "write everything from scratch as the only
alternative" non-argument.

>
> The jQuery project should be scrapped and replaced by tens of thousands
> of individually developed and maintained general purpose DOM/Ajax
> libraries.

The "jQuery project" is just a bad script that's been demonstrated to
fail at virtually everything it has tried to do.  It's become a symbol
of JS futility, just like Prototype and countless others like it.

> Perhaps hundreds of thousands. Each one slowly expanded over
> time as a developer comes to realize he/she would find value in another
> bit of reusable functionality in his arsenal.

When you consider how bad jQuery has been demonstrated to be, it
doesn't make a hell of a lot of sense to for everyone to use it for
everything, does it?

On Aug 6, 7:48=A0pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> On 2010-07-17 07:12 PM, David Mark wrote:
>
> > On Jul 17, 9:41 pm, Garrett Smith<dhtmlkitc...@gmail.com> =A0wrote:
>
> [...]
>
> >> One thing that I have wanted to change is the "Avoid modifying objects
> >> you don't own. ". While that is a nice trite phrase, it doesn't cover
> >> the aspects of defining cohesive objects.
>
> > I think it gets the point across. =A0It's very easy to by accident (or
> > in haste).
>
> Which point?

The point about not modifying objects you don't own.

>
>
>
> >> "Define cohesive objects" is better but that does not imply that doing
> >> the opposite is wrong.
>
> > In contrast, I don't know what that means; so the first one is
> > definitely better.
>
> Any programmer should know what cohesion is. Google is your friend.

That's not what I said.  Google yourself.

>
> The reason "don't modify objects you don't own" isn't enough is that,
> say, Joe Coder creates and ADT* Menu and puts that in Menu.js, then he
> creates an ADT FlyMenu and puts that in FlyMenu.js. So far so good. Then
> he realizes that for FlyMenu, the show behavior needs to be different,
> and so within FlyMenu.js, he modifies Menu.js. This creates a coupling
> so that when FlyMenu is used, it works, but when Menu is used and
> FlyMenu.js is on the same page, Menu doesn't work the same.

See, that's a completely different point.

>
> According to code guidelines doc, that's allowable.

You lost me, doc.

On Aug 6, 8:01=A0pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> On 2010-07-14 09:58 PM, David Mark wrote:
>
> > On Jun 18, 11:06 am, Johannes Baagoe<baa...@baagoe.com> =A0wrote:
> >> Thomas 'PointedEars' Lahn :
>
> >>> Matt is still not getting that (JS) libraries as a concept are not th=
e
> >>> issue, but the people writing them.
>
> >> That, exactly, is what bothers me in those discussions : the issue see=
ms
> >> to be *the people* writing those libraries. Technical objections alone
> >> would hardly justify personal smears.
>
> > When choosing a script, the relative proficiency of the author(s) is
> > certainly relevant.
>
> The code itself is what matters.

Try to follow me on this.  Authors who don't know what they are doing
usually attempt to "solve" problems by mystical incantation.  That
never leads to good code.  So if you know the relative proficiency of
the author(s) is poor you can skip wading through their magic spells.

>
> Though it might make you angry, in the case of an author such as
> yourself, I can see why some might make an exception to that.

How can something that makes no sense make me angry?

>
> It was also once claimed that you threatened to sue John Resig while he
> was in the midst of publicly discussing porting over your tests.

I'll sue anyone who tries to steal material bearing my copyright.  And
you are really all over the map here.  Try to focus.

> if that
> is true, then I can see why one in John Resig's position would want to
> avoid using your code.

You mean why he would try to avoid (blatantly) stealing my code.  And,
again, this has no relevance to the fact that jQuery is junk.  Whether
I posted a library or not, it's still junk.

RobG wrote:
> On Jul 16, 7:21 am, ScottSauyet<scott.sau...@gmail.com> wrote:
> [...]
>
>> I've written table-striping code for when I can't add the "odd"
>> classes on the server. =A0I've written several different version of such
>> code. =A0It's not at all difficult to write. =A0But including that code =
in
>> my build and adding whatever calls are needed to apply it is more
>> difficult than doing this:
>
>> =A0 =A0 $("#myTable tbody tr:odd").addClass("odd");
>
> Presuming this is a task you've done often, you should be re-using a
> simple function that should not be re-written every time. So the
> alternative is something like:
>
> =A0 =A0 stripeTable(tableId, oddClass[, evenClass]);
>
> Damn, that is so much more difficult.

Sorry for the late response.  Just catching up from two weeks'
vacation.

I believe you're missing the point here.  I was saying that I have
done exactly that, and can do so competently and without issue.  If I
needed to add zebra striping to an otherwise static page, I would
certainly not introduce a library as large as jQuery to do so.  But in
a page that needs some simple animation, perhaps some rounded corners,
a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
coder before me may well have introduced a library which makes this
new zebra call quite easy, without introducing any other old scripts
of mine.

So, coding in a page that already uses jQuery, I can either (a) dig
through my libraries and find an existing zebra function, add that to
my custom JS or import a new JS file, making sure that it's included
in all pages that might want to stripe, and then call it with a one-
liner or (b) include a jQuery one-liner.

Determining the exact threshhold of when to introduce a larger library
is tricky, and crossing it often means going through existing code and
removing parts duplicated by the library, but it will generally speed
up further development.

I've recently joined a new project that had already gotten underway
and was heavily using two of the big libraries.  Just today, I helped
remove the last vestiges of YUI from the code, but only by using the
equivalent jQuery tools.  I wouldn't even consider trying to replace
all the jQuery in the application with custom code right now, and even
if I were to try, I'd never convince management of my teammates of the
rationale for it, not unless they were to run across issues with
jQuery that seemed substantial.  I've been in the same place with Dojo
in the past.  It's not that I think these libraries are even remotely
close to perfect, but they fit the need of the client.

--
Scott

On 2010-08-19 08:21 PM, Scott Sauyet wrote:
> RobG wrote:
>> On Jul 16, 7:21 am, ScottSauyet<scott.sau...@gmail.com>  wrote:
>> [...]
>>
>>> I've written table-striping code for when I can't add the "odd"
>>> classes on the server.  I've written several different version of such
>>> code.  It's not at all difficult to write.  But including that code in
>>> my build and adding whatever calls are needed to apply it is more
>>> difficult than doing this:
>>
>>>      $("#myTable tbody tr:odd").addClass("odd");
>>
>> Presuming this is a task you've done often, you should be re-using a
>> simple function that should not be re-written every time. So the
>> alternative is something like:
>>
>>      stripeTable(tableId, oddClass[, evenClass]);
>>
>> Damn, that is so much more difficult.
>
> Sorry for the late response.  Just catching up from two weeks'
> vacation.
>
> I believe you're missing the point here.  I was saying that I have
> done exactly that, and can do so competently and without issue.  If I
> needed to add zebra striping to an otherwise static page, I would
> certainly not introduce a library as large as jQuery to do so.  But in
> a page that needs some simple animation, perhaps some rounded corners,
> a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
> coder before me may well have introduced a library which makes this
> new zebra call quite easy, without introducing any other old scripts
> of mine.
>

A server side function has the advantage in that it requires no JS -- no 
js to download and none to execute for that. Better performance and 
works in any browser.

if you reduce dependency upon a generalized object, then that thing can 
be removed. The jQuery object is about animation, dom manipulation, DOM 
events, and finding other elements, so a generalized object.

If animation is being used as a visual enhancement then why not use 
degrading CSS transitions? Rounded corners is a visual effect and 
border-radius and friends (-moz-border-radius etc) is widely supported.

A function to stripe a table makes sense but it could be more 
generalized though, such forEach. Where supported, static array generic 
Array.forEach, Array.prototype.forEach.call, or, where neither are 
available, a fallback.


A little psycho eye candy will stimulate the neuron of Google Group'ers.

forEach(document.getElemnetsByTagName("td"), function(el, i, arr) {
   el.style.background = (i % 2 === 0) ? "papayawhip" : "lawngreen";
});

// Untested:
var forEach = Array.prototype.forEach ? function(arr, callable, thisp) {
     Array.prototype.forEach.call(arr, callable, thisp);
   } : function (arr, callable, thisp) {
   // Handle callable object that is not a function.
   var call = Function.prototype.call;
   for (var i = 0, len = arr.length >>> 0; i < len; i++) {
     if (i in arr)
       call.call(callable, thisp, arr[i], i, arr);
   }
};

Keep in mind that those methods perform [[HasProperty]] checks operator 
and when the implementations uses a catchall, as some browsers do, the 
function will have inconsistent and surprising results. Example:

   var form = document.forms[0];
   "0" in form; // false in Gecko
   Array.prototype.indexOf.call(form, form[0]);

Firefox: -1
Safari: 0

And likewise,

   var form = document.forms[0];
   "0" in form; // false in Gecko
   Array.prototype.forEach.call(form, console.log, console);

No logging in Firefox, yet:

// Use elements collection.
   var elements = document.forms[0].elements;
   Array.prototype.forEach.call(elements, console.log, console);

Observe logging.

> So, coding in a page that already uses jQuery, I can either (a) dig
> through my libraries and find an existing zebra function, add that to
> my custom JS or import a new JS file, making sure that it's included
> in all pages that might want to stripe, and then call it with a one-
> liner or (b) include a jQuery one-liner.
>

Well with jQuery you don't have to write a function. However, the 
forEach approach has concise clean implementation, is very flexible, it 
requires a minimal dependency (the forEach fallback), it's a standard 
ECMAScript method and supported natively in newer browsers.

The downside to forEach is that it will be slower in older browsers that 
don't support it natively.

> Determining the exact threshhold of when to introduce a larger library
> is tricky, and crossing it often means going through existing code and
> removing parts duplicated by the library, but it will generally speed
> up further development.
>

Rather than choosing a larger library, I'd favor choosing more pieces 
that can function independently. The independent pieces can take in 
other interface objects with which to work.

> I've recently joined a new project that had already gotten underway
> and was heavily using two of the big libraries.  Just today, I helped
> remove the last vestiges of YUI from the code, but only by using the
> equivalent jQuery tools.  I wouldn't even consider trying to replace
> all the jQuery in the application with custom code right now, and even
> if I were to try, I'd never convince management of my teammates of the
> rationale for it, not unless they were to run across issues with
> jQuery that seemed substantial.  I've been in the same place with Dojo
> in the past.  It's not that I think these libraries are even remotely
> close to perfect, but they fit the need of the client.
>
What I always prefer in those cases is to find the sorest parts, go back 
to the original requirements, get refinement on those (based on feedback 
and collaboration) and then redo the feature based on those requirements.
-- 
Garrett

On 2010-08-19 11:51 PM, Garrett Smith wrote:
> On 2010-08-19 08:21 PM, Scott Sauyet wrote:
>> RobG wrote:
>>> On Jul 16, 7:21 am, ScottSauyet<scott.sau...@gmail.com> wrote:

[...]
> Keep in mind that those methods perform [[HasProperty]] checks operator

Bad edit. HasProperty is an internal method, not an operator!

Garrett Smith wrote on 20 aug 2010 in comp.lang.javascript:

> A server side function has the advantage in that it requires no JS

There is no advantage for a serverside function not to be in JS.

And, a serverside function can easily be in JS.

This has the added advantage you [often] can use the same or highly 
simmilar function both serverside and clientside.

Serverside functions in general have the advantage 
that they are by nature highly cross-browser compatibel. 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Garrett Smith wrote:
> On 2010-08-19 08:21 PM, Scott Sauyet wrote:
>> [ ... ]
>> If I needed to add zebra striping to an otherwise static page, I would
>> certainly not introduce a library as large as jQuery to do so. =A0But in
>> a page that needs some simple animation, perhaps some rounded corners,
>> a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
>> coder before me may well have introduced a library which makes this
>> new zebra call quite easy, without introducing any other old scripts
>> of mine.
>
> A server side function has the advantage in that it requires no JS -- no
> js to download and none to execute for that. Better performance and
> works in any browser.

....and only works if the DOM is static.  I usually do this on the
server when the DOM is static; then my eye-candy is visible even when
the user isn't using JS.  But if the DOM is dynamic, server-side
techniques are irrelevant.

> [ .. ]
> A function to stripe a table makes sense but it could be more
> generalized though, such forEach. Where supported, static array generic
> Array.forEach, Array.prototype.forEach.call, or, where neither are
> available, a fallback.
>
> A little psycho eye candy will stimulate the neuron of Google Group'ers.
>
> forEach(document.getElemnetsByTagName("td"), function(el, i, arr) {
> =A0 =A0el.style.background =3D (i % 2 =3D=3D=3D 0) ? "papayawhip" : "lawn=
green";
>
> });
>
> // Untested:
> var forEach =3D Array.prototype.forEach ? function(arr, callable, thisp) =
{
> =A0 =A0 =A0Array.prototype.forEach.call(arr, callable, thisp);
> =A0 =A0} : function (arr, callable, thisp) {
> =A0 =A0// Handle callable object that is not a function.
> =A0 =A0var call =3D Function.prototype.call;
> =A0 =A0for (var i =3D 0, len =3D arr.length >>> 0; i < len; i++) {
> =A0 =A0 =A0if (i in arr)
> =A0 =A0 =A0 =A0call.call(callable, thisp, arr[i], i, arr);
> =A0 =A0}
> };
> [ ... ]

Or, if you already have a library such as MooTools, Prototype, or
jQuery, you might just choose to use the one that's built into that
library, for example in jQuery:

    $.each(myArrayLikeObject, function(index, element) {
        // whatever
    });

No new custom code to test, just the same function I used in other
places in this and other recent applications.

Or of course:

    $("td:odd").css("background-color": "papayawhip");
    $("td:even").css("background-color": "lawngreen");

I can write a forEach if I need to.  But I may not need to, and that
frees me up to work on the more interesting parts of the application.

>> So, coding in a page that already uses jQuery, I can either (a) dig
>> through my libraries and find an existing zebra function, add that to
>> my custom JS or import a new JS file, making sure that it's included
>> in all pages that might want to stripe, and then call it with a one-
>> liner or (b) include a jQuery one-liner.
>
> Well with jQuery you don't have to write a function. However, the
> forEach approach has concise clean implementation, is very flexible, it
> requires a minimal dependency (the forEach fallback), it's a standard
> ECMAScript method and supported natively in newer browsers. [ ... ]

You seem to be missing the point.  A competent programmer can build
these functions.  But a competent programmer will usually also take
advantage of libraries that make the job easier.


>> Determining the exact threshold of when to introduce a larger library
>> is tricky, and crossing it often means going through existing code and
>> removing parts duplicated by the library, but it will generally speed
>> up further development.
>
> Rather than choosing a larger library, I'd favor choosing more pieces
> that can function independently. The independent pieces can take in
> other interface objects with which to work.

When I do build my own JS without using such a library, I do try to do
just that.  But I'm often working in environments in which a library
is already present, or I'm working with an application that requires
enough different features supported by a library that it makes sense
to use one.  Assembling the few dozen little scripts required to
fulfill all the requirements is often significantly more burdensome
than including a library.


>> I've recently joined a new project that had already gotten underway
>> and was heavily using two of the big libraries. =A0Just today, I helped
>> remove the last vestiges of YUI from the code, but only by using the
>> equivalent jQuery tools. =A0I wouldn't even consider trying to replace
>> all the jQuery in the application with custom code right now, and even
>> if I were to try, I'd never convince management of my teammates of the
>> rationale for it, not unless they were to run across issues with
>> jQuery that seemed substantial. =A0I've been in the same place with Dojo
>> in the past. =A0It's not that I think these libraries are even remotely
>> close to perfect, but they fit the need of the client.
>
> What I always prefer in those cases is to find the sorest parts, go back
> to the original requirements, get refinement on those (based on feedback
> and collaboration) and then redo the feature based on those requirements.

But I'm simply not seeing many pain points.

Yesterday was the first time in this project we had to work around a
limitation of jQuery on the project.  It took half an hour.  Writing
all the code that we were using jQuery for here would have taken many
hours, or even days.

I think jQuery has substantial flaws.  I'd like to find an
alternative.  But licensing issues would prohibit even trying APE in
this project, even if it were more mature.  My Library has the obvious
issue of no one who can offer support.  Nothing else has caught my eye
yes.

--
Scott

On 2010-08-20 04:52 AM, Scott Sauyet wrote:
> Garrett Smith wrote:
>> On 2010-08-19 08:21 PM, Scott Sauyet wrote:
>>> [ ... ]
>>> If I needed to add zebra striping to an otherwise static page, I would
>>> certainly not introduce a library as large as jQuery to do so.  But in
>>> a page that needs some simple animation, perhaps some rounded corners,
>>> a bit of DOM manipulation, a few AJAX calls or whatnot, I or some
>>> coder before me may well have introduced a library which makes this
>>> new zebra call quite easy, without introducing any other old scripts
>>> of mine.
>>
>> A server side function has the advantage in that it requires no JS -- no
>> js to download and none to execute for that. Better performance and
>> works in any browser.
>
> ...and only works if the DOM is static.  I usually do this on the
> server when the DOM is static; then my eye-candy is visible even when
> the user isn't using JS.  But if the DOM is dynamic, server-side
> techniques are irrelevant.
>
>> [ .. ]
>> A function to stripe a table makes sense but it could be more
>> generalized though, such forEach. Where supported, static array generic
>> Array.forEach, Array.prototype.forEach.call, or, where neither are
>> available, a fallback.
>>
>> A little psycho eye candy will stimulate the neuron of Google Group'ers.
>>
>> forEach(document.getElemnetsByTagName("td"), function(el, i, arr) {
>>     el.style.background = (i % 2 === 0) ? "papayawhip" : "lawngreen";
>>
>> });
>>
>> // Untested:
>> var forEach = Array.prototype.forEach ? function(arr, callable, thisp) {
>>       Array.prototype.forEach.call(arr, callable, thisp);
>>     } : function (arr, callable, thisp) {
>>     // Handle callable object that is not a function.
>>     var call = Function.prototype.call;
>>     for (var i = 0, len = arr.length>>>  0; i<  len; i++) {
>>       if (i in arr)
>>         call.call(callable, thisp, arr[i], i, arr);
>>     }
>> };
>> [ ... ]
>
> Or, if you already have a library such as MooTools, Prototype, or
> jQuery, you might just choose to use the one that's built into that
> library, for example in jQuery:
>
>      $.each(myArrayLikeObject, function(index, element) {
>          // whatever
>      });
>
> No new custom code to test, just the same function I used in other
> places in this and other recent applications.
>

A tested fallback would follow the standard Array.prototype[xxx], simply 
shifting the thisArg to the first parameter.

> Or of course:
>
>      $("td:odd").css("background-color": "papayawhip");
>      $("td:even").css("background-color": "lawngreen");
>

Rather than reducing dependency on a generalized object, that adds 
dependency on a generalized object. That makes the removal of said thing 
harder.

It also much less efficient (provided you fix the errors) than forEach. 
jQuery methods are long and complicated and take a long time to analyze. 
  I've gone over the complexity of these methods before.

Here's the jQuery.init method discussed:
<http://groups.google.kg/group/comp.object/msg/eed4f90405ab91b9?dmode=source>

Your approach also uses the jQuery `css` method, which has been 
discussed a number of times and also complex.

>>> So, coding in a page that already uses jQuery, I can either (a) dig
>>> through my libraries and find an existing zebra function, add that to
>>> my custom JS or import a new JS file, making sure that it's included
>>> in all pages that might want to stripe, and then call it with a one-
>>> liner or (b) include a jQuery one-liner.
>>
>> Well with jQuery you don't have to write a function. However, the
>> forEach approach has concise clean implementation, is very flexible, it
>> requires a minimal dependency (the forEach fallback), it's a standard
>> ECMAScript method and supported natively in newer browsers. [ ... ]
>
> You seem to be missing the point.  A competent programmer can build
> these functions.  But a competent programmer will usually also take
> advantage of libraries that make the job easier.
>

It seems that the competent programmer has a penchant for jQuery 
javascript library that is getting in the way of seeing pros and cons of 
other solutions.

You're criticism against forEach is that it wasn't tested and that it's 
too much trouble to test.

Did I get that right?

[...]

>
>>> I've recently joined a new project that had already gotten underway
>>> and was heavily using two of the big libraries.  Just today, I helped
>>> remove the last vestiges of YUI from the code, but only by using the
>>> equivalent jQuery tools.  I wouldn't even consider trying to replace
>>> all the jQuery in the application with custom code right now, and even
>>> if I were to try, I'd never convince management of my teammates of the
>>> rationale for it, not unless they were to run across issues with
>>> jQuery that seemed substantial.  I've been in the same place with Dojo
>>> in the past.  It's not that I think these libraries are even remotely
>>> close to perfect, but they fit the need of the client.
>>
>> What I always prefer in those cases is to find the sorest parts, go back
>> to the original requirements, get refinement on those (based on feedback
>> and collaboration) and then redo the feature based on those requirements.
>
> But I'm simply not seeing many pain points.
>

I'm not talking about problems in jQuery. I'm talking about sore parts 
of an application (that need refinement, etc, as explained).

Seems a little defensive there.

> Yesterday was the first time in this project we had to work around a
> limitation of jQuery on the project.  It took half an hour.  Writing
> all the code that we were using jQuery for here would have taken many
> hours, or even days.
>
> I think jQuery has substantial flaws.  I'd like to find an
> alternative.  But licensing issues would prohibit even trying APE in
> this project, even if it were more mature.  My Library has the obvious

APE is designed to use a custom build with ANT. That means you make a 
one or more builds of the things you need. It sounds like you want an 
all-in-one or drop-in library.

APE is licensed as FreeBSD.
-- 
Garrett

Garrett Smith wrote:
> On 2010-08-20 04:52 AM, Scott Sauyet wrote:
>> Garrett Smith wrote:
>>> On 2010-08-19 08:21 PM, Scott Sauyet wrote:

>>> [ Garrett's `forEach` deleted ]

>> Or, if you already have a library such as MooTools, Prototype, or
>> jQuery, you might just choose to use the one that's built into that
>> library, for example in jQuery:
>
>> =A0 =A0 =A0$.each(myArrayLikeObject, function(index, element) {
>> =A0 =A0 =A0 =A0 =A0// whatever
>> =A0 =A0 =A0});
>
>> No new custom code to test, just the same function I used in other
>> places in this and other recent applications.
>
> A tested fallback would follow the standard Array.prototype[xxx], simply
> shifting the thisArg to the first parameter.

Then why write your custom code?


>> Or of course:
>
>> =A0 =A0 =A0$("td:odd").css("background-color": "papayawhip");
>> =A0 =A0 =A0$("td:even").css("background-color": "lawngreen");
>
> Rather than reducing dependency on a generalized object, that adds
> dependency on a generalized object. That makes the removal of said thing
> harder.

You seem to assume that there is a goal to reduce the dependency of an
application on a library it uses.  While there are certainly times to
do that, at other times its much more efficient to use the library as
needed, keeping in mind its limitation.  If I were trying to reduce
the dependency on jQuery in my application, I would not write code
like that; I would use a custom "stripe" function or something like
your "forEach" solution; those might still depend upon jQuery, but I'd
be comfortable knowing that to remove the jQuery for this sort of
code, I could do so in one place.  But that has not been my goal.


> It also much less efficient (provided you fix the errors) than forEach.
> jQuery methods are long and complicated and take a long time to analyze.

There are times when the ability to analyze the source is very
important.  But with many tools I never bother to look into their
source.  I use a large number of open-source Java libraries whose
source I don't examine.  Joda is a great replacement for Java's flawed
date and time handling, but I haven't once dug into its source; it
just works for me.  Javascript libraries, when they simply do as I
expect them to and don't cause noticeable performance problems, are
easy for me to treat as black boxes.

Of course I have looked at the jQuery source, and I agree that it
tries to be too tricky.  Advantages in file download size don't seem
enough compensation for that sort of code.  But it hasn't yet made me
lose any sleep.


> =A0 I've gone over the complexity of these methods before.
>
> Here's the jQuery.init method discussed:
> <http://groups.google.kg/group/comp.object/msg/eed4f90405ab91b9?dmode=3D.=
...>

I saw it the first time around.  That complexity has more to do with
the overloaded API for the jQuery function than with poor
implementation.  I really don't like that complexity myself, but some
people seem to love how much can be done with `$`.


> Your approach also uses the jQuery `css` method, which has been
> discussed a number of times and also complex.


>> You seem to be missing the point. =A0A competent programmer can build
>> these functions. =A0But a competent programmer will usually also take
>> advantage of libraries that make the job easier.
>
> It seems that the competent programmer has a penchant for jQuery
> javascript library that is getting in the way of seeing pros and cons of
> other solutions.

I don't think so.  As I said, I wouldn't introduce jQuery just for one
or two otherwise simple-to-duplicate features.  I certainly wouldn't
do it just for table-striping.  But I also would not avoid using a
jQuery-based one-liner to stripe my tables if I was already using it
in the project.


> You're criticism against forEach is that it wasn't tested and that it's
> too much trouble to test.
>
> Did I get that right?

Not really.  To me the main issue is that it's unnecessary.  I already
have a library in this application that does forEach, and it also has
tools that make the striping a one-liner.  Why write another?


> [...]
>
>>>> I've recently joined a new project that had already gotten underway
>>>> and was heavily using two of the big libraries. =A0Just today, I helpe=
d
>>>> remove the last vestiges of YUI from the code, but only by using the
>>>> equivalent jQuery tools. =A0I wouldn't even consider trying to replace
>>>> all the jQuery in the application with custom code right now, and even
>>>> if I were to try, I'd never convince management of my teammates of the
>>>> rationale for it, not unless they were to run across issues with
>>>> jQuery that seemed substantial. =A0I've been in the same place with Do=
jo
>>>> in the past. =A0It's not that I think these libraries are even remotel=
y
>>>> close to perfect, but they fit the need of the client.
>
>>> What I always prefer in those cases is to find the sorest parts, go bac=
k
>>> to the original requirements, get refinement on those (based on feedbac=
k
>>> and collaboration) and then redo the feature based on those requirement=
s.
>
>> But I'm simply not seeing many pain points.
>
> I'm not talking about problems in jQuery. I'm talking about sore parts
> of an application (that need refinement, etc, as explained).

I'm not sure what "these cases" means to you, then.

As we extend the application, there will surely be issues that need to
be addressed.  Of course we'll address them and rethink approaches
based upon a reexamination of the requirements.  But it is not a goal
of the team, or even a goal of my own, to remove jQuery or reduce
dependence upon it.

> Seems a little defensive there.

I didn't feel that way at all.


>> [ ... ] I think jQuery has substantial flaws. =A0I'd like to find an
>> alternative. =A0But licensing issues would prohibit even trying APE in
>> this project, even if it were more mature. =A0My Library has the obvious
>
> APE is designed to use a custom build with ANT. That means you make a
> one or more builds of the things you need. It sounds like you want an
> all-in-one or drop-in library.

We won't use Ant on my current project (my first time in the .NET
world) but I'm sure I could port the build over to the .NET port of
Ant.  I don't mind making building our script from parts a task in the
build process, so I don't need a library that is all-in-one.  But I do
prefer a library whose parts are not too granular, generally.  I'd
rather know that, e.g., I have all the AJAX tools when I import the
AJAX module rather than having to grab a number of related AJAX
pieces.  But that preference would never be a show-stopper in choosing
a library.

> APE is licensed as FreeBSD.

Oh, that's a nice change.  Last I knew (February?) it was AFL.

--
Scott