Re. disabling the trailing execution during throttle: you might want a
function to execute every N milliseconds only while you're performing
an action. Perhaps it doesn't update a state value, but simple shows a
progress bar while the action is taking place. In this case, it would
be detrimental to perform that action after completion.
Re. debouncing at the beginning: if you're accepting input and only
want to register the first click but not subsequent clicks, this will
make an interface feel as responsive as possible while not allowing
accidental extra clicks.
Throttle, trailing: updating state (great for event handlers)
Throttle, no trailing: showing progress
Debounce, end: User input for expensive or asynchronous actions
Debounce, begin: User input for synchronous actions
I'm sure people can come up with many more examples, these were the
first that came to mind.
On Apr 27, 10:19 am, Mislav Marohnić <mislav.maroh...@gmail.com>
> On Tue, Apr 27, 2010 at 16:09, "Cowboy" Ben Alman <cow...@rj3.net> wrote:
> > That being said, this throttle (and yours) don't have an option for
> > disabling that final "deferred" execution.
> What is the use case for disabling this final call? Or for forcing the
> intial call right at the start? I've noticed you have these options
> available in your plugin.
> You received this message because you are subscribed to the Google Groups
> "Prototype: Core" group.
> To post to this group, send email to firstname.lastname@example.org
> To unsubscribe from this group, send email to
> For more options, visit this group
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at