Qooxdoo strikes back

[David Mark]

http://qooxdoo.678.n2.nabble.com/Fw...oxdoo-from-Common-Lisp-tp5123235p5123647.html

"Don't worry, Kenny."

Promise of reassurance.

"He hates us."

Who are they anyway? This single response was from the usual poster
with no (real) name. I really believe it is always the same clod each
time.

"We do "browser sniffing" (must be the worst crime in the
universe...)!"

Bizarre hyperbole and the post he (she?) responded to made no mention
of browser sniffing.

"And since we're all deluding ourselves, I
mean, you, us, and all the other people out there using or producing
libraries and frameworks,"

I don't think Kenny has produced any JS libraries or frameworks. I
can't speak for "all the other people", but I certainly have produced
such (and without resorting to browser sniffing).

"doing thousands of successful projects,"

Name one (and no, qooxdoo doesn't count as a success).

"he seems like the only sane person in this crazy world..."

Any novice could see that qooxdoo is junk (well, except Kenny). Same
for jQuery, Dojo, etc. Trouble is many don't bother to look. And
anyone with any real experience shouldn't have to look far (first line
of this one would suffice).

Crazy world, indeed (certainly as far as JS is concerned). Just full
of kooks spouting non-arguments; screaming until they are red-faced
that it is their God-given right to be incompetent. Couldn't care
less about them, but you've got to feel for their clients.

"Must be really hard. "

Actually it's quite easy. Like shooting fish in a barrel really.

And, as usual, not a single technical point was addressed. That's
hardly reassuring.

 

[toby.oconnell]

I don't really care about anyone's emotional state on a NG when
discussing javascript. If A says script B is of low quality because of
C, D, and E and the main response is "A is a not a nice person" then I
*know* which argument is more likely valid.

Yes, I don't think it's David's demeanor that causes several pages,
linked to from http://demo.qooxdoo.org, to display a white screen of
death in three of the five browsers I have handy.

 

[David Mark]

Yes, I don't think it's David's demeanor that causes several pages,
linked to fromhttp://demo.qooxdoo.org, to display a white screen of
death in three of the five browsers I have handy.

LOL. Can't pin that one on me.

 

[Frobernik]

"Don't worry, Kenny."

Someone needs to kill Kenny (OMG) and get rid of his audience

"he seems like the only sane person in this crazy world..."

Sanity is inversely proportional to the amount of badly written code

Fro

 

[David Mark]

Someone needs to kill Kenny (OMG) and get rid of his audience

No worries. AFAIK, he has no audience.

Sanity is inversely proportional to the amount of badly written code

Yes. Once informed, using something as appalling as qooxdoo is
clearly an insane thing to do. I read recently that the odd name is
supposed to be prounounced "cooks do". That's not far from "kooks
do".

 

[Kenneth Tilton]

Someone needs to kill Kenny (OMG) and get rid of his audience


Sanity is inversely proportional to the amount of badly written code

What do you think of jsMath?

Wait till you see my next screen shot. Uses jsMath. You will all come
crawling to me begging forgiveness and asking to worship at my alter.

I will be gracious.

kenny

 

[David Mark]

What do you think of jsMath?

Haven't looked at it. Does it have qooxdoo as a dependency? If so,
it can be dismissed out of hand.

Wait till you see my next screen shot.

Screen shot?! I'll look at the code (if anything).

Uses jsMath. You will all come
crawling to me begging forgiveness and asking to worship at my alter.

Oh brother. Where did this imperious alter ego come from? It doesn't
suit you at all.

I will be gracious.

Doesn't sound like it.

 

[VK]

to David Mark:

Your position is well-known in this newsgroup. jQuery is unfit to eat
crap using technique and approaches that David Mark would never do,
because David Marks makes only really perfect and really reliable
code. The only more-or-less sane conclusion would be to get John Resig
out of the project and let David Mark to re-write jQuery in "My
Library" library style. The really sane conclusion would be the
immediate migration of all jQuery users to "My Library" library. Once
David Mark was QA tester of jQuery and used this chance to deliver
these obvious things to jQuery team. To his huge surprise and
disappointment jQuery idiots ignored the obvious and dared to send
David Mark to hell. They *send* *to hell* *David* **Mark** !!?

Any way, it's getting really boring to read how bad jQuery is. Tell us
how good My Library is in comparison with jQuery. "ML can do this, and
jQuery cannot." "Here ML acts properly and jQuery fails". And stuff.
So instead of blindly dispropagating one brand, advertise a better
alternative using implicit dispropagation in comparisons.

 

[David Mark]

to David Mark:

Your position is well-known in this newsgroup.

As is yours. In a word, untenable.

jQuery is unfit to eat
crap using technique and approaches that David Mark would never do,

This is hardly news.

because David Marks makes only really perfect and really reliable
code.

There it is. The same old non-argument. jQuery would be an
incompetently designed and implemented script whether I existed or
not.

The only more-or-less sane conclusion would be to get John Resig
out of the project and let David Mark to re-write jQuery in "My
Library" library style.

You don't get it at all. The design of jQuery is not salvageable.
They need to scrap and start over (as Dojo and Prototype are doing).
But then you have to think, if new ground is broken by the same old
suspects, then these scripts will be jQuery, Dojo and Prototype in
name only. I don't know about you, but I can't see clinging to
brands, even if they weren't tarnished to hell.

The really sane conclusion would be the
immediate migration of all jQuery users to "My Library" library.

I never said anything like that. My position has always been that GP
libraries are contrary to good practice. You don't need them at all
for the majority of projects.

Once
David Mark was QA tester of jQuery and used this chance to deliver
these obvious things to jQuery team.

I was never a QA tester for jQuery (and I don't think they have any
concept of QA testing anyway).

I don't follow the rest of the sentence.

To his huge surprise and
disappointment jQuery idiots ignored the obvious and dared to send
David Mark to hell. They *send* *to hell* *David* **Mark** !!?

Mad as a mongoose.

Any way, it's getting really boring to read how bad jQuery is.

You know, it's odd. The only one screaming about jQuery in this
thread is you.

Tell us
how good My Library is in comparison with jQuery.

It's been done to death.

"ML can do this, and
jQuery cannot."

That too. Where have you been?

"Here ML acts properly and jQuery fails".

It's not really a contest, is it? jQuery is so completely lacking
that virtually anything would look good in comparison (including, and
especially, the lack of a GP library).

And stuff.
So instead of blindly dispropagating one brand, advertise a better
alternative using implicit dispropagation in comparisons.

Now I'm confused. The previous were sincere requests? I thought you
were bemoaning the repetition as all of that territory has been
explored here ad nauseam. In any event, I don't take requests.

 

[David Mark]

As is yours.    In a word, untenable.


This is hardly news.


There it is.  The same old non-argument.  jQuery would be an
incompetently designed and implemented script whether I existed or
not.


You don't get it at all.  The design of jQuery is not salvageable.
They need to scrap and start over (as Dojo and Prototype are doing).
But then you have to think, if new ground is broken by the same old
suspects, then these scripts will be jQuery, Dojo and Prototype in
name only.  I don't know about you, but I can't see clinging to
brands, even if they weren't tarnished to hell.


I never said anything like that.  My position has always been that GP
libraries are contrary to good practice.  You don't need them at all
for the majority of projects.

For example, this mockup:-

http://www.hartkelaw.net/

....which is still waiting for some proper graphics, BTW; so don't
start with the usual "aw, that looks ugly" BS. I was only charged
with created a wireframe; the rest is out of my hamds.

The minified (not GZipped) script is about 15K. It features a simple
widget, themes (which can be changed on the fly), a dynamic layout,
loads of animation, a zoomable thumbnail and a few other tricks
typically desired by the average library afficianado.

Furthermore, it's a clinic on progressive enhancement, working
properly or degrading gracefully in virtually every browser I've tried
(many long after the fact). And no, there's not a single browser
sniff to be found.

Though it was written long before IE8 came out, I was not at all
surprised that it worked flawlessly in that browser (in all modes). I
was pleasantly surprised that it continues to work as well in the IE9
Beta (only because it is a Beta). Same goes for the other browsers
that have come out since. Many browser scripting projects pride
themselves on the number of updates they make to "keep up" with the
latest browsers (and dismiss scripts that remain unchanged as
necessarily outdated), but that is backwards thinking. The goal is
"write once, do nothing", not write, rewrite, re-test, ad infinitum.

It wasn't written from scratch (or in assembly language). I simply
used the tools I had at hand. I have such tools as I haven't spent my
career swapping out third-party scripts. As a result, my tools (and
skills) are honed to the point where I rarely have to swap out
anything. This saves a lot of money as re-testing from ground zero is
expensive, even for a simple Website.

So, what would be the excuse for relying on browser sniffing scripts,
burning bridges to old browsers, breaking down in new (or unknown)
agents, etc.? Does the typical "Ajax site" demonstrate much more than
can be found in that mockup? From what I've seen, they demonstrate
much less with far more effort.

Try this one out for size (no puns intended):-

http://www.dojofoundation.org/

This is what I'm talking about. Ten tons of browser sniffing scripts,
everything sized in pixels to make it easy (on the authors, not the
users) and it is still a complete catastrophe, even in contemporary
desktop browsers. Try sizing the browser window and see if you can
guess what resolution the author(s) tested in. Forget future-proof,
the thing is not even close to present-proof. And certainly it will
fall apart in anything older or unknown to the authors. I know for
certain that the authors are aware of how badly botched this site is,
but I don't have to wonder why they haven't addressed it. It's a
complicated, convoluted mess that is pegged to an older Dojo version.
A rewrite and accompanying "upgrade" would certainly cost a small
fortune.

There are tens of thousands of sites out there just like it. Most
were written with jQuery, Prototype, etc. and many of them will dry up
and blow away as there aren't enough developers available to
constantly fiddle with these things. Eventually they will have to
start over, which benefits only the incompetent authors who are
selling both a problem and a solution.

That's what happens when you rely on blind faith and bad scripts.
Most developers seem to be so numb to their failings at this point
that they resent being told there are better ways. On the contrary, I
have found that site owners are tiring of the merry-go-round of late.
That's got to be a nightmare for the VK's of the world.

 

[David Mark]

What do you think of jsMath?

Oh, jsMath. Silly me, I looked at mathjs. Still, you can't swing a
dead cat around Google Code without hitting some laughably
preposterous JS. To wit:-

"use strict";


Cargo cult copy and paste. Not a promising start.


/**
* An extension to the Array object that filters out repeated values.
* @return(Array) Returns the filtered array.
*/
if (Array.unique === undefined) {
Array.prototype.unique = function Array_unique() {


Fail (miserably). Array is a function, so the first test is nonsense
(and is followed by at least a dozen identical blunders). NFE too.
Strike three.

And up comes jsMath:-

if (!window.jsMath) {jsMath = {}}


Strikes one and two. We've already covered the first. The second is
an undeclared variable (a la Dojo). Maybe he heard they were
faster.


if (!jsMath.Script) {jsMath.Script = {}}

jsMath.Script.Uncompress = function (data) {
for (var k = 0; k < data.length; k++) {
var d = data[k]; var n = d.length;
for (var i = 0; i < n; i++) {if (typeof(d) == 'number') {d =
d[d]}}
data[k] = d.join('');
}
eval(data.join(''));


He's out of there.

Was there a point to this Kenny? The only pattern I see is that
authors of free scripts try their damnedest to foul up everything. A
roster stocked with these things will lose 100+ games every season.
But if you refuse to learn for yourself, I guess you have no choice
but to suffer perpetual futility.

 

[Kenneth Tilton]

What do you think of jsMath?

Oh, jsMath. Silly me, I looked at mathjs. Still, you can't swing a
dead cat around Google Code without hitting some laughably
preposterous JS. To wit:-

"use strict";


Cargo cult copy and paste. Not a promising start.


/**
* An extension to the Array object that filters out repeated values.
* @return(Array) Returns the filtered array.
*/
if (Array.unique === undefined) {
Array.prototype.unique = function Array_unique() {


Fail (miserably). Array is a function, so the first test is nonsense
(and is followed by at least a dozen identical blunders). NFE too.
Strike three.

And up comes jsMath:-

if (!window.jsMath) {jsMath = {}}


Strikes one and two. We've already covered the first. The second is
an undeclared variable (a la Dojo). Maybe he heard they were
faster.


if (!jsMath.Script) {jsMath.Script = {}}

jsMath.Script.Uncompress = function (data) {
for (var k = 0; k < data.length; k++) {
var d = data[k]; var n = d.length;
for (var i = 0; i < n; i++) {if (typeof(d) == 'number') {d =
d[d]}}
data[k] = d.join('');
}
eval(data.join(''));


He's out of there.

Was there a point to this Kenny?

Yeah, I have now created a wysiwyg maths editor for web applications,
with TeX-quality typesetting. Using jsMath.

Oh, and the author of jsMath (now being succeeded by MathJax, to support
MathML) is pretty cool, does very good work, and does so without being a
jerk about it.

The only pattern I see is that
authors of free scripts try their damnedest to foul up everything. A
roster stocked with these things will lose 100+ games every season.
But if you refuse to learn for yourself, I guess you have no choice
but to suffer perpetual futility.

I'll come crawling back here when I need your help.

kt

 

[David Mark]

Oh, jsMath.  Silly me, I looked at mathjs.  Still, you can't swing a
dead cat around Google Code without hitting some laughably
preposterous JS.  To wit:-

"use strict";

Cargo cult copy and paste.  Not a promising start.

/**
 * An extension to the Array object that filters out repeated values.
 * @return(Array) Returns the filtered array.
 */
if (Array.unique === undefined) {
    Array.prototype.unique = function Array_unique() {

Fail (miserably).  Array is a function, so the first test is nonsense
(and is followed by at least a dozen identical blunders).  NFE too.
Strike three.

And up comes jsMath:-

if (!window.jsMath) {jsMath = {}}

Strikes one and two.  We've already covered the first.  The second is
an undeclared variable (a la Dojo).  Maybe he heard they were
faster.  

if (!jsMath.Script) {jsMath.Script = {}}

jsMath.Script.Uncompress = function (data) {
  for (var k = 0; k <  data.length; k++) {
    var d = data[k]; var n = d.length;
    for (var i = 0; i < n; i++) {if (typeof(d) == 'number') {d =
d[d]}}
    data[k] = d.join('');
  }
  eval(data.join(''));

He's out of there.  

Was there a point to this Kenny?

Yeah, I have now created a wysiwyg maths editor for web applications,
with TeX-quality typesetting. Using jsMath.

Good night.

Oh, and the author of jsMath (now being succeeded by MathJax, to support
MathML) is pretty cool, does very good work, and does so without being a
jerk about it.

You are bizarre. People write bad code and you say they do "great
work". I point out bad code and you intimate that I am a "jerk".
Doesn't add up.

I mean, didn't you ask what I thought of that math library? And
aren't you the one who will be harmed by using such code? If you've
already painted yourself into a corner, that's hardly my fault. Not
to mention that your well-documented petulance hardly encourages a
compassionate reply. You are lucky I respond at all at this point.

In other words, your appeals to pathos will buy sympathy only from
fellow kooks (who can offer little more than commiseration in
exchange). So what's the point?

I'll come crawling back here when I need your help.

If that is your strategy, you aren't helping yourself.

 

[Richard Cornford]

Yes, I don't think it's David's demeanor that causes several
pages, linked to from http://demo.qooxdoo.org, to display a
white screen of death in three of the five browsers I have handy.

I don't think so either. A couple of years ago I looked at the qooxdoo
code and its 'demos' (which mostly produced white screens back then as
well, even in the latest Firefox browser). Two things struck me about
the code (disregarding the UA sniffing, which retains its status as a
sure indicator of bad code); 1. there was an attempt to provide a very
detailed 'classical OO' implementation (inheritance, setters/getters
for all properties, etc.), and 2, there was an attempt to replace
virtually all of the browser's (or HTML's) 'presentation' with
scripted alternatives.

I have never really liked attempts to impose 'classical OO' systems on
javascript, particularly in a way that suggests it should be the norm.
Javascript's object handling already provides most of the facilities
that you need to emulate concepts from OO programming, but it also
does not need them much of the time. Basically, in real situations
there are a range of needs and most of them can be fully satisfied by
native javascript facilities. There may be some very rare occasions
where some 'classical OO' system could be of use, but they are
designed for occasional use, instead their existence in a framework is
used to encourage their use for all object/type creation tasks.
Qooxdoo's system looked so elaborate that if it were widely adopted
the resulting code, if it achieved any real size, would run like
treacle. Still, improved hardware performance has prevented many
poorly performing frameworks from fully suffering for their faults.

Replacing the browser's (or HTML's) 'presentational' facilities with
scripted alternatives is an old idea. People find that what the
browser provides can (at least initially) be too complex for them to
cope with. The flexibility, the way things 'flow', etc., becomes
difficult to 'control'. So they start to see advantages in using
things like absolutely positioned, and sized DIV elements and
scripting them to control their behaviour, layout, appearance, etc.

All this allows for total control. However, there is a price, and that
price is what you lose when stop using the browser's (or HTML's) built-
in controls, etc. Over the years the pursuit of layout 'control' has
thrown up thousands of examples that sacrifice features that the
browser would have been providing otherwise, and an ongoing struggle
to script them back in again. A really obvious example being keyboard
accessibility; often the initial attempts to replace what the browser
would have done with scripted alternatives are very mouse-orientated.
It is quite difficult for people to think beyond themselves and
consider how others may interact with computers, and that can also
prevent them from seeing some of the available facilities in web
browsers, and so not even knowing that they should be addressing those
facilities in their scripted alternatives.

Given the history of these things, when presented with a new attempt,
there are series of test that can be performed to see how closely the
example manages to re-achieve the facilities that the browser would
have provided otherwise (or, more likely, exactly how much has been
scarified in the attempt). So, two years ago, when looking that (those
that 'worked' of) the qooxdoo demo pages, I tried some of those tests,
starting with their imitation of the SELECT element. A browser's
(HTML's) SELECT element presents (at least part of) a list of options
from which a user is expected to chose one (in the case of the SELECT
I was looking at). To that end it has to present the list to the user
in a way that is accessible/viable. If a browser cannot drop the list
from the box in the available space it may display the list above the
SELECT element, or extend the list beyond the browser's window, and if
there is still insufficient room it will provide scrollbars for the
list, all handled automatically in internally. This is really a very
minimal requirement for a SELECT element, but reducing the size of the
browser window on the demo page to the point where the SELECT was at
the bottom of the viewport and activating the SELECT element, qooxdoo
dropped the box down from the SELECT so that it was out of sight, and
so inaccessible. That is a total fail on a fairly fundamental feature,
so there was little point in carrying on.

Well, that was an early version and I was expecting it authors to have
failed to take much into account in their initial efforts. On the
other hand, I did think that once all the extra layout code was in
place to handle these things a framework that already looked slow and
clucky was likely to be starting to look non-viable.

Yesterday I looked at (those that were 'working' of) the demos again,
and applied the same test to the same scripted imitation of a SELECT
element, and its behaviour was unchanged; failing at even attempting
to present the list of options where they could be seen. Two years of
work and it looks like its authors are not even aware of the basics of
the task they are attempting to achieve.

For a commercial web application these things actually do matter, so
while it may be asserted that qooxdoo may allow someone to rapidly
achieve a 'working' prototype, that prototype will fall short of the
necessary standard because it will be built from components that are
not yet anywhere near finished, and (if they remain unchanged for two
years) may never be finished. Any 'rapid' progress is meaningless if
at the end of it you have to go right back to the beginning and start
again in order to actually get to the required end point (in terms of
quality and usability).

Richard.

 

[Gregor Kofler]

Am 2010-06-08 14:41, schrieb Richard Cornford:

I have never really liked attempts to impose 'classical OO' systems on
javascript, particularly in a way that suggests it should be the norm.
Javascript's object handling already provides most of the facilities
that you need to emulate concepts from OO programming, but it also
does not need them much of the time. Basically, in real situations
there are a range of needs and most of them can be fully satisfied by
native javascript facilities. There may be some very rare occasions
where some 'classical OO' system could be of use, but they are
designed for occasional use, instead their existence in a framework is
used to encourage their use for all object/type creation tasks.
Qooxdoo's system looked so elaborate that if it were widely adopted
the resulting code, if it achieved any real size, would run like
treacle. Still, improved hardware performance has prevented many
poorly performing frameworks from fully suffering for their faults.

Opening and closing (no "option" selected) "SelectBox" yields 30,000+
function calls according to Firebug's profiling (even an idling qooxdoo
results in a few hundred calls per second - it constantly seems to
create and dispatch events).
Picking up 3 items in their drag-and-drop example and dropping them in
the second container sums up to 100,000+ calls and requires 1,800ms...

All this allows for total control. However, there is a price, and that
price is what you lose when stop using the browser's (or HTML's) built-
in controls, etc. Over the years the pursuit of layout 'control' has
thrown up thousands of examples that sacrifice features that the
browser would have been providing otherwise, and an ongoing struggle
to script them back in again. A really obvious example being keyboard
accessibility; often the initial attempts to replace what the browser
would have done with scripted alternatives are very mouse-orientated.
It is quite difficult for people to think beyond themselves and
consider how others may interact with computers, and that can also
prevent them from seeing some of the available facilities in web
browsers, and so not even knowing that they should be addressing those
facilities in their scripted alternatives.

In addition, the custom layout breaks entirely when the page is zoomed.
(Perhaps some "skins" for various zoom factors would be the proper
qooxdoo answer to that.)

Gregor

 

[Richard Cornford]

Am 2010-06-08 14:41, schrieb Richard Cornford:

In addition, the custom layout breaks entirely when the page
is zoomed.

Yes, when the first object tried totally fails the first (and
simplest) test applied to it then the total list of possibilities not
taken into account is going to be very long.

(Perhaps some "skins" for various zoom factors
would be the proper qooxdoo answer to that.)

If it were actually possible to fully sort out the issues that arise
from the qooxdoo approach to UI components then a similar system would
already exist and be in common use. Instead the people who tried this
in the past, as soon as they delved below the surface and spotted the
range of issues hiding there, decided it was ultimately more realistic
to let the browser do the work and go with the HTML flow (in more than
one sense of the word).

Richard.

 

[David Mark]

Yes, when the first object tried totally fails the first (and
simplest) test applied to it then the total list of possibilities not
taken into account is going to be very long.


If it were actually possible to fully sort out the issues that arise
from the qooxdoo approach to UI components then a similar system would
already exist and be in common use. Instead the people who tried this
in the past, as soon as they delved below the surface and spotted the
range of issues hiding there, decided it was ultimately more realistic
to let the browser do the work and go with the HTML flow (in more than
one sense of the word).

Aw, "raw" html is so old-fashioned. Why don't we all program assembly
language too?

 

[John G Harris]

Aw, "raw" html is so old-fashioned. Why don't we all program assembly
language too?

Nah. When I started *real* programmers wrote in binary. It was only
noddy engineers and scientists who wrote in anything resembling text.

John