My Library _passes_ TaskSpeed in IE < 7
in [JavaScript]
|
Prev: A good opportunity to investment
Next: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
From: David Mark on 24 Feb 2010 00:13 David Mark wrote: > Matt Kruse wrote: >> On Feb 23, 5:03 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>> Every time I point out one of >>> jQuery's many flaws, you claim it isn't something you care about. >> Not quite, but it would be fair if I did. > > You don't care that a query-based DOM scripting library can't query > straight? Then I guess you don't care about cross-browser (or even > cross-IE!) consistency. That's an odd stance. > >> It's similar to you pointing out that my car will blow up if I push it >> to 120mph on a Sunday during a full moon. That's interesting, but if I >> know that I will never do that, then it's not a convincing argument >> for me to stop driving it. > > Another ridiculous comparison. When very basic queries fail to achieve > consistent results, even in the very latest browsers, it's time to admit > defeat (though it is clear you never will). > >>> Did you care about ActiveX being disabled in corporate environments >>> before I pointed out that jQuery would unceremoniously blow up in such >>> cases >> No > > But anyone aspiring to publish documents to the _Web_ better care about it. > >>> or were you oblivious like the jQuery developers? Yeah, they >>> eventually fixed it (after I beat them over the head with it for >>> _years_) >> Actually, I politely pointed it out to them and it was fixed the same >> day. I got results, you didn't. > > No, you would never have even _known_ about it if I hadn't pointed it > out over and over as a ridiculous oversight. Cause and effect. > >>> That's ridiculous. If you can't measure an element's dimensions or read >>> its attributes with any reasonable reliability, you can't possibly have >>> a firm DOM scripting foundation. >> You read like a wikipedia article on logical fallacies. > > And how do such articles read? You really are king of inappropriate > (and often incomprehensible) similes. > >>> That's also ridiculous. I've had far more impact on your "real world" >>> than you care to admit. Who is it that keeps getting things fixed in >>> jQuery (for example?) Sure as hell not you. In fact, you have tried to >>> parrot my ideas to jQuery from time to time and are usually shouted >>> down. We've seen it over and over, so why continue to delude yourself? >> jQuery forum archives surely point to the opposite. > > You say that assuming I won't bother to post links to your futile > attempts to communicate my ideas (the selected option "issue" in Webkit > comes to mind). And how about that 100+ post thread about attr? That > went nowhere (and it was a full two years after I first raised the issue > with Resig). They are clearly not capable of writing a cross-browser > script and you are clearly ineffectual at enlightening them. Perhaps > you are too polite to be effective? Personally, I wouldn't bother with > them at this point. > >> You know what would be interesting, DM? > > Gee, what MK? > >> If you wrote up a convincing >> article detailing the reasons why a developer should use My Library >> instead of jQuery, and the process by which they should do so. > > Why would that interest you? You should know the basic reasons by now. > >> You >> could target it at business web app developers, for example. Be sure >> to cover all the factors that would matter to such a user of jQuery, >> not just technical points about attributes and dimensions. That >> writeup might actually be useful. > > It's been done to death (sans any mention of My Library). And I grow > weary of you dismissing attribute issues as attributes are the basic > building blocks of elements, which add up to documents, which are then > queried (often by attributes). How you can ignore the fact that you > can't get/set dimensions of elements (or documents or windows) > consistently with this magic 70K+ blob of JS is also beyond belief. > What does it do right again? > >> Do I expect you to actually do anything like that? Umm, no. Of course >> not. > > You should have all of the information you need at this point. And what > sort of a disingenuous crank would say something like that after I > published a 10000+ example (in part due to their incessant badgering) > and enough reasons to switch to it to choke a newsgroup. :) 10000+ lines in one example, not 10000+ examples. :)
From: Andrew Poulos on 24 Feb 2010 00:24 On 24/02/2010 3:35 PM, Matt Kruse wrote: > On Feb 23, 5:03 pm, David Mark<dmark.cins...(a)gmail.com> wrote: >> Every time I point out one of >> jQuery's many flaws, you claim it isn't something you care about. > > Not quite, but it would be fair if I did. > > It's similar to you pointing out that my car will blow up if I push it > to 120mph on a Sunday during a full moon. That's interesting, but if I > know that I will never do that, then it's not a convincing argument > for me to stop driving it. How do you know? That is, you can't know you'll *never* drive over 120mph. And would you be happy if you knew the public were driving cars with such a fatal flaw? >> Did you care about ActiveX being disabled in corporate environments >> before I pointed out that jQuery would unceremoniously blow up in such >> cases > > No > >> or were you oblivious like the jQuery developers? Yeah, they >> eventually fixed it (after I beat them over the head with it for >> _years_) > > Actually, I politely pointed it out to them and it was fixed the same > day. I got results, you didn't. You have to give them feedback on their terms or else they don't accept it? If I matter-of-factly pointed out a bug would they ignore it/me??? >> That's ridiculous. If you can't measure an element's dimensions or read >> its attributes with any reasonable reliability, you can't possibly have >> a firm DOM scripting foundation. > > You read like a wikipedia article on logical fallacies. Still the logic seem robust whereas yours seems lacking. >> That's also ridiculous. I've had far more impact on your "real world" >> than you care to admit. Who is it that keeps getting things fixed in >> jQuery (for example?) Sure as hell not you. In fact, you have tried to >> parrot my ideas to jQuery from time to time and are usually shouted >> down. We've seen it over and over, so why continue to delude yourself? > > jQuery forum archives surely point to the opposite. > > You know what would be interesting, DM? If you wrote up a convincing > article detailing the reasons why a developer should use My Library > instead of jQuery, and the process by which they should do so. You > could target it at business web app developers, for example. Be sure > to cover all the factors that would matter to such a user of jQuery, > not just technical points about attributes and dimensions. That > writeup might actually be useful. > > Do I expect you to actually do anything like that? Umm, no. Of course > not. And if a convincing article were written would you simply ignore it? Andrew Poulos
From: David Mark on 24 Feb 2010 00:50 Andrew Poulos wrote: > On 24/02/2010 3:35 PM, Matt Kruse wrote: >> On Feb 23, 5:03 pm, David Mark<dmark.cins...(a)gmail.com> wrote: >>> Every time I point out one of >>> jQuery's many flaws, you claim it isn't something you care about. >> >> Not quite, but it would be fair if I did. >> >> It's similar to you pointing out that my car will blow up if I push it >> to 120mph on a Sunday during a full moon. That's interesting, but if I >> know that I will never do that, then it's not a convincing argument >> for me to stop driving it. > > How do you know? That is, you can't know you'll *never* drive over > 120mph. And would you be happy if you knew the public were driving cars > with such a fatal flaw? Yeah, not to mention that his comparison is way off. > >>> Did you care about ActiveX being disabled in corporate environments >>> before I pointed out that jQuery would unceremoniously blow up in such >>> cases >> >> No >> >>> or were you oblivious like the jQuery developers? Yeah, they >>> eventually fixed it (after I beat them over the head with it for >>> _years_) >> >> Actually, I politely pointed it out to them and it was fixed the same >> day. I got results, you didn't. > > You have to give them feedback on their terms or else they don't accept > it? If I matter-of-factly pointed out a bug would they ignore it/me??? Probably. More like they would rubber stamp it with "would you be willing to file a ticket on that?" They are very bitchy about bug reports as they seem to see most of them as nit-picking their "robust" library and tarnishing their "genius" credentials. > >>> That's ridiculous. If you can't measure an element's dimensions or read >>> its attributes with any reasonable reliability, you can't possibly have >>> a firm DOM scripting foundation. >> >> You read like a wikipedia article on logical fallacies. > > Still the logic seem robust whereas yours seems lacking. Lacking is putting it mildly. I'd say virtually non-existent. :) > >>> That's also ridiculous. I've had far more impact on your "real world" >>> than you care to admit. Who is it that keeps getting things fixed in >>> jQuery (for example?) Sure as hell not you. In fact, you have tried to >>> parrot my ideas to jQuery from time to time and are usually shouted >>> down. We've seen it over and over, so why continue to delude yourself? >> >> jQuery forum archives surely point to the opposite. >> >> You know what would be interesting, DM? If you wrote up a convincing >> article detailing the reasons why a developer should use My Library >> instead of jQuery, and the process by which they should do so. You >> could target it at business web app developers, for example. Be sure >> to cover all the factors that would matter to such a user of jQuery, >> not just technical points about attributes and dimensions. That >> writeup might actually be useful. >> >> Do I expect you to actually do anything like that? Umm, no. Of course >> not. > > And if a convincing article were written would you simply ignore it? If his pattern of behavior holds...
From: Garrett Smith on 24 Feb 2010 01:03 Matt Kruse wrote: > On Feb 23, 6:33 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> What it means for something to work is that that thing fulfills a >> contract of functioning in the way it has been specified to function. > > Very little - if any - software "fulfills a contract of functioning" > 100% of the time, without problems. I use many pieces of software > every day that surely have countless unresolved bugs. Yet they still > provide much value to me. I'd say they "work" as long as those > problems do not cause a problem for me, despite their existence. > Me too. Internet Explorer, for example, I use for testing. Internet Explorer a major, popular web browser. It is more popular than any other browser out there. Internet Explorer works for millions of other users. Internet Explorer has a long, troubled history of not fulfilling the contract to follow web standards. Microsoft has simultaneously stated that they are committed to supporting standards while showing the opposite (words and actions don't match). For example, take "Internet Explorer 6 and Standards" http://msdn.microsoft.com/en-us/library/bb263979%28VS.85%29.aspx | Microsoft believes very strongly in Internet standards and the | standards process, and is committed to implementing appropriate | standards when driven by customer demand. However, standards | compliance is part of a larger effort that includes many | constituencies. By innovating, and driving customer requirements into | Internet Explorer and then into the standards groups, we'll make the | Internet a richer platform for all users. Which goes to great length to communicate to the reader that they are committed, but they concluding with weasel words about a "larger effort" (the "big picture" as some might call it). Is Internet Explorer 6 slow and bugyy? Yes. It was slow and buggy and did not support many standards and failed to meet the expectations for many developers (including an angry me) on its date of release. Are better alternatives available? Provided a definition of "better" includes mention of things like security, support of standards, performance, frequency of bug fixes (or time to fix a bug), then yes, better alternatives exist. > In that vain, jQuery "works" because it does not cause a problem for > most users, despite its flaws. It works. Perfectly? No. But it works. > The problem is not jQuery, but the actual thing that the customer has presented. jQuery not causing errors on a page that it is included on is not very much to ask, and if it failed to do that, then it would be considered horribly broken (did this happen in 1.3 release?) Do we have an example of problem applicaiton comparing solutions giving a solution using jQuery versus one that uses something else? We have discussions of solution comparisons that here on this NG on a daily basis, but not one of an entire application or "the big picture". Sometimes, in those discussion of solutions, jQuery comes up. When that happens, when was jquery shown to be comparitively good in terms of speed/efficiency, readability, or reliance on stable abstractions? If the reasoning is: "I used jQuery" and "it worked", and therefore "jquery works", then there may be disjunction error between cause and effect on the part of the person claiming "works". If the outcome of using jQuery is that "it works", then the outcome of what jQuery did to enable that outcome needs to be looked at. If the outcome complies with web standards CSS, HTML, EcmaScript, and a11y standards like 508 or WCAG and does not violate good OOP and API design conventions and patterns, and the use of jQuery enabled code that was cleaner, clearer, and more efficient than otherwise would been possible, then it could be said to work well. If, however, the outcome is your typical web 2.0 site, full of errors, not cross browser, doesn't work with JS disabled, uses `javascript:` psuedo-protocol, uses tight coupling API strategies and falls apart at the slightest change requirement, uses browser detection, then "works" needs a new definition. For example "works" could be defined as: JQuery works to help the developer get a job and earn some money by producing average web sites. In that sense, anything that itself does not produce errors or crashes can be said to work and thing doesn't have to be jQuery. > The idealistic, unachievable goal of software development is bug-free > perfection. No piece of software - including jQuery - should be judged > by that measure. Instead, you have to look at the big picture and many > factors, of which technical robustness if just one. > What other factors and how does each rank in the big picture? Surely you cannot mean API design. What factors in, as you see it? Ubiquity? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Matt Kruse on 24 Feb 2010 09:43
On Feb 23, 11:24 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: > On 24/02/2010 3:35 PM, Matt Kruse wrote: > > It's similar to you pointing out that my car will blow up if I push it > > to 120mph on a Sunday during a full moon. That's interesting, but if I > > know that I will never do that, then it's not a convincing argument > > for me to stop driving it. > How do you know? That is, you can't know you'll *never* drive over > 120mph. And would you be happy if you knew the public were driving cars > with such a fatal flaw? The example was used to demonstrate the premise: Just because something has a flaw in one situation does not invalidate its use in _all_ situations. This is to counter David's premise, which apparently is: If a product has significant flaws in one area, then it should never be used. Clearly, his logic does not hold true for many other situations or even software products. So I agree with his assertion that there are flaws in jQuery. That's obvious. What I do not agree with is drawing the conclusion that therefore jQuery should never be used by anyone in any situation. It does not follow. If he were to apply this reasoning (or lack thereof) to other software, he would find that he could use no software at all. Even his own. > > Actually, I politely pointed it out to them and it was fixed the same > > day. I got results, you didn't. > You have to give them feedback on their terms or else they don't accept > it? No, you have to approach it in a reasonable way. Which is pretty basic for dealing with people. This is not David's strong point. > >> That's ridiculous. If you can't measure an element's dimensions or read > >> its attributes with any reasonable reliability, you can't possibly have > >> a firm DOM scripting foundation. > > You read like a wikipedia article on logical fallacies. > Still the logic seem robust whereas yours seems lacking. It seems to me to be so clearly the opposite. David makes observations and draws unjustified conclusions based on premises that he is unwilling to equally apply to other situations. That points to clear bias against jQuery (duh), and weakens his arguments. I'm looking for reasoned, logical arguments. Not arguments full of obvious logical fallacies. > > You know what would be interesting, DM? If you wrote up a convincing > > article detailing the reasons why a developer should use My Library > > instead of jQuery, and the process by which they should do so. [...] > And if a convincing article were written would you simply ignore it? No. I may disagree with its conclusions, but it would be a fantastic asset to developers evaluating javascript solutions. It also might challenge DM to consider more factors than he typically focuses on, and form a more reasoned and convincing argument than his usual finger- pointing and whining. DM starts out with valid observations. Most of them not really unique. Such as: 1) jQuery is built on an API that is misguided, limiting, and error- prone 2) jQuery has historically used and defended browser sniffing, and only recently became aware of better alternatives 3) jQuery does not handle attributes correctly in some situations 4) jQuery is not robust in dealing with width/height calculations 5) jQuery does not enable progressive enhancement, despite its claims 6) jQuery changes its API randomly and frequently, and new versions are not always backwards-compatible 7) jQuery is not modular, so upgrading to fix a bug in one area while maintaining the code in another area for backwards-compatibility is not possible 8) jQuery is unsuited for mobile browsers 9) jQuery has a limited list of supported browsers, with no graceful degradation 10) jQuery uses a test-driven development approach that leads to conclusions that "seem to work" instead of robust, researched algorithms that will "always work". I'm sure there are others I'm not thinking of right now. Now, David throws these arguments out there, and with no more reasoning or explanation, declares jQuery to be junk that should not be used by anyone in any situation, calls John Resig inept, and repeatedly insults anyone who uses jQuery or defends its use. To me, the step from those observations to the conclusion that jQuery should never be used is not a logical or reasonable step. Those are purely technical points. They may lead to conclusions like "jQuery will require X amount of ongoing testing and maintenance if used in an application" or "jQuery will break in situation Y, which most applications will find unacceptable." If he were to take those arguments, and combine them with other business factors, technical factors, and "people" factors, he may be able to make a good case for moving from jQuery to My Library or some other approach. He may be convincing to some people, and may give them a real reason and strategy for moving away from jQuery. Or for others, perhaps his conclusions will not be convincing because their factors are unique or differently weighted. Perhaps, as I've seen a number of times, only libraries that are on the vendor's "approved" list may be used in a webapp. jQuery is on there, My Library is not. Getting My Library on the list is not practical for the project. Therefore, any arguments for this approach are simply not applicable, and David's argument is not valid in this situation. Things like this really happen, and his all-or-nothing approach simply falls apart in such situations. He has no solution unless it is ideal. And most of the development world is not working with an ideal environment. If nothing else, it would be a reasonable way to promote his position and help people arrive at their own conclusions that may result in better products being created, whether with jQuery or not. Matt Kruse |