Welcome to the second installment of the “A Brief Introduction to JavaScript” series. In this post, we’ll be discussing JavaScript as a front-end or client-facing language. JavaScript has become, and is to this day, the de-facto standard programming language of the web, and for good reason. It’s universally supported by all modern web browsers, standardized, and honestly, a really good language overall especially due to its dynamic nature and seamless integration with the Document Object Model (DOM).
Why JavaScript as a Front-End Language?
That seamless integration into the DOM is a large portion of what this post is about—the fact that JavaScript can quickly and effortlessly integrate with a website and add to, change/modify, remove from, and manipulate the DOM, or the code on the webpage. It’s so seamless, in fact, that you don’t even actually need to put the code on the website, as most modern browsers will let you test JavaScript directly in the Web Developer Console (<CTRL> + <SHIFT> + <K> in Firefox). Okay, so maybe that doesn’t attest to its seamlessness, but it does mean that you can test JavaScript on any webpage on the internet by simply plugging it into your console. Since the console is managed client-side, this change only effects the page you’re currently on, and cannot affect any other users, or the website itself.
Let’s take a step back and introduce some of the basic ideas from the programming side of JavaScript. Like many other programming languages, JavaScript has variables, functions, objects, operators, expressions, and a ton of other constructs that are utilized in order to create scripts. Unlike many programming languages, however, JavaScript is relatively loose in its declarations and evaluations of these concepts—which allows you to manipulate the scripting language itself to produce some awesome products, even if it’s not “the right way” or “the intended way” for those constructs to be used.
Some ways WE use JavaScript
For example, in building our framework, Arrow, we ended up using several different JavaScript libraries (both written by our team, and by external resources) in order to create and facilitate the process flow we wanted. Occasionally, we end up running into code collisions—when we reuse a variable that another piece of code is using, or redeclare a function by the same name and break another portion of the framework’s code.
In order to combat this, we’ve taken to one method of avoiding these collisions: we save all of our new libraries to objects. What does this mean, exactly? Well, instead of declaring some code like this:
function myFunction(args){ //do something awesome here } myFunction(var);
Where there is an opportunity for collision globally on the function name, we instead declare that function as a part of an object—generally, we create an object for each feature-set within the framework:
var myObject = {}; myObject.myFunction = function(args){ //do something awesome here }; myObject.myFunction(var);
This doesn’t remove the opportunity for collisions entirely, but it does change the scope of those potential collisions from global, to within (in this case) the myObject
object.
So, how do we use JavaScript as a front-end language here at Armor? Well, let’s use this website, for example: if you take a look at our homepage, the first thing you’ll probably see is our banner slider opener—this is made primarily with JavaScript. We create a timeline object that holds different variables on how long frames last, how many frames there are, which are tied to the navigation frames, where the text starts, the animations/classes that need to be applied, and more. We initialize the container and then use JavaScript (in this case, a library called jQuery) to add and remove CSS classes from the elements to slide them around, change opacity, and generally create the animations and interactivity you see in the slider.
Another thing you might have noticed on Armor’s website (if you’re on mobile, anyway) is our mobile hamburger menu. This menu is initialized by a JavaScript library we wrote in-house, that checks the size of your screen, and then engages or disengages based on that screen size. It wraps the core menu in a few new <div>
tags to allow for our CSS styles to change it from what could be called a “standard” desktop menu into the hamburger, hidden-until-opened mobile menu.
One thing you might not have seen on our website actually has to do with our featured blog posts section of our homepage. This section’s data is actually populated on page load with JavaScript, using an Asynchronous JavaScript and XML request, or AJAX request for short. This section is actually empty at the start of the page load, but once the JavaScript parser is initialized it asks a PHP script on our server to give it the most recent featured blog posts. That PHP document queries our database for those posts, formats the DOM properly, and returns it to the JavaScript which then appends it to the blog posts container.
jQuery and the role JavaScript libraries/frameworks
I mentioned the JavaScript library jQuery above, primarily because it’s the main library we work with, even more so than vanilla JavaScript. Libraries are an additional benefit to a language like JavaScript—since it’s so accessible, just about everyone has a library, function, or chunk of code to share. We use jQuery because it takes a lot of the functionality of vanilla JS and expands upon it, while making it easier to work with. As a brief example, AJAX in vanilla JavaScript can look something like this:
var ajaxHandle = new XMLHttpRequest(); ajaxHandle.addEventListener('load', ajaxListener); ajaxHandle.open("POST", "https://www.example.org/ajax-endpoint.php"); //the send() function takes url-encoded parameters as the POST data. //ex: "foo=bar&baz=foo" ajaxHandle.send(); function ajaxListener(event){ //do stuff with the data returned by the POST event var the_response_data = ajaxHandle.response; }
But with jQuery, we can shorten that exact piece of code to roughly 3 lines:
$.post('https://www.example.org/ajax-endpoint.php', {foo: bar, baz: foo}).done( function(returned_data){ //do stuff with the data returned by the POST event var the_response_data = returned_data; } );
The jQuery library is a wrapper for vanilla JS in many respects, making it a little easier to work with. This, however, does not mean that it’s good for every project. The compressed version of jQuery is around 75KB of data, which is a huge amount of bloat, honestly. This is one of the main reasons I say it’s not good for every project. There is also chatter around the internet (usually by startups) that jQuery is a dead library, and that frameworks like React, Vue, and Angular are the only important JavaScript libraries to use. I say to each their own, but working in jQuery is relatively intuitive, it definitely makes things easier to work with, to understand, and to scale, and I see it on TONS of websites still—so it’s probably in a web developer’s best interest to at least be familiar with it.
These are just a few of the things that the development team here use JavaScript for on basically a daily basis. From animations and effects, to swapping out content, and even to interact with the server behind-the-scenes, JavaScript is a super powerful and flexible language. I dare you to find a language that is more robust, more universal, or more widely used—but I’m not sure you’ll find anything in that realm of possibility (at least, not in 2019). JavaScript is a keystone for almost any developer, and these front-end uses hardly scratch the surface.
Thanks for joining me for the second entry in my “Intro to JavaScript” blog series. At this point, we’ve talked about JavaScript as a whole and JavaScript as a front-end, client-facing language. The next entry will discuss JavaScript’s many other uses on the web and otherwise—from back-end and server-side applications to software applications and so much more! If you’d like to see us talk about something specific, just let us know on our social media or fill out our contact form at the bottom of this page. I’d like to personally thank you again for keeping up with this series, supporting myself and Armor Techs, and allowing me to do what I love every single day—you guys rock!