New Posts

Monday, August 30, 2010

Javascript 101: The Basics

Today we'll start our Journey down the wondrous world of client side scripting.
Javascript is an object oriented interpreted language used to give websites a bit more dynamism in the form of user interactions and interface usefulness that gives the website more ease of use.

However Javascript can and frequently is overused, or misused. We'll look at how a little further into this post.

First of all what does Javascript being object oriented and interpreted mean to the web site developer.

Its interpreted, which means you don't need to compile it, as most browsers automatically understand it and interpret it on the fly.

Its also Object Oriented which means its designed to work off of little black boxes called objects that have properties and methods. That is they have traits to them and can do things.

Everything in JS is an object From the browser window, to the HTML button tag they are all objects which have properties that define them like height, width and a name, and methods; things they can do, like the click() method of a button which clicks the button and executes any associated actions.

For the Browser to understand that Javascript is present in a page it can be in 1 of 3 locations.

Between script tags
In an event of an element in the page such as onClick.
Or preceded by the javascript protocol in a link reference or address section < a href="javascript:someFunction();">

When writing Js code, you will be using objects to access and manipulate things on your page, the principal object you will be dealing with the most is the document object.

This object contains most of the other elements and functions you may want or need to access. From page elements to action events.

Its most useful functions are the getElementBy functions. These functions allow you to find an element in a web page and be able top manipulate its properties and methods.

These are getElementById, getElementsbyName , and getElementsByTagName


getElementById allows you to find any element by its ID. It returns a single element you can use, and if erroneously there is more than one element with the same ID it will only return the first element it finds.

getElementsByName returns an array of all elements that have a matching name.

getElementsByTagName returns an array of all the element of a specific type. Say all Divs all inputs, all images etc..

For instance:

var myElement=document.getElementById('theID');
This returns a reference or pointer if you will to the object or element with an id of 'theID'


To exemplify lets say you have a textbox in your page you want to manipulate when a button is pressed:


<input type=text id="myTextBox" value="Sample">

<input type=button name="manipulate" value="Manipulate Text Box">


First we need to determine when the button is pressed for that we use one of the buttons events. Events are actions that occur to the object. An action such as when the button itself is clicked would trigger the onClick event of the object. So we want to have something happen at that time.

Lets say we want to alter the contents of the text box when the button is clicked. so we use the onClick event of the button to have it execute our JS function to change the value of the text box:


<input type=button name="manipulate" id="MyTxtBox" value="Manipulate Text Box"
onClick="changeTxtBox();">


So know we've set our button to execute a function when its pressed, but what would our function look like and where should it go:

Usually our Javascript code should reside in the script section of our page, which goes in between the <head></head> tags.


<html>
<head>
<script type="text/javascript">

function changeTxtBox(){
...
}
</script>
</head>



Notice how the name of your function matches exactly what we placed in the onClick event of our button. Javascript is case sensitive which means uppercase letters are treated differently to lower case letters. so FunctionName would be different to functionname.


So now that we have our function we need to access our textbox and modify its contents. We'll want to access our element using the getElementById method of the document object and passing the ID we gave to our text box "MyTxtBox".



var OurTextBox=document.getElementById('MyTxtBox');


So we now have a reference to our text box in OurTextBox variable. From here we can manipulate the text box as require. Since we want to change the contents of th textbox which currently says "Example" we'll use its value property:


OurTextBox.value="This is the replaced value";



So at the end our function look like:


function changeTxtBox(){
var OurTextBox=document.getElementById('MyTxtBox');
OurTextBox.value="This is the replaced value";
}


And that's it. Our Button will now alter the contents every time it is clicked.

Try it out here, write something into the textbox and press the button.



By the same toke we can access many other properties of the object such as width, height, name etc...




Javascript 102: Reinventing the Wheel



There are many things that can be done with JS, but as I've said before just because you can do something doesn't mean you should.

JS is supposed help you provide a more pleasant experience to the user, but not at the cost of bugs, and strange issues because your code is so complex you have a hard time maintaining it.

If there's already an HTML element for what you want to do its always a good idea to use it rather that to try to reinvent the wheel.

The most common "Wheel Reinvention" I've encountered is of course the lowly link.
Using a button, or some other html element to simulate a link by using JS.

A few examples follow. A Div, a button, an img, and last one is an actual link.
Notice how all of them look pretty much the same, even the picture-less image. There is no point in using JS to make those things act like a link when there's already a link element.



This is a simple example which only required a single line of JS, but you may encounter other times when you want to do something when there's already something there that does it.




Javascript 103: Error Checking



When coding in Javascript its important to check for errors, as you'll find that for the most part a website will lad without complaining about Javascript issues, but your actions may not function properly.

But how does one check for error when none are shown? Simple you request them. Most Browsers offer some type of debugger to let you know that something went wrong with your client side code.

  1. Internet Explorer shows its very conspicuous Gold shield on the bottom left corner of its window. Double clicking there will bring up the debugger window when there are errors.

  2. Firefox has its Error Console which can be accessed from the Tools menu

  3. Safari has an Error Console under its Develop menu which needs to be activated from its Advanced Tab in the Preferences Dialog.



From there you can see any and all errors you may have listed, and attempt to correct them.

Monday, August 16, 2010

DSL Speed and Downloads

This is slightly tangential to the Web development side of things but its interesting to note none the less since it affects how fast the website will have downloaded to the client machine, and be ready for our users to ... well.. use.


I was going to download a Mandriva Linux ISO image to install, and I noticed by download speed was only around 30KBps (Kilobytes per second) which considering my Internet connection is clocked at 4Mb (4 Megabits) by my ISP was rather strange. I figured out I was downloading from a far away mirror server, once I changed to a closer one, the download speed multiplied to around 350KBps. So I went from a download that was going to take 16 hours, to one that took only 30 minutes to complete.

But how can you tell your speed is not right, well that's what we will be talking about today.

When the internet first became publicly accessible, we had modems with blazing speeds of 9600 Kb/s, then 14400 Kb/s until they reached the modem cap of 56Kbps. Websites were pretty much text based up until the latter days of 36K modems when we started to get more and heavier graphics, flash animations made their debut, and videos and audios starting to trickle into the web consciousness.

But alas, the modems were sadly outclassed because they just weren't fast enough to keep up with the demands of the content. At this point Web developers had to keep a careful eye on how big the site would end up being, how many images were going to have to be downloaded, and how big these files were because the speed of the modems was limited, and you wouldn't want to have your users waiting for the page to load.

Today speeds have multiplied at least 10 times what they were then, but they still cause the same amount of confusion.

ISP's will tell you you have xMb (Megabits) of blazing speed but how does that actually translate into how fast your downloads will be, or how quickly your Youtube videos will start playing. In practice downloads are measured in bytes, while ISP's will use bits to promote their blazing bandwidths.

Lets take a regular 56k modem. That's 56000 bits per second of data transfer.
Since 1 byte equals 8 bits that modem was transferring at a "blazing" speed of 7000 bytes per second or about 7 kilobytes per second. For a reference, a regular text file is about 1 or 2KB. Low res images range in 30 to 50 KB range while mid range images have file sizes in the hundreds of kilobytes, and hi res images move into the thousands of kilobytes or what we know as Megabytes. So a website, with pictures, audio and text quickly starts to add up the download time. A single 200KB image which by today's standards is pretty small, would take about 30 seconds to download through our 56K modem. So for half a minute you'd sit there waiting for the picture to come up. Granted back then 200KB files were considered somewhat large so most WB developers had smaller images sacrificing quality, but imagine a website with more pictures, and code etc... you'd be waiting for a while before you had a fully downloaded website.

Fast forward a few yeas and we get MegaBit speed plans. These DSL plans basically tell you your plan will have a download speed of up to the specified number. That is X will be the maximum speed yo can expect from the connection. However, due to the way DSL works, the speed can't be guaranteed so you'll have a variance of speed. Still there should be an operational margin where you can feel you are getting what you are paying for.

Say your DSL is offering you a 4Mb Plan at $19.99. That's 4,000,000 (Four million)
bits per second maximum data transfer or 488 KiloBytes per second. You should be expecting a bit less than that, somewhere between 250 to 400 KBps; depending on where you are downloading from, is acceptable. Anything less and you can argue you are in the next lowest price package at 2Mb. It may vary from time to time, but as long as it stays more consistently in that range your o.k.

Online DSL speed tests calculate this by measuring how long it takes for you to download a specifically sized file.

If you want to try out your speed, here are a few sites that offer speed tests.