What is a function?

I’m trying my hand at writing a ridiculously easy-to-follow guide on JavaScript essentials. There might be many of these out there, but this one is mine. Tell me what you think and whether I can clarify or simplify at any point.

In JavaScript, a function is a bunch of code that can be run, or called, repeatedly.

Creating a function

Here is an example of a function being created:

var doStuff = function () {
  // Code you want to run goes here!
}

In this example, we are first creating a variable called doStuff. doStuff is then being assigned a function as its value – which means, from now on when we refer to doStuff, we are referring to a bunch of code that can be called.

Calling a function

Whenever you see parentheses following a variable, it means we are calling a function – the code inside it will be run:

doStuff(); // the doStuff function is being called.

This is in contrast to just referring to a variable, which is valid, but doesn’t do anything:

doStuff; // no-op

Arguments

Some functions can change what they do, based on how they are called.

When we are writing code for the browser, we automatically have access to a function named alert, which tells the web browser to pop up a dialog box. When we call alert, we need to specify what exactly to show inside that dialog box:

// the alert function is being called with the string 'Hello!'
alert('Hello!');

In this example, we are putting a string inside the parentheses. Anything placed inside these parentheses is called an argument. In the case of alert, the argument determines what text appears in the dialog box that shows up:

Screen Shot 2013-04-05 at 5.19.18 PM

If we want to create a function that makes use of an argument, it would look like this:

var takeThis = function (foo) {
  // Inside these brackets,
  // we have access to a variable named foo.
}

// foo's value will be "Hello!" when the function is called.
takeThis("Hello!");

// foo's value will be 3 when the function is called.
takeThis(3);

In this example, we are saying that whatever is passed in as an argument when we call takeThis will be referred to as foo as the function runs. We can name the argument whatever we want, but it only affects how it will be referred to inside the function’s code.

Returning

Functions can also give back a result after they’ve been called. This is called returning. Returning is important if we want to receive the result of a function and use it someplace else:

var giveMeSomething = function () {
  return "Here you go";
}

var something = giveMeSomething();
// now something's value will be "Here you go"

In this example, we are using the command return to specify what comes out of the function when it is called. Upon calling giveMeSomething, we are taking its result and assigning it as the value of a new variable named something.

Multiple arguments

Functions can accept multiple arguments. It is as simple as separating the values being passed in with a comma. In this example, we are creating a function that can add two numbers together and return the result:

var add = function (addend1, addend2) {
  // add the two arguments together and then return the result
  return addend1 + addend2;
}

// pass 1 and 2 when calling add and assign its result, 3, to sum
var sum = add(1, 2);

Having called add with 1 and 2 as the arguments, those values are then assigned to addend1 and addend2, respectively.

Calling functions inside other functions

There’s nothing stopping us from calling functions within the code of another:

var sayHello = function () {
  alert("Hello!");
}

Here, we’re creating our own function and calling it inside another function we’re creating:

var bar = function () {
  // do something
}

var foo = function () {
  bar();
}

foo(); // call foo, which will call bar

Here’s a more complex example where we’re passing in arguments and getting things returned to us:

var bar = function (arg) {
  return arg - 1
}

var foo = function (arg) {
  return bar(arg) - 1;
}

var result = foo(3);

Seem complicated? Hover over these steps to see how this code will run:

  1. bar is defined and assigned
  2. foo is defined and assigned
  3. foo is called with 3 passed as the argument
  4. foo begins to run, with arg having a value of 3
  5. bar is called with arg passed as the argument
  6. bar begins to run, with its own version of arg having a value of 3
  7. arg is subtracted by 1, and returned
  8. The result of bar(arg), which is 2, is subtracted by 1, and returned
  9. The result of foo(3), which is 1, is assigned to result.

Passing functions into other functions

To take it one step further, we can even pass functions themselves as arguments:

var bar = function () {
  // do something
}

var foo = function (callMe) {
  // we are assuming that the argument is a function
  callMe();
}

// we are not calling bar here,
// merely passing it in as an argument while calling foo
foo(bar);

This last example might take a bit of time to understand. The difference between merely referring to a function versus calling it is an important distinction.

  1. When we run foo(bar); we are calling foo, but not calling bar – remember, we don’t see a pair of parentheses following it – we’re only referring to it and passing it in.
  2. When foo begins to run, it has access to a variable named callMe. Having specified the function bar as the argument, callMe now refers to it as well.
  3. callMe, or bar, is called.

Why would we want to do this? So we can call foo multiple times and tell it specifically which function to run each time. In the real world, foo would do more than just call another function – it might do something with the result of that function, or return something itself.


That’s it for an introduction. I’ll see if I can write something about more complex topics like scopes, this, recursion, closures, asynchronicity, et cetera – but we’ll start here and see how it goes.

New website: Jeffrey and Anna

At work and at play, I’m always makin’ websites! Shortly after getting engaged at the beginning of the year, I started brainstorming on how best to tell family, friends, and the world at large about us. Naturally, it would be a website, but I realized I’d have to pick up a pen and pencil for the first time in years if I really wanted to make it special.

Screenshot of Jeffrey and Anna

After a few months of tinkering, I present to you Jeffrey and Anna, a super-fun, animated adventure through our life. Everything has been coded (save for some plugins) and drawn by me, and written by both of us.


What follows is a bit of a technical walk through the site.

Jeffrey and Anna is, naturally, pure HTML, CSS, and JavaScript. It adapts to different resolutions and form factors with media queries, using the same technology to gracefully degrade for less capable browsers. The site is very different from on a desktop computer, but hopefully just as usable, when you view it on a phone or tablet.

I drew everything on paper, scanned it, and colored it in Photoshop. I designed the site to use different complementary color schemes for every section, and further personalized it with Google Web Fonts and Font Awesome.

Superscrollorama is the engine behind the animations which happen as you scroll through the page. I slightly modified the library to detect whether you’re scrolling up or down, and to cause certain animations to start from wherever you currently are on the page.

I used certain parts of Twitter Bootstrap. Scrollspy causes our clothes to change as we jump through the sections, and Carousel provides CSS-animated navigation between subsections.

The site runs on Rails, my current web application framework of choice. Being database-driven, it doubles as our guest list management tool, as we can easily create invitations for guests by using RailsAdmin – and guests can enter their automatically-generated RSVP codes to instantly notify us of their attendance.

The stylesheet is written in Sass + Compass. Compass’ astounding ability to automatically generate sprites would have been an amazing help, given the massive amount of images on the site, but unfortunately, the sheer size of the sheets it generated caused the site’s performance to slow to a crawl. It turns out that it’s not a good idea to have dozens of images at tens of thousands of square pixels moving around on the screen at once. Instead, images are individually crushed and preloaded.

A little easter egg: some of you will see a little range slider in the lower-right corner of the page. Use it and see what happens!

I feel that this site represents the epitome of my current skills. It’s a bit hard to poke through the files on the site as it’s minified for best performance, but fortunately, it’s all open-source! Please poke through the code on GitHub, and feel free to comment (or create an issue) with any suggestions.


For those who are wondering, we haven’t sent out invitations yet! There’s still the task of combing over the list with the parentals, and then collecting the physical addresses of almost a hundred families. It’ll be a few weeks. But do be on the lookout soon for the location and date of our wedding!

Website Review: Treasure Island Music Festival 2010

mentioned she liked reading my rants on how websites are built, and since I’m in the website-building business, it makes sense that I’d have some insights on what’s what. This is not to say that I’m an authority on how sites should be built, nor am I the only one spending time nitpicking. There are sites that focus on the whole package, like Sitecritic.net and Web Pages That Suck – both of which, for some reason, have pretty bad UI – but are thorough and well-written. As a developer, not a designer, I’ll try to focus mostly on use of code, and how websites that look just fine could greatly benefit from a bit of code rewriting.

(I don’t know if I’m going to write even more than one of these, so I decided I’d stick this on my personal blog for now.)

The lineup for the 2010 Treasure Island Music Festival was released yesterday. I’m pretty excited about everything on day 1 (being more of an electronic than indie guy). The color scheme for this year is a little strange (reminds me of a rotten fruit salad) but otherwise I like the design they’re going for. I was a bit appalled when I took a look at the code and a hodgepodge of tables jumped out at me.

The tables, Duke! The taaabblles!

There’s a myth that the <table> element is an awful, taboo, even deprecated thing that shouldn’t even be thought about when it comes to putting a site together. It’s false: <table> is great for, well, tables. Spreadsheets. Charts of data. Anything that can be logically arranged in rows and columns. But I don’t see any spreadsheets on this page:

Rotten fruit salad

In fact, I don’t see any rows or columns at all, in a traditional sense. I suspect tables were used to “speed up” development, as this reeks of a “slice and dice” job, where the developer was given a mockup and he decided, for some reason, to splice it into tiny bits and shove it into a series of convoluted tables with rowspans and colspans.

Bottom line: splicing is baaaad. I can’t think of a situation in which splicing would be a good thing to do. When you splice a PSD into tiny images and scatter them throughout a page, you do a few things:

  • You waste time taking apart an existing design and putting it back together, when you don’t have to
  • You make a page hard to maintain – what if the design changes?
  • You increase the amount of HTTP requests by a buttload
  • You doom a page’s SEO value by increasing load times, removing any opportunities to make a page semantic and machine-readable

The developer, instead, could have exported the entire design as a single PNG (oh god, I just noticed that they’re all GIFs), set it up as the background of the main site container, and overlaid some absolutely-positioned lists, whose text content is hidden via CSS. That is to say, the site with styles disabled would look something like this:

Treasure Island Music Festival

October 16 & 17, 2010

  • LCD Soundsystem
  • Deadmau5
  • etc…
  • Belle & Sebastian
  • The National
  • etc…

And with CSS implemented, the site would still look like it does above.

I am generalizing in one area, though, and that’s with hover states. If you yearn for the days when your visitors could be whisked away to a magic cyberspace of interactivity, then I guess you gotta implement your danged hover states one way or another, so you do have to splice the PSD and save the images individually (or turn them into sprites, or something equally clever), and use CSS to specify what shows up when you hover where. Instead, this site uses a horrid cocktail of JavaScript and invalid HTML attributes (srcover? oldsrc???).

In general, this a site that, despite being functional and pretty-looking, makes me want to smack the developer upside the head. It lives in a world where <table>, <div>, and <img> are the only HTML elements worth using, substitutes CSS for deprecated/invalid HTML attributes, loads a million images when in a perfect world it wouldn’t have to load any (web fonts! SVG! etc.!…), and sacrifices any chance of being accessible to search engine bots or those with disabilities (no meta tags, no alt text, not a hint of semantic HTML usage).

Boy, this was kind of therapeutic. If you found this at all interesting, feel free to send me some more examples. I’m looking to rant about recent, small-scale sites that aren’t overtly horrible but could use some work. Or I’ll find ’em instead.

Binary Image Converter

Binary Image Converter

I made another HTML5 toy! It deals with binary images that print ASCII messages when converted, and vice versa. Try it out!

Last night, I noticed chickensnack‘s favicon on his site – I converted it to a binary string by hand (by literally typing out the 1’s and 0’s), and then feeding it through a binary-to-ASCII converter I found through Google. I decided that there must be a better way!

I wrote this toy to function almost entirely in JavaScript, so everything except form submission and image verification happens in JavaScript. This includes the actual pixel manipulation to read or generate a bitmap, thanks to data URI and canvas.

I learned how ASCII and binary are converted from one another – JavaScript has a handy function to parse a binary digit into an integer (parseInt(x, 2)), but not the other way around. I also learned how to convert images and canvas data into base64-encoded data URIs, meaning that I don’t need to temporarily host an uploaded image on my server – just process it in memory and spit it back out in the response.

This toy (currently) only works with ASCII, meaning you’re out of luck if you try throwing Unicode in there. And also due to the way that browsers display non-printing ASCII characters, you’ll run into problems if you try encoding any old image into ASCII. Perhaps I’ll create a variation that converts the binary into base64 intermediately, so non-ASCII characters can be displayed properly. This would be incompatible with the version I’ve made, though.

Some examples for you to try:

Source for this can be found here: