jQuery 1.3 Released
Matt Kruse
http://docs.jquery.com/Release:jQuery_1.3
One of the improvements in this release is the removal of all browser
sniffing. As I look at the internals I still see room for improvement,
but I am reassured that it is headed in the right direction for a
generalized scripting library.
Any thoughts?
Matt Kruse
Richard Cornford
For some reason I am not at all surprised that when I load that page
with IE 6 it pops up a "Exception thrown and not caught" error (line
2565, which is in the new JQuery 1.3 code as that is the only resource
loaded that has that many lines). You would think that javascript
experts would know to try their stuff in various browsers, but
apparently not.
> One of the improvements in this release is the removal of
> all browser sniffing.
It does rather concede the point that has been being made repeatedly
since the turn of the century.
> As I look at the internals I still see room for improvement,
> but I am reassured that it is headed in the right direction
> for a generalized scripting library.
There are (at least) two ways of looking at "the right direction"; there
is moving away from things that are bad, and then there is moving toward
some 'ideal goal'. The latter may imply the former but the former does
not necessarily result in the latter. The problem with the library's
public API and usage style being set in concrete by the existence of a
(large-ish) user base is that if the starting point is incompatible with
the 'ideal goal' then no amount of (internal) movement is going to end
up there.
> Any thoughts?
I notice you wrote:-
<URL:
http://groups.google.com/group/jquery-dev/browse_frm/thread/5e87613fc36ff7bd >
| Fantastic! There is definite improvement here. Now I just
| need to do a bunch of testing to work it into some existing
| apps and benefit from the performance increases.
Now, if you want that performance improvement then I suspect that you
may have been fibbing a bit when previously asserted here that JQuery
was quite fast enough for your project. And, of course, the need to do
the "bunch of testing" when upgrading/updating shows the lie in all
those claims that JQuery is low maintenance.
Richard.
Matt Kruse
wrote:
> > jQuery 1.3 has been released.
> >http://docs.jquery.com/Release:jQuery_1.3
> For some reason I am not at all surprised that when I load that page
> with IE 6 it pops up a "Exception thrown and not caught" error
Wow, that's embarrassing for them. I'll point it out.
> There are (at least) two ways of looking at "the right direction"; there
> is moving away from things that are bad, and then there is moving toward
> some 'ideal goal'. The latter may imply the former but the former does
> not necessarily result in the latter. The problem with the library's
> public API and usage style being set in concrete by the existence of a
> (large-ish) user base is that if the starting point is incompatible with
> the 'ideal goal' then no amount of (internal) movement is going to end
> up there.
Agreed, in an idealistic view. For me, it is and always has been about
balancing pros and cons. I see improvements (even if they are "moving
away from things that are bad") as a good thing from my practical
point of view.
I do not think jQuery will be relevant in 2012, for example. But in
the mean time, it's relevant to me.
> > Any thoughts?
> I notice you wrote:-
> <URL:http://groups.google.com/group/jquery-dev/browse_frm/thread/5e87613fc...>
> | Fantastic! There is definite improvement here. Now I just
> | need to do a bunch of testing to work it into some existing
> | apps and benefit from the performance increases.
> Now, if you want that performance improvement then I suspect that you
> may have been fibbing a bit when previously asserted here that JQuery
> was quite fast enough for your project.
Not fibbing at all. It has always been fast enough for my purposes
(partly because I don't use the slow stuff). Any performance increase
is welcome.
> And, of course, the need to do
> the "bunch of testing" when upgrading/updating shows the lie in all
> those claims that JQuery is low maintenance.
There are some API changes with this release. Some plugins are not yet
updated. And when dealing with important production code, much testing
is needed when upgrading a core library whether it has any impact or
not.
I'm interesting in your thoughts on the other points I raised in that
thread, specifically about how they have implemented "feature
detection". I feel they have once again kind of missed the point, and
it's disappointing. But I'd like to hear other viewpoints.
Matt Kruse
Richard Cornford
>On Jan 14, 4:28 pm, Richard Cornford wrote:
>>> jQuery 1.3 has been released.
>>>http://docs.jquery.com/Release:jQuery_1.3
>
>> For some reason I am not at all surprised that when I load that
>> page with IE 6 it pops up a "Exception thrown and not caught"
>> error
>
> Wow, that's embarrassing for them. I'll point it out.
Maybe embarrassing but not surprising in my experience of both John
Resig's site and the JQuery site. Both have plagued with errors in IE
browsers. I suspect that it is a consequence of developing in firefox
out of a love of firebug. One of my quibbles with the 'method chaining'
style of programming is that it makes debugging significantly harder;
pretty much requires a full debugger as first tool in debugging as it
turns what would be (long-ish) sequences of statements into sequences of
complex expressions. With statements you can do the very simple things,
such as sticking an alert between two statements and seeing what value a
variable/property has at that point. Finding out what is going on half
way through a long chain of method calls pretty much requires a debugger
to be running.
<snip>
> There are some API changes with this release.
Yes, it looks like some of argument type-checking is being taken down a
notch so it becomes the user's (in the sense of the web developer's)
responsibility not to be sending in things that could not be
unambiguously identified (such as host objects). Well for many years we
have been pointing out here that emulating 'method overloading' in
javascript was not such a good idea as it may appear at first. It looks
like that truth is finally starting to be perceived by JQuery
developers.
> Some plugins are not yet updated. And when dealing with
> important production code, much testing is needed when
> upgrading a core library whether it has any impact or
> not.
Absolutely, so anything that necessities updates is a bad thing, and so
techniques that manage to avoid any need for updates are a good thing.
We all knew that browser sniffing actually necessities continuous
updates (and feature detection can totally avoid the need, in the right
context), it is just a bit ironic that removing the browser sniffing
also necessitates an update.
> I'm interesting in your thoughts on the other points I raised
> in that thread, specifically about how they have implemented
> "feature detection". I feel they have once again kind of missed
> the point, and it's disappointing.
"Missing the point" is precisely how that (and surrounding threads)
struck me. There seems to be a huge confusion between feature detection
and object inference browser detection (with some really dodgy
inferences being propose, apparently with completely straight faces). It
is perhaps understandable given the history of this subject. Object
inference (under the name "object detection") was the 'big idea' after
UA sting-based browser sniffing was shown to be non-viable. You have to
go forward into this century before feature detection started to be
formalised as a 'preferred' strategy. Maybe someone who has used, and
gone as far as attempting to defend, UA string based browser sniffing
has to learn the mistakes of object inference the hard way before they
can see how it is distinct from feature detection.
In the context of JQuery finally conceding the folly of UA string based
browser sniffing I enjoyed Diego Perini writing "John, you and all the
jQuery team members are always at the top of innovation."
> But I'd like to hear other viewpoints.
I haven't (had time to) look at the new JQuery code in detail yet, so I
do not know the validity of your specific comments in that thread. Maybe
by the weekend, maybe not.
Richard.
Peter Michaux
> jQuery 1.3 has been released.http://docs.jquery.com/Release:jQuery_1.3
>
> One of the improvements in this release is the removal of all browser
> sniffing. As I look at the internals I still see room for improvement,
> but I am reassured that it is headed in the right direction for a
> generalized scripting library.
>
> Any thoughts?
It seems the .live() method is getting a lot of attention. At one
point, at least a year ago, I did quite a bit of experimenting with
the type of programming the .live() method allows. I thought it was is
a really neat idea, it avoids the window.onload problem in some ways
as handlers can be "attached" to elements before the elements appear.
It can even be quite efficient as the check if an element matches a
selector is only a check up the element's ancestors (no a search
through the whole document.) As long as the selectors are only allowed
to be reasonably simple, the whole library does not need to be very
big.
Technically, there are problems with event types that don't bubble. It
seems people have worked quite hard to get focus and blur working in
four or five recent browsers. Capture for standard-compliant browsers
and some IE-specific focus/blur-related events. There are other events
which don't bubble and so the .live() style cannot be used exclusively
which seems to put a damper on the .live() style idea to me. If I
adopted it then I would want to go all the way as it would make the
code clearer to have a single style of programming
If avoiding the window.onload delay is the goal then the listeners are
"attached" to elements before the elements even exist. This is
probably done in the <head> of the document and the <body> doesn't
exist. If this is the case and the <body> doesn't yet exist, then many
feature tests are not even possible.
I found that the .live() style didn't work so well with the concept of
a widget. Because the .live() handler is the Flyweight Design Pattern,
the widget needs to be sent to the handler. Since the clicked element
is sent as part of the event to the handler, it is possible to use
that element to determine the associated JavaScript widget backing
object. All this hunting around for things at the beginning of each
event was very unappealing to me.
Peter
David Mark
> On Jan 14, 10:26 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>
>
> > One of the improvements in this release is the removal of all browser
> > sniffing. As I look at the internals I still see room for improvement,
> > but I am reassured that it is headed in the right direction for a
> > generalized scripting library.
>
> > Any thoughts?
>
> It seems the .live() method is getting a lot of attention. At one
> point, at least a year ago, I did quite a bit of experimenting with
> the type of programming the .live() method allows. I thought it was is
> a really neat idea, it avoids the window.onload problem in some ways
> as handlers can be "attached" to elements before the elements appear.
Personally, I don't consider window.onload to be a problem (though I
recommend the onload attribute of the body instead.) If pages are
kept lightweight and http requests minimized, the delay between parse
and load should be hardly palpable. It is the practice of loading
tons of images, Flash movies, etc. per document that causes developers
grief in this area. One inexplicably popular technical news site I
visited recently must have opened 100 connections on each navigation.
Certainly they were using the unload event to break fast history
navigation, probably because whatever library they used would leak
memory otherwise. Hitting the back button on this thing would keep
the progress bar jumping for 20-30 seconds on a high-speed
connection. IIRC they used YUI and their pages weighed over 300K as a
result. On the "plus" side, it was a real "Web 2.0" site with several
(useless) drag and drop features (and lots of interesting script
errors of course.)
For heavier applications I use DOMContentLoaded as a quicker firing
alternative for standards-based browsers (except Safari IIRC.) Sure
IE and Safari are a split-second later to initialize interactive
portions of the document, but that doesn't qualify as a problem to me,
at least not one that justifies the very odd simulated
DOMContentLoaded hacks that are floating around out there (see the
jQuery ready method.)
The idea of attaching listeners to elements before they exist (!)
seems like silliness to me. More bloat and confusion where efficiency
and understanding would do better. ISTM that Yahoo and perhaps Dojo
already do ill-advised things this and the jQuery developers are just
repeating their mistakes.
From the comments of others, it appears no review of this thing is
necessary. Why are so many developers adamant about following this
ridiculous effort off the proverbial cliff. No matter how many
blunders pile up over the years, the hopelessly indoctrinated just
keep waiting it out. One day, maybe John Resig will learn browser
scripting and write some useful scripts. In the meantime, why not
drop his aborted attempts on your sites, since lots of bloggers and
other clueless people (e.g. Diego Perini) hail them as "innovation."
Write less code, save more money, don't re-invent the wheel, huddle
with other clueless people and make due; but, for God's sake, don't
even try to learn anything about what you are doing.
Then there are the others (e.g. Dojo, MooTools, YUI) and the shared
misconception that one of these things is (or one day will be) the one
true "solution" to browser scripting. I saw an article recently where
representatives of some of these efforts were asked in turn which
library they would use if they couldn't use theirs. This was at a
technical conference for Web application developers. Why not ask them
what sort of tree they would be?
Small wonder that virtually every site I visit these days throws
script errors. Sometimes they cause obvious problems, sometimes not.
I do not report them regardless as I know who will be on the other end
of the email logging the latest "edge case." Ask most Web developers
about script errors and they will say they almost never hear about
them and testing confirms that their scripts work on some arbitrary
subset of browsers and configurations (and there aren't enough hours
in the day to test more than that.) Neither do they have time to
learn browser scripting, but can't afford to fall behind all of the
new "Web 2.0" sites, so they rely on the collected works of John Resig
(or whoever) to keep them in style. I guess for most it "works"
better than cobbling together random scripts from Dynamic Drive.