I'm using mostly Javascript on my scripting. I have some scripts which do several tasks every 1 second, and some every 0.02 seconds, etc. My intervals do tasks like checking of ifs, doing some innerHTML, little animation, etc. Now I have 4, but I think it would increase in the future; maybe I'll control myself to less than 10. Though it doesn't lag at all in my computer.

1. Generally, will it be good for a site?
2. Since it's client-side obviously there won't be any issues with internet connection, right?
3. Is it a bad practice, or is it not much of an issue at all?

Also, I have a question for jQuery. There are things that normal Javascript and jQuery can do similarly (like innerHTML and .html()), right? Given this situation, which should I prefer to use, jQuery or Javascript?

Thank you.

I'm using mostly Javascript on my scripting. I have some scripts which do several tasks every 1 second, and some every 0.02 seconds, etc. My intervals do tasks like checking of ifs, doing some innerHTML, little animation, etc. Now I have 4, but I think it would increase in the future; maybe I'll control myself to less than 10. Though it doesn't lag at all in my computer.

1. Generally, will it be good for a site?
2. Since it's client-side obviously there won't be any issues with internet connection, right?
3. Is it a bad practice, or is it not much of an issue at all?

Also, I have a question for jQuery. There are things that normal Javascript and jQuery can do similarly (like innerHTML and .html()), right? Given this situation, which should I prefer to use, jQuery or Javascript?

Thank you.

• javascript
• jquery

• 1 Regarding your second question: When to use Vanilla Javascript vs. jQuery? – Matt Ball Commented Mar 17, 2011 at 14:09

5 Answers 5

Is having too many setTimeout()s good?: You already gave your self the answer too many is not good, no matter what you talk about.

Generally will it be good for the site: Probably not, remember you don't know the cpu/browser combo of your users, so you should build your site so it will still be nice to use for people who have slower computers than you. A laggy/unresponsive site is the first one users will flee from.

Since it's client-side obviously there won't be any issues with internet connection, right? right, unless you do network requests as part of the timeouts. Ajax calls every second is rarely a good idea.

Is it a bad practice, or is it not much of an issue at all? poor architecture is bad practice. If you wish to follow the best practices, read up on design patterns.

Also, I have a question for jQuery. There are things that normal Javascript and jQuery can do similarly (like innerHTML and .html()), right? Given this situation, which should I prefer to use, jQuery or Javascript? Using jQuery gives you convinient crossbrowser compatibility. In most cases for non-experts using a library like jQuery is better than not using it.

Generally, will it be good for a site? Most of the other answerers are saying no, but they can't possibly make this claim without more information. This decision is specific to your site. It might be perfectly fine. Don't make guesses about performance. Measure things. Fix performance issues where they really exist, not where your gut tells you they exist.

Since it's client-side obviously there won't be any issues with internet connection, right? Correct.

Is it a bad practice, or is it not much of an issue at all? There are lots of tasks that are best performed with a timeout callback. If you need to do something periodically, or after a certain amount of time has passed, then setTimeout is not only reasonable to use, it's specifically designed for those tasks.

For your first question, it's more a case of what you're doing in each callback that gets called after the timeout. Without knowing that it's hard to provide a clearer answer.

But remember that javascript is single threaded in the browser, so if you're running expensive operations regularly it's not going to work well. If you're looking to do animations with this, I'd strongly urge you to consider one of the existing libraries first (dojo, jquery, mootools etc) and only try and implement this yourself if you find them insufficient. A lot of work has gone into making those libraries performant and it's unlikely you'll do better on a first stab.

Second question: Again, I'd use the library. For a simple innerHTML there's unlikely to be much difference, but in the general case a library like jQuery or Dojo will help to cover over the differences between the DOMs in the different browsers, catch the nasty edge cases you don't know (or want to know) about and is likely to be better tested and supported than your own code. Get it working their way, then optimise with your own vanilla JS if/when you need to.

1) Generally good: no, in general it creates processor load, which slows down the browser. But that will be influenced more by the actual code than the timeouts itself. But modern day browser don't have any problems with 10 timers... ;)

2) Yeah, no problem with the timeout.

3) No, it's the only way to do asynchronous processing. so it isn't really an issue ;)

4) The difference with innerHTML and .html() (and other jQuery functions) is that jQuery has better cross-browser implementations. It knows the quirks of certain browsers and is able to circumvent them. For simple problems plain 'ol JavaScript is perfect (and is cheaper in bandwidth and processing power). But for more complex scripts, and once you have chosen to use jQuery, why not use it anyway. ;)

Go with Jquery - Write Less, Do More

You can have so many functions , effects , plugins will help you to save time from coding.

Any way when you are developing a website with javascript or jquery effects , you will be expecting the user should have an updated browser and system.

your functionality not gonna work on ie 5 . :)

So adding time out and js functions will not affect performance as per my understanding.

http://api.jquery.com/delay/

http://api.jquery.com/toggle/

http://api.jquery.com/html/

Go with jquery api functions and develop your own..instead of usng plugins.