Develop Reference

While true difference between browser and a compiled program on the OS

Today I watched a colleague of my program a small game in Python on his Raspberry Pi. The game engine ran by using a while(true) or infinite loop. I myself use a websocket program in PHP that uses while(true). In these examples a infinite while loop is used which doesn't cause the program to become unresponsive. Without it, it wouldn't work properly. However in JavaScript we need to avoid a infinite loop at all costs. When a loop becomes infinite the browser hangs and becomes unresponsive.
My question: What is the difference between a infinite loop running in a compiled Python program and a infinite loop written in JavaScript running in a browser?

The difference is that the JavaScript runs on the browser's UI thread (preventing it from pumping normal OS messages like paint), whereas the Python program doesn't have a UI, and thus it doesn't matter if the main thread is hogged by your code.
You're still blocking the main thread either way, but in different contexts.

The main diffrence between the Python and the JavaScript code is that the Python code takes care of updating the UI, whereas the JS code just loops it's game logic and is therefore preventing the browser from updating it's view.
When you make a game, you usually put your in a loop where the first call goes to the game logic to update positions, player health, cat count and something like this. After that, you call a render method so that your updated content is processed as a picture and send to the screen. Then you start again. In JavaScript, you omitt the call to the render function and therefore the browser's UI never updates.
This has nothing to do with threading, but in a language like Pyhton (and many others) you can separate the game logic and the rendering so that when your logic is taking a while to do it's cat repositioning the programm is still able to update your screen (with the same, non-updated content over and over but that's another topic).
TL;DR The JavaScript blocks the rendering process of the Browser, whereas the Python loop explicitly calls the rendering function for it's UI.
For JS you should use setInterval(function, time), as #RúnarBerg noted.
EDIT: #mouser noted that you can also use web workers, which seem to be a html5 approach to multi-threading in JS. It may be worth a look if you are developing a game in JS, especially since it's supported in all major browser according to w3schools.

In Python, your loop probably looks like this:
while true:
TakeInput()
DoStuff()
So each iteration of the loop does something, and it keeps doing that forever.
In JavaScript, the input usually comes from the browser. If your JavaScript code is looping forever, the browser never gets a chance to let your code know new input has arrived.
You could write JavaScript code like this:
while (true) {
x = input('Give me input!');
// Process x
alert(result);
}
which would approximate the Python code, but that's not the way JavaScript usually works, and side-steps the browser all together.

Javascript has asynchronous runtime, meaning that your code doesn't usually have to wait for other parts to continue. You can run an infinite non-blocking loop with setInterval(fn, time) which executes the function fn at an interval of time milliseconds.

How does JavaScript's Single Threaded Model handle time consuming tasks?

This question is regarding the sinlge threaded model of JavaScript. I understand that javascript is non-block in nature cause of its ability to add a callbacks to the async event queue. But if the callback function does infact take a long time to complete, won't JavaScript then be blocking everything else during that time as it is single threaded? How does nodejs handle such a problem? And is this an unavoidable problem for developers on the front end? I'm asking this question cause I have read that its generally good practice to keep function tasks as small as possible. Is it really because long tasks in javascript will actually block other tasks?

But if the callback function does infact take a long time to complete, won't JavaScript then be blocking everything else during that time as it is single threaded?
Yes.
How does nodejs handle such a problem?
Node.js handles nothing. How you handle concurrency is up to you and your application. Now, Node.js does have a few tools available to you. The first thing you have to understand is that Node.js is basically V8 (JavaScript engine) with a lightweight library split between JavaScript and native code bolted on. While your JavaScript code is single-threaded by nature, the native code can and does create threads to handle your work.
For example, when you ask Node.js to load a file from disk, your request is passed off to native code where a thread pool is used, and your data is loaded from disk. Once your request is made, your JavaScript code continues on. This is the meaning of "non-blocking" in the context of Node.js. Once that file on disk is loaded, the native code passes it off to the Node.js JavaScript library, which then executes your callback with the appropriate parameters. Your code continued to run while the background work was going on, but when your callback is dealing with that data, other JavaScript code is indeed blocked from running.
This architecture allows you to get much of the benefit of multithreaded code without having to actually write any multithreaded code, keeping your application straightforward.
I'm asking this question cause I have read that its generally good practice to keep function tasks as small as possible. Is it really because long tasks in javascript will actually block other tasks?
My philosophy is always to use what you need. It's true that if a request comes in to your application and you have a lot of JavaScript processing of data that is blocking, other requests will not be processed during this time. Remember though that if you are doing this sort of work, you are likely CPU bound anyway and doing double the work will cause both requests to take longer.
In practice, the majority of web applications are IO bound. They shuffle data from a database, reformat it, and send it out over the network. The part where they handle data is actually not all that time consuming when compared to the amount of time the application is simply waiting to hear back from the upstream data source. It is in these applications where Node.js really shines.
Finally, remember that you can always spawn child processes to better distribute the load. If your application is that rare application where you do 99% of your work load in CPU-bound JavaScript and you have a box with many CPUs and/or cores, split the load across several processes.

Your question is a very large one, so I am just going to focus on one part.
if the callback function does infact take a long time to complete, won't JavaScript then be blocking everything else during that time as it is single threaded? (...) Is it really because long tasks in javascript will actually block other tasks?
Non-blocking is a beautiful thing XD
The best practices include:
Braking every function down into its minimum functional form.
Keep CallBacks asynchronies, THIS is an excellent post on the use of CallBacks
Avoid stacking operations, (Like nested Loops)
Use setTimeout() to brake up potentially blocking code
And many other things, Node.JS is the gold standard of none blocking so its worth a look.
--
--
setTimeout() is one of the most important functions in no-blocking code
So lets say you make a clock function that looks like this:
function setTime() {
var date=new Date();
time = date.getTime()
document.getElementById('id').innerHTML = time;
}
while(true){setTime();}
Its quite problematic, because this code will happily loop its self until the end of time. No other function will ever be called. You want to brake up the operation so other things can run.
function startTime() {
var date=new Date();
time = date.getTime()
document.getElementById('id').innerHTML = time;
setTimeout(startTime(),1000);
}
'setTimeout();' brakes up the loop and executes it every 1-ish seconds. An infinite loop is a bit of an extreme example. The point is 'setTimeout();' is great at braking up large operation chains into smaller ones, making everything more manageable.

Javascript callback function on a separate thread

Javascript is single threaded. So does the callback function and it's containing function execute on the same thread as the main loop/event loop?
database.query("SELECT * FROM hugetable", function(rows) { // anonymous callback function
var result = rows;
console.log(result.length);
});
console.log("I am going without waiting...");
If query() method and its callback function executes on the same thread as the event loop does then the blocking will occur. If not why Javascript is called single-threaded?
Can anyone help verify that javascript(browser/node.js) is using multiple threads behind the scene in order to achieve non-blocking?
Friends,
I saw your comments and answers. Sorry I am very new to Javascript. I am confused in that single thread async call won't block. If there are 100 users request data from hugeTable which may take one minute each concurrently and the event loop dispatch these tasks in to a queue and execute them in turn how can the query() method execution not blocking the event loop since they are all on one single thread?
Brad answered this part.

Node.js native libraries (not the JavaScript portions) use separate threads all the time, but all of the data for your code gets shuffled back to a single JavaScript execution thread.
It's impossible to tell you if other threads in the background are working on this query, since you didn't specify what DB library you're using. However, that doesn't matter as much as you think.
Let's suppose you were to create a thread for handling your database connection. You fire off a query, and that thread takes care of getting the query to the database server. Then what? That thread sits around doing absolutely nothing until there's data to come back. You've effectively wasted resources keeping a thread around that doesn't do a whole lot. Node.js doesn't work this way. You have one thread for JavaScript execution.
If you are sending or receiving data (which is mostly what your DB connector is going to do), then this is handled out of a background thread pool for you automatically. It's also possible whatever DB connector you're using has a native extension that can do whatever it wants with threads.
See my post here for a more full explanation: https://stackoverflow.com/a/19324665/362536

Javascript is single threaded. So does the callback function and it's containing function execute on the same thread as the main loop/event loop?
Yes, you kind of answered your own question.
You are correct, JavaScript is single threaded. There is no other thread for a callback to execute on.
That said, external libraries written in C or C++ are free to spawn threads all they want.

Good question, javaScript is single-threaded yet asynchronous, that means for each asynchronous call it will perform a small pause on the main thread to execute the callback, at least that's for browsers and even there you will have web-workers that will spawn a new thread per worker.

What you're doing in your code is deferring the evaluation of the query (execution of the callback) until after the query has run and rows have been retrieved.
In modern browsers you can create two threads if desired using webworkers.
Node.js is a seperate story - you can create child processes which will run on a seperate thread when desired. See this post for further information.

Call setTimeout without delay

Quite often see in JavaScript libraries code like this:
setTimeout(function() {
...
}, 0);
I would like to know why use such a wrapper code.

Very simplified:
Browsers are single threaded and this single thread (The UI thread) is shared between the rendering engine and the js engine.
If the thing you want to do takes alot of time (we talking cycles here but still) it could halt (paus) the rendering (flow and paint).
In browsers there also exists "The bucket" where all events are first put in wait for the UI thread to be done with whatever it´s doing. As soon as the thread is done it looks in the bucket and picks the task first in line.
Using setTimeout you create a new task in the bucket after the delay and let the thread deal with it as soon as it´s available for more work.
A story:
After 0 ms delay create a new task of the function
and put it in the bucket. At that exact moment the UI thread is busy
doing something else, and there is another tasks in the bucket
already. After 6ms the thread is available and gets the task infront
of yours, good, you´re next. But what? That was one huge thing! It has
been like foreeeeeever (30ms)!!
At last, now the thread is done with that and comes and gets your
task.
Most browsers have a minimum delay that is more then 0 so putting 0 as delay means: Put this task in the basket ASAP. But telling the UA to put it in the bucket ASAP is no guarantee it will execute at that moment. The bucket is like the post office, it could be that there is a long queue of other tasks. Post offices are also single threaded with only one person helping all the task... sorry customers with their tasks. Your task has to get in the line as everyone else.
If the browser doesn´t implement its own ticker, it uses the tick cycles of the OS. Older browsers had minimum delays between 10-15ms. HTML5 specifies that if delay is less then 4ms the UA should increase it to 4ms. This is said to be consistent across browsers released in 2010 and onward.
See How JavaScript Timers Work by John Resig for more detail.
Edit: Also see What the heck is the event loop anyway? by Philip Roberts from JSConf EU 2014. This is mandatory viewing for all people touching front-end code.

There are a couple of reasons why you would do this
There is an action you don't want to run immediately but do want to run at some near future time period.
You want to allow other previously registered handlers from a setTimeout or setInterval to run

When you want to execute rest of your code without waiting previous one to finish you need to add it in anonymous method passed to setTimeout function. Otherwise your code will wait until previous is done
Example:
function callMe()
{
for(var i = 0; i < 100000; i++)
{
document.title = i;
}
}
var x = 10;
setTimeout(callMe, 0);
var el = document.getElementById('test-id');
el.innerHTML = 'Im done before callMe method';
That is the reason I use it.

Apart from previous answers I'd like to add another useful scenario I can think of: to "escape" from a try-catch block. A setTimeout-delay from within a try-catch block will be executed outside the block and any exception will propagate in the global scope instead.
Perhaps best example scenario: In today's JavaScript, with the more common use of so called Deferreds/Promises for asynchronous callbacks you are (often) actually running inside a try-catch.
Deferreds/Promises wrap the callback in a try-catch to be able to detect and propagate an exception as an error in the async-chain. This is all good for functions that need to be in the chain, but sooner or later you're "done" (i.e fetched all your ajax) and want to run plain non-async code where you Don't want exceptions to be "hidden" anymore.
AFAIK Dojo, Kris Kowal's Q, MochiKit and Google Closure lib use try-catch wrapping (Not jQuery though).
(On couple of odd occasions I've also used the technique to restart singleton-style code without causing recursion. I.e doing a teardown-restart in same loop).

To allow any previously set timeouts to execute.

JavaScript and single-threadedness

I always hear that JavaScript is single-threaded; that when JavaScript is executed, it's all run in the same global mosh pit, all in a single thread.
While that may be true, that single execution thread may spawn new threads, asynchronousy reqeiving data back to the main thread, correct? For example, when an XMLHttpRequest is sent, doesn't the browser create a new thread that performs the HTTP transaction, then invoke callbacks back in the main thread when the XMLHttpRequest returns?
What about timers--setTimeout and setInterval? How do those work?
Is this single-threadedness the result of the language? What has stopped JavaScript from having multi-threaded execution before the new Web Workers draft?

XMLHttpRequest, notably, does not block the current thread. However, its specifics within the runtime are not outlined in any specification. It may run in a separate thread or within the current thread, making use of non-blocking I/O.
setTimeout and setInterval set timers that, when run down to zero, add an item for execution, either a line of code of a function/callback, to the execution stack, starting the JavaScript engine if code execution has stopped. In other words, they tell the JavaScript engine to do something after it has finished doing whatever it's doing currently. To see this in action, set multiple setTimeout(s) within one method and call it.

Your JavaScript itself is single-threaded. It may, however, interact with other threads in the browser (which is frequently written with something like C and C++). This is how asynchronous XHR's work. The browser may create a new thread (or it may re-use an existing one with an event loop.)
Timers and intervals will try to make your JavaScript run later, but if you have a while(1){ ; } running don't expect a timer or interval to interrupt it.
(edit: left something out.)
The single-threadedness is largely a result of the ECMA specification. There's really no language constructs for dealing with multiple threads. It wouldn't be impossible to write a JavaScript interpreter with multiple threads and the tools to interact with them, but no one really does that. Certainly no one will do it in a web browser; it would mess everything up. (If you're doing something server-side like Node.js, you'll see that they have eschewed multithreading in the JavaScript proper in favor of a snazzy event loop, and optional multi-processing.)

See this post for a description of how the javascript event queue works, including how it's related to ajax calls.
The browser certainly uses at least one native OS thread/process to handle the actual interface to the OS to retrieve system events (mouse, keyboard, timers, network events, etc...). Whether there is more than one native OS-level thread is dependent upon the browser implementation and isn't really relevant to Javascript behavior. All events from the outside world go through the javascript event queue and no event is processed until a previous javascript thread of execution is completed and the next event is then pulled from the queue given to the javascript engine.

Browser may have other threads to do the job but your Javascript code will still be executed in one thread. Here is how it would work in practice.
In case of time out, browser will create a separate thread to wait for time out to expire or use some other mechanism to implement actual timing logic. Then timeout expires, the message will be placed on main event queue that tells the runtime to execute your handler. and that will happen as soon as message is picked up by main thread.
AJAX request would work similarly. Some browser internal thread may actually connect to server and wait for the response and once response is available place appropriate message on main event queue so main thread executes the handler.
In all cases your code will get executed by main thread. This is not different from most other UI system except that browser hides that logic from you. On other platforms you may need to deal with separate threads and ensure execution of handlers on UI thread.

Putting it more simply than talking in terms of threads, in general (for the browsers I'm aware of) there will only be one block of JavaScript executing at any given time.
When you make an asynchronous Ajax request or call setTimeout or setInterval the browser may manage them in another thread, but the actual JS code in the callbacks will not execute until some point after the currently executing block of code finishes. It just gets queued up.
A simple test to demonstrate this is if you put a piece of relatively long running code after a setTimeout but in the same block:
setTimeout("alert('Timeout!');", 5);
alert("After setTimeout; before loop");
for (var i=0, x=0; i < 2000000; i++) { x += i };
alert("After loop");
If you run the above you'll see the "After setTimeout" alert, then there'll be a pause while the loop runs, then you'll see "After loop", and only after that will you see "Timeout!" - even though clearly much longer than 5ms has passed (especially if you take a while to close the first alert).
An often-quoted reason for the single-thread is that it simplifies the browser's job of rendering the page, because you don't get the situation of lots of different threads of JavaScript all trying to update the DOM at the same time.

Javascript is a language designed to be embedded. It can and has been used in programs that execute javascript concurrently on different operating threads. There isn't much demand for an embedded language to explicitly control the creation of new threads of execution, but it could certainly be done by providing a host object with the required capabilities. The WHATWG actually includes a justification for their decision not to push a standard concurrent execution capability for browsers.