jQuery 1.3 Released

[Matt Kruse]

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?

Matt Kruse

 

[Matt Kruse]

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.

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

 

[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