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 17 Jul 2010 22:12 On Jul 17, 9:41 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [...] > > An example of this is seen in the opening lines to Sencha: > > | window.undefined = window.undefined; Yes, I can't believe that breakthrough "HTML5 framework" opened with that old groaner. > > Another is in dojo: > dojo.isArray = function(it) { > return it&&(it instanceof Array||typeof it=="array"); > > }; Is that *still* there?! If so, there is truly no hope for them. IIRC, I explained to one James Burke that it was gobbledygook (and why that was the case) and he asked me to show him a browser where it "fails". :) If the only justification for a line of code is that it appears to get the right result, then that line of code has no place in a production system. You've got to have at least some semblance of an idea of *why* it should be expected to work. For very good reason, programming has never been about mindless observation. Rather it is about understanding abstractions. Testing programs does involve observation, but only to confirm that there were no misunderstandings. And in this business, a thousand positive test results do not mean the code will work everywhere. That's where experience and a knowledge of history come into play. > > The authors of Ext-js and dojo may have more experience than I do. No, they are mostly Ajax-era greenhorns. Have you seen ExtJS? Er, Ext-js. Or was it Ext JS? Whatever. Maybe the name change wasn't such a bad idea after all (other than breaking a million Google search results of course). :) > What > does that say when they continue to publish code that shows a lack of > knowledge? That they are ignorant. No news there. The usual "excuse" is that they don't have time to learn. You've got to wonder why so many developers are keen to use their scripts. Oh wait... We are talking about Dojo and ExtJS after all. Of course, jQuery is just as mystically silly and, inexplicably, Prototype was once popular. Then there's MooTools... Somebody asked me recently whether there was any framework I *do* like. They asked in a nice enough way, but I could sense their implication that I was a serial doubter. Of course, I asked them "a framework for what?" The answer was: well, something like Dojo or YUI or jQuery... In other words, something that makes outrageous false claims about making browser scripting accessible to the masses. > > Code may be obscurely written, have an unrecognized flaw that applies > exclusively to the situation (perhaps only in an uncommon case), provide > a workaround to something irrelevant, contain misleading or obsolete > comments, be mostly irrelevant, and can be full of bugs that exist in > code paths that are untested but never reached. The same code may also > fulfill the requirements. Hence, "show me where it fails" is the rallying cry for incompetent JS developers. Show them anything but the latest versions of three or four major desktop browsers (in their default configurations) and they assert that they don't "care" about those cases. Of course, it's insanity to project the cares of deluded Web developers onto the general public (who just want working documents). > > The author is of such code may be overlooking important considerations > of code quality including clarity, efficiency, extensibility, etc. ....competence, sanity, etc. > > Sufficient criteria for the assessment of front end skill has not been > formally established. You, I, and Cornford all have seem to have > expressed that to some degree. Then there are things like Dojo. I think most can agree that it does not demonstrate skill on the part of its developers. Delusions yes, proficiency no. > > A precursor to making assessments of front end skill is the ability to > make assessments of the quality of front end code. That much is clear. :) > For that, I have been > working on the code guidelines document. > > <http://jibbering.com/faq/notes/code-guidelines/> I think I skimmed it at some point. > > This document can be improved and I would like more feedback on it. > > One thing that I have wanted to change is the "Avoid modifying objects > you don't own. ". While that is a nice trite phrase, it doesn't cover > the aspects of defining cohesive objects. I think it gets the point across. It's very easy to by accident (or in haste). > > "Define cohesive objects" is better but that does not imply that doing > the opposite is wrong. In contrast, I don't know what that means; so the first one is definitely better. > > "Avoid interdependencies" is better But something else altogether. > and expounding on host object in > that section is still appropriate, however some interdependencies make > sense, so I can't say I'm satisfied with that, either. Well, you can't satisfy everybody. :)
From: Garrett Smith on 18 Jul 2010 03:35 On 2010-07-17 05:13 AM, Tim Streater wrote: > In article <i1rkkj$lj0$1(a)news.eternal-september.org>, > Garrett Smith <dhtmlkitchen(a)gmail.com> wrote: > > >> That seems out of touch. Surveys aren't a big part of the user story. >> Like help (F1), these don't get top priority in testing and I've >> worked at out-of-touch companies that had such surveys along with >> foreseeresults, and omniture. They employed these because they were >> out of touch with the end user, ... > > What makes anyone think that F1 is Help? Or that "you can add this link > to your favorites (sic) by typing ctrl-d" or whatever it is? The former > applies to nothing on my computer and the latter to only one out of five > browsers I have. > Well, sure, F1 might not be help, ctrl + D might not be a bookmark, backspace might perform scrolling, navigation, or nothing at all. Those things depends on the app. The point I was trying to make, and what Richard's popup feedback survey example showed, was that such features may not be as well tested as the rest of the application. Additionally help is often a failed user experience. When the user gets to that point, it can often be considered a problem. User usually does not want to launch help. Help takes time to launch and use. Even if it is only 10 seconds, that is still a lot of time for the user. Help also changes context and focus of what he was doing and might not even have the answer for what he's trying to get done. Things such as as "help" or "surveys" tend to be not as well-tested. They are sometimes irrelevant and may be an indication that the application developers are out of touch. This is generally the case with foreseeresults, which opens windows in popups (that can fail), asks questions that are irrelevant (if the user ever sees them) using marketing lingo. They rely on cookies to determine if the customer has been provided with the survey and since that can fail, the user can get the same survey again and again. Any company that uses foreseeresults is clearly out and using foreseeresults won't help change that. Sorry if that was too long-winded. In short, F1 could be anything and web surveys and help are usually indicators of a company that is out of touch with the user. -- Garrett
From: Kenneth Tilton on 18 Jul 2010 11:57 David Mark wrote: > On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: >> David Mark wrote: >>> Kenneth Tilton wrote: >>>> Using a little FUD to keep >>>> those billing rates up, are we? Best of luck, these are tough times. >>> FUD? That's what the displaced Java developers behind Dojo were >>> saying back around 2007. >> Is that true, Dojo was written by people who thought in Java? It >> would explain a lot. >> > > Yep and it does indeed. Avoid like the plague. :) > I agree. And we would be in de facto agreement over JS libraries were it not for qooxdoo (and possibly the proprietary library I gather qooxdoo was modelled after). Most JS libraries are bad beyond salvation by bugfix. But engineering is like that: eventually someone gets it right. One thing they got right is hiding HTML/CSS so a new generation of developers need not mess with those. ie, The library is not an additional learning curve, it replaces several. Until I see a widget set like qooxdoo's and other things like the messaging mechanism and their databinding mechanism and their sophisticated layout API in some raw HTML/CSS library, I'll be using qooxdoo. And I am an NIH kinda developer, preferring to roll my own rather than sort through someone else's mess in the time I could develop my own. kt -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld
From: David Mark on 18 Jul 2010 14:48 On Jul 18, 11:57 am, Kenneth Tilton <kentil...(a)gmail.com> wrote: > David Mark wrote: > > On Jul 17, 4:04 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > >> David Mark wrote: > >>> Kenneth Tilton wrote: > >>>> Using a little FUD to keep > >>>> those billing rates up, are we? Best of luck, these are tough times. > >>> FUD? That's what the displaced Java developers behind Dojo were > >>> saying back around 2007. > >> Is that true, Dojo was written by people who thought in Java? It > >> would explain a lot. > > > Yep and it does indeed. Avoid like the plague. :) > > I agree. And we would be in de facto agreement over JS libraries were it > not for qooxdoo (and possibly the proprietary library I gather qooxdoo > was modelled after). And it is likely not a coincidence that you have hitched your wagon to qooxdoo's star. Perhaps you have a special place in your psyche for that one? http://en.wikipedia.org/wiki/Cognitive_dissonance > Most JS libraries are bad beyond salvation by > bugfix. That's 100% correct. Most developers realize that trying to solve every problem for every conceivable context is the wrong approach. Scripts must be downloaded, JS is single-threaded, etc. Logic says that context-specific scripts are needed to make non-trivial scripts download and execute fast enough. Furthermore, solving every problem for every *browser* is virtually impossible, so it is necessary to design around some problems, which you can't do if the stated goal is to tackle everything at once. So it follows that working on such projects is left to inexperienced and/or hopelessly deluded developers who clearly have no shot at making such omnipotent designs a reality. They carry on year after year, giving up on last year's browsers and redirecting their efforts to the latest in a never-ending quest to do the impossible. They are cheered on by have-nots (typically non-programmers or fellow greenhorns) who desperately want to develop cross-browser scripts, but require a magical solution to handle every conceivable cross-browser issue for them. Inevitably, with time and experience, rational developers realize that the "anti-library zealots" were right all along. > But engineering is like that: eventually someone gets it right. You don't seem to understand the basic concept, which is that the library authors are chasing an ill-advised and untenable goal. You can never get a wrong design right. :) And seeing as IE6 came out around the turn of the century, it is not 2010 and none of the "major" efforts (presumably with armies of developers behind them) haven't gotten close to getting that browser "right". Same for IE7. The inevitable "solution" is for them to throw in the towel (which many are now advocating). Doesn't that tell you something? Furthemore, the major browsers (the only ones these efforts seek to "fix") have been converging for years (recently and most dramatically illustrated by the preview of IE 9) further reducing the need for monolithic libraries to "smooth over" the ever-decreasing differences. As for widget frameworks, they are invariably built atop incompetently- written libraries, so can be dismissed out of hand. And as HTML5 creeps in to the picture, they will become increasingly less attractive (who needs a qooxdoo date picker if the browser has one built-in?) Predictably there are already "HTML5 frameworks" popping up, even before the recommendation is finalized. And predictably they are taking the usual approach of ignoring built-in degradation mechanisms (which they can't can and brand) in favor of dubious hacks (e.g. browser sniffing). > > One thing they got right is hiding HTML/CSS so a new generation of > developers need not mess with those. As you've been told repeatedly, "hiding" HTML/CSS means short- circuiting built-in browser behavior (e.g. layout) and then trying to rebuild it all with (single-threaded) scripts. That's obviously folly. One pervasive example is the "CSS reset" which wipes out default styles and then tries to build an "ideal" set that will be appropriate for every agent. That clearly makes no sense as default styles are chosen by browser developers to suit specific environments (e.g. desktop, phone, tablet). Another much-maligned practice is sizing everything with pixel units, which breaks accessibility. For example, the text zooming feature in IE breaks completely. The framework developers know this, but typically argue that the user should simply use the general zoom feature and stop getting in the way of their quest to control every aspect of the browser. Of course, zooming *everything* causes horizontal scroll bars, which futher impairs readability. In reality, they are simply trying to compensate for their ill-advised GP scripts which are predictably overwhelmed by the diversity of browsers. Then there is the antiquated notion that every document must look exactly the same in every browser (when in fact the goal should be to leverage each agent as best as possible without breaking accessibility). Also, qooxdoo does not have a monopoly on such ill-advised and overbearing strategies (see ExtJS, Cappuccino, etc.) The authors of these scripts just don't get it. Either that or they refuse to get it as that would get in the way of book sales. > ie, The library is not an > additional learning curve, it replaces several. It certainly is an additional learning curve and it (sort of) replaces many built-in and standard features that you could have gotten for free with dubious and ever-shifting scripts that cost dearly in terms of performance and usability. In short you are learning the wrong things. > > Until I see a widget set like qooxdoo's and other things like the > messaging mechanism and their databinding mechanism and their > sophisticated layout API in some raw HTML/CSS library, I'll be using > qooxdoo. The widgets are slow, bloated, over-engineered junk and nothing you are writing needs the overkill of messaging and data-binding mechanisms. As for the "sophisticated" layout API, it is demonstrably less sophisticated (and far less useful) than the built-in mechanisms it aspires to replace. And these pipe dreams come at a price that is prohibitive (as evidenced by your recent "train wreck" example). > > And I am an NIH kinda developer, preferring to roll my own rather than > sort through someone else's mess in the time I could develop my own. > In the time you've spent sorting through qooxdoo (with no end in sight), you could have learned how to leverge the browser's built-in layout engine, XHR, etc. to create your algebra application in something far less than 1MB. Also, unlike qooxdoo, those represent marketable skills. ;)
From: Kenneth Tilton on 19 Jul 2010 13:41
David Mark wrote: > On Jul 18, 6:53 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: >>> And these pipe dreams come at a price that is >>> prohibitive (as evidenced by your recent "train wreck" example). >> It's kinda sad when someone of your supposed intellect and expertise >> tries a cheap shot like that. A moment of silence for your self-respect. > > You are the one who labeled it a "train wreck", remember? I'm just > pointing out the irony that you seem to have been emboldened by the > experience. Yeah, I did, in reference to the ongoing development on my end. So it's a cheap shot to present that as qooxdoo being a problem, given that I was at the same time raving about qooxdoo (and linking to non-rave experiences with other JS libraries). I'll give you the benefit of the doubt that you lost that context. kt -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld |