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: David Mark on 21 Jul 2010 19:09 On Jul 21, 5:25 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > 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. Oh shut up. How's that for warranted? :) > > > Do you realize how silly you sound? Use "the library"? What > > library? > > Whichever one you identify as being good enough to use, obviously. But you are clearly incapable of making such an identification. > > > 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. Yet, you talk in black and white terms of "the libraries" and "anti- library zealots". > > > 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. Of course they do. They have no specific goal other than to "fix" JS and browsers. > For example, jQuery > doesn't support animations in IE in quirks mode. Much to their chagrin. I'm well aware of their "punt" on that issue. They do a lot of that, but they don't advertise such things. And those are not design considerations but failings. > For stupid reasons, > actually, and my patched version has no such limitation. Haven't you figured it out by now? Patching jQuery will only lead to more "upgrade" issues. You'll have enough trouble with all of the hacks, patches, workarounds, etc. that they add to try to satisfy the umpteen million other people clinging to the library. Professionals don't rely on such things for reasons that should be obvious at this point. Hell, they should have been obvious three years ago. > But they > certainly do limit the context. No. Failing to do something; having to be told that you failed and then refusing to even try to fix the problem is not "limiting the context". In other words, they didn't sit down at the beginning and say "we won't bother with animations in quirks mode". It wasn't part of the "design" of jQuery for that to happen. > > > > 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. That's pretty funny. Think of how many times I've posted demonstrations of basic problems in jQuery that you didn't know about. Your analysis must have been somewhat lacking. In fact, the first time you started up about jQuery in here, you claimed it didn't use browser sniffing. Then you changed your tune to there was a little in there, but only where "needed". Then when confronted with the source code, which was indeed teeming with unneeded browser sniffing, you became a defender of browser sniffing (using the same old non-arguments about SELECT's bleeding through in IE, Flash problems, etc.) Finally, confronted with Resig's humiliating attempts to defend his code, you started pushing him to change the browser sniffing. That's not analysis (well, not yours anyway). And we've seen numerous, similar examples since then. The most recent was probably the ridiculous selectedIndex "problem", for which you proposed an equally ludicrous solution. And yes, I gave you the real solution and you tried to get Resig to accept it, but he didn't get it at all. See the pattern? That was about the point where you started railing against their problem-solving ability (parroting me basically). Again, not analysis. Being ignorant and then told about something by the very people who "don't get it" (in your words) and only *then* trying to address problems does not constitute anything but failures on your part. Ironically, you'd have remained oblivious to at least some of these failures if it were not for *me*. Still think I don't get it? :) > > > > 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. The general public of developers? You mean Web developers right? In what way are Web developers "pretty reasonable" (as opposed to off the reservation?) And they agree with you on *what*? You don't have any original ideas, remember? > I don't think the few hard-core zealots here > define "reasonable". There it is. > > > > 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. It's been thoroughly explained that you can't use something for what it's good (and avoid using it for things it is bad at) at if you don't know (in advance) what the tool is good at and what it is bad at? Your oversimplifications are truly painful in light of your tribulations of the last few years. Which version of jQuery are you up to? How are its queries doing in relation to the previous version? Worse or better? > > I just used a microwave to heat up leftovers. Things tight? :) > I would never use it to > cook a pizza. That doesn't mean microwaves are a complete failure. Child-like oversimplifications are your trademark. Do you really think they belong in a technical group though? > 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) Folksy. Again, this is a technical group, not a PTA meeting. > > > 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. Appeal to loonies. > > > > 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"? As a whole, very much so, though as it is modular rather than tangled up in interdependencies... And why do I have to keep repeating the same things to you year after year? Is it amneaia or are you simply playing to some perceived audience? If newcomers are unfamiliar with your broken record imitations, they'll figure you out soon enough (perhaps with help from the archive). > > > > 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. In what way? ISTM that it shows just the opposite, as detailed in this group over the course of years. > jQuery sucks at some things, and causes > great frustration sometimes. Yes, which you could have avoided by not using jQuery in the first place. The browsers really aren't that bad these days. And back when they were, jQuery was never close to bridging the gaps. > 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. As for saving time, you could have done that with any code re-use strategy. Of course, you likely have little code of your own due to your perpetual reliance on John Resig's. See the problem? Same for consistency. Less maintenance is laughable in regard to jQuery. You had to sit on some old version (1.2?) for years, despute its many well-documented problems, simply because the next version was wildly incompatible (a recurring pattern with that project). And as for performance, who are you trying to kid? Better implies a comparison. Just what imagined entity does jQuery outperform? > I'm not sure why you think you have any argument > to the contrary of my experience and many others. I've seen you and countless others going around in circles for years. Get a load of the posts in the jQuery "support" forums. If these people think they are having a good experience, then I wonder what it is they are comparing it to. Perhaps they have nothing to compare it to. Then again, maybe they tried their hand at cross-browser scripting years ago and gave up. Either way, it's not a comparison rooted in reality (especially not today). > > > 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? Yes, you are. That's what jQuery is (a query engine). Or are you really in love with the illogical and ham-fisted API? That's hard to imagine, even for you. Maybe you like the chaining? :) > > > 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? Not really. You are simply deluded. > > Same old broken record with you, David. Again, my line.
From: Frank Buss on 22 Jul 2010 00:25 Kenneth Tilton wrote: > So are the buttons appearing OK now that each typing example gets loaded > separately? http://teamalgebra.com/ I've tried it with Opera. When trying to register, I didn't fill out each field and it says "Login error: Please fixFORM-FIELD98737". That's a very useful information :-) Some other things I noticed: - I can't use any key above my numbers (German keyboard), e.g. "/" or "(" doesn't work and "=" is on "*" - Backspace deletes always two characters - cut, copy and paste to and from the input field doesn't work - when I press repeated times the square root, the input field doesn't size, so I see only the upper part of it anymore - sometimes the text for the buttons in the traing center is not readable (e.g. "Cle..." and "O..."), but sometimes the whole text is visible - in the Typing Tutorial, it is a green vertical bar, not a red vertical bar In general I think it is not a good idea trying to make a GUI application in a web browser. If you don't want the user to install a program, you could use Flash, which works the same in all browsers on all platforms. But maybe better, if the user has no flash, would be a simple HTML interface without JavaScript, e.g. entering expressions in basic programming syntax, like sqrt(1/3)<10*x. This would work even for visually impaired users, too. I guess your current application is useless for blind users. You can explain the syntax with some examples, and it has the advantage that the user can use this syntax later for programming or spreadsheets, too. Then you can use simple text forms, which works with all browsers, even very old or strange ones without Flash and JavaScript, e.g. on some mobile phones. On post, generate a nice image of the expression on server side and send it back to the browser, if you like. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: David Mark on 22 Jul 2010 01:38 On Jul 22, 12:25 am, Frank Buss <f...(a)frank-buss.de> wrote: > Kenneth Tilton wrote: > > So are the buttons appearing OK now that each typing example gets loaded > > separately?http://teamalgebra.com/ > > I've tried it with Opera. When trying to register, I didn't fill out each > field and it says "Login error: Please fixFORM-FIELD98737". That's a very > useful information :-) > > Some other things I noticed: > > - I can't use any key above my numbers (German keyboard), e.g. "/" or "(" > doesn't work and "=" is on "*" > > - Backspace deletes always two characters Well, either KooksDo or Kenny botched the keyboard handling. > > - cut, copy and paste to and from the input field doesn't work Unsurprising from what I've heard of the input scheme. > > - when I press repeated times the square root, the input field doesn't > size, so I see only the upper part of it anymore Yes, there are loads of layout problems that would never happen if layout were left to the browser. Again, predictable (and what's worse predicted). > > - sometimes the text for the buttons in the traing center is not readable > (e.g. "Cle..." and "O..."), but sometimes the whole text is visible Yes, browsers wouldn't likely make the same mistake. > > - in the Typing Tutorial, it is a green vertical bar, not a red vertical > bar > > In general I think it is not a good idea trying to make a GUI application > in a web browser. It's very doable if you know what you are doing (and has been for well over a decade). More to the point, it's not a good idea to try to make GUI applications with frameworks designed and implemented by relative neophytes. ;) > If you don't want the user to install a program, you > could use Flash, which works the same in all browsers on all platforms. I would advise against that. Flash is the wave of the past. > > But maybe better, if the user has no flash, would be a simple HTML > interface without JavaScript, e.g. entering expressions in basic > programming syntax, like sqrt(1/3)<10*x. This would work even for visually > impaired users, too. Exactly, but Kenny doesn't like "raw HTML" for some reason (likely because he's never bothered to learn it). > I guess your current application is useless for blind > users. No question there. But Kenny stated something to the effect that handicapped students were the "bottom of the barrel". I took that to mean that he considers such children unworthy of his efforts. See Kenny squirm. :) > > You can explain the syntax with some examples, and it has the advantage > that the user can use this syntax later for programming or spreadsheets, > too. Then you can use simple text forms, which works with all browsers, > even very old or strange ones without Flash and JavaScript, e.g. on some > mobile phones. On post, generate a nice image of the expression on server > side and send it back to the browser, if you like. What a great idea! Unfortunately, similar proposals were dismissed out of hand. Something about assembly language and trolls. :)
From: RobG on 22 Jul 2010 02:18 On Jul 21, 11:14 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > RobG wrote: > > On Jul 21, 12:01 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > >> David Mark wrote: > > [...] > >>> Oddly enough, it seems to go back to the server constantly during user > >>> interaction. > >> Oddly enough, that's the frickin idea > > > It seems to me that you are using qooxdoo purely for presentation in > > the client. Apparently you think it's massive bulk is required in > > order to present a tabbed interface and do XHR. > > > Suppose you slim your application down to the following components: > > Sorry, but what problem of /mine/ are you trying to solve? You are using a javascript library to cure your lack of knowledge of HTML and CSS. You don't need to learn a lot about those technologies to build your site. Had you invested the same amount of time and effort learning them instead of qooxdoo, you may have a much more efficient and accessible site. > I appreciate > all the links, but it means months more work and I am wondering why I > would do that. It's not months, hours maybe. As for why, see above. [...] > > A web search will show lots of examples of creating extensible tabs > > with a small amount of HTML, CSS and script. Your pages are pretty > > static so it should be a snap to create them without any javascript > > library at all. > > My pages are static? I think you stopped at the typing tutorial. I said *pretty* static, meaning they could be achieved largely using static markup. Right now, of the 9 tabs, 5 do nothing so I can't comment on those. One is a simple login tab (that should display instantly but takes at least 3 seconds, even when going back to it after it's been previously visible), the other 3 only work if I laboriously enter keystrokes very slowly and wait for the display to update. The interface is still very buggy, I can only judge by what I see. Incidentally, on the login screen, if you check the "New User" button more inputs are displayed (after about a 2 second display). In IE 6, checking "Returning User" doesn't go back to the login and password version (it does in Firefox, after a couple more seconds...). In the typing tutor, the first button after "Press these keys" is nested inside 5 span elements inside 27 div elements, 14 of which are inside the tab. You think that isn't inefficient? Each div has a large amount of inline styling, a lot using -moz so there's some browser detection going on here. [...] > > Incidentally, if Firefox users have the "Search for text when I start > > typing" preference checked, it plays havoc with your interface because > > Firefox doesn't see it as an editable area and starts capturing > > keystrokes. > > You see that happening? Ah, I limited calling preventDefault to > backspace for some reason. Putting it back to all keystrokes until I > remember the reason. > > Firefox needs to lose that option, btw. No, you need to deal with it. It's a great option, I don't think it will go away soon. [...] > > Your use of qooxdoo is essentially as crutch to generate the client > > UI. There are many alternatives, a more popular one is to do the work > > on the server and send generated HTML to the client. It tends to be > > much faster and more robust. > > It seems fast enough. Not to me, it is very slow. I'm comparing it to other commercial sites that I use, such as banking or share trading, that have complex script- driven dynamic UIs (I'm not commenting on the quality of the UI, just that they are *much* snappier and do a lot of dynamic modification of the page). > Robust? qooxdoo is an active and steadily > advancing library worked on by better web developers than I, how am I > going to do better work than them? Their work isn't that great, I think you'd be surprised at how easy it is to do what you are doing without qooxdoo. And if your site is an example, it isn't robust at all, it is very easy to break the UI. Of course you'll say you aren't finished yet, but you're saying it's simple to knock up the site yet you're having lots of UI issues (that you seem to write off as either "I'm not finished yet" or "I don't believe you"). > >> I know I have to linked to those before, what I do not know is how well > >> you can read. The idea is to program in one language in one IDE and > >> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exists. > > > That's been tried many, many times before and strangely those IDEs > > haven't taken over the world. They likely fail for much the same > > reasons general purpose javascript libraries fail - one is that if you > > try to please everyone, you end up pleasing no one. > > They are doing fine, actually, tho the desktop per se not so much. There will always be some around, maybe one day there'll be one worth using (for web pages). Cappuccino is doing so well on Apple's MobileMe site that they use browser sniffing to *prevent* their own mobile devices from accessing the site. > > Their main use seems to be programmers who know one language well but > > need to write programs in another (in your case, Lisp -> HTML and > > CSS). However the generated code is not as good as that written in the > > target language to start with - natural selection takes care of the > > rest of the story. > > Right, and I should be programming in assembler instead of Lisp. Except > compilers eventually started writing better assembler. If you insist on misrepresenting my argument then there's not much point in continuing. To paraphrase, yet again, you likely would have a better site had you spent the same amount of time learning HTML and CSS as learning qooxdoo. And you would have avoided the issues associated with that "framework". I don't think you can seriously compare learning HTML the equivalent of learning assembler. > > All the time and effort you've spend learning qooxdoo might well have > > been much better spent learning a bit of HTML and CSS - the actual > > javascript part seems to be minimal. > > And later you suggest I rewrite the whole thing in JS. No, I didn't. I would never contemplate that. > I am sure I would have done better with Mr. Mark's library than with > Dojo or anything else other than qooxdoo, I'm not pushing MyLibrary, I'll let you judge it on it's merits. > but I have done an in-depth > survey of these things (which usually includes raw HTML/CSS) and I > actually understand pretty well how much faster I can develop a web app > using qooxdoo vs raw HTML/CSS. Because you went looking for a framework to control from LISP, so that's what you found. > >> That said, I could reduce the size of each round-trip by taking an hour > >> or two to create some pre-fab qooxdoo classes expressing the boilerplate > >> I am shipping over, but the thing is so fast now I'll get to that after > >> I get the "leveling-up thru Algebra" thing going. > > > I don't think the amount of data being transmitted is the issue, it's > > the number of requests. There's a certain overhead that you can never > > reduce so the speed of the application is limited to the speed of an > > XHR request, and you have very little control over that. > > Sounds like a theoretical objection not supported by experience. The experience of your site? It is positively slothful. > I would > not still be going down this path if performance did not look so good, > and I have not even focused much on performance yet. The performance is really, really slow. I have never experienced it before because no site I know of has tried an XHR on every keystroke (for obvious reasons). You don't have to have built many web sites to know that an HTTP request takes a certain amount of time that is beyond your control and may take a very long time based on completely external factors, to do one on every keystroke is ridiculous. > > The fix for that is to run your algebra program on the client. If you > > care to rewrite it in javascript, it may be of interest. > > You want me to port 80kloc of a high-level language like Lisp to a toy > language like JS? How big will the client be then? And how many motnhs > would that take? Javascript isn't a toy language - it's a bit like C in that respect. The basic language is small and simple but you can build very large and powerful applications using it. Richard Cornford has built applications running to over 100,000 lines of code, perhaps you should ask him whether it's a toy language. Anyway, I had no idea how big your server component is, nor how big it would be if ported to ECMAScript (since the clever part would likely only need ECMAScript). DM's library is about 8,000 lines of code (with comments and unminified) and minifies to about 80kB apparently. I'm sure if you think about it you can work out how to modularise the application and move bits to the client to reduce the use of XHR. > To solve what problem? Remember, this group defines "Using a library" as > a problem, but only this group. You're nearly there... This group doesn't define using *any* library as a problem, only the badly written ones. In fact it promotes the use of *good* libraries - there should rarely be a need to write everything from scratch. -- Rob
From: David Mark on 22 Jul 2010 02:33
On Jul 22, 2:18 am, RobG <rg...(a)iinet.net.au> wrote: [...] > DM's library is about 8,000 lines of code (with > comments and unminified) and minifies to about 80kB apparently. I expect you are thinking of the example build that I use of varies demos. It is not the full build, but just the bits that were necessary for the Examples page. I should really use smaller builds for other demos (e.g. the Touch add-on). JFTR, at the moment, the full build is 140K+ minified (and as Kangax recently mentioned to me, could me somewhat smaller if I removed the repeated var statements). For comparison with "major" libraries that blare about their compressed sizes, it's 48K after GZIP. :) |