jquery vs dojo vs yui etc
in [JavaScript]
|
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
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
From: Alessio Stalla on 21 Jul 2010 09:55 On Jul 21, 3:14 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: [snip] > > > 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. Too bad you don't control Firefox development... it's the web, baby! ;) > > >> 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. > 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. > > >> 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? 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
From: Kenneth Tilton on 21 Jul 2010 10:50
Alessio Stalla wrote: > 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 -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld |