jquery vs dojo vs yui etc

[David Mark]

Bad news: Qooxdoo/Lisp looking better/faster all the time:

Bad news for whom?

   http://teamalgebra.com/

The initial script it downloads is still over one *million* bytes.
Oddly enough, it seems to go back to the server constantly during user
interaction.

1. Registering can be ignored for now.

No worries there.

It will be needed to do Missions,
but that's not ready yet. Recovering login does not work yet (forgot to
remove that option).

2. Should load faster. Curious how folks far from US east coast do.

I'm near there and have a fairly speedy broadband connection, yet it
took several seconds to progress past the white screen stage.

3. If you do register, your info will be stored using AllegroGraph!

Great. What the hell is that?

4. qooxdoo continues to rock, as does qooxlisp.

Groan. You misspelled suck.

I could file a bug or
rfe against qooxdoo every four hours, but so far it's superficial stuff
easily worked around at the cost of some UI elegance. (You'll laugh if
you try tabbing through the fields of the registration form.

Or cry perhaps.

5. Enjoy. And tell your Algebra teacher friends I am looking for local
schools interested in being guinea pigs.

If you do, they likely won't remain friends.

It's interesting that qooxdoo eschewed the browsers' built-in
scrolling mechanisms and tried to build the same functionality with
script. They failed miserably as I can't scroll by clicking the
mousewheel and then moving the mouse. Furthermore, resizing the
window to the point where the tabs' content overflows does not produce
any scroll bars, so basic usability is ruined. And why? Do you think
those gray-ish scroll bars are more aesthetically pleasing than those
provided by the browsers? I don't. Were you concerned they would
clash with your all-gray color scheme?

And do you really think that any of this mess will be accessible to
handicapped students? It's ironic that your overweight application is
all tabs and (fake) form controls. FYI there is nothing to creating a
"tabstrip" widget and real form controls are infinitely preferable to
your washed out looking phonies. Why do you think your keyboard
navigation is such a mess? Zooming in eventually displays some sort
of scrolling interface for the tabs, but not the content. This is
backwards. Widgets should not have any need to respond to changes in
the zoom factor, but the page content should certainly be able to be
scrolled (which it would automatically if you hadn't used an ill-
advised "layout" script instead of HTML).

Also that picture on the "Community" tab (which does nothing) looks
like Big Boy after a crash diet and a week-long bender. He appears to
be pan-handling too. On the "Notebook" tab (also bereft of meaningful
content), he appears to have sobered up and snapped back into his
normal pose, but it seems he lost his giant hamburger.

http://melindaschwakhofer.files.wordpress.com/2008/02/bigboy.jpg

I suppose you are trolling for feedback. My message, which you should
pass along to the qooxdoo people is: what's wrong with you?

 

[Kenneth Tilton]

Bad news for whom?

Your skill set sleeps with the fishes. I recommend bartending school.
Proof: I know next to nothing about html/css and am no qooxdoo guru and
look at this:

http://teamalgebra.com/

Done in ten weeks, most of those part-time/weekends-only. Now look at this:

http://www.cinsoft.net/mylib-builder.asp

Checkboxes, the universal widget?

QED.

The initial script it downloads is still over one *million* bytes.

That's *eight million* bits!! Loads in less than three seconds on the
east coast. Now open gimp or open office /on your frickin desktop/ and
you'll have time for a run to Starbuck's.

Google needs to open fast, not an Algebra study site.

Oddly enough, it seems to go back to the server constantly during user
interaction.

Oddly enough, that's the frickin idea if you noticed a word I have
written. Check out the qooxlisp wiki pages:

http://wiki.github.com/kennytilton/qooxlisp/

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 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 understand you have no idea what I am talking about because you do not
know qooxdoo has some nice syntax for creating a higher-level way of
authoring JS classes:

http://qooxdoo.org/documentation/1.1/oo_introduction

When you need a break from coding assembly language all day, you should
check it out.

No worries there.

Careful, it won't be free forever and early registrants will be
grandfathered in.

I'm near there and have a fairly speedy broadband connection, yet it
took several seconds to progress past the white screen stage.

Gasp! Now start up gimp or open office or any number of desktop apps.
(sigh). 8 billion bits over the web is many times faster.

Great. What the hell is that?

http://en.wikipedia.org/wiki/Graph_database

Built into the Lisp environment I use. I was using S3 but that is too
slow/expensive for small amounts of data my app stores.

The graph db is a seriously better model for storing data.

Groan. You misspelled suck.


Or cry perhaps.


If you do, they likely won't remain friends.

It's interesting that qooxdoo eschewed the browsers' built-in
scrolling mechanisms and tried to build the same functionality with
script. They failed miserably as I can't scroll by clicking the
mousewheel and then moving the mouse.

Oh grow up and file an RFE (or contrib it).

Furthermore, resizing the
window to the point where the tabs' content overflows does not produce
any scroll bars, so basic usability is ruined. And why?

Because I did not wrap everything in scrollers. Sue me.

Do you think
those gray-ish scroll bars are more aesthetically pleasing than those
provided by the browsers? I don't.

Yes, delivering an environment where kids can positively enjoy
hand-to-hand battle with the arch nemesis Algebra relies on how the
scroll bars look. Your instinct for the relevant dazzles.

Were you concerned they would
clash with your all-gray color scheme?

Have you forgotten what I did with color? You should be thanking me.
btw, the author of this page need not rag on anyone over graphic design:

http://www.cinsoft.net/mylib.html

And do you really think that any of this mess will be accessible to
handicapped students?

See bottom of barrel. See Mark. See Mark scrape.

It's ironic that your overweight application is
all tabs and (fake) form controls. FYI there is nothing to creating a
"tabstrip" widget and real form controls are infinitely preferable to
your washed out looking phonies. Why do you think your keyboard
navigation is such a mess? Zooming in eventually displays some sort
of scrolling interface for the tabs, but not the content. This is
backwards. Widgets should not have any need to respond to changes in
the zoom factor, but the page content should certainly be able to be
scrolled (which it would automatically if you hadn't used an ill-
advised "layout" script instead of HTML).

Also that picture on the "Community" tab (which does nothing) looks
like Big Boy after a crash diet and a week-long bender. He appears to
be pan-handling too. On the "Notebook" tab (also bereft of meaningful
content), he appears to have sobered up and snapped back into his
normal pose, but it seems he lost his giant hamburger.

http://melindaschwakhofer.files.wordpress.com/2008/02/bigboy.jpg

I suppose you are trolling for feedback. My message, which you should
pass along to the qooxdoo people is: what's wrong with you?

Shouldn't you be more forthright in disclosing your massive conflict of
interest as a competitor of qooxdoo?

Meanwhile: "Starting this summer, cinsoft.net will be the home of
Cinsoft, a startup that will provide world-class browser scripting
solutions and professional support for My Library (as well as /any/
other Javascript library or framework)."

Including qooxdoo? You whore!

Best of luck with Cinsoft.

kt

 

[David Mark]

Your skill set sleeps with the fishes. I recommend bartending school.

Let me see if I get this straight. Somebody like *you* can compete
with me in the area of front-end development. Is that really what you
meant to say?

Proof: I know next to nothing about html/css and am no qooxdoo guru and
look at this:

   http://teamalgebra.com/

I saw it. Suffice to say, I'm less than impressed. Be fair, it's a
load of crap.

Done in ten weeks, most of those part-time/weekends-only.

I could write that stupid framework you are using in ten weeks.

Now look at this:

   http://www.cinsoft.net/mylib-builder.asp

Yes, that's the builder form for My Library.

Checkboxes, the universal widget?

For representing on or off? Yes. Are you proud of yourself for using
phony checkboxes in lieu of real ones?

QED.

I'm afraid I didn't follow your "logic".

That's *eight million* bits!! Loads in less than three seconds on the
east coast.

Didn't for me and I am not far from there. Maybe this stuff is a bit
more complicated than you think.

Now open gimp or open office /on your frickin desktop/ and
you'll have time for a run to Starbuck's.

Ah, I see. Now you turn your sword on desktop software? I'm sure
they are as worried as I am.

Google needs to open fast, not an Algebra study site.

All together: everything is relative!

Oddly enough, that's the frickin idea if you noticed a word I have
written.

My point is that it is odd that it takes a million byte script to load
and then still has to go back and forth to the server constantly.
Seems like the worst of both worlds.

Check out the qooxlisp wiki pages:

   http://wiki.github.com/kennytilton/qooxlisp/

No thanks!

I know I have to linked to those before, what I do not know is how well
you can read.

You linking and me reading don't typically go together. I made an
exception for your app, which was funny. Now I get the impression
that you were serious with that thing. (?)

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 *the* idea?

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.

It's always some lame excuse.

I understand you have no idea what I am talking about because you do not
know qooxdoo has some nice syntax for creating a higher-level way of
authoring JS classes:

Of course, there are no such thing as JS classes.

   http://qooxdoo.org/documentation/1.1/oo_introduction

Not reading it. See how that works?

When you need a break from coding assembly language all day, you should
check it out.
Kennywannacracker?



Careful, it won't be free forever and early registrants will be
grandfathered in.

I'll take my chances. And what the hell makes you think I need to
learn algebra? From you of all people?!

Gasp! Now start up gimp or open office or any number of desktop apps.
(sigh). 8 billion bits over the web is many times faster.

You aren't competing with desktop apps.

     http://en.wikipedia.org/wiki/Graph_database

Another link I'll never follow.

Built into the Lisp environment I use. I was using S3 but that is too
slow/expensive for small amounts of data my app stores.

I find all of this fascinating.

The graph db is a seriously better model for storing data.

Do tell.

Oh grow up and file an RFE (or contrib it).

I see. The reason that the framework that I told you not to use is a
failure is because I am childish. And there's likely no way to fix
the problem I described anyway.

Because I did not wrap everything in scrollers. Sue me.

I just might.

Yes, delivering an environment where kids can positively enjoy
hand-to-hand battle with the arch nemesis Algebra relies on how the
scroll bars look. Your instinct for the relevant dazzles.

You misstate. My "quibble" is that it wiped out the built-in scroll
bars that come free with every browser and replaced them with nothing.

Have you forgotten what I did with color?

I suppose.

You should be thanking me.

Thanks so much for several good laughs. I'm convinced you are some
sort of surrealist performance artist.

Thanks for all of the plugs though.

btw, the author of this page need not rag on anyone over graphic design:

 http://www.cinsoft.net/mylib.html

What graphic design? Some user sent in the logo. I never felt the
need for a logo at all as I don't believe in trying to razzle dazzle
people into using a completely transparent script. Misdirection is
just not my thing.

See bottom of barrel. See Mark. See Mark scrape.

Ah, you don't care about handicapped students and consider them the
bottom of the barrel. Misfits, unworthy of your precious attention?
Is that the idea?

Shouldn't you be more forthright in disclosing your massive conflict of
interest as a competitor of qooxdoo?

Ah, I see. It's the old "he is just jealous" ploy. Well, my library
is free and I couldn't care less how many people use it. I don't have
to pay for "9 full-time engineers" to keep it up (or try to anyway) so
why should I care?

Meanwhile: "Starting this summer, cinsoft.net will be the home of
Cinsoft, a startup that will provide world-class browser scripting
solutions and professional support for My Library (as well as /any/
other Javascript library or framework)."

Including qooxdoo? You whore!

Specially and emphatically *not* qooxdoo. If you use that you are
SOL.

And what the hell is wrong with helping people that find themselves
saddled with junk code. Am I the bad guy for making money off that?
Aren't the people who gave them the junk code to blame?

Best of luck with Cinsoft.

Don't need it.

 

[RobG]

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:

1. HTML and CSS interface
2. XHR to the server to do the algebra stuff
3. math.js to do the client rendering.

The XHR stuff takes less than 100 lines of code - there are a zillon
small AJAX libraries around, you could do worse than Matt Kruse's
AjaxRequest library:
<URL: http://www.ajaxtoolbox.com/request/ >

Next time look for s simple, extensible interface in plain HTML and
CSS. Tab have been done in HTML and CSS with minimal script for over a
decade, they can be done with no script at all.

Here's a small, simple tutorial:
<URL: http://www.htmldog.com/articles/tabs/ >

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.

Editable text areas have been done for ages too, though I think what
you are doing is very simple - capture keystrokes, send them to the
server, then send back stuff to put in the "editable" area.

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.

if you noticed a word I have
written. Check out the qooxlisp wiki pages:

http://wiki.github.com/kennytilton/qooxlisp/

So you are happy about writing in Lisp to generate javascript, good
for you. Maybe someone in a Lisp group cares, but the relevant part
here is the generated javascript - how it came into being is almost
entirely irrelevant.

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.

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.

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.

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.

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.

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.

 

[Alessio Stalla]

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:

1. HTML and CSS interface
2. XHR to the server to do the algebra stuff
3. math.js to do the client rendering.

The XHR stuff takes less than 100 lines of code - there are a zillon
small AJAX libraries around, you could do worse than Matt Kruse's
AjaxRequest library:
<URL:http://www.ajaxtoolbox.com/request/>

Next time look for s simple, extensible interface in plain HTML and
CSS. Tab have been done in HTML and CSS with minimal script for over a
decade, they can be done with no script at all.

Here's a small, simple tutorial:
<URL:http://www.htmldog.com/articles/tabs/>

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.

Editable text areas have been done for ages too, though I think what
you are doing is very simple - capture keystrokes, send them to the
server, then send back stuff to put in the "editable" area.

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.

if you noticed a word I have
written. Check out the qooxlisp wiki pages:

   http://wiki.github.com/kennytilton/qooxlisp/

So you are happy about writing in Lisp to generate javascript, good
for you. Maybe someone in a Lisp group cares, but the relevant part
here is the generated javascript - how it came into being is almost
entirely irrelevant.

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.

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.

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.

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.

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.

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.

Kenny, screw qooxdoo! Lispers have had the Parenscript library - a
Lisp-to-js compiler - for a long time. If it were extended with a
built-in, XHR-based server callback mechanism and maybe a minimally
intrusive widget set, it would really rock! It would be a library in
the vein of GWT, but with much less boilerplate. If only I had the
time...

Alessio

 

[Kenneth Tilton]

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? I appreciate
all the links, but it means months more work and I am wondering why I
would do that.

1. HTML and CSS interface
2. XHR to the server to do the algebra stuff
3. math.js to do the client rendering.

The XHR stuff takes less than 100 lines of code - there are a zillon
small AJAX libraries around, you could do worse than Matt Kruse's
AjaxRequest library:
<URL: http://www.ajaxtoolbox.com/request/ >

Next time look for s simple, extensible interface in plain HTML and
CSS. Tab have been done in HTML and CSS with minimal script for over a
decade, they can be done with no script at all.

Here's a small, simple tutorial:
<URL: http://www.htmldog.com/articles/tabs/ >

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.

Editable text areas have been done for ages too, though I think what
you are doing is very simple - capture keystrokes, send them to the
server, then send back stuff to put in the "editable" area.

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.

So you are happy about writing in Lisp to generate javascript, good
for you. Maybe someone in a Lisp group cares, but the relevant part
here is the generated javascript - how it came into being is almost
entirely irrelevant.

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

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.

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.

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.

I am sure I would have done better with Mr. Mark's library than with
Dojo or anything else other than qooxdoo, 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.

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

To solve what problem? Remember, this group defines "Using a library" as
a problem, but only this group.

kt

 

[Alessio Stalla]

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.

Too bad you don't control Firefox development... it's the web,
baby!

It seems fast enough. 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?





They are doing fine, actually, tho the desktop per se not so much.




Right, and I should be programming in assembler instead of Lisp. Except
compilers eventually started writing better assembler.




And later you suggest I rewrite the whole thing in JS.

I am sure I would have done better with Mr. Mark's library than with
Dojo or anything else other than qooxdoo, 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.

Oh, I think we finally nailed down the problem/misconception. I don't
think anybody is saying that raw HTML/CSS/JavaScript is faster to
develop than qooxdoo; rather that the end result is generally poorer
with qooxdoo than with the "lower-level" approach.

Sounds like a theoretical objection not supported by experience. 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.




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?

JS is much less of a toy language than most people think (and I'm a
Lisper, too). And you'd not need to port the whole application; just
move to the client stuff that pertains there, like formula editing,
while leaving other stuff on the server (e.g. the problem solving
logic).

To solve what problem? Remember, this group defines "Using a library" as
a problem, but only this group.

Not any library, but a certain class of libraries.

Alessio

 

[Tim Streater]

RobG wrote:

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?

Now now, no need to sneer. I've just finished writing an e-mail client
using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
No JS libraries in sight and my ajax routine is just 20 lines long.

I looked at Lisp in 1968 and decided I didn't like it - it didn't appear
to relate to anything.

 

[Kenneth Tilton]

Kenny, screw qooxdoo! Lispers have had the Parenscript library - a
Lisp-to-js compiler - for a long time.

Writing the JS glue hardly calls for Parenscript, and with the glue we
Just Write Lisp. P/s is not all that hot, anyway.

If it were extended with a
built-in, XHR-based server callback mechanism and maybe a minimally
intrusive widget set, it would really rock! It would be a library in
the vein of GWT, but with much less boilerplate. If only I had the
time...

Now it is time to ask a Lisper: what problem are you trying to solve?
Qooxlisp is the ideal solution for RIAs: a great HLL (Common Lisp) and a
great JS framework.

I'll team up with Mr Mark on a lighter weight Cells/HTML solution for
simpler web pages down the road.

kt

 

[Alessio Stalla]

Now now, no need to sneer. I've just finished writing an e-mail client
using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
No JS libraries in sight and my ajax routine is just 20 lines long.

I looked at Lisp in 1968 and decided I didn't like it - it didn't appear
to relate to anything.

Kenny was very wrong in calling JS a toy language, but you're also
wrong if you consider Lisp today as it was in 1968. It would be like
comparing Ruby with Pascal

Lisp generating JS could bring very high-level constructs to JS
without the need of a huge library like qooxdoo. For example, you
could use macros to define functions which automagically invoke remote
services with XHR, without coding them by hand.

(defun-remote foo (args))

function foo(args, callback) {
... xhr(args, callback) ...
}

(defun bar ()
(do-stuff)
(foo 1 2 3)
(do-other-stuff))

function bar() {
doStuff();
foo(1, 2, 3, function() { doOtherStuff(); });
}

you can get the idea.

Alessio

 

[Tim Streater]

Kenny was very wrong in calling JS a toy language, but you're also
wrong if you consider Lisp today as it was in 1968. It would be like
comparing Ruby with Pascal

Oh quite possibly. But then I didn't like Pascal with its SESE model
either.

Lisp generating JS could bring very high-level constructs to JS
without the need of a huge library like qooxdoo. For example, you
could use macros to define functions which automagically invoke remote
services with XHR, without coding them by hand.

(defun-remote foo (args))

function foo(args, callback) {
... xhr(args, callback) ...
}

(defun bar ()
(do-stuff)
(foo 1 2 3)
(do-other-stuff))

function bar() {
doStuff();
foo(1, 2, 3, function() { doOtherStuff(); });
}

you can get the idea.

Hmmm I must be missing something. Isn't this what functions are supposed
to be for? And I'm not keen on macros (except when using assembler - see
Metasym). After I discovered that C macros knew nothing about C, I stuck
to using the C preprocessor for simple substitutions of the:

#define wiggy 3

variety.

 

[Kenneth Tilton]

Too bad you don't control Firefox development...

That is actually true of all software.

it's the web,
baby!

Nice that qooxdoo had a trivial workaround. Hint.

Oh, I think we finally nailed down the problem/misconception. I don't
think anybody is saying that raw HTML/CSS/JavaScript is faster to
develop than qooxdoo; rather that the end result is generally poorer
with qooxdoo than with the "lower-level" approach.

Once I can handle HTML and CSS and browser variability as well as the
qooxdoo team. Does anyone else detect a loop in this discussion?

btw, I think we finally nailed down the source of our disagreement: I am
not just pissing around on Usenet spouting crap, I am trying to build an
RIA. Need some spam here: http://teamalgebra.com/

JS is much less of a toy language than most people think (and I'm a
Lisper, too).

It has some nice qualities, but it is still a toy language.

And you'd not need to port the whole application; just
move to the client stuff that pertains there, like formula editing,
while leaving other stuff on the server (e.g. the problem solving
logic).

Un-hunh. I have about six month's savings before I go under, excuse me
if I go with Worse Is Better instead of trying to mollify The Savages of
comp.lang.javascript by porting things to a crummy language for no reason.

kt

* Credit to gavino (IYRC).

 

[Kenneth Tilton]

Now now, no need to sneer.

I know that sounds like a put-down, but it really is not. JS has many of
the best qualities of Lisp. When I say it is a toy language, I mean it
just does not go very far (and I am not sure it should). Don't get me
wrong, I am thrilled that JS is the de facto standard client HLL.

I've just finished writing an e-mail client
using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
No JS libraries in sight and my ajax routine is just 20 lines long.

Nice. What did the 13k lines translate to in download size?

I looked at Lisp in 1968 and decided I didn't like it - it didn't appear
to relate to anything.

Lisp in 1968 was pretty weird, but the seed of greatness (code as data)
was there. From that has grown Common Lisp, a redwood of a language.
Ironically damned (like qooxdoo) for its size. More here on why it is
time to look again:

http://smuglispweeny.blogspot.com/2008/02/ooh-ooh-my-turn-why-lisp.html

It's been 42 years, you know. 42...coincidence? I don't think so. btw, I
too had to be dragged back to Lisp: My road:

http://smuglispweeny.blogspot.com/2008/02/my-road-to-lisp.html

kt

 

[Tim Streater]

Once I can handle HTML and CSS and browser variability as well as the
qooxdoo team. Does anyone else detect a loop in this discussion?

If you write standard code there *is* no variability, not these days. My
app works pretty identically in five browsers (except IE, fortunately I
have no access to a copy of that, neither do I want one).

I did find some variability or actual failures initially, but guess
what, it was essentially all my fault. Safari is a bit more tolerant of
mistakes than some, so the other browsers highlighted typos, missing
declarations, old-style usages. I spent an hour or fixing that and
everything is peachy.

And you're still using non-standard scroll-bars, thus preventing me from
having both arrows at each end of the scroll bar.

 

[Kenneth Tilton]

Oh quite possibly. But then I didn't like Pascal with its SESE model
either.


Hmmm I must be missing something. Isn't this what functions are supposed
to be for?

Many a Lisper makes the mistake of using macros where functions would
suffice, ie, yes, macros and fucntions both hide details and often a
macro hides no more than could a function hence should be eschewed.

Mr. Graham explains it better than anyone:
http://www.paulgraham.com/onlisp.html

And I'm not keen on macros (except when using assembler - see
Metasym). After I discovered that C macros knew nothing about C, I stuck
to using the C preprocessor for simple substitutions of the:

#define wiggy 3

variety.

I did OK with the C preprocessor, I just used a lot of parentheses and
braces and stuff. One great five-day bug, tho.

C macros and Lisp macros have in common the word "macro". Nuff said.

kt

 

[Tim Streater]

I know that sounds like a put-down, but it really is not. JS has many of
the best qualities of Lisp. When I say it is a toy language, I mean it
just does not go very far (and I am not sure it should). Don't get me
wrong, I am thrilled that JS is the de facto standard client HLL.


Nice. What did the 13k lines translate to in download size?

Well its not all downloaded at once, but 5.7k lines translates to
215kbytes. Safari's profiler tells me it takes 23msec to download.
Initialising the whole app with 10 mailboxes open takes about 4 secs
elapsed (of course Safari has to be running first, as does apache).

 

[Matt Kruse]

If you write standard code there *is* no variability, not these days. My
app works pretty identically in five browsers (except IE, fortunately I
have no access to a copy of that, neither do I want one).

Problems are easier to solve when you ignore the trouble-makers

For those who still contend with IE6, writing js for webapps is still
a messy proposition, made easier with prudent use of libraries.

Matt Kruse

 

[Tim Streater]

Problems are easier to solve when you ignore the trouble-makers

For those who still contend with IE6, writing js for webapps is still
a messy proposition, made easier with prudent use of libraries.

Well you have my sympathy. I work at home, on a Mac. And - it's all a
*hobby*, as I'm retired now. So I decided my tools are going to be
JavaScript, PHP, and SQLite, all of which are free on this platform
along with apache. I was curious to see whether it would be possible to
duplicate those features of Eudora that appeal to me using this toolset.
I was expecting to hit show-stopping roadblocks at every turn, but
rather to my surprise after 18 months I have a useable app, even to the
extent of creating an installer for it.

It's not perfect but it's now what I use full-time for email.

 

[Kenneth Tilton]

Well its not all downloaded at once, but 5.7k lines translates to
215kbytes.

Yikes. These yobbos will kill me if I port ten times that to JS, which
could be fifty times that by the time all the Lisp macros get expanded.
And my investor (me) will kill me if I spend three months on a port. I
think the math editor better stay in Lisp on the server.

Naysayers in re that need to remember that Algebra students are
generally not entering equations at 60 wpm.

We'll see, but so far it looks like a no-brainer. As I said, I have not
yet begun to optimize.

So are the buttons appearing OK now that each typing example gets loaded
separately? http://teamalgebra.com/

Hmmh, I have to figure out how to give diff tabs their own url. Anyone
here know how to do that with qooxdoo?

kt

 

[David Mark]

Problems are easier to solve when you ignore the trouble-makers

Users (and their agents) cannot be considered "trouble-makers" by
professionals. You have to play the hand you are dealt. The recent
trend of "not caring" about whatever browsers you can't handle is
ridiculous as end-users don't care what you don't care about.

For those who still contend with IE6, writing js for webapps is still
a messy proposition,

No it isn't. IE6 is very much like IE7 (and IE8 can mimic IE7 fairly
closely). And as IE6 has been out since the turn of the century,
professional developers should know how to deal with it by now.

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? Why do you think most library authors have
given up on trying to "solve" that browser? They tried for years and
never got close, so now they want to wish it out of existence.