When running code on Chrome Inspector's console and typing the this keyword, I can see the global scope object that is exposed with many properties already set. But, how can I create mine? Or when I call a function, the call-site is the "global scope" of that function?
I'm reading YDKJS book series and some concepts get really confusing sometimes.
First of all Kyle Simpson's series You Don't Know JavaScript is very nice. Few know that topic as well as he does.
Second, in the context of a browser, what you are calling global variables are all variables that are owned by the Window object. So, keep that in mind when naming them so you don't clobber an existing and important property.
Third, learn more JavaScript and realize you can generally avoid using these types of variables
Related
Is it a good idea to add properties to Node's global object? Searches for this lead me to a discussion of global variables in Node, and frankly I can't find much about the global object for some reason.
From my understanding, global in Node is analogous to the window object that's used in the conventional JS environment, and mutating that is generally frowned upon.
I ask because I'm using Electron whose docs list all sorts of examples that use global, and they even provide an API that lets us set/get global properties from other processes.
From a recent code review, my team was asked to replace the use of global with our own Node module so to avoid overwriting important global attributes set by Node/Electron/3rd party resources.
This seems like a good idea, but why then does Electron recommend the use of global? Why is that the paradigm?
Taking a closer look at the examples, it looks like they recommend only adding one property to the global (sharedObject), so this isn't as bad as I thought, but is this good enough, or should I really take the time to create a separate Node module?
Perhaps this is an opinion-based question.
In a lot of code examples I see around the internet, global variables such as innerWidth, onresize, navigator, etc., are written as window.innerWidth, window.onresize, window.navigator, respectively.
Why are some of these globals prepended with window. and others, such as document and console typically not prepended?
Edit:
I know how OOP works and that I am accessing various properties of the window object. I'm no novice to JavaScript. I'm sorry if my question may have been unclear. I have been programming in JS for years but have never questioned this convention, hence my question.
In essence, I am asking why we don't put window. before document, but we put it before innerWidth. Is it simply a matter of clarity? In theory, shouldn't I be able to reference any of the globals without the window. prefix and have no problem?
It's unfortunate but window in your browser refers to one object which represents two logically distinct concepts :
an instance of Window, an object with well defined properties like Window.innerWidth, logically mapped to your browser's window (or rather the tab, today, but that distinction is hidden from your script)
the global object to whom all global variables are attached as properties
Semantically, it's cleaner to not prefix the global variables, unrelated with the Window concept, with window..
Now note that this introduces a problem when you refer to your global specific variable like myThing : it's hard to know if you're knowingly referring to a global variable or if it's declared in some intermediate scope (or if you just forgot to declare the variable with var). which leads to a situation in which you won't use window. only for properties of the instance of Window but also for your specific global variables. Of course in practice you'll avoid global variables as much as possible.
Not prefixing with window. also has the advantage, when you forget a var declaration or a library import, to make your code fail fast in a not subtle way (which is better than failing in production in a hard to debug way) :
window.undeclaredVariable // no error, just an undefined value
undeclaredVariable // reference error
JavaScript would probably have been better with a distinction between those two concepts (something like global or root as in node).
All the global functions and variables are attached to the object activator, this object dependent of your host environment (browser, node, etc), in the browser environment the object activator is the window object, so each global function could be access with window.console, this.console or just console, I think the prepend is useful to have a more readable code.
You could access to global scoped variables without the window prepend just innerWidth.
Think of it like objects. You are trying to get the innerWidth of the window object its self. Document is the same way. You are trying to get those variables that describe the document itself instead of the window as a whole. And console is just that, a console that you console.log to for debugging. It also has its own properties.
They may be global variables, but they still belong to and describe a specific "object" that you must call on first. If that makes sense.
In Javascript: The Good Parts Crockford writes that "Javascript depends on the global variable for linkage." I understand that in javascript if you declare a variable outside a function it "is in the global namespace" -- meaning you can access it anywhere in the program. I sort of understand how linkage limits where in a C++ program you can access a variable (regardless of its scope). With that said, what does Crockford mean?
I think what he means is that global variables are how you communicate with libraries. For example jquery uses the global variable $, underscore uses _, etc. You link to the libs through a global name.
Continuing
All the top-level variables of all compilation units are tossed
together in a global namespace called the global object. This is a bad
thing because global variables are evil, and in JavaScript they are
fundamental. Fortunately, as we will see, JavaScript also gives us the
tools to mitigate this problem.
What Crockford is referring to, I think, is the absence of module or namespace-like mechanisms in JS to segregate and modularize chunks of functionality at a macro level, where those chunks are explicit about what they are exposing (export), or what they are using from other chunks (import). However, as he points out, JS does provide the ability, albeit imperfectly, to do this through existing language features, and the world has not come to an end. At the same time, this problem is now being addressed on a number of fronts, notably the ES6 module mechanism.
I've heard that it's not a good idea to make elements global in JavaScript. I don't understand why. Is it something IE can't handle?
For example:
div = getElementById('topbar');
I don't think that's an implementation issue, but more a good vs bad practice issue. Usually global * is bad practice and should be avoided (global variables and so on) since you never really know how the scope of the project will evolve and how your file will be included.
I'm not a big JS freak so I won't be able to give you the specifics on exactly why JS events are bad but Christian Heilmann talks about JS best practices here, you could take a look. Also try googling "JS best practices"
Edit: Wikipedia about global variables, that could also apply to your problem :
[global variables] are usually
considered bad practice precisely
because of their nonlocality: a global
variable can potentially be modified
from anywhere, (unless they reside in
protected memory) and any part of the
program may depend on it. A global
variable therefore has an unlimited
potential for creating mutual
dependencies, and adding mutual
dependencies increases complexity. See
Action at a distance. However, in a
few cases, global variables can be
suitable for use. For example, they
can be used to avoid having to pass
frequently-used variables continuously
throughout several functions.
via http://en.wikipedia.org/wiki/Global_variable
Is it something IE can't handle?
No it is not an IE thing. You can never assume that your code will be the only script used in the document. So it is important that you make sure your code does not have global function or variable names that other scripts can override.
Refer to Play Well With Others for examples.
I assume by "events" you mean the event-handling JavaScript (functions).
In general, it's bad to use more than one global variable in JS. (It's impossible not to use at least one if you're storing any data for future use.) That's because it runs into the same problem as all namespacing tries to solve - what if you wrote a method doSomething() and someone else wrote a method called doSomething()?
The best way to get around this is to make a global variable that is an object to hold all of your data and functions. For example:
var MyStuff = {};
MyStuff.counter = 0;
MyStuff.eventHandler = function() { ... };
MyStuff.doSomething = function() { ... };
// Later, when you want to call doSomething()...
MyStuff.doSomething();
This way, you're minimally polluting the global namespace; you only need worry that someone else uses your global variable.
Of course, none of this is a problem if your code will never play with anyone else's... but this sort of thinking will bite you in the ass later if you ever do end up using someone else's code. As long as everyone plays nice in terms of JS global names, all code can get along.
There shouldn't be any problem using global variables in your code as long as you are wrapping them inside a uniqe namespase/object (to avoid collision with scripts that are not yours)
the main adventage of using global variable in javascript derives from the fact that javascript is not a strong type language. there for, if you pass somes complex objects as arguments to a function, you will probebly lose all the intellisence for those objects (inside the function scope.)
while using global objects insteads, will preserve that intellisence.
I personally find that very usfull and it certainly have place in my code.
(of course, one should alwayse make the right balance between locales and globals variables)
In Javascript we don't have to declare a variable with var keyword before using it. We can straight away do things like myCount = 12; or myStr = "Hello"; (where myCount, myStr are not declared before). Any such usage, declares and initializes the variables in the 'global' scope.
What could be the reasons for providing this feature? And is it a good standard at all?
UPDATE: My question is not what the differences are between 'using a variable without declaring' and 'declaring and then using' and how it affects scope.
My question is 'why it is allowed in javascript to use a variable directly without declaring it' as most of the programming languages have a strict check on this.
UPDATE : I see the following quoted text as a bad effect of this feature. So, why have this feature at all?
"Suppose there is a globally declared variable x (var x="comparison string") already which i am unaware of and i with intention of creating my own global 'x' inside one of my functions initialize one(x=-1) and there i end up breaking other functionality.
So, is there any good reason at all? for having this feature?
Javascript was intended for very simple scripts in the browser. Requiring variable declarations seemed unnecessary.
Of course, it's an error in the language. And the makers of javascript know that. They wanted to change it. But they couldn't. Why?
Because Microsoft had already reverse engineered JavaScript and created their duplicate JScript, with bugs and all. Microsoft vetoed any changes, even bugfixes, since they were adamant about not breaking anyones scripts. So even if they changed JavaScript, JScript in IE would stay the same.
It's not a good reason. But it's the one we have.
Source: I got my javascript history class from Douglas Crockford: "The JavaScript Programming Language", http://video.yahoo.com/watch/111593/1710507 This part of the story is between 9 and 11 minutes into the video.
Good reasons? Honestly can't think of one, it's one of the few things I really dislike about JS.
It's possible because everything happens within the global scope if not otherwise controlled and JS allows implicit variable creation like this. The cost of this is enormous potential for scoping bugs and pollution, and only benefit given that "this" exists to explicitly define self scope and "window" and "document" exist for global referencing, is saving a few characters - which is no reason at all.
My question is 'why it is allowed in javascript to use a variable directly without declaring it' as most of the programming languages have a strict check on this.
That's the difference between statically and dynamically typed languages. Javascript is dynamically typed, so there is no need to declare first. As it was pointed out in other answers, var keyword is more responsible for scope of a variable than its declaration.
And I don't think that most programming languages have a check on that.
Lua has a similar issue: any non-declared variable is global by default. In the mailing list it's a recurring theme, asking why shouldn't it be 'local by default'. unfortunately, that would introduce very nasty ambiguities in the language, so the conclusion typically is "global by default is bad, local by default is worse"
Because it is a scripting language. Fact kids. And that is how it was designed!