MARKUP LANGUAGES SHORT CONTINUATION
Let us recollect on what we can find in the “front-end” layer:
HTML– is our stack of gears. Every website on the internet is a structured file stored on a device. Always ready to be sent to anyone that requests it. Whatever information is passed through the www, needs to be understood not only by users but computers as well. Therefore, we use markup to help our dear computer in differentiating . What’s for us to see and what’s for him to do.
CSS – is our oil. A car’s gears will grind and chip away if there is not enough oil pressure. Similarly, text by itself is tedious to look and navigate through. Meaningful placement, highlights and colour, images, and responsive design contribute to bringing our paragraphs to life. But there is so much you can do, with the above. Two gears turning and some engine oil to keep the scraping to a minimum isn’t going to cut it. We are in need of some interaction to happen.
JS as OOP?
For instance, a car service register keeps records of several manufacturers, models and detailed description on changing parts and general maintenance. While every car has its own proprietary systems design (Mercedes engine vs Toyota engine) they share the same template. Name, number, technicalities. A template entry for a specific car resembles an object attributed to a specific class. As ruled by “The Clean Code” classes receive their names by convenience. So… We’ll call this one: “car maintenance register”. Now, whenever you need to access data for a particular auto vehicle, all you have to do is search through a specific number of objects within the “car maintenance register” class, and voilà: you can view & manipulate the object’s properties according to your needs.
The internet has come a long way and its initial purpose has changed since the 90s. Starting from the first web browser, developed in 1990 by Tim Berners-Lee for the NeXT Computer, we have witnessed an indisputable growth.
What was once lines of text, came to be a fully customizable experience and is yet to achieve its final phase. Our story starts in September 1993, with the release of NCSA Mosaic. The first time a browser displayed images in line with the text. Prior browsers provided a non-seamless experience since they required the user to go through a few steps before viewing a multimedia piece.
THE PATTERN IN THE BELT
Each entry of the tree is called a node and depending on its position in the tree, relative to other nodes, we can differentiate the following:
- an element node – the most basic term of any element of the DOM.
- a root node – just as the name implies, it’s the origin seed from where everything sprouts. In the case of HTML, it’s always HTML node.
- a child node – a node directly inside another node.
- a descendant node – Similarly to you not being a child of your grandparents, and yet being one of their descendants, the elements of the DOM are subject to the same logic.
- a parent node – the opposite of the child node.
- a sibling node – brothers and sisters of a child node that sit on the same level.
If you want to observe proof of concept, hit the f12 key (developer tools) in any browser and view the current page DOM.
As previously mentioned, web-enabled applications are built from marked-up documents. Regardless of the language used to do so (XML, HTML, xHTML), the DOM doesn’t take into account the media content within the file. However, it does care about some of the tags found inside such as: <div></div>, <section></section>, <image>, <p></p> to name a few. For instance, a family tree branch embodies a picture accompanying a small description, usually the date of birth and/or profession. When building the DOM the browser disregards whatever description there is, it only cares about the branch as a whole and assigns a node correspondingly. Therefore, the DOM doesn’t describe objects in XML or HTML files, it describes XML and HTML as objects.
Creating the DOM is a multi-step process. Once the requested HTML file reaches a computer, the browser will attempt to create a DOM and in the process of doing so loads it up into the RAM. Any changes done through the DOM interface remain in the memory and do not reflect on the source file, just as writing on a copy doesn’t change the original file.
Now that we solved the mystery of what we are working with, let us talk about how a developer goes about changing these particular elements. There are no special actions required to access the DOM. As we have mentioned before, different browsers exhibit different implementations of it, but due to structural isomorphism, you get the same result.
We will avoid getting into various implementation scenarios here. Instead, let’s just graze this subject enough to give you an idea regarding basic DOM procedures.
<code>var element = document.getElementById(id);</code>
Let’s unfurl what exactly is going on here:
var element – used to declare a variable. In simple terms, this element instructs the computer to reserve memory for a variable called “element”. Think of it as the recordkeeping of a student’s name.
= – represents the operation of an assignment, just like the action of actively typing a student’s name under a reserved field, in that school register.
document – the interface used to access the file itself. It’s important to understand that this interface can’t access content outside its reach. A perfect analogy would be how you can only have your mouse click one thing at a time. While multiple applications run on your desktop, only one holds input.
getElementById(id) – a method of the DOM API, used to search a document and return an element equal to the inputted parameter. Now that was a lot of nerdy words. Let’s go back to our car example. In attempting to fetch information about a particular piece of a model, first we would have to search its part number in the registry and to do so, we need the right decimals, or the “id”. Now, access is available to all the data regarding this piece.
Just as other elements of the web made technical progress, the “pattern” interface had to provide the required support, hence, it evolved as well. Several levels contributed to maintaining an even ground between elements and scripting possibilities. While they may be obscure, I believe it’s necessary to at least mention this cycle.
- DOM Level 0 or Legacy – marks the first attempts of modifying a HTML document. There was no standard so might’ve been pretty convoluted to go about it;
- DOM Level 1 – initiates a set of interfaces aimed at introducing basic functionality when working with marked-up documents (XML & HTML);
- DOM Level 2 – contains a number of pillars supporting basic operations. It implements accessibility and editing of an object’s style sheet, event handling, as well as an iteration through the logic tree;
- DOM Level 3 – addresses document validation as well as loading and saving. Elaborates event handling through Keyboard events implementation.
BACK TO THE PRESENT
Once again, I’d like to highlight that we are still within the “front-side” layer.
As such, your computer’s browser does most of the horse-work. Whatever instructions the mastermind creator has designed, will use the resources available on your PC. CPU (central processing unit). GPU (Graphics processing unit). Disk, Network utilization – are all dedicated to working on the task at hand. Worry not about performance hits, modern computers do millions of tasks within seconds. There is no delay in content delivery since everything is happening on your PC and there is no need to communicate with the server just yet.
After loading a beautiful website with moving contents and interactivity, you might want to sign up for their services. You pull up the registration form, insert a password with special characters and try to go over other fields.
A red field will appear saying you’ve inserted an unaccepted character and require you to type another password. There was no need to send the password to the server for it to be checked if it fits the required parameters. This is a simple example that as a sole won’t affect the performance of a server, but if you scale it up to thousands of users the feedback can be quite devastating.
Therefore, a reduction in data requests results in decreased server load. In a nutshell, that’s how client-server relations work: when server load reaches capacity, services are slowed down for everyone, so reducing the strain indirectly allows for more people to use it.
TO SUM IT UP
So far, we’ve talked about the performance & efficiency side, however, those aren’t the only redeeming qualities. The multiple ways of combining different systems to create your “custom-car” is what JS is about. From slideshows to fully animated transitions, the possibilities seem endless. You can get a live application that speaks with its user one way or another: data input and validation, event handling, interactive objects enriching your experience as a user at the cost of just a few milliseconds attention span of your computer.
One last point to mention is how versatile the language has come to be. Initially developed just as a “belt” for text and image gears, it currently features numerous implementations, branching out of “front-end layer” and heading straight to “server-side scripting” as well as “database layer”. I won’t name the frameworks or framework-like libraries since I will be expecting you to visit our next episode “5 JS Frameworks and Libraries that will serve you well.” Until then, don’t forget to follow our Linkedin, Facebook or Twitter feed, to explore more about who we are, what we do and how we’re bringing development to the next level.