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: Hans-Georg Michna on 5 Apr 2010 08:51 On Sun, 04 Apr 2010 15:31:57 -0400, David Mark wrote: >Hans-Georg Michna wrote: >> On the other hand, new stuff is continuously invented and added >> to browsers, which may well push them apart again. >Another problem is that there will be so many browser variations in the >future that multi-browser strategies (particularly, but not limited to >UA sniffing) will be even more unworkable than they are now. Hm, that sounds ominous. Who knows, perhaps in five years we'll all be writing new web pages in Silverlight or its open-source equivalent from the Mono crowd, Moonlight. Let's keep our eyes open, watching the surroundings, while we beaver away on our web pages. Hans-Georg
From: Matt Kruse on 5 Apr 2010 11:00 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. You could also have suffered the wrath of their published (but unfortunate) API changes like the [@prop-val] selector change or the attr() changes. As with any software upgrade, you have to be careful to check for changes and adjust your own code accordingly. Matt Kruse
From: David Mark on 5 Apr 2010 18:15 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. So, isn't it about time you started using My Library instead? You were the one that asked for it, remember? 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. So it's all there now, though I still have a little work left to do on the docs. > > 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. But, as mentioned and as we all know, the very likely suspect is jQuery. Bad code does as bad code is. > > You could also have suffered the wrath of their published (but > unfortunate) API changes like the [@prop-val] selector change or the > attr() changes. As with any software upgrade, you have to be careful > to check for changes and adjust your own code accordingly. > Yes, it is unfortunate that they put their users through the wringer like that. You couple bad code with even worse design decisions/strategies and you get something that should simply be avoided (then you don't ever have to worry about upgrading it). And it is ironic that they are still fiddling with - attr - without coming close to fixing the obvious bugs that were reported here two and a half years ago. I mean, what sort of query engine could work without reading attributes properly? It's like a phone operator that can't read numbers. From the discussions I've read, they don't understand the problems (despite the fact that they date back to the turn of the century) and are therefore hesitant to adjust their voodoo code. Also, the whole QSA "Sizzle" thing is unspeakable. Sure, why not add a layer that returns correct answers in most of the latest browsers and then fall back to something that can't read attributes or handle many of the more involved CSS3 selector queries? Then tell people to bet the farm on it and use queries for everything (even basic form manipulation). And why stop there? Build "shiny" widgets on top of that mess to entice clueless PM's. I'm sure that won't present any problems, as long as end-users abstain from using non-QSA browsers (or ones that have QSA-related bugs or inconsistencies). And, oh BTW, make sure that you upgrade all of it (core, plug-ins, widgets) in perfect sync to "keep up" with releases of the "supported" browsers (and let the end-users know that they must upgrade their browsers to stay in step as well). Do you think the end-users will sign such a contract? As a developer, would you? I know you did once, but it's long past time to tear it up. ;)
From: Dr J R Stockton on 5 Apr 2010 13:52 In comp.lang.javascript message <aqvgr5176lifa783kuo3s5jbjrooashsa5(a)4ax. com>, Sun, 4 Apr 2010 20:20:49, Hans-Georg Michna <hans- georgNoEmailPlease(a)michna.com> posted: > >Eventually I went a different way, opened the http://winhlp.com/ >web site and directly helped users to work around the known >problems. Search does not find DatePart or 10.51 : see respectively <URL:http://www.merlyn.demon.co.uk/vb-date2.htm#DP> <URL:http://www.merlyn.demon.co.uk/js-datex.htm#O1051>. You might like to cite the links. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05. Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: Ivan S on 6 Apr 2010 07:07
On Apr 5, 5:00 pm, Matt Kruse <m...(a)thekrusefamily.com> 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. 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). 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. Doing things like now, JQuery pushes users to upgrade due to browser sniffing (new browser breaks a script, so upgrade is inevitable), 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. |