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: Gregor Kofler on 15 Jul 2010 12:21 Am 2010-07-15 16:17, Stefan Weiss meinte: > One more thing. I am a JS developer (among other things), and I am able > to create these things if I want to. Other people, including many web > designers and amateur bloggers, webmasters, etc, don't have that > experience. They can either use the best existing script they can find, ....or leave it to someone experienced in those things. -- http://www.gregorkofler.com
From: Garrett Smith on 15 Jul 2010 14:59 On 2010-07-15 07:31 AM, Thomas Allen wrote: > I see really no discussion of the (de)merits of MooTools in this > topic, a library that I have found to be very useful over the years. I It is generally a very good idea to review the source code for any third party javascript library. With the dynamic nature of javascript the dynamic nature of the web, and web browsers, a script may have problems that are not immediately apparent. It may have errors but they not necessarily be seen either immediately or ever. > see attribute getter/setter methods consistently criticized, and for > good reason in that they typically offer little. I think that > MooTools' implementation of "get" and "set" for Element is otherwise > in that it is intended to allow for an intermediary layer of element > data "storage," although in my own code that use case is infrequent. > Discussions of problems of MooTools have included problems such as: * unrelated inferences / browser sniffing, including using nonstandard Gecko-only etBoxObjectFor (which they deprecated) * modification DOM prototypes and other host objects; use of expandos * needless interdependency/tight coupling * The dollar function (meaningless) Some of these things were discussed in "MooTools: An Objective Look". See also: [1] <http://jibbering.com/faq/notes/detect-browser/> [2] <http://perfectionkills.com/whats-wrong-with-extending-the-dom/> -- Garrett
From: Scott Sauyet on 15 Jul 2010 17:21 David Mark wrote: > Scott Sauyet wrote: >> "S.T." wrote: >>> [in response to Matt Kruse] >>> You are in a small subset of developers that use jQuery by choice, yet >>> are also highly critical of it. In fact you might be the only person >>> I've read that shares those characteristics. Not that there's anything >>> wrong with that, just a somewhat unique view. > >> You can put me in that category as well. > > The category of those who abdicate responsibility for cross-browser > scripting to the jQuery authors (of all people), despite being told > repeatedly of their collective incompetence? No, you must have misread. I was discussing the category of people who use their clients' and employers' resources wisely, using tools that work well for the environments those clients care about, people who understand enough about browser-scripting to do the work themselves but choose to use a library that substantially speeds up certain parts of the job, people who make up their own minds about the competence of their tools and the authors of those tools. >> I find that JQuery often >> simplifies my development, but I recognize many flaws in it and would >> love to see something more solid come along to take it's place. > > It only allow creates the illusion of simplifying your development. > Odd that you can't see that after all of the related discussions. No. In fact, it does simplify my development. Odd that you think you can see over my shoulders from way back there. Are you really as arrogant as you come across? > And why do you need something to take its place? It's a 70K QSA > wrapper. As we've been over repeatedly, CSS selector queries are > highly ill-advised and there aren't many "supported" browsers left > that lack QSA anyway. What's left to replace? A ham-fisted API that > is completely inappropriate for browser scripting? As we've been over repeatedly, CSS-selectors are often the very best tools for the job. And I know that you've read enough of jQuery's source to realize that the selectors engine is probably 15% - 20% of the total. >> But >> those need to be libraries that I would feel comfortable handing off >> to a client to continue with, which leaves out, for instance, My >> Library. > > That makes no sense at all. You'd feel comfortable handing off a > script that you know is full of holes? No. I am willing to hand off code that I know is not perfect, if I can comfortably describe its limitations and flaws, and if it works reliably. What I'm not comfortable doing is handing off code that I think the client cannot fix themselves or for which they cannot find simple help fixing. I'm afraid right now that any clients I have who do not have the expertise to fix things themselves would not get helpful responses from the minimal community around My Library. > And unlike jQuery, the code in > My Library is relatively easy to follow. So what's your point? If > the client Googles the name they won't find tons of gushing blog posts > and bad examples? No, that doesn't bother me much. Frankly, it's you and the attitude you display here that prevents me from even considering suggesting My Library to any clients. >> At the moment, JQuery seems the best of a fairly bad bunch. > > And what seems to indicate that? Like the rest, it calls QSA (with > very little in the way of feature testing) and hands off to a proven > mess of unfinished nonsense in the event of an error. > > http://www.cinsoft.net/slickspeed.html > > But, of course, you've already seen that. IIRC, your position was > that the demonstrably execrable results were somehow my fault for > "trying to break it". :( I'm afraid you don't recall correctly. My position was simply that you were misusing the speed test as a conformance test, misrepresenting the other libraries thoroughly in the process. >> But I really don't want to skip a library altogether. > > Why? Cross-browser scripting is relatively easy these days, making > jQuery and the like antiquated notions. By far, they create more > problems than they solve. They haven't for me or my clients. >> Yes, I trust my own >> skills enough to believe I could do everything that's done in those >> libraries, but I really don't want to spend the time. > > And therein lies the problem. If you would stop and think about it, > you would realize that you don't need most of what is in those > libraries, not to mention the fact that those libraries have failed > miserably (over the course several years) at their shared goal. They > are selling both problems and (very bad) solutions. Using them over > and over leaves you with no solutions of your own, which is your own > fault. I've written table-striping code for when I can't add the "odd" classes on the server. I've written several different version of such code. It's not at all difficult to write. But including that code in my build and adding whatever calls are needed to apply it is more difficult than doing this: $("#myTable tbody tr:odd").addClass("odd"); Moreover if I decide I want to apply it to a certain class of tables instead, I don't need to ensure that I can collect them by class name and then run a loop over the bunch. I can do this instead: $("table.zebra tbody tr:odd").addClass("odd"); I don't have to want to use all the code that jQuery supplies, just enough of it that it's worth my time dealing with its flaws. >> And I don't think it's *that* bad. > > Software either works or it doesn't. Software either meets your needs or it doesn't. Doesn't it annoy you when posters come here complaining just that their script "doesn't work?" We need to know what they expect before we can tell for ourselves that it doesn't work. The same holds true for libraries. What I expect out of them is clearly something less than what you expect. So you shouldn't use them, clearly. But your evangelizing against them has really not convinced me that these libraries are inherently flawed. > Software authors have talent or they don't. Do you think Donald Knuth never wrote any bad code? Was Edsger Dijkstra's code so perfect that no one would ever find a flaw in it? Talent is only part of the story. It's important, but there is more to well-built software, especially software built by a community. > Some apologists like to point to Windows as a product > that is not "that bad", but still pervasive. Of course, the > difference between a completely transparent 70K script and an OS > should be apparent. It seems apparent to me, but in a manner that belies the rest of your argument. Which do you think you should trust more, a reasonably small script that you can understand in detail with some concentrated effort, whose flaws you can detail for yourself efficiently -- or a 50+-million lines-of-code behemoth that you can only treat as a black box? > What has jQuery done for you, other than leave you short of time and > code and therefore perpetually dependent on it? I think it might do that for script kiddies. But for competent developers, it's just a collection of short-cuts for things they could do themselves if they really wanted to. I do a lot of work in Java. And years ago I wrote logging systems to fit my needs. They were better adapted to exactly what we wanted to do than any general-purpose logging library ever could be. But I would probably never write one again, because the general-purpose libraries have gotten so useful, and they work well-enough for my needs, and they come without several weeks worth of development. > [too much more for me to respond to right now.] -- Scott
From: Richard Cornford on 16 Jul 2010 10:40 Stefan Weiss wrote: > On 15/07/10 15:23, Richard Cornford wrote: >> On Jul 15, 1:43 pm, Stefan Weiss wrote: >>> No, it really did simplify the development, and it saved me >>> a day of work. Here's the case story: a relatively simple >>> website which didn't use a lot of JavaScript ... Lightbox >>> clones out there. The best clone I found was a jQuery plugin. >>> I gave it a shot and it worked very well. It may have all the >>> drawbacks that jQuery brings with it, but in this case, I >>> didn't care anymore. They wanted Lightbox, I gave them Slimbox2, >>> and didn't look back. >>> >>> I'm not a fan of jQuery by any means, and I know its weak points >>> well enough. In this case, however, it did save me a lot of work. >> <snip> >> >> Doesn't that story boil down to 'JQuery allowed me to take the >> money and run'? > > I suppose you could see it that way, Particularly as I tend towards the cynical. > if you assume the jQuery + Slimbox combination is going to cause > trouble in the future, but Prototype.js + script.aculo.us + > Lightbox (the customer's original request) would be > stable. The 'if' supposes that those were the only two alternatives. > From my point of view, this replacement was already a (minor) > improvement I was not obligated to do. > > In other circumstances, I would probably have bitten the bullet > and created a Lightbox replacement myself. In this particular > case, they'd already got 4 times the work they should have for > my fixed fee (which they still haven't paid, by the way). Sometimes there are client who get what they deserve. Unfortunately there are also clients who do not deserve what they get. > As a > result, leaving them with jQuery doesn't pose a big moral problem > for me. You can't expect me to add an additional day of work in > this environment, just to save them the trouble of uploading a > new jQuery version every couple of years. The "trouble" isn't just uploading a new JQuery version every couple of years, it is uploading a new JQuery version and then doing a full regression test of the functionality of the whole site, and then fixing anything that may have been broken by non-back-compatible changes in JQuery (and that may not be necessary every couple of years, but instead following a first update rapidly followed three or four similar cycles as bugfix releases rapidly follow a major version release (based on previous releases)). Of course formal (or even effective) QA/regression testing is nearly unheard of in general web development so its implied expense is avoided, and in return the expense is experienced in the negative impact of non fully functional websites going unnoticed for indeterminate periods of time and not achieving whatever they were intended to achieve during that time. > I did hesitate, and I did look for alternatives for over an > hour. The next time I have to make this decision, hopefully > with a fairer contract, I might go ahead and create a > stand-alone Lightbox clone. The ones I've seen were much, > much worse than the jQuery one. > > One more thing. I am a JS developer (among other things), and I > am able to create these things if I want to. Other people, > including many web designers Does "web designers" mean (effectively) graphical designers working on/producing websites? (as distinct from 'web developers' responsible for code/application architecture design, UI interaction design, database design (in relation to websites), server configuration design, and so on.) > and amateur bloggers, webmasters, etc, don't have that > experience. No, they (mostly) do not. That is not an unexpected situation as realistically most people do not have experience in most (more than slightly) specialised things. Generally that is not a problem as (effectively) we sell our own specialised experience in order to purchase the experience (or products of the experience) we need/want of others. And faced with a lack of experience/knowledge in an area most people are happier (and probably better off) purchasing that experience than trying to do it themselves. Almost nobody, for example, would contemplate making their own china, even though it would not be at all physically difficult to do so (at least using available fabrication techniques that do not include throwing posts on a potter's wheel). One of the things that is gained with experience is an understanding of consequences. An inexperienced individual setting about making their own china (from the previous example) may not appreciate the harmful/toxic characteristics of the materials they would be working with. The toxic characteristics of lead were first identified early in the (British) industrial revolution when a study into why some Staffordshire pottery workers were dying unusually early (at a time when life expectancy was already relatively short) found a direct correlation with those workers handling (inhaling/ingesting) while lead powder. Ironically, when the lead handling had been improved to reduce the associated risks those workers only gained an extra couple of years of life before they died from the Silicosis caused by years of inhaling clay dust (thus revealing the second hazard in the pottery industry). The colorants used in pottery (especially the brighter, low temperature, colors) tend to be more or less toxic metals (e.g. Cobalt, Cadmium) (Uranium was used to produce a bright yellow during the early part of the 20th Century, but that been banned for obvious reasons). There are questions of appropriateness; a lead based low temperature (900-1100 degrees centigrade is low in pottery terms) glaze colored with Cadmium is acceptable on a decorative vase, but on the inside of a dish used for cooking in an oven it becomes a health hazard. Then there are the technical considerations, such as glaze "fit" where the relative expansion/contraction with temperature of the clay body and the glaze are calculated (and the glaze composition designed). Structural strength is improved if the glaze has a slight compressing effect on the clay it surrounds, but too much and the glaze will craze. Reverse the 'fit' and the resulting pot will be structurally week, and taken too far the glaze can crack the underlying clay leading to an sudden extreme failure. Obviously this has more significance in the context of cooking vessels than decorative or tableware, as they will experience more extreme/frequent fluctuations in temperature throughout their lives. So the inexperienced can easily make their own china, but they risk doing significant harm to themselves in the process, and could create something that is hazardous to use and unacceptably short lived. There is much to be said for understanding the consequences of actions, particularly in terms of avoiding the bad ones. > They can either use the best existing script they can find, > or do without the functionality of Lightbox & co. I have no > problem whatsoever when these people are using jQuery and > its plugins. It enables them to do things they otherwise > couldn't. The moral dilemma I was facing does not apply to > them. A different moral dilemma might apply to them. Granted, if you are talking about a complete armature doing what they like to please themselves then any consequences (good or bad) fall only on them. But as soon as someone is acting in the role of 'client' is involved the consequences of design decisions are no longer local. Yet without the experience that would have informed the 'designer' about what consequences were likely to follow from particular design decisions no anticipation can be exercised, and negative consequences cannot be avoided. Which doesn't mean that there necessarily will be negative consequences, everything may be just fine, but the point is that the inexperienced designer will not know one way or the other. It is the professional's responsibility (even duty) to know. It is for their knowledge and experience that clients hire them. In allowing the inexperienced to achieve things they could not otherwise (which they demonstrably do) things like JQuery (not to single out JQuery as any 'copy-n-paste' script 'collection' can have exactly the same effect) also allow inexperienced individuals to put themselves across as having the professional knowledge and experience that clients/employers are looking for, and to a large extend get away with it. There is dubious morality in this latter possibility. Now it could be argued that 'getting away with it' is enough; that in many cases the real professional in the same circumstances would do no more than get the same widget to work the same way on the same page. And judging only by results that may often be the case. However, what the experience of the real professional brings is the overview of the bigger picture; the perception of permutations, the consideration of alternatives, the anticipation of consequences (and the rest of a very long list). Even when what ends up being done is identical there is a huge defence in why it is being done; in one case because it is the right thing to do (based on informed judgment) and in the other because it is the only thing that can be done. (And, of course, 'getting away with it' can be a short term thing in the cases where the real professional would have done something else.) Reading this group for any extended period reveals a parade of design decisions made in ignorance having negative consequences. One humorous story (from around 2004) is of an individual who come here looking for help on something or another in relation to a site he had created that was heavily dependent on opening pop-up browser windows. He was asked about the wisdom of this design, and particularly about how it would get along with the (exponentially increasing, at the time) use of pop-up blockers. His response was that pop-up blocking could not be an issue for the site because it had a 'feedback' form and that zero feedback had been received relating to non-functional pop-ups. But then closer examination revealed that this 'feedback' form opened in a pop-up window, designing away the possibility of ever receiving feedback form a user with a pop-up blocker running. The designer's inability to anticipate pop-up blocking (pretty much a pre-requisite for designing a site that depends on pop-ups) effectively generated its own self-reinforcing feedback; the absence of complaints justified the design, while the design prevented the recite of those complaints. The result would have been a site that was effetely unusable for an increasing proportioning of its visitors, with whatever consequences for the site's owners that could be expected to have (the site would be becoming less effective and doing whatever it had been created to do). Just yesterday I encountered what was probably another example of this on a site that I use fairly frequently. It was my first visit to the site since its UI had been redesigned (and AJAXed) and as I logged out I noticed IE 8 show that strip at the top that announces that it has blocked a pop-up. Ah, I thought, that is going to be survey about what I think of the new UI, and as I wanted to tell them that they had rendered it significantly slower, more clunky and expended the number of clicks between me and what I actually wanted to do (figuring that they would only have tested it locally and be under the impression that they had somehow improved the site with AJAX), I used the 'allow the pop-up' option. IE then re-loads the page in its 'pop-ups allowed' state, but of course, being AJAXed, the site has lost its context and no longer thinks it is my first visit to the new UI, and so no longer wants to show me the survey pop-up. A cynic might think that the designers of the new AJAXed UI had done that deliberately in order to avoid the survey generating negative feedback, but, on the principle that you should never attribute to malice anything that can be explanted by ignorance, I concluded that web developers responsible where too inexperienced to have taken into account the (default) behaviour of IE 8 with regard to pop-ups. Kenneth Tilton recently demonstrated a similar inexperience based short-sightedness in his 'this site is a train wreck' warring; where everything on the screen is put there by javascript, including the warring that things may not work correctly, then when the javascript doesn't work correctly the odds are pretty good that the warning will not be shown. The path of the reasoning is obvious, but you have to be a little more experienced in the field in order to take the first step. Richard.
From: Kenneth Tilton on 16 Jul 2010 13:03
Richard Cornford wrote: > Kenneth Tilton recently demonstrated a similar inexperience based > short-sightedness in his 'this site is a train wreck' warring; where > everything on the screen is put there by javascript, including the > warring that things may not work correctly, then when the javascript > doesn't work correctly the odds are pretty good that the warning will > not be shown. The path of the reasoning is obvious, but you have to be a > little more experienced in the field in order to take the first step. Yeah, I am really worried about people who have JS turned off during this stage of development when I am just running the site to keep my morale up and sharing with programmers who might be interested in driving qooxdoo from lisp. Not. Hell, I am not even worried about the template Algebra hints sometimes failing to locate the operands they try to lift from the problem at hand, so the hints can be that much easier to connect with the problem. That comes soon, tho, because my port of a full-blown desktop app to the Web (http://teamalgebra.com/) is going so well (thanks to qooxdoo: http://qooxdoo.org/) that in a week or two I will want to share it with normal people vs Lisp/javascript geeks. Speaking of which, any lisp/js geek who gets curious about my lisp/qooxdoo library and checks it out without having javascript turned on -- um, I think I'm OK with the probable outcome. As for this group bravely standing up for clients in the face of scurrilous thieving lying consultants who rip themm off by using a JS library, um, I /am/ the client. When I do have clients they ask me to check out different libraries they themselves have come across, and one explicitly encouraged me to use a /big/ library like Dojo instead of a small one like jQuery so I would not be re-inventing the wheel. Tilton's Law: Solve the right problem. In this case, if the problem is that a JS library has a bug, the solution is to fix the bug, not burn the library and have every programmer who wants to put up a web page spend five years learning HTML and CSS and browser variability. That's actually rather obvious, so it's fun seeing the alpha males around this NG forever arguing against it. Using a little FUD to keep those billing rates up, are we? Best of luck, these are tough times. kt > > Richard. -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld |