jQuery Forum

What makes you think the adoption rate is slow? I get the feeling
that a good number of people are using it.

I would like to see livequery in the core, but John believes that its rate of adoption is too slow to justify getting it in the core. If that's the case, I want to know why, since it fundamentally improves on core jQuery concepts in (like I said above), what I believe to be the most innovative improvement to the jQuery paradigm since its inception.
<div><br class="webkit-block-placeholder"></div><div>If you use it, please speak up! If not, why not?</div><div><br class="webkit-block-placeholder"></div><div>-- Yehuda
<div><span class="gmail_quote">On 10/31/07,
<b class="gmail_sendername">Mike Alsup</b> <<a href="mailto:malsup@gmail.com">malsup@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
What makes you think the adoption rate is slow?  I get the feeling
that a good number of people are using it.
> So as far as I'm concerned, livequery is the biggest advance in jQuery since
> its inception (no, I am not its author). I'm trying to understand why it's
> having such a slow rate of adoption.
</blockquote></div>
<br clear="all">
--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325
</div>

Here's my 2p
I've recently been using livequery a lot on my pastebin app - however
I've been taking it out again, and I really wonder if it should be
core?
Don't get me wrong, it is a great plugin - however I think it breeds
bad (lazy) design in Ajax apps as it lacks
and I wonder if it's really that fast? Since taking a lot of
livequery out I've noticed speed improvments in my app.

Bahh, I accidently hit the send button as I was typing this out....
What I was trying to say was livequery is missing one major component
that breeds bad design - an ajax history manager. I've tried using
jquery ajax history plugins, and even tried developing my own hijax,
but just couldn't get it to play nice when livequery was involved.
This has led me to take out a lot of my ajax navigation and livequery
is now only used for the messaging system in the app.
Also, as I was also saying I wonder if it needs more speed testing and
optimisation, as I've noticed an increase in speed in my app since I
removed a lot of livequery.

I less than one pence would be I love and use the plugin, but I don't
believe it's used enough to but included into jQuery core, I would
like to see jQuery core stay light and fresh. There's nothing wrong
with adding LiveQuery yourself, just add another file or append all
the plugins you want to the same js file.
/James

My less than one pence worth would be I love and use the plugin, but I
don't think it should be included into jQuery core, I would
like to see jQuery core stay light and fresh. There's nothing wrong
with adding LiveQuery yourself, either just add another js file to
your html or append all the plugins you want to the same js file.
/James

As far as I cel tell LiveQuery runs every time the DOM is modified,
adding extra overhead to the already slow DOM operations (This isn't
jQuery or LiveQuery's fault, it's just a fact of web development that
manipulating the DOM is slow). If you can get away without using
LiveQuery then it's best to from a performance point of view. Don't
get me wrong, LiveQuery is great, you just hace to remember that its
power comes at a price, and tha price is high enough to justify
keeping it as an optional plugin.

I'd like to second this opinion. I'm using livequery more and more,
but there are plenty of places where I DON'T use it, so not having it
in the core would still be my preference.

I think what I'd be more interested is having a method that would allow me
to really easily *manually* re-apply effects/events to a jQuery object.
For example:
$('li')
.cache('some.name', function(){
// use the helper function hover to bind a mouseover and mouseout event
$(this)
.hover(function() {
$(this).addClass('hover');
}, function() {
$(this).removeClass('hover');
});
});
Now you could do:
$('li').applyCache('some.name');
Something like that would definitely save me some coding. (I'd allow a
manual cache "key", just so you could re-use the chain on other selectors.)
The benefit is you don't have the overhead of having to constantly monitor
the DOM, but you have an easy way to re-apply a bunch of commands to a
selector.
Right now I just use helper functions--which isn't hard, just not very
jQueryish. :)
Too bad there's no way to programmatically know the jQuery chain. It would
be really sweet to be able to do:
$('li')
    .hover(function() {
        $(this).addClass('hover');
    }, function() {
        $(this).removeClass('hover');
    })
    .cache('some.name');
And have the cache() method be aware of all the methods called in the
current chain.
-Dan
>-----Original Message-----
>From: jquery-en@googlegroups.com [mailto:jquery-en@googlegroups.com] On
>Behalf Of tlphipps
>Sent: Thursday, November 01, 2007 9:22 AM
>To: jQuery (English)
>Subject: [jQuery] Re: LiveQuery (Discuss Please)
>
>
>I'd like to second this opinion. I'm using livequery more and more,
>but there are plenty of places where I DON'T use it, so not having it
>in the core would still be my preference.
>
>On Nov 1, 5:53 am, James Dempster <letss...@gmail.com> wrote:
>> My less than one pence worth would be I love and use the plugin, but I
>> don't think it should be included into jQuery core, I would
>> like to see jQuery core stay light and fresh. There's nothing wrong
>> with adding LiveQuery yourself, either just add another js file to
>> your html or append all the plugins you want to the same js file.
>>
>> /James
>>
>> On Nov 1, 2:04 am, "Yehuda Katz" <wyc...@gmail.com>

On 10/31/07, Yehuda Katz <wycats@gmail.com>

My example was shorthand for the problem that's being solved. LiveQuery allows you to define behaviors on the DOM that will be applied on current *or future* nodes. It basically takes the selector engine from being a snapshot tool to making the DOM "alive", just like CSS (in CSS, if a class is removed, all styles are removed; with liveQuery, if a class is removed, all associated behaviors are removed).
<div><br class="webkit-block-placeholder"></div><div>Also, re: liveQuery breaking Hijax: can you give some more detail about why this is the case?</div><div><br class="webkit-block-placeholder"></div><div>Finally, use in every single app is not a requirement for inclusion in the Core. There are a number of features that are not ubiquitously used, but represent extremely common usage patterns, and are in use in a large number of apps (think getJSON, for instance).
</div><div><br class="webkit-block-placeholder"></div><div>-- Yehuda
<div><span class="gmail_quote">On 11/1/07, <b class="gmail_sendername">Lee Hinde</b> <<a href="mailto:leearchive@gmail.com">leearchive@gmail.com
</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/31/07, Yehuda Katz <<a href="mailto:wycats@gmail.com">wycats@gmail.com</a>> wrote:
> So as far as I'm concerned, livequery is the biggest advance in jQuery since
> its inception (no, I am not its author). I'm trying to understand why it's
> having such a slow rate of adoption.
>
>
> it solves this problem:
> $("div.klass").draggable();
> $("#foo").load("url", function() { $("div.klass").draggable(); });
>
>
> beautifully, as you now only need to do:
>
>
> $("div.klass").livequery(function() { $(this).draggable() });
> $("#foo").load("url");
>
Since this is an evangelism discussion, I'd suggest that LiveQuery
page doesn't explain the problem it solves. And your sample takes two
lines of code and reduces it to two lines of code. That's not, in and
of itself, compelling.
A lot of us beginners don't get what itch is getting scratched. The
specific suggestion would be to update the Live Query page with an
introduction as to why the plug-in is useful, with an emphasis on DOM
changes via Ajax calls.
</blockquote></div>
<br clear="all">
--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325
</div>

Perhaps you didn't see the example page:
http://brandonaaron.net/jquery/plugins/livequery/test/test.html
Doing those same two examples without Live Query would require you to
write other helper functions to bind those events and to manually
monitor when an element is added or removed. Hardly just two lines of
code. Feel free to add an element to the list via firebug as well to
see how it works.
I personally feel that Live Query should not be put in the core. To
many people seem to think it is a replacement for bind and perhaps
that is my fault for making it a little to easy. Remember that the
power comes at the price of performance. Live Query is best used on a
section of your web site that changes via AJAX calls and you need to
bind events or even just know when the change took place. There will
be absolutely no noticeable performance hit when using it this way. It
is when you start using Live Query in place of your regular bind calls
that you will start to see performance drop.
Live Query should not interfere with any Ajax history manager nor any
hijax methodologies. Live Query is only calling .bind for you.
Also Live Query doesn't make you lazy ... it simply abstracts a more
difficult task into one line. The only reason to suspect you've become
lazy is b/c you are a programmer and I believe we are all a little
lazy at times. :p
Live Query is a very cool plugin but don't use it just b/c it is cool.
BTW ... the adoption rate has been pretty good from my perspective.
--
Brandon Aaron

LiveQuery is a staple in my list of plugins. No matter how much I mess
with the DOM, my events always fire. Leave the core lean, but this
plugin deserves more recognition for sure.

> LiveQuery is a staple in my list of plugins. No matter how much I mess
> with the DOM, my events always fire. Leave the core lean, but this
> plugin deserves more recognition for sure.
Given the dispersed nature of the jQuery community, what are some
suggestions to get the plugin more recognition?

I think this is a great plugin.
Malsup makes me happy already with his dimensions plugin (ok it is not
perfect, all the divs that are containing floats return 0px as height
then i have to use float:left on the container to discard this
problem), and this livequery, wow, is what i've looked for. Thnx a lot!

A slight correction to give credit where it is due: <a href="http://www.malsup.com/jquery/">Malsup</a> has written some great plugins (BlockUI, Cycle, Form, etc.), but Dimensions and Live Query are both by <a href="http://blog.brandonaaron.net/">
Brandon Aaron</a>.
- Richard
<div><span class="gmail_quote">On 11/2/07, <b class="gmail_sendername">resetstudio</b> <<a href="mailto:navylon@gmail.com">navylon@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think this is a great plugin.
Malsup makes me happy already with his dimensions plugin (ok it is not
perfect, all the divs that are containing floats return 0px as height
then i have to use float:left on the container to discard this
problem), and this livequery, wow, is what i've looked for. Thnx a lot!
</blockquote></div>

<div>I'd cast my vote for leaving it out of core for now. The beauty of jQuery is the leaness of the core. I've had my eye on LiveQuery for quite some time but haven't had a chance to put it into practice for our enterprise toolkit. Performance is a major concern but of greater issue is the inconsistency within our organization for jQuery code. I fear too many developers would just use it as a replacement for bind and with the level of dom manipulation that we do the performance hit would be too much.
</div>
<div> </div>
<div>Again let me state that this is not reflective of jQuery or LiveQuery but the browser limitations and the sheer size of data we internally have to deal with on a single page.</div>
<div> </div>
<div>I would theorize that the majority of jQuery users have onReady event binding. For those that have dom manipulation it's probably pretty light and thus the benefit of LiveQuery isn't realized.</div>
<div> </div>
<div>Cheers,</div>
<div>-Jonathan
 </div>
<div><span class="gmail_quote">On 10/31/07, <b class="gmail_sendername">Yehuda Katz</b> <<a href="mailto:wycats@gmail.com">wycats@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">So as far as I'm concerned, livequery is the biggest advance in jQuery since its inception (no, I am not its author). I'm trying to understand why it's having such a slow rate of adoption.
<div>
 </div>
<div>it solves this problem: </div>
<div>$("div.klass").draggable();</div>
<div>$("#foo").load("url", function() { $("div.klass").draggable(); });</div>
<div>
 </div>
<div>beautifully, as you now only need to do: </div>
<div>
 </div>
<div>$("div.klass").livequery(function() { $(this).draggable() });</div>
<div>$("#foo").load("url");</div>
<div>
 </div>
<div>Obviously, that was only a simple example. The more general case, wanting to bind some event handler to a selector regardless of when it appears on the page, is extremely common. So again, I'm trying to understand why the rate of adoption has been so slow. Any thoughts? 
<br clear="all"></div><span class="sg">
--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325 </span></blockquote></div>

I'd like to second Lee Hinde-3's comment. From a beginner's perspective, I
don't really get it. I mean, when I read the description when it was first
announced, I sensed that it was something great, and I've been wanting to
use it, but I really don't understand enough about it and when to use it...
or not use it. As a designer, jQuery has been liberating, allowing me to do
things with javascript I never could before... but I'm very aware of the
fact that my javascript knowledge is very shallow, and LiveQuery is a plugin
that seems rooted in a deeper topic than I'm comfortable with... hence, I
haven't touched it. Maybe Karl Swedberg could take up the topic at
LearningJquery.com?
Lee Hinde-3

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I 2nd Dan's idea. What has made me wary about dipping into using
LiveQuery is:
1. loss of an element of control, compared to just calling a helper
function at the right time to rebind events
2. concern about overhead, since (as I understand it), it's watching
for DOM changes and hence maybe not rebinding things in as efficient a
manner as I would want. This concern could just come from not knowing
(or having looked at) how it works under the covers, but I'd have to
make time for that, to ease my concerns
3. concern about possibly rebinding things that I don't want rebound,
so I'd have to write code to prevent it, ending up with around as much
code as just rebinding via my helper function
- Jack
Dan G. Switzer, II wrote:
<blockquote cite="mid:020f01c81c8d$20271da0$0a01a8c0@dreamtheater"
type="cite">
<pre wrap="">I think what I'd be more interested is having a method that would allow me
to really easily *manually* re-apply effects/events to a jQuery object.
For example:
$('li')
.cache('some.name', function(){
// use the helper function hover to bind a mouseover and mouseout event
$(this)
.hover(function() {
$(this).addClass('hover');
}, function() {
$(this).removeClass('hover');
});
});
Now you could do:
$('li').applyCache('some.name');
Something like that would definitely save me some coding. (I'd allow a
manual cache "key", just so you could re-use the chain on other selectors.)
The benefit is you don't have the overhead of having to constantly monitor
the DOM, but you have an easy way to re-apply a bunch of commands to a
selector.
Right now I just use helper functions--which isn't hard, just not very
jQueryish. :)
Too bad there's no way to programmatically know the jQuery chain. It would
be really sweet to be able to do:
$('li')
.hover(function() {
$(this).addClass('hover');
}, function() {
$(this).removeClass('hover');
})
.cache('some.name');
And have the cache() method be aware of all the methods called in the
current chain.
-Dan
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:jquery-en@googlegroups.com">jquery-en@googlegroups.com</a> [<a class="moz-txt-link-freetext" href="mailto:jquery-en@googlegroups.com">mailto:jquery-en@googlegroups.com</a>] On
Behalf Of tlphipps
Sent: Thursday, November 01, 2007 9:22 AM
To: jQuery (English)
Subject: [jQuery] Re: LiveQuery (Discuss Please)
I'd like to second this opinion. I'm using livequery more and more,
but there are plenty of places where I DON'T use it, so not having it
in the core would still be my preference.
On Nov 1, 5:53 am, James Dempster <a class="moz-txt-link-rfc2396E" href="mailto:letss...@gmail.com"><letss...@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">My less than one pence worth would be I love and use the plugin, but I
don't think it should be included into jQuery core, I would
like to see jQuery core stay light and fresh. There's nothing wrong
with adding LiveQuery yourself, either just add another js file to
your html or append all the plugins you want to the same js file.
/James

I'd argue that it actually provides you more control over the element
in the sense that you will know when it is initially added or removed
from the DOM.
It is actually pretty smart about how it watches for DOM changes.
Thanks to jQuery's architecture this is all possible with very little
initial overhead. For example if you had the following chain:
$('...').css('...').attr('...').append('...');
Live Query wouldn't run until after the append was done even though
the css and attr methods are also monitored. It also doesn't apply
just to chains. The above could also be broken apart and Live Query
still wouldn't run until after the append was done.
$('...').css('...');
$('...').attr('...');
$('...').append('...');
The performance issues come about when you are selecting _lots_ of
elements with several Live Queries. It has the same performance
concerns as you would with regular jQuery selectors. For example to
increase performance give it a context.
$('div', '#myDynamicArea').livequery('...')
That will obviously run faster than just $('div').livequery('...').
As with all performance concerns ... don't get caught up in pre-
optimizations. After the app is built use profiling and experiment
with selectors to find the areas that are actually slowing you down.
Finally, Live Query will never bind a particular event to an element
more than once. In fact it _only_ binds the event (or calls the
callback) once per a newly matched element.
Live Query's main purpose is to solve a _very_ common problem in AJAX
development ... the need to rebind events to elements added to the DOM
after the initial page load. It does this _very_ well and on most
common uses there will be absolutely no noticeable performance hit.
--
Brandon Aaron

Hi,
I had the same experience as Tane. In the beginning, because of the
JQuery's bug that non-root level script cannnot be evaluated after
Ajax call in 1.2 release, I used livequery a lot, and did find that
the page was not very responsive. The performance is getting better
after I removed some of them.
Regards,
Changsu

I don't see what the disconnect for most users is, but I always
assumed that after destroying an element, no matter how it was
reconstructed, I would have to re-bind events using helper functions.
LiveQuery is a useful shortcut for bypassing a logical (IMHO) series
of events, and as such, should remain a plugin rather than added to
the core.
- jake

I'm all for keeping the core lightweight, but there's plenty of stuff
already in the core that is far less useful to me on a daily basis
than LiveQuery. You should not need an extra plugin to indicate that a
particular binding needs to be refreshed when the DOM updates.
- jason

This is the best discussion that I met about livequery... Im the one
who loves it at beginning, now the plugin at reacting of weird ways...
Its a great plugin and necessary, but in a large project with ajax it
becomes a tricky... Now I dont know what I can do... when I test a
site that uses it for all ajaxs, I see in firebug the amount of
scripts duplicates and gives a lot of machine performace and makes
javascript heavy... And Im think, theres something wrong with the
system or its the livequery plugin...
I hope we can find a way to make it work for a log ajax navigation
like a project that Im working...
This project act with a php framework that load the js especifically
in body for each page... but sometimes with the use of another plugins
and in some situations that I can detail because its normal situation
theres a lot of ajax request per time... Im really lost in it...
jQuery its my work and I was dreaming with that... but when we deep
into aplications that rely of ajax and go against browsers layws... im
completely lost...
I have a function to make all ajaxs requests... this functin makes a
link work with ajax automatically... its a plugin that I dont have a
way to rebind events in another way at least livequery... My plugin
have a dependencie of that...

Its a great plugin, you say everything I was needing to hear... the
absoluteley true... Im using livequery like regular bind calls and are
happening thinks not planned... but I can´t find another way to do
it...
Livequery becomes a dependency of the plugin that I was trying to
develop... I need a complete ajax navigation... somethimes complex...
this plugin need the live query... the livequery when I discover was
to me a part of core of jQuery...
How I can register this plugin...
What means with right words "register a plugin"???
I think sometimes that I can enjoy more the plugin... im feeling that
Im not using well or I can make it a substitute for bind calls since I
make some precautions... its this precautions that Im falling...
But the great problem its how decrease a performance... but I dont
have a choose that not be a solution... I said that I could make and
I'll have to do it... I dont know how my plugin used in a project of
my work would survive without livequery... has a way to work with it
without callhim everytime???? All in this project is ajax... theres no
refresh at least the first load... it has to be this way, thats the
original idea...
This way I discover all the problem that cames with this idea and how
to make it truth...
I think livequery great, but my gift maybe gonna be my disaster...

This problem that comes with ajax its a headache... livequery its a
great iniciative to solve it... but has it issues, but everyone has to
remember, that the problem the this plugin is trying to solve its a
problem of the core of the nature of ajax request... so... they try to
fight with limitations thats run out of it control...

Yeah, sure... maybe future jquery versions will take care of that...
its a thing to be concern like priority...

maybe adding some event delegation to LiveQuery could improve its
performance.
Ariel Flesler

> Obviously, that was only a simple example. The more general case, wanting to
> bind some event handler to a selector regardless of when it appears on the
> page, is extremely common. So again, I'm trying to understand why the rate
> of adoption has been so slow. Any thoughts?
I've been using jQuery for about a year, but this is the first I've
heard of livequery. I found it today because I ran into an obstacle
in an application I'm developing for the first time that it solves
nicely; now I expect to use it frequently (though I don't do much
AJAX, admittedly).
I think if it came down to a vote, this seems central enough to me to
warrant including in the core, though I'm sure there are many other
folks who think many hundreds of other plug-ins are likewise good
candidates. Is adoption rate the principal consideration for
inclusion? Seems the best resolution is to decide on clear
criteria...
I suppose as long as it's possible to do this via 'bind' with the core
-- even if inelegant -- it may be wiser to leave it as a plugin, the
better to preserve jQuery's "leanness". That's a more important
consideration, by far, and one of the reasons I bailed from both
Prototype and Mootools...
Cheers,
Nathan