JavaScript Good-to-Knows and Other Stuff

One cool thing I learned in class today Austin Coding Academy bootcamp is all about loops, and how they are essential for processing and manipulating data structures. The most basic loop of several is the for loop, and one of its most common uses is looping over an array. For just one simple example, suppose we wanted to write a function that could take in an array of numbers and return a new array of each of those numbers multiplied by 2. This could easily be accomplished with a for loop as follows:

// create a function that takes in an array as it's argument
const multiplyArrayByTwo = (arr) => {
// initialize an empty array that we will push our new manipulated data to at the end (in this case each of the numbers of the initial array multiplied by 2)
let arrayTimesTwo = [];
// loop over that array from index 0 until the end of the array
  for (i=0; i<arr.length; i++) {
    
// create a new variable called product to store the number at each index multiplied by two
   let product = (arr[i]*2)
// then push the product to our new array 
   arrayTimesTwo.push(product)
}
// finally, return the new array completed with all the new data
return arrayTimesTwo
}

Invoking this function on an array that equals [1,2,3], for example, will return a new array [2,4,6].

The difference between == and ===

In JavaScript, == checks if two variables are equal to one another without regard for their datatype. Whereas ===, which is stricter, checks if two variables are equal in both content AND datatype. For instance, if I have 10 declared as both a number datatype and a string datatype in two respective variables, const tenNumber = 10 and const tenString = ‘10’, then tenNumber == tenString will be true, whereas tenNumber === tenString will be false, because in this later, stricter case, these two variables do not have the same datatype.

Similarly, another example of how paying attention to datatype is critical in JavaScript is the case of the value of foo in const foo = 10 + ‘20’; If we console.log(foo, typeof foo), we will see that is equals 1020, and is a string and NOT 30, a number as we might expect. The reason for this is that ‘20’ is a string, so when asked to evaluate 10+’20', Javascript concatenates ‘20’ to 10 returning a new string 1012. So if we wanted to get the actual numerical sum of 10 plus 20, we would need to remove the quotes from the 20, so that javascript will understand it as likewise a number datatype, and not a string datatype.

What a terminal application is

A terminal application, or command line application, is an application that is meant to be run in a text editor or shell environment only, without a Graphical User Interface, (GUI), often pronounced ‘gooey’ by developers. For example, Git software is a terminal application. Also, many javascript applications are first developed and tested as terminal applications only via node.js, well before being connected to a GUI, which would be the HTML page with all of its user friendly CSS decoration.

The ternary operator

The ternary operator ?/: is one shorthand alternative to a singleif/else statement. The ? checks if the condition is satisfied, and if so executes the code following the :. For instance if we had an if/else statement to check if a number n is even:

const myFunction = (n) => {
if (n%2 === 0) {
return true;
} else {
return false;
}
}

It could be rewritten shorthand with a ternary operator as

const myFunction2 = (n) => {
return true
? n % 2 === 0: true
? !n % 2 === 0: false
}

Some ways to ensure that your website design or web application is accessible and user-friendly.

To ensure optimal accessibility and user-friendliness for a website, the short answer is that it should be as intuitive and simple as possible for the user. The page should load in less than 2 seconds, and every aspect of the design should have an obvious purpose. Just a few of many practical examples of what this means include: opting for simpler navigation over menus that require endless clicking or scrolling, choosing colors that are easily perceived and do not clash even for those who are colorblind, using animations and transitions practically and subtly to help communicate that the user has interacted successfully with page features — instead of as confusing and flashy distractions. It also includes making good use of semantic elements in HTML 5 so that screen readers can clearly communicate the content of a page to users with visual impairments or other disabilities, as well as making sure any CSS styling does not change the order of those elements so as to cause the screen reader to be inconsistent with the actual content of the page. Again these are just some of the continually evolving best practices in accessibility and UX/UI. For more of an idea of how factor likes these and more come into play, check out this Simple Guide to Web Usability from digital marking consultant site Quicksprout.

My favorite features of HTML5

One of my favorite features of HTML5 is definitely the <canvas> element! I love the endless possibilities for drawing on the canvas with the built in javascript methods. My latest implementation of HTML 5 canvas for a frontend project is my using it to draw islamic star patterns. Check out a codepen example here.

You can also see a full frontend I created with multiple patterns at my github repo here: https://github.com/Michael-Fares/IslamicStarPatterns

The importance of commenting code

Making sure that I leave detailed comments through all the steps of my CSS and Javascript code is a critical part of how I keep it well structured so that both myself and other developers can read and understand easily what it is supposed to do. When I first started coding, I made the mistake of not commenting enough, and was surprised at how easily I could loose my own train of thought as to what the code was supposed to be doing in the particular project, even after returning to it after a hiatus of only a day or two!

Addressing browser-specific rendering problems

To address browser specific rending problems, my process so far is something like the following:

1. I check that all my HTML tags are validated (properly nested and closed). One great tool I discovered for this recently is the W3C Markup Validation Service, which lets you upload your code, checks it, and and gives you a list of any validation errors.
2. I make sure I have used a CSS reset sheet and linked it to all pages in the project. CSS reset is critical because it overrides the different custom CSS spacing rules most browsers have built in, and therefore ensure that your layout will be the same on all browsers.
3. I test my project on as many actual browsers and devices that I can, and I address any issues from there.
4. For things still not rendering consistently, I double and triple check that I have included the correct vendor prefixes for each browser, which it is a best practice to include for things yet to be fully cross-broswer standardized, such as CSS animations and transitions, or certain experimental APIs.

So far, one browser that seems to be uniquely challenging to work with is Microsoft Edge and its older predecessor Internet Explorer. An example of this is having to put a second unique <meta> tag <meta http-equiv=”X-UA-Compatible” content=”ie=edge”> just to ensure proper rending on all versions of Microsoft browsers.