jquery vs dojo vs yui etc

[Tim Streater]

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.

 

[Alessio Stalla]

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









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

 

[Tim Streater]

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.

 

[Alessio Stalla]

I'm really not sure I want to do that.

As Kenny said, Lispers sometimes want *too much* to do that

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.

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

 

[Matt Kruse]

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

 

[David Mark]

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.

 

[Matt Kruse]

Which means it is far more trouble than it's worth.  

Non sequitur. Your leap to such a conclusion is unwarranted.

Do you realize how silly you sound?  Use "the library"?  What
library?

Whichever one you identify as being good enough to use, obviously.

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

 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.

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.

Do you see the gaping hole in your logic?  You don't know what the
80/20 split will be, do you?

Not until you do some analysis on your library of choice, no.

Nope.  Any 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".

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)

 And what makes you think
that everything you do outside of browser scripting applies to browser
scripting?  The 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.

For God's sake.  That's why you don't use tools that try to do
*everything*.

Like "My Library"?

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.

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.

 You are
simply clinging to the notion that you can use CSS selector queries
for everything and end up with production quality code.

Am I?

 And 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

 

[David Mark]

Non sequitur. Your leap to such a conclusion is unwarranted.

Oh shut up. How's that for warranted?

Whichever one you identify as being good enough to use, obviously.

But you are clearly incapable of making such an identification.

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

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.

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?

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.

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.

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.

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

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

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?

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.

 

[Frank Buss]

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.

 

[David Mark]

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

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

 

[RobG]

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.

[...]

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.


[...]

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.


[...]

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

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.

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.

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.

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.

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.

 

[David Mark]

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.

 

[David Mark]

[...]

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.

 

[Laurent vilday]

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.

 

[Kenneth Tilton]

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

 

[Kenneth Tilton]

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

 

[David Mark]

Kenneth Tilton :


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.

 

[Kenneth Tilton]

Kenneth Tilton :


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

 

[David Mark]

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

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

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

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.

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

  


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.

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.

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.

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.

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:

    $("#myTable tbody trdd").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.  I can do this instead:

    $("table.zebra tbody trdd").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.

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.

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?

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.

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?

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

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

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.

 

[Captain Paralytic]

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)