As the others have said, you can use var at global scope (outside of all functions and modules) to declare a global variable:

<script>
var yourGlobalVariable;
function foo() {
    // ...
}
</script>

(Note that that's only true at global scope. If that code were in a module — <script type="module">...</script> — it wouldn't be at global scope, so that wouldn't create a global.)

Alternatively:

In modern environments, you can assign to a property on the object that globalThis refers to (globalThis was added in ES2020):

<script>
function foo() {
    globalThis.yourGlobalVariable = ...;
}
</script>

On browsers, you can do the same thing with the global called window:

<script>
function foo() {
    window.yourGlobalVariable = ...;
}
</script>

...because in browsers, all global variables global variables declared with var are properties of the window object. (The new let, const, and class statements [added in ES2015] at global scope create globals that aren't properties of the global object; a new concept in ES2015.)

(There's also the horror of implicit globals, but don't do it on purpose and do your best to avoid doing it by accident, perhaps by using ES5's "use strict".)

All that said: I'd avoid global variables if you possibly can (and you almost certainly can). As I mentioned, they end up being properties of window, and window is already plenty crowded enough what with all elements with an id (and many with just a name) being dumped in it (and regardless that upcoming specification, IE dumps just about anything with a name on there).

Instead, in modern environments, use modules:

<script type="module">
let yourVariable = 42;
// ...
</script>

The top level code in a module is at module scope, not global scope, so that creates a variable that all of the code in that module can see, but that isn't global.

In obsolete environments without module support, wrap your code in a scoping function and use variables local to that scoping function, and make your other functions closures within it:

<script>
(function() { // Begin scoping function
    var yourGlobalVariable; // Global to your code, invisible outside the scoping function
    function foo() {
        // ...
    }
})();         // End scoping function
</script>

If you have to generate global variables in production code (which should be avoided) always declare them explicitly:

window.globalVar = "This is global!";

While it is possible to define a global variable by just omitting var (assuming there is no local variable of the same name), doing so generates an implicit global, which is a bad thing to do and would generate an error in strict mode.

You can assign to the window object, i.e. window.myGlobal = 3;. window is the default context for variable binding. That's why you can reference document instead of needing to do a window.document.

But yeah as David says, you should avoid using globals. And if you are going to use globals, you should place them and other top-level declarations in a "namespace" object to avoid potential naming collisions with other libraries, like this:

myNamespace = { myGlobal: 3 };

// Then to access...
myNamespace.myGlobal = 6;

All JavaScript code executes in some environment, most commonly in a browser. The code that executes must execute in some "root" scope referred to as the global context or global scope (think of it as the main container). In your browser, this "root" scope is the window object (unique window object per tab, page, or iframe).

That is why when in the example a variable gets declared in the global scope var carName = "Volvo"; you can access this variable on the window object window.carName, because in the browser the 'window' object the global object.

When you execute JavaScript code using Node.js for example the global object is very aptly named global and in that environment if you declare var carName = "Volvo"; you can also access the variable using global.carName (this is only true on the Node.js REPL; var declarations in files do not attach to the global object).

To elaborate:

var myObject = { };
myObject.myVariable = 1;
console.log(myObject.myVariable); // Logs 1

myVariable is created on myObject, and this is done explicitly.

var myVariable = 1; // Behind the scenes this declaration is doing window.myVariable = 1;
console.log(window.myVariable); // Logs 1

myVariable is implicitly created on the window object which in the context of a browser is the global object.

For maybe a better explanation, I strongly recommend this book series You Don't Know JS Yet (book series) - 2nd Edition, specifically for this question You Don't Know JS Yet - Scope & Closures - 2nd Edition

In your example, customer is a global variable. You should be able to do the following:

<button onclick="changeID(customer)">Add One to Customer ID</button>

Javascript is single-threaded, if you have a loop like:

while(!downloadFinished) {

}

that loop will keep running forever and no other function will run (your .on('complete' callback can't execute until the while loop finishes, because of the single-threaded nature of Javascript, so it won't ever finish since you don't set downloadFinished = true inside that loop or use a break statement).

To work around this, you can do all your other stuff in a callback which you don't call until the download completed:

var downloadPage = function(url, file, callback) {
  rest.get(url).on('complete', function(result) {
    if (result instanceof Error) {
      console.log('Error:', result.message);
    } else {

      /* Don't use writeFileSync, unless you want to block your server,
        from handling any requests at all until the disk IO completes

        fs.writeFileSync(file, result, 'utf8');
        callback();
      */
      fs.writeFile(file, result, 'utf8', callback);
    }   
  }); 
};

if(require.main == module) {
    downloadPage('http://google.com', 'new.html', function after_download(){
        // do other stuff make sure download is finished to 'new.html'
    });
}

A good technique for this is a self-executing closure:

// bob is a global variable, which you want to avoid
var bob = 1;

// By wrapping this function declaration in parentheses, then
// appending (), it gets invoked immediately. But everything
// inside it is scoped to the anonymous function!
(function () {
    // sue can only be seen inside this function
    var sue = 1;

    // But if you want to, you can still create global variables.
    // This creates a global variable called joe:
    window.joe = 1;
})();

Applying this technique to your code, you could write this to have no global variables:

(function() {
    var size_li = $("#myList li").size();
    var x = 3;

    $('#myList li:lt(' + x + ')').show();
    $('.loadmore').on('click', function() {
        x = (x + 2 <= size_li) ? x + 2 : size_li;
        $('#myList li:lt(' + x + ')').show();
    });
})();

Only variables declared without var become global, this does not apply to functions.

You can, however, declare foo like so:

foo = function() {}

and it should be global.

Omitting var is generally not recommended for these reasons (off the top of head):

• Variable resolution starts at the most local and goes toward looking in the global namespace, making it slower. Much slower in certain browsers.
• You tend to eventually have naming conflicts by polluting the global namespace. One of the worst offenders would be, say, for(i = 0; i < arr.length; i++) (note the lack of var)

You might want to declare functions using var due to a language feature called hoisting

BTW, if you do choose to declare functions with var, I recommend you do so this way:

var foo = function foo() {}

because it gives the function a "name" instead of being treated as an anonymous function, which will help with debugging. Most people do not do this and declare using function, I believe.

Just define your variables in global.js outside a function scope:

// global.js
var global1 = "I'm a global!";
var global2 = "So am I!";

// other js-file
function testGlobal () {
    alert(global1);
}

To make sure that this works you have to include/link to global.js before you try to access any variables defined in that file:

<html>
    <head>
        <!-- Include global.js first -->
        <script src="/YOUR_PATH/global.js" type="text/javascript"></script>
        <!-- Now we can reference variables, objects, functions etc. 
             defined in global.js -->
        <script src="/YOUR_PATH/otherJsFile.js" type="text/javascript"></script>
    </head>
    [...]
</html>

You could, of course, link in the script tags just before the closing <body>-tag if you do not want the load of js-files to interrupt the initial page load.

They clutter up the global namespace and are slower to look up than local variables.

First of all, having many global variables is always a bad thing because it's easy to forget you declared a variable somewhere and accidentally re-declare it somewhere else. If your first variable was local then you don't have a problem. If it was global, then it just got overwritten. This gets even worse when you get into implied globals (e.g. when you say someVar = someValue without declaring someVar with the var keyword).

Secondly, global variables take longer for Javascript to "find" than local variables. The difference in speed isn't huge, but it does exist.

For further reading and a more in-depth explanation of why globals are considered bad practice, you may want to check out this page.

You need to declare the variable before you include the helpers.js file. Simply create a script tag above the include for helpers.js and define it there.

<script type='text/javascript' > 
  var myFunctionTag = false; 
</script>
<script type='text/javascript' src='js/helpers.js'></script>     
... 
<script type='text/javascript' > 
  // rest of your code, which may depend on helpers.js
</script>

Just reference the variable inside the function; no magic, just use it's name. If it's been created globally, then you'll be updating the global variable.

You can override this behaviour by declaring it locally using var, but if you don't use var, then a variable name used in a function will be global if that variable has been declared globally.

That's why it's considered best practice to always declare your variables explicitly with var. Because if you forget it, you can start messing with globals by accident. It's an easy mistake to make. But in your case, this turn around and becomes an easy answer to your question.

You have to call myFunction() first, e.g.:

myFunction();
alert(x);

I'd bet on it being caused by some slight confusion...

Being that putting var in front of a variable puts that variable into the local scope only in Javascript, and a variable delcaration without it (a = 16) is global.

function test() {
    a = 16;
    var b = 16;

}
test();

alert(a); # alerts 16
alert(b); # throws error, b is undefined

The problem with globals is not memory, and it's not performance.

The problems with globals is entirely different. The problems are that they introduce global state and that scripts are not bound to a namespace.

Let's go through these problems one by one.

Having global state

This is the biggest issue here. Coding necessitates that the dependencies of a module be explicit and that communication between pieces of code is very clear.

When you have global variables which part of the code uses the variable is not nearly as clear and you can't be sure what part of the code needs it and what does not.

Let's say I have a Zoo project and I have a Bathe service that cleans an animal. Instead of passing Bathe around to each animal that needs it I have it on a global namespace and I just call Bathe(myAnimal).

Now I want to restructure my zoo and I want to know which animals need bathing because I want to optimize that. I have no way of knowing that other than going through my whole code. In order to see if my Giraffe needs bathing I have to read the entire code of the Giraffe class. If instead I passed Bathe to the constructor of Giraffe instead of using it or creating it inside giraffe (a concept called dependency injection) I can see that a Giraffe needs bathing just by reading the signature.

Now this can get way worse, what if I have state? If I'm actually changing a global variable in multiple places it becomes extremely hard to track. In a more than a few lines code base this means that you have state changing all around and no clear indication of who is changing it.

This is the main reason you should avoid globals altogether .

Scripts are not bound to a namespace

If I have two scripts on a page and my first script declares a A variable on the global namespace, the second script can access that variable. This is useful because scripts can interact this way but it's very harmful because it means that scripts can override each other's code, and communicate in an unclear way.

This of course is completely mitigated if you use a module loader like browserify or RequireJS which means your whole script only exposes two globals - require and define and then script loading is done through the loader.

This way the way independent pieces of code interact is well defined. That doesn't prevent you from creating variables on the global object, but it helps mitigating the need to do so in a uniform manner.

A note on security

Of course, anything on the client side is compromised, you can't do security or anything like that in client side JavaScript on an insecure browser (that is, you didn't prevent anything external on) because the client can just run arbitrary code on your code and read it.

Like all node.js functions that deal with I/O csv works asynchronously. Therefore, the call csv.from..to.. returns immediately, but the callback function is only called later. Make your Loader asynchronous as well, like this:

var csv = require('csv');
var Loader = function(onData) {
  csv()
  .from.path('./data/ebay.csv', {
    columns: true,
    delimiter: ';'
  })
  .to.array(onData);
};
module.exports = Loader;

Functions are objects. They can have properties like any other objects:

function a(){
    if (a.executed) return;
    a.executed = true;

    //do stuff
}

As @Ian mentioned in his comment you can easy make the function reusable. It can be advantage as well as a downside of this approach.

And as @Dave said it can be achieved with closure:

var a = (function (){
    var executed = false;

    return function (){
        if (executed) return;
        executed = true;

        //do stuff
    }
})(); 

You have nothing to worry about.

The performance impact of a global variable is minute.
Global variables are discouraged because they can make code harder to maintain.
In your case, they won't.