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. :)
From: RobG on
On Jul 21, 11:14 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:
> RobG wrote:
> > On Jul 21, 12:01 pm, Kenneth Tilton <kentil...(a)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
From: David Mark on
On Jul 22, 2:18 am, RobG <rg...(a)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. :)