jQuery crashes again
in [JavaScript]
|
Prev: FAQ Topic - How do I generate a random integer from 1 to n? (2010-04-03)
Next: active (x)html newsgroup?
From: Richard Cornford on 7 Apr 2010 07:51 On Apr 6, 5:40 pm, Matt Kruse wrote: > On Apr 6, 8:34 am, Richard Cornford wrote: > >>> Yes ... but, IMHO, code modifications after framework's >>> upgrade should be exceptions, not a regular practice. >> That is a very reasonable expectation. The public API of a >> framework/library/object/etc. could be thought of as a >> contract; you agree to use it as advertised (documented) >> and in return its creators/maintainers undertake to keep >> it working as advertised. > > Within minor versions, I agree. But obviously each software > author has the right to decide how frequently their API will > change. The people who own the rights to the various libraries have a right to do as they like, but if someone has been promoting the idea that other programmers use that library the people who react to offer by using the library should have a reasonable expectation of their best interests being considered by its authors. > More frequent = Lose developers because it's a PITA, but > more flexible and ability to evolve and become more useful > Less frequent = More backwards-compatible, developers love you, > but less ability to add more functionality, so developers hate > you That sidesteps the question of whether certain approaches to the code design would facilitate more flexibility and future development without sacrificing back-compatibility than others. Whether it might be possible to have your cake and eat it too. > It really varies a lot depending on the library in question. > >> Which doesn't mean things won't change over time but that >> change can be managed, with new features added in parallel >> to features that become deprecated (and eventually removed >> in the fullness of time). > > jQuery does do this, but not enough. It's very difficult to > evolve an API like they have created, which highlights the > fundamental flaws in it to begin with. > > As we've seen with Windows, the slow evolution of a platform > and its API can be great for backwards-compatibility, which > users love, but also make forward progress very slow and painful, > which users hate. I am not user that "forward progress" means much here, or that users do hate not having it. > It's a fine line. Having a large, established userbase makes > things more difficult. Perhaps jQuery got too big too soon, > and John Resign missed the opportunity to re-think his initial > design. Yes, it had probably gotten too big before he published his first book (on the back of being the author of JQuery) and given that book promoting some of the poorer aspects of JQuery's design (e.g. emulated method overloading) it is difficult to see how they could have benn re-thought prior to that. >> But published javascript frameworks/libraries have tended to >> be the products of their author's first attempts to create >> such a thing. > > It's tricky, because most people who become experts in JS then > shy away from frameworks and recommend not using them, I don't think that is at all true. Some types of web application contexts pretty much require a framework of some sort. It is the 'popular' attempts at general purpose frameworks/libraries that are recommended against. And it is these that are the things that the people who become experts don't seem to be interested in creating. > so by its very nature, most frameworks are written by > relative novices. Yes, by their very nature. > Once they > become popular, the weight of the support community, bug reports, > new features, etc become the priority rather than the creator > becoming more and more of an expert in the language. The demands > of supporting a growing userbase (and the praise that usually > comes with it) keeps the creator ignorant of his follies. It is an interesting trap, with some apparent need for self-promotion resulting in efforts going into justifying mistakes instead of recognising them for what they are. >> Indeed, when John Resig expressed the notion that nobody could >> justly criticise JQuery until they had themselves created (and >> published) a general purpose javascript library he was implying >> that this action was itself the ultimate demonstration of >> javascript authoring competence, rather than the reality where >> it is no more than one more step on a learning curve. > > I have a different take on it. > > I think the argument is that unless you have written a public > library and had to face all the other issues that come with > it (community, support, evangelism, upgrades, testing, > backwards-compatibility, different usage scenarios,...) then > you lack the perspective needed to understand why some decisions > are made. Which would still be a foolish position to take. Without actually going through the process it might be difficult to realise the full range of possibilities for yourself, but that does not suggest any inability to understand them (if explained). > Even if a bug in a method is pointed out, there may be thousands > of people who now rely on the wrong behavior, and fixing it will > actually cause more pain than it prevents! Fine, that is one category of bug, but then why take so long to eliminate mistakes like:- if ( typeof array != "array") - after they have been pointed out? Nobody is relying on that simply because a - typeof - operation never ever, and never has, resulted in the string "array". My point about people's ability to understand better if the situation is explained is prompted by observing that generally when things like this get questioned no explanation is forthcoming. > And you get flooded with hundreds of emails and bug reports > and have to somehow manage that. It gets very difficult to > run a project the size of jQuery. I have put a number of > things out for public consumption (though none have obviously > reached the success level of jQuery) and have found it to be > very overwhelming at times. When the 'internet bubble' was happening I kept finding myself responding to various ideas being pitched by asking "where is the money going to be coming from?", and being unconvinced by the proposed revenue generating potential of internet advertising. Letting a project like JQuery become a full time job when it does not generate any income, and so you need a full time job in order to live, is gong to be a problem. Then it is a bit of a catch 22 when you only get the full time job on the basis of being responsible for JQuery. <snip> > In short, he's not even playing the same game as jQuery yet. > So his comparisons are still apples and oranges. > >> So now, instead of the widespread re-think of the design >> that would have been the second step otherwise, the library's >> public API has become difficult to change at the same time >> as the author becoming more aware of the shortcomings of the >> original design. The combination of the need to change things >> that follows from the shortcomings of the original design and >> the resistance to change necessitated by a desire to support >> an existing user-base means that changes get drawn out over >> an extended period, ultimately falling to satisfy anyone as >> upgrades break existing code without ever having a hope of >> addressing the more fundamental issues in the design. > > Exactly right, and this is where jQuery stands. And why it needs > to be branched out to another project that can take the good stuff, > throw away a lot of the bad stuff, and not be limited by > compatibility or a obfuscated API. It would be interesting to see that happen, to see which ideas would be abandoned entirely, or re-created from the ground up. To see which mistakes had been recognised (or at least admitted to) and which would be carried through to the third effort. But I won't be holding my breath. Richard.
From: Richard Cornford on 7 Apr 2010 07:52 On Apr 6, 11:25 pm, Hans-Georg Michna wrote: > On Tue, 6 Apr 2010, Richard Cornford wrote: >> The public API of a framework/ >> library/object/etc. could be thought of as a contract; >> you agree to use it as advertised (documented) and in >> return its creators/maintainers undertake to keep it >> working as advertised. > > This hinges on the functions actually being documented in > detail. To some extent. A vaguely worded contract will difficult to understand or enforce, and probably should not be entered into in the first place. > So let's look at jQuery's .attr(...) method's > documentation: > > ----- Begin ----- > .attr( attributeName ) Returns: String > > Description: Get the value of an attribute for the first > element in the set of matched elements. > > attr( attributeName ) attributeName The name of the > attribute to get. > ----- End ----- > > That's it. No mention what the function does when the > attribute exists, but has an empty string value, what > it does when the attribute does not exist, what it does > when the attribute has been modified with JavaScript > earlier, etc. It doesn't even say what "the name of" an attribute is. If you assumed the HTML definition of an attribute name then case insensitivity is implies and 'tyPe' is as much an attribute name as 'TYPE', but JQuery will not like either. > The docs continue in that minimalistic style, for example, > the .attr(attributeName, value) doc does not say what > happens when value is undefined or an empty string. > > One reason I now try to avoid jQuery is that I cannot > read up on what exactly it does. A cynic might suggest that poor documentation might support a JQuery book market to properly explain what the software does (and then maybe suggest that changing the API would force upgrading of those books with each upgrade of the library, which is even more good news for their authors). > This also generally shows that good documentation is > essential for good software. If creating such were practical, truly intuitive software would probably qualify as 'good' and not need any documentation. But certainly for a software API good documentation is very important. Richard.
From: Ivan S on 7 Apr 2010 10:00 On Apr 6, 3:34 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On Apr 6, 12:07 pm, Ivan S wrote: > > Yes ... but, IMHO, code modifications after framework's upgrade > > should be exceptions, not a regular practice. > > That is a very reasonable expectation. The public API of a framework/ > library/object/etc. could be thought of as a contract; you agree to > use it as advertised (documented) and in return its creator's/ > maintainers undertake to keep it working as advertised. > > Which doesn't mean things won't change over time but that change can > be managed, with new features added in parallel to features that > become deprecated (and eventually removed in the fullness of time). Yes, I agree. But these changes over time shouldn't affect functionality of a certain part of the API (except for bug fixing of course). If these changes affects API's functionality, they should be made as different source code branches: 1.3.2 --- 1.3.3 --- 1.4.0 .... for example. JQuery's attr() method is a good example. It mixes attributes and properties and has some kind of hybrid behaviour (you know that much better than me). If they should decide to fix that in a way to make it more precise, they should maintain old behaviour (at least for some time): 1.3.3 -> 1.3.4 1.4.0 -> 1.4.1 > Having published the first effort the issues in that design will > become evident when people start to use it, but now there is a user- > base who don't want the things they have already created to become non- > functional. So now, instead of the widespread re-think of the design > that would have been the second step otherwise, the library's public > API has become difficult to change at the same time as the author > becoming more aware of the shortcomings of the original design. The > combination of the need to change things that follows from the > shortcomings of the original design and the resistance to change > necessitated by a desire to support an existing user-base means that > changes get drawn out over an extended period, ultimately falling to > satisfy anyone as upgrades break existing code without ever having a > hope of addressing the more fundamental issues in the design. I was recently in a similar situation. My boss asked me to make a new version of one company's software which was old and (very) badly designed (actually, I said that would be a good idea right after I got hired). The problem was that he required that old version should be upgradable to new version because of large number of clients using that old version. I told him that was bad idea - bad design can't be upgraded to great design. But he didn't listen (as many times, probably because I'm still young and inexperienced). And when people don't listen, I don't talk. :) I've made decent new design and the old one could upgrade (that was just a proof of concept, some more important things had to be done and I stopped working on that). But, was that a good decision? I think it wasn't. This decent design wasn't as near good as it could be if that application was rewritten from a scratch. The upgrade for totally new design would be painful (upgrade in means of customization based on customer's requirements and manual application configuration), but it's future would be much brighter (future upgrades, customer customizations would be much easier to do, etc.). Bad implementation can be fixed IMHO, bad design ... well, maybe in some cases. In general, I think it's better to make new and better design. I'm not so experienced, so ... any thoughts from someone more experienced? :) > The authors of many of these libraries have the notion that users will > be continually upgrading their web browsers so back-compatibility with > previous browsers is not an issue. Users ... maybe. Corporations - definitely not (at least not the ones which I was working with - banks and insurance companies). They are still stuck with IE6, just recently started to upgrade to IE7. > Pretty much they publish their list > of supported browsers and that is it. If the end user is not using a > browser on that list then it is the user's fault, even if that > actually translates into some business (web developer's employer or > client) not being able to take money off some of its potential > customers for no better reason than an arbitrary (and non-business) > decision made by some web developer. They are neglecting corporate users that can't upgrade their browsers. And I'm not saying just from intranet point of view. Many of them surf on internet with that same old browser.
From: Matt Kruse on 7 Apr 2010 10:08 On Apr 6, 10:36 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > So you are really going to eschew a CSS-only solution for an > Ajax/jQuery/Live monstrosity, all in the name of IE6? Yes, when IE6 is the only supported browser and the functionality is required. Your point about the overhead of evaluating a selector in the live() method is valid. If it creates a performance problem, I would certainly switch it over to a "normal" event listener and evaluate the target element with POJS to see if it matches. But as long as it works well as-is, I see no reason to prematurely optimize. Matt Kruse
From: Ivan S on 7 Apr 2010 10:36
On Apr 6, 6:40 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > Even if a bug in a method is > pointed out, there may be thousands of people who now rely on the > wrong behavior, and fixing it will actually cause more pain than it > prevents! So ... bug in JQuery is actually a feature. :) |