Prev: Simple question
Next: Scoping Issue
From: David Mark on 6 Jun 2010 21:10
On Jun 6, 7:45 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:
> David Mark wrote:
> > On Jun 6, 1:43 am, Kenneth Tilton <kentil...(a)gmail.com> wrote:
> >> Frobernik wrote:
> >>> David Mark wrote:
> >>>> "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
> >> 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[i]) == 'number') {d[i] =
> > d[d[i]]}}
> >     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?

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

If that is your strategy, you aren't helping yourself. ;)
From: Richard Cornford on 8 Jun 2010 08:41
On Jun 4, 9:06 am, toby.oconn...(a)gmail.com wrote:
> On Jun 3, 8:24 pm, Andrew Poulos wrote:
>> 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.

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.
From: Gregor Kofler on 8 Jun 2010 09:59
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
From: Richard Cornford on 9 Jun 2010 06:47
On Jun 8, 2:59 pm, Gregor Kofler wrote:
> Am 2010-06-08 14:41, schrieb Richard Cornford:
<snip>
>> 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.

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.
From: David Mark on 9 Jun 2010 07:40
On Jun 9, 6:47 am, Richard Cornford <Rich...(a)litotes.demon.co.uk>
wrote:
> On Jun 8, 2:59 pm, Gregor Kofler wrote:
>
> > Am 2010-06-08 14:41, schrieb Richard Cornford:
> <snip>
> >> 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.
>
> 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).
>

Aw, "raw" html is so old-fashioned. Why don't we all program assembly
language too? :)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Simple question
Next: Scoping Issue