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 6 Apr 2010 09:34 On Apr 6, 12:07 pm, Ivan S wrote: > On Apr 5, 5:00 pm, Matt Kruse wrote: > >> As with any software upgrade, you have to be careful >> to check for changes and adjust your own code accordingly. > > 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). > I have to admit that I have made mistakes and blamed JQuery > for them many times. But, with time and practice, my > knowledge growed, but JQuery breaks after upgrades remained > constant. :) > > This is not specific to JQuery only, ExtJs also knows to break > from time to time (and I'm not working with ExtJs, my colleagues > are). ExtJs is still full of browser sniffing, so its authors have not yet learnt the lessons that (at least some of) Query's authors have. Browser sniffing is notoriously brittle so even if everything else was being well done that alone would result in library upgrading issues. > I don't know about other JS frameworks. > > Now ... I'm using frameworks in others programming languages > and they don't break after upgrade. There are compability > breaks from time to time and that is specially mentioned. I > don't know if I have false expectations, but I expect the same > from JS framework. Much of the difference here comes from the relative experience of the people involved. It that the frameworks that get created for other languages tend to get created by the more experienced individuals, who have seen how other code changes over time and appreciate why things are done that way. Or, as likely, the products of the less experienced don't tend to achieve widespread use. Having written a fair amount of javascript, including a few things that would qualify as frameworks, I have seen (and probably made) most of the mistakes that can be made, and come to the concussion that starting from scratch it generally takes three attempts at creating any substantial javascript system before the end result would be good enough for general use. The first attempt will generally be bad, and attempting to employ it will teach its author many lessons about how the whole should be designed. The second attempt (assuming an author capable of learning the lessons of the first attempt) will address the lessons learnt form the first, but in being quite different will highlight a set of entirely new issues (the ones that you don't even get to with the first attempt. By the third attempt you should see a well thought out product with a great deal taken into account in its design, including details like upgrading paths. The third attempt may not be perfect but it should be a reasonable basis for moving forward in a way that the first attempt could never be. But published javascript frameworks/libraries have tended to be the products of their author's first attempts to create such a thing. 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. <URL: http://groups.google.com/group/comp.lang.javascript/msg/56d22b30b168fbb5 > 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. > Doing things like now, JQuery pushes users to upgrade due to > browser sniffing (new browser breaks a script, so upgrade is > inevitable), In theory, JQuery having removed all the UA string based browser sniffing, things should be better in that regarded in the future. Some of the misconceptions about what feature detection is (and mistaking object inference browser sniffing for feature detecting) means that they are not yet gone entirely, but those details are the easier ones to handle as they can be addressed internally (don't necessitate any changes in the public API). > user/ developer upgrades and things after upgrade don't work > in older browser version dispite it worked before! That's not > a good practice, IMHO. 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. 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. Richard.
From: S.T. on 6 Apr 2010 10:11 On 4/5/2010 8:00 AM, Matt Kruse wrote: > On Apr 3, 5:06 am, Hans-Georg Michna<hans- > georgNoEmailPle...(a)michna.com> wrote: >> To make it entirely clear---I had used jQuery 1.3.2 on a few >> pages with good success. >> [...] >> Then I upgraded jQuery to its latest version 1.4.2. Immediately >> these pages failed. > > While the upgrade itself may certainly be to blame (I've suffered the > jQuery upgrade hell as well, and most of us are familiar with the > problems with jQuery itself), you should be careful to place blame > properly. > > It could be that you were using jQuery incorrectly, like relying on a > non-published API or using a quirky side-effect, which was fixed in > the latest version. Other non-jQuery code could also be broken that > was only highlighted when jQuery was upgraded and perhaps different > code branches were taken. I was thinking the same thing. Seems like one can safely upgrade from, say, 1.4.x to 1.4.y with very little chance of issues, but if you're upgrading from 1.x to 1.y you should probably be prepared to revisit your code, or at least test it thoroughly. Alternative if one doesn't want to review code is don't bother to upgrade jQuery versions on those pages. It's not as though they're plugging security holes -- generally just a little faster and some new functionality.
From: Matt Kruse on 6 Apr 2010 12:40 On Apr 6, 8:34 am, Richard Cornford <Rich...(a)litotes.demon.co.uk> 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. Within minor versions, I agree. But obviously each software author has the right to decide how frequently their API will change. 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 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. 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. > 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, so by its very nature, most frameworks are written by relative novices. 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. > 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. 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! 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. This is why David's library is still not in the same arena as jQuery. It may be quality code, it may work well, and it may have the beginnings of a community. But call me when he has tens of thousands of sites using his code and has successfully managed the whole process. Because that's a whole different game. It's easy for him to put out quick bug fixes now on a whim. It's easy for him to enhance the API. It's easy to get by with few examples and bad documentation. 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. Matt Kruse
From: Matt Kruse on 6 Apr 2010 12:47 On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > So, isn't it about time you started using My Library instead? No. The poorly-documented API kind of sucks. Despite its flaws and limitations, I recently used the "sortable" project of jQuery UI and found it very easy to create an interface to reorganize content by dragging and dropping things around. All the options I wanted were there, and it was relatively painless to create in a small amount of time. When you have that kind of high-level functionality ready to deliver, documented, tested, and with examples, let me know. Or I also did this: $('tr.task').live('hover', function() { $ (this).toggleClass('hover'); }); Again, despite its limitations, this was a very easy way to add :hover support to some table rows in IE6. Does ML make it that easy? > You were the one that asked for it, remember? Umm, no. > Apparently, you wanted it all on a > silver plate from the start (e.g. community, repository, examples, > documentation) but didn't really do anything to help. I'm not interested in working with the author. Matt Kruse
From: David Mark on 6 Apr 2010 14:41
S.T. wrote: > On 4/5/2010 8:00 AM, Matt Kruse wrote: >> On Apr 3, 5:06 am, Hans-Georg Michna<hans- >> georgNoEmailPle...(a)michna.com> wrote: >>> To make it entirely clear---I had used jQuery 1.3.2 on a few >>> pages with good success. >>> [...] >>> Then I upgraded jQuery to its latest version 1.4.2. Immediately >>> these pages failed. >> >> While the upgrade itself may certainly be to blame (I've suffered the >> jQuery upgrade hell as well, and most of us are familiar with the >> problems with jQuery itself), you should be careful to place blame >> properly. >> >> It could be that you were using jQuery incorrectly, like relying on a >> non-published API or using a quirky side-effect, which was fixed in >> the latest version. Other non-jQuery code could also be broken that >> was only highlighted when jQuery was upgraded and perhaps different >> code branches were taken. > > I was thinking the same thing. > > Seems like one can safely upgrade from, say, 1.4.x to 1.4.y with very > little chance of issues, but if you're upgrading from 1.x to 1.y you > should probably be prepared to revisit your code, or at least test it > thoroughly. > > Alternative if one doesn't want to review code is don't bother to > upgrade jQuery versions on those pages. It's not as though they're > plugging security holes -- generally just a little faster and some new > functionality. That's completely wrong. They are often adjusting their object inferences to "keep up" with what they consider "supported" browsers. Why do you think that list keeps changing? They seem to think that end-users will be reading the list of browsers they "care about" and will be able and willing to upgrade in sync with these cares. In short, stick with an older version and your site will start to break in newer (and previously unknown) browsers. It's an endless loop. |