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 16 Jun 2010 19:06 On Jun 16, 6:53 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 6/16/2010 2:35 PM, David Mark wrote: > > > On Jun 16, 2:34 pm, Joe Nine<j...(a)yahoo.com> wrote: > >> Does anyone have any links to very convincing articles that eloquently > >> state the major flaws of these libraries? I'm not considering using any > >> of them, I've heard enough here to know how bad they are. I just want a > >> few article links to keep in my back pocket that I can fire back when > >> someone suggests we use one of them. > > > I've reviewed salient bits of all three in the last six months or so. > > Search the archive. > > > In short, jQuery is terribly inept and unneeded, YUI is terribly > > botched and bloated and Dojo is just plain terrible. > > Pure opinion. Amnesia flaring up again? :) There's a tsunami of evidence and demonstration behind my statements (as you well know). As I said, search the archive. > Anybody can say that about anything. Example: Disco sucks. > The design of the Prius is terribly botched. The US Government is just > plain terrible. Easy, right? I've done all of the hard work. You yourself were just parroting some of it recently. > > A no-nonsense analysis demonstrating major shortcomings is not easy, but > would be valuable. It's been done to death (as you well know). > > The article should provide a concise summary of problems, elaborate on > that, with examples, link to any pertinent standards, and finally, > provide advice on what the reader should do instead of using that. That ship has sailed and long since reached its destination. [...] > > A couple of years back I did areview on Prototype.js:http://dhtmlkitchen.com/?category=/JavaScript/&date=2008/06/17/&entry... I thought that was where this was headed. Well, good for you then. But drop the laughable, indefensible stance against what I've done (which towers over your "achievements" in this area). > > In that review, I painfully showed how the library works. Sorry to hear it was painful. > Something as > complicated as that should be explained, so that it can be fully > appreciated. Yes. Again, done to death at this point. I mean, Prototype?! Could there be a less relevant example at this juncture? > > Prototype.js has mostly died out since then. Exactly. > > I would like to see such articles. All together: Search the archive. > I would, but I am busy with JSON > stuff and writing a test runner. Great. > I will be publishing an article next > week related to the W3C Selectors library, too. I don't have time for > another article. Okay. I think you are way late on that one as well. > > Dojo is nearly dead, so that one is low hanging fruit. Yes, I'd like to think I helped kill it. :) > jQuery and YUI > might be good subject matter for changing the industry. You can't stand it, can you? I've already changed the industry. Where were you? > > As a final emphasis, the article should emphasize what to do instead. We've been over that ad nauseam as well. > That is: How to analyze code quality and where to learn about web > scripting. > The article should not simply turn the reader away from a one > library, only to leave him directionless or jumping to another library > (as many ex-prototype.js users switched to jQuery). > Your hypothetical article pales in comparison to my somewhat legendary output in this area. Best of luck with it!
From: RobG on 16 Jun 2010 20:14 On Jun 17, 8:53 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > On Jun 16, 2:34 pm, Joe Nine<j...(a)yahoo.com> wrote: > >> Does anyone have any links to very convincing articles that eloquently > >> state the major flaws of these libraries? I'm not considering using any > >> of them, I've heard enough here to know how bad they are. I just want a > >> few article links to keep in my back pocket that I can fire back when > >> someone suggests we use one of them. [...] > The summary should be something that can be explained simply and should > be understandable by anyone. The exposition should elaborate on that. > > For example: > > Summary of library X: > * String methods slow > * method M doesn't work consistently in browsers > * silly and useless methods > > [elaboration of each point, with examples] > > [reasons the bugs can't be simply patched/design analysis] > > [alternative] > > [Conclusion recapping on problems an alternative.] A discussion of the library architecture and usage patterns with their pros and cons would also be helpful. > A couple of years back I did areview on Prototype.js:http://dhtmlkitchen.com/?category=/JavaScript/&date=2008/06/17/&entry... > > In that review, I painfully showed how the library works. Something as > complicated as that should be explained, so that it can be fully > appreciated. I'm sure it took quite a bit of time, it would be good to update it. There does not seem to be mention of the version reviewed (June 2008 => v 1.6.0.2?). The section $a toString gave me a bit of a revelation: browser detection based on the rendering engine ignores differences in the script engine. There are a number of browser families based on WebKit, there are two main script engines - Chrome, Maxthon and Android use V8 whereas KDE and Safari use SquirrelFish. There may be others. > Prototype.js has mostly died out since then. Would somebody please tell Apple that? Their main web site uses version 1.6.0.2 [...] > Dojo is nearly dead, so that one is low hanging fruit. jQuery and YUI > might be good subject matter for changing the industry. It should also look at massive frameworks like Qooxdoo, Cappuccino ("...an open source framework that makes it easy to build desktop- caliber applications that run in a web browser"[1]) and SproutCore ("... an HTML5 application framework for building responsive, desktop- caliber apps in any modern web browser..."[2]). 1. <URL: http://cappuccino.org/ > 2. <URL: http://www.sproutcore.com/what-is-sproutcore/ > > As a final emphasis, the article should emphasize what to do instead. Yes, such as: let the browser do as much work natively as possible, keep it simple and use scripting only where necessary to add value (i.e. the antithesis of Qooxdoo, Cappuccino and SproutCore which aim to completely replace the browser's UI). -- Rob
From: Thomas 'PointedEars' Lahn on 16 Jun 2010 20:25 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >> > On Jun 16, 2:34 pm, Joe Nine<j...(a)yahoo.com> wrote: >> >> Does anyone have any links to very convincing articles that eloquently >> >> state the major flaws of these libraries? I'm not considering using >> >> any of them, I've heard enough here to know how bad they are. I just >> >> want a few article links to keep in my back pocket that I can fire >> >> back when someone suggests we use one of them. >> > >> > I've reviewed salient bits of all three in the last six months or so. >> > Search the archive. >> > >> > In short, jQuery is terribly inept and unneeded, YUI is terribly >> > botched and bloated and Dojo is just plain terrible. >> Pure opinion. > > Amnesia flaring up again? :) > > There's a tsunami of evidence and demonstration behind my statements > (as you well know). As I said, search the archive. Search it yourself. I must agree that the problem with what is in "the archive" is that it is unstructured, not to the point, full of useless sentiments, and on top of it widely unreadable thanks to sloppy formatting (on your part, despite several requests to do better), if it is available at all (you know about Google Groups' search flaws, don't you?). It is unfortunately impractical to find the pearls in the mud that have been thrown. So much for amnesia. Therefore, I, too, would welcome an unbiased, unemotional, and theoretically sound peer review. In fact, not having observed it to date, I have been considering to try and write one myself when and if I find the time. Perhaps this is such consuming a task that it requires a step-by-step approach to be done properly. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Garrett Smith on 16 Jun 2010 20:43 On 6/16/2010 4:06 PM, David Mark wrote: > On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 6/16/2010 2:35 PM, David Mark wrote: >> >>> On Jun 16, 2:34 pm, Joe Nine<j...(a)yahoo.com> wrote: >>>> Does anyone have any links to very convincing articles that eloquently >>>> state the major flaws of these libraries? I'm not considering using any >>>> of them, I've heard enough here to know how bad they are. I just want a >>>> few article links to keep in my back pocket that I can fire back when >>>> someone suggests we use one of them. >> Of course, so when somebody -- a recruiter, for example, says, "what's wrong with the jQuery library?", you can say: - Poor selector engine - Non-descriptive method names - Hard to debug - long, overloaded methods with too much abstraction - Poorly degradable - loosely defined constructs and vague documentation - Low-quality plugins - Silly (and futile) things in source, like `isPlainObject` - Significant and numerous core upgrades that break functionality - plugins don't work - documentation doesn't reflect new behavior (modified list of gripes from a colleague). >>> I've reviewed salient bits of all three in the last six months or so. >>> Search the archive. >> >>> In short, jQuery is terribly inept and unneeded, YUI is terribly >>> botched and bloated and Dojo is just plain terrible. >> >> Pure opinion. > > Amnesia flaring up again? :) > > There's a tsunami of evidence and demonstration behind my statements > (as you well know). As I said, search the archive. > The OP asked for "links to very convincing articles". In your response, I see cynical opinion and no links. That's not even a concise summary of any one library. It sounds snide, actually. And no urls. >> Anybody can say that about anything. Example: Disco sucks. >> The design of the Prius is terribly botched. The US Government is just >> plain terrible. Easy, right? > > I've done all of the hard work. You yourself were just parroting some > of it recently. > That is untrue. I've have never wanted to copy anything of yours. >> >> A no-nonsense analysis demonstrating major shortcomings is not easy, but >> would be valuable. > > It's been done to death (as you well know). > URL? >> >> The article should provide a concise summary of problems, elaborate on >> that, with examples, link to any pertinent standards, and finally, >> provide advice on what the reader should do instead of using that. > > That ship has sailed and long since reached its destination. > If you are trying to say that an article was published then post a URL so the OP can see it. [...] >> Something as >> complicated as that should be explained, so that it can be fully >> appreciated. > > Yes. Again, done to death at this point. I mean, Prototype?! Could > there be a less relevant example at this juncture? > One point to be gleaned from that is what sort of change it can affect. A subtler point is that the mistake I made was not emphasizing enough about what to do instead. Look how many switched to jQuery. The review also shows an example outline of how to do a review. It starts at a very high level with technical *facts*. | A code review should be objective and should state actual problems. | Saying "the code is bad" is not a helpful review. Instead, explain | the problem clearly. If the problem is severe, then say why. <http://jibbering.com/faq/notes/review/> I've emphasized these points many times regarding your reviews and I've noticed improvement, but I think it can still get better. People will respect you if you follow that. >> >> Prototype.js has mostly died out since then. > > Exactly. > And even a Prototype core developer criticizing Prototype: http://perfectionkills.com/whats-wrong-with-extending-the-dom/ Now more and more are flocking to jQuery. Great. Well, not really. [...] > >> I will be publishing an article next >> week related to the W3C Selectors library, too. I don't have time for >> another article. > > Okay. I think you are way late on that one as well. > Opinions are funny things. Everybody's got one. My observations are that many developers are unaware of how selectors work. I've notice that some foster beliefs that the jQuery "bare words" proprietary selector syntax is designed to work match attributes instead of properties. In contrast, the source code of jQuery indicates that it was designed to select properties. Further evidence indicates that there may be uncertainty as to whether or not the jQuery author(s) know what it was designed to do or knew that it was invalid CSS selector syntax. The documentation says it selects attributes, the website says it is css3 compliant. Blog entries seem to be vague and contradictory. My observation is that developers are confused as to how selectors really work. > > Your hypothetical article pales in comparison to my somewhat legendary > output in this area. Best of luck with it! Then post a link to what you feel are your best ones. Let them speak for themselves and quit boasting about them. Look: <http://www.google.com/search?q=jquery+%22code+review%22> I don't see any jQuery code reviews. Chances are, the OP doesn't either. I've found: http://www.doxdesk.com/#u20091116-jquery - which is funny, but not a serious code review (the author is knowledgeable and provides humorous insight. He seems to not take jQuery seriously). My opinion is that jQuery is taken seriously by so many that it cannot be just laughed off and it cannot be just called garbage. In order to effect a change, one must take it head on in a more formal code review. Talk to the reader as if he's right in front of you; don't insult his intelligence and don't assume he understands everything you do. Be concise. Make it understandable at a high level to anyone. Try to see it from the perspective of the user who llikes it. Try to see it from the perspective of the author who wrote it and is now stuck with design decisions -- what can he do? Are they fixable? If so, how? If not, why not? Parsing selectors - sounds neat, right? Well, the problems with that are... [brief introduction] [summary overview of problems] [exposition and demonstration of each problem] [elaboration on design issues] [alternative] [conclusion] Writing something like that is not going to be easy; not something that can be completed in under a week. A link to such formal review of jQuery would be useful and valuable. My prototypejs review was painful, not because I had to go and find problems, but because I had to communicate them effectively to readers who liked Prototype.js. Garrett
From: Garrett Smith on 16 Jun 2010 20:52
On 6/16/2010 5:14 PM, RobG wrote: > On Jun 17, 8:53 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> >>> On Jun 16, 2:34 pm, Joe Nine<j...(a)yahoo.com> wrote: >>>> Does anyone have any links to very convincing articles that eloquently >>>> state the major flaws of these libraries? I'm not considering using any >>>> of them, I've heard enough here to know how bad they are. I just want a >>>> few article links to keep in my back pocket that I can fire back when >>>> someone suggests we use one of them. > [...] >> The summary should be something that can be explained simply and should >> be understandable by anyone. The exposition should elaborate on that. >> >> For example: >> >> Summary of library X: >> * String methods slow >> * method M doesn't work consistently in browsers >> * silly and useless methods >> >> [elaboration of each point, with examples] >> >> [reasons the bugs can't be simply patched/design analysis] >> >> [alternative] >> >> [Conclusion recapping on problems an alternative.] > > A discussion of the library architecture and usage patterns with their > pros and cons would also be helpful. > > [...] > Yes, such as: let the browser do as much work natively as possible, > keep it simple and use scripting only where necessary to add value > (i.e. the antithesis of Qooxdoo, Cappuccino and SproutCore which aim > to completely replace the browser's UI). Good advice. However, it touches on a core antipattern of Quooxdoo, Cappuccino and SproutCore. It's not a new technique. It would be good for the article to do one of 1) focus entirely on one library 2) focus or a problem that is solved and show how libraries solve it, with examples from the library, and then show an alternative. 3) focus on an antipattern I'm going to publish an article next week, after it has been reviewed and edited (the draft is being reviewed now). The article will cover some things here, but it is not a formal review, as I have outlined. I'd really like to see that, and if it is a good one, probably even more than the article I'm working on. Garrett |