jquery vs dojo vs yui etc
in [Lisp]
|
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: Kenneth Tilton on 20 Jul 2010 17:44 Bad news: Qooxdoo/Lisp looking better/faster all the time: http://teamalgebra.com/ 1. Registering can be ignored for now. 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. 3. If you do register, your info will be stored using AllegroGraph! 4. qooxdoo continues to rock, as does qooxlisp. 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. 5. Enjoy. And tell your Algebra teacher friends I am looking for local schools interested in being guinea pigs. kt -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld
From: David Mark on 20 Jul 2010 18:33 On Jul 20, 5:44 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > 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?
From: RobG on 21 Jul 2010 00:02 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: 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. -- Rob
From: Alessio Stalla on 21 Jul 2010 04:16 On Jul 21, 6:02 am, RobG <rg...(a)iinet.net.au> 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: > > 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
From: Kenneth Tilton on 21 Jul 2010 09:14
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? 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. > > >> 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. 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? > > >> 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. > > 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. > >> 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. 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 -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld |