Also, because there is client-side JS and server-side JS, there's a tendency to, when we switch between environments, have a blurred perception of what our capabilities in the language now are.
Let's take a closer look. Browse the docs, and see if what I'm asserting below matches up with your findings:
windowrefers to the global object to which your current (literal) window is scoped.
documentis an object which refers to the current HTML being served on the page, and is scoped to the
eventis an object which is constructed whenever a new event is triggered, and is scoped to the object that invoked it.
The functionality that the browser provides you doesn't end with the DOM. On the frontend, there are several more APIs which you are likely to interact with, all of which fall under the umbrella of "Web APIs":
I hope I've made my message clear at this point: When you write code for the frontend, the majority of what you're doing is utilizing these APIs which are exposed to you. So what happens when you take the browser away?
> node > document.getElementById('target') ReferenceError: document is not defined
Our implementation of JS is mostly due to the nature of the kinds of problems we're solving as web developers. Familiarizing yourself with this pattern will help you approach problems with a far more keen mindset than otherwise, and will greatly aid in understanding the details of what you're working with.
Elements are the "things" that live in your environment; in particular, they are the "things" that, we've decided beforehand, are going to be the primary targets for our code.
On the frontend, they're often DOM
Elements, like a
div or a
button. On the backend, "they" is often singular, in the form of the one server that the browser is interacting with at the time. In both cases, we generally choose these as our elements because they are prone to some kind of interaction with the user.
Sometimes elements contain inherent data, like HTML attributes or other properties. Whatever they are, they're kind of just hanging out until something happens to them.
Listeners, you might infer, listen for events. When a user clicks a button, an event is called on the button, and the button's listener "hears" that.
That button might then send some data back to the server, where that data is received as part of a request. The server then presumably does something with that data.Both the button and the server likely had listeners attached to them which allowed that data to move from client to server, and from the server to wherever its final destination is.
Clearly the only way for a listener to be valuable is attach it to an element, and that syntax is almost always something like
However, it's not the listeners which actually move that data. That responsibility is given to the final piece of this puzzle...
When we tell the browser to send data to a server when we click a button, we are defining that button's behavior.
Behavior is defined by handlers, or handler functions. This is the meat of your program, as you're defining what happens when an event is triggered on an element. To continue with this example: You might assign the behavior of "send some data to the server" to a button. You might also assign the behavior of "when I receive this data, send back an HTML file" to the server which receives the data.
Obviously, there is no one definition of what "a behavior" is. That part is up to you, and lucky for you, defining the behavior of your script is the fun part!
I hope you enjoyed this short breakdown!