From: David Mark on
On Jul 21, 4:31 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Jul 21, 12:55 pm, David Mark <dmark.cins...(a)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.
From: Matt Kruse on
On Jul 21, 3:48 pm, David Mark <dmark.cins...(a)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.  

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.

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

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

> > Any reasonable person would understand that strategy, IMO.
> 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".

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

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

> > Almost no tool gets everything
> > right.
> For God's sake.  That'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.  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
From: David Mark on
On Jul 21, 5:25 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Jul 21, 3:48 pm, David Mark <dmark.cins...(a)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.  
>
> 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?  Use "the library"?  What
> > library?
>
> Whichever one you identify as being good enough to use, obviously.

But you are clearly incapable of making such an identification.

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

Yet, you talk in black and white terms of "the libraries" and "anti-
library zealots".

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

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

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

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.

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

Appeal to loonies.

>
> > > Almost no tool gets everything
> > > right.
> > For God's sake.  That'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.  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.

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

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

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

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

Not really. You are simply deluded.

>
> Same old broken record with you, David.

Again, my line.
From: Frank Buss on
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(a)frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: David Mark on
On Jul 22, 12:25 am, Frank Buss <f...(a)frank-buss.de> 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 :-)
>
> 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. :)