Why is the default delay 600ms?

[LinusU]

Sorry if this has already been answered, I tried searching past issues

I have a hard time figuring out why you would want a delay of 600ms before triggering the build. My workflow is filled with saving a file, switch to the browser, reload. Often thought, the 600ms delay keeps me from seeing the new content, and I have to reload once again.

[mattdesl]

Good question! I have been using delay=0 on budo for some months now, and nobody else has complained. :)

For simple things you might rather use budo than straight up watchify; one of its features is to suspend the server response until the bundle is finished, so you never get a stale or empty bundle during reload.

https://github.com/mattdesl/budo

Sent from my iPhone

On Jul 27, 2015, at 9:14 AM, Linus Unnebäck notifications@github.com wrote:

Sorry if this has already been answered, I tried searching past issues

I have a hard time figuring out why you would want a delay of 600ms before triggering the build. My workflow is filled with saving a file, switch to the browser, reload. Often thought, the 600ms delay keeps me from seeing the new content, and I have to reload once again.

— Reply to this email directly or view it on GitHub.

[LinusU]

Cool project, it doesn't suite the project I'm currently inquiring for but I might use it for other projects in the future! Thanks for your input :+1:

[zertosh]

@LinusU switching branches - but you can use any value you want, I use 400ms personally

[LinusU]

Do you mean when switching branches in git? It seems like that could be solved better. How about waiting ~20ms, but any event resets this timer and it waits ~20ms again. This way the timeout should never run out during the branch switch since the events will come flying in?

[tnguyen14]

Is the -d option the same as --delay?

[mattdesl]

No, -d is short for --debug (a browserify option to enable source maps).

[tnguyen14]

Ah I see. Thanks @mattdesl

[zertosh]

Do you mean when switching branches in git? It seems like that could be solved better. How about waiting ~20ms, but any event resets this timer and it waits ~20ms again. This way the timeout should never run out during the branch switch since the events will come flying in?

@LinusU Yes, I've been thinking of switching the timer to a debounce and lowering it just a bit (maybe ~400ms?). Seeing as how the delay is configurable though, I don't really see the upside of changing it by an order of magnitude.

[LinusU]

What I'm describing is not quite a debounce thought. I think that a debounce fires as soon as the first event is hit, and then waits x seconds until it can fire again.

What I was suggesting was something like this:

function smartDelay (ms, fn) {
  var timeoutId = null

  function fire () {
    timeoutId = null
    fn()
  }

  function trigger () {
    if (timeoutId !== null) clearTimeout(timeoutId)
    timeoutId = setTimeout(fire, ms)
  }

  return trigger
}

ms could be something like 20, but maybe experiment with an git checkout to see what works best.

[zertosh]

What you're describing is exactly a debounce. I think 20 is too low. It maybe be enough for your setup, but may not be for others. NFS is slow. git checkouts can be big. editors do weird things to keep atomic saves. The defaults should work safely for everyone, if you need faster rebuilds, then use the delay option.

[LinusU]

Cool, I thought it triggered on the leading edge of the time interval.

The problem with using the delay option is that my module now will have the same problems as you are describing. It may very well be so that 20 works in my setup, but not on someones else.

I think that this option is a setup/computer specific option rather than a build/module specific, so I would rather treat it as such.

What are your opinions on reading an environmental variable, say WATCHIFY_DELAY and then look for the value in this order: opts.delay, env['WATCHIFY_DELAY'], 600?

[zertosh]

What are your opinions on reading an environmental variable, say WATCHIFY_DELAY and then look for the value in this order: opts.delay, env['WATCHIFY_DELAY'], 600?

Neither browserify or related tools use environment variables for configuration. So I feel like I should stick to flags :/

[LinusU]

I guess that it's because they don't have any environment dependent settings, which I think that this is.

What would be greatly beneficial with including this is that I can specify WATCHIFY_DELAY in my .bashrc since I know that a lower value works on that machine. If I specify it in the build script, that change will then be propagated to all the other developers machines.

[mattdesl]

Would the environment variable only be used when no option is provided?

Budo currently does watchify(bundler, { delay: 0 }) and then uses debounce if the user specifies any additional delay.

Seeing as how the delay is configurable though, I don't really see the upside of changing it by an order of magnitude.

Something worth considering; the default delay might give a general perception that watchify is slow/sluggish. I always thought this was the case until I started using 0ms for delay.

[LinusU]

They way I suggested it is that it's only used when no option is provided.

Something worth considering; the default delay might give a general perception that watchify is slow/sluggish. I always thought this was the case until I started using 0ms for delay.

This is very true, I didn't realise about the delay until a friend asked how long time it took to rebuild the file. I said that it took just over a second, but when looking in the log it said something like 0.31s. That's when I found the delay option.