Prev: net.html.generator indented code
Next: Hey RACIST and INcompetent FBI/CIA Bustards where is the ANTHRAX MAILER ??? Where are the 4 blackboxes, where are the 5 dancing israelis and what is the status of FORENSIC evidence and trace of NANO THERMITE in WTC dust ?
From: RobG on 22 Jul 2010 02:18
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 22 Jul 2010 02:33
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. :)
From: David Mark on 22 Jul 2010 04:10
On Jul 22, 2:18 am, RobG <rg...(a)iinet.net.au> wrote:

[...]

>
> 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.
From: Kenneth Tilton on 22 Jul 2010 12:46
Matt Kruse 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...
>
> 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



--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
From: Kenneth Tilton on 22 Jul 2010 13:21
Frank Buss 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 :-)

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


--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: net.html.generator indented code
Next: Hey RACIST and INcompetent FBI/CIA Bustards where is the ANTHRAX MAILER ??? Where are the 4 blackboxes, where are the 5 dancing israelis and what is the status of FORENSIC evidence and trace of NANO THERMITE in WTC dust ?