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: Alessio Stalla on 21 Jul 2010 15:07 On 21 Lug, 17:48, Tim Streater <timstrea...(a)waitrose.com> wrote: > In article > <f7253284-7fc1-47d8-bca3-b3aeca686...(a)k39g2000yqb.googlegroups.com>, > Alessio Stalla <alessiosta...(a)gmail.com> wrote: > > > > > On Jul 21, 4:42 pm, Tim Streater <timstrea...(a)waitrose.com> wrote: > > > In article <4c46f2e3$0$31286$607ed...(a)cv.net>, > > > Kenneth Tilton <kentil...(a)gmail.com> wrote: > > > > > RobG wrote: > > > > > 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? > > > > 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 :) > > 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? Macros are about source code transformations at compile-time. You can't do that with functions. In the fictional example I posted, a piece of code like: doStuff(); callSomeFunctionOnTheServer(1, 2, 3); doOtherStuff(); got translated to: doStuff(); callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); }); i.e. from plain imperative style to asynch XHR callback-driven style. Only a macro can do that. > 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. Lisp macros know Lisp, and are written in Lisp. C macros are little more than text substitutions. Alessio
From: Alessio Stalla on 21 Jul 2010 16:26 On 21 Lug, 21:47, Tim Streater <timstrea...(a)waitrose.com> wrote: > In article > <67d9e6e5-0640-437a-ada3-26598707c...(a)c10g2000yqi.googlegroups.com>, > Alessio Stalla <alessiosta...(a)gmail.com> wrote: > > > > Hmmm I must be missing something. Isn't this what functions are supposed > > > to be for? > > > Macros are about source code transformations at compile-time. > > I'm really not sure I want to do that. As Kenny said, Lispers sometimes want *too much* to do that ;) > > You can't do that with functions. > > In the fictional example I posted, a piece of code like: > > > doStuff(); > > callSomeFunctionOnTheServer(1, 2, 3); > > doOtherStuff(); > > > got translated to: > > > doStuff(); > > callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); }); > > In my JS, a call to my 20-line ajax function looks like: > > ajax ("some-script.php", data-string-for-script, someCallbackFunction); > > arg 1 is a PHP script to do some work for my app and return results > arg 2 is an argument string of values for the script in the form: > arg1=value&arg2=value > arg3 is a JS function that will be given the script's results later and > will process them. > > So I'm already doing that in JS. You're doing it manually. You could program the compiler to translate imperative code to callback-driven code, making it appear as if XHR calls were regular synchronous function calls when they're really not. E.g. withSynchrXHR { stuff(); ajax(...); moreStuff(); ajax(...); evenMoreStuff(); } gets translated to ajax(..., function() { moreStuff(); ajax(..., function() { evenMoreStuff(); }); }); just a rough sketch, not taking into account return values, error conditions, ... > Hmmm, perhaps a different fictional example might show the point better. Another, simpler example, again in JS syntax rather than Lisp syntax: ajaxFunction foo(args) { code } translated to function foo(phpScript, args) { ajax(phpScript, args, function() { code }); } and macros for defining classes if you want to turn JavaScript into a class-based OO language, macros for representing DOM subtrees literally in source code, there are many examples. Cheers, Alessio
From: Matt Kruse on 21 Jul 2010 16:31 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. Matt Kruse
From: David Mark on 21 Jul 2010 16:48 On Jul 21, 4:31 pm, Matt Kruse <m...(a)thekrusefamily.com> 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... That's my line. You have no point. Instead you advocate using "the libraries" as if they are some sort of magical solution for everything. > > A library may work well in IE6 for, let's say, 80% of problems that > the library may try to solve. That would be well short of a passing grade. > It may work only partially on 15%, and > fail miserably on the remaining 5%. Which means it is far more trouble than it's worth. They change constantly, remember? So you whatever library quirks you memorized yesterday may be invalidated today or tomorrow. > > Take advantage of the 80% of features that work just fine, and use the > library. Do you realize how silly you sound? Use "the library"? What library? Are all libraries good and anyone who points out otherwise "anti-library" (and therefore bad). It is too bad that all of the "major" efforts (by virtue of the fact that they try ill-advisedly to solve every problem for every context) are such garbage. > 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. Do you see the gaping hole in your logic? You don't know what the 80/20 split will be, do you? Certainly not from one day to the next. It's worse than dealing with browsers. Just admit it. > > Any reasonable person would understand that strategy, IMO. Nope. Any reasonable person can see the fallacy in your proposals. > Because we > do it all the time with other things. You do what all the time with other things? And what makes you think that everything you do outside of browser scripting applies to browser scripting? The very idea is ludicrous. > Almost no tool gets everything > right. For God's sake. That's why you don't use tools that try to do *everything*. That's also why reasonable and experienced developers don't waste their time on such folly, leaving the efforts to the B team. Get it? > Successful people know how to identify which parts of which > tools should be used, and then use them. But you are equating success with doing the impossible. It's been demonstrated repeatedly that neither you, John Resig or virtually anyone else related to that jQuery project has a clue which parts should be used and which parts are botched beyond belief. You are simply clinging to the notion that you can use CSS selector queries for everything and end up with production quality code. Face it, you can't. And even if you could, jQuery's query engine is demonstrably broken in more ways than you could ever keep tabs on. > Not throw them out because > they fail to solve 100% of all conceivable problems that they may > encounter. > You've been spouting that nonsense for years. You started out saying that jQuery was a really good "cross-browser" script. Then you wavered and said it was actually fairly bad, but "good enough" for you. And all along, you've been playing this waiting game waiting for Resig and co. to "eventually get it right", despite the fact that their goal is untenable and unneeded.
From: Matt Kruse on 21 Jul 2010 17:25
On Jul 21, 3:48 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > It may work only partially on 15%, and > > fail miserably on the remaining 5%. > Which means it is far more trouble than it's worth. Non sequitur. Your leap to such a conclusion is unwarranted. > Do you realize how silly you sound? Use "the library"? What > library? Whichever one you identify as being good enough to use, obviously. > Are all libraries good and anyone who points out otherwise > "anti-library" (and therefore bad). Of course not. Some analysis is necessary to determine which libraries are suitable. > It is too bad that all of the > "major" efforts (by virtue of the fact that they try ill-advisedly to > solve every problem for every context) are such garbage. I don't think they try to solve every context. For example, jQuery doesn't support animations in IE in quirks mode. For stupid reasons, actually, and my patched version has no such limitation. But they certainly do limit the context. > > 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. > Do you see the gaping hole in your logic? You don't know what the > 80/20 split will be, do you? Not until you do some analysis on your library of choice, no. > > Any reasonable person would understand that strategy, IMO. > Nope. Any reasonable person can see the fallacy in your proposals. I think the general public of developers are pretty reasonable, and they agree with me, IMO. I don't think the few hard-core zealots here define "reasonable". > > Because we > > do it all the time with other things. > You do what all the time with other things? Use imperfect tools for the things they are good at, and avoid using them for the things they are not good at. I just used a microwave to heat up leftovers. I would never use it to cook a pizza. That doesn't mean microwaves are a complete failure. It means they are good at some things, bad at others. Despite the fact that people try to make pizzas that cook well in microwaves! (they don't) > And what makes you think > that everything you do outside of browser scripting applies to browser > scripting? The very idea is ludicrous. It seems to be the norm for most things. I see no reason not to apply it to browser scripting also, unless there are good reasons not to. You've not offered any. > > Almost no tool gets everything > > right. > For God's sake. That's why you don't use tools that try to do > *everything*. Like "My Library"? > > Successful people know how to identify which parts of which > > tools should be used, and then use them. > But you are equating success with doing the impossible. It's been > demonstrated repeatedly that neither you, John Resig or virtually > anyone else related to that jQuery project has a clue which parts > should be used and which parts are botched beyond belief. My experience shows otherwise. jQuery sucks at some things, and causes great frustration sometimes. It's also been extremely useful in a number of projects and proven its value with faster development, more consistent code across a team of developers, less maintenance, and better performance. I'm not sure why you think you have any argument to the contrary of my experience and many others. > You are > simply clinging to the notion that you can use CSS selector queries > for everything and end up with production quality code. Am I? > And even if you could, jQuery's query engine is demonstrably > broken in more ways than you could ever keep tabs on. Yet it consistently performs perfectly well for every task I throw at it. Amazing, eh? Same old broken record with you, David. Matt Kruse http://BetterFacebook.net <-- Blatant advertisement for my current pet project |