Warning: This page is out of date

For a more modern take on JavaScript for CS559 see 2021 CS 559 JavaScript page. It’s less philosophical than this page. JavaScript (and JavaScript usage) is evolving so it is a more “normal” language. A lot of what is below is obsolete.

This post gives you some advice on how to learn JavaScript. It spends most of its time giving you a general strategy, and a sense of why this general strategy is the right thing. I recommend getting that philosophical dose, since it will make the reasons for the actual choices in books and stuff make more sense when they do come later down.

Warning: This is from 2015, and Javascript has evolved. New language features make a lot of the weirdness go away. Better constructs mean you don’t need to use the general functional programming mechanisms for everything.

Learning JavaScript

This is assuming you already know how to program in some other language. If you don’t already know how to program, I don’t think JavaScript is the right first language. I also don’t think it’s a terrible choice. However, the way to go about learning your first language will be different since your main focus should be on the concepts that are common across programming languages.

One interesting thing about JavaScript is that it builds on a lot of “foundational” computer science concepts. One of the cool things about JavaScript is that it provides the very basic abstractions that you can assemble into the things you need. This creates two kinds of problems: first, you must understand these foundations of how programming languages work (first class functions, scopes, environments, closures, …); second you must think about programming language feature needs in a general way so you can have an open mind about their being other ways to meet your needs (e.g. think about code re-use, data hiding, polymorphism and information organization rather than rigid classes and hierarchies). I fear that the way many intro CS classes work, they don’t do either of those things: they teach Java features, not necessarily the concepts from which they are built.

The effect of this is that the key to learning JavaScript is to see how it is a manifestation of the foundational programming language concepts, and understand how these concepts can be used to get stuff done in nice ways. The fact that the actual language isn’t an ideal representation of these concepts will get in the way – but try not to focus on that aspect. Try to focus (at first) on understanding why functional programming can be cool, why lexical scope (closures) can give you nice building blocks for making object and module systems, why a uniform and flexible type system lets you do object-oriented programming in the way that you want (for lots of different definitions of the way that you want), etc. If you appreciate that good stuff, you will not only be prepared to learn to work around the bad stuff, but even motivated to do so.

The bad parts of JavaScript will still be there. Being aware of them is important.

There are several kinds of problems with JavaScript:

1. Issues with it being different (and in some ways better) than what people are using, but people wanting to use it in the old ways.
2. Issues in it providing basic abstractions that can be used to build language features we’re used to. And often these more basic abstractions are not taught. And we’re (usually) not taught to think about programming languages in general ways, but rather just shown the specific features (not what the general issue they address are).
3. Issues where its flexibility let you shoot yourself in the foot.
4. Issues where poor design decisions make things ambiguous or misleading.
5. Issues from the fact that it’s embedded in the web browser, and the web-browser wasn’t necessarily designed to make it easy for people to write code inside of it. (but this isn’t really JavaScript’s fault)
6. Issues from non-standardization (different browsers/compilers being incompatible) – these are largely a thing of the past
7. Other historical issues. It has a name that creates association with something very different, the early implementations of the language weren’t so great, etc. Fortunately, you can view these as historical footnotes.

If you think about this, most of these issues either: don’t effect what you actually program since you will use a modern compiler in a modern browser (and for class we will let you pick 1, so compatibility isn’t a problem) or can be gotten around by taking the time while learning JavaScript to learn to think about things in the right way. Number 3 and 4 will still be there – and you’ll need to learn to protect yourself.

How can you learn JavaScript this way?

Here are three paths:

You could try to learn about the programming language foundations first. Learn to program in a functional language that is a pure instantiation of these concepts. Then JavaScript will just be “Scheme (or Lisp) with ugly syntax.” Even Python has most of these concepts (although people don’t often learn Python this way). I don’t think this is the most practical way to learn JavaScript quickly. Full disclosure #1: this was my path, except that the programming language for me to get at the foundations was one that I was making myself in grad school (called whisper). Full disclosure #2: I am a Python fan, and for me, my biggest complaints with JavaScript are often “but Python does this so much better.”

You could look for resources that emphasize those foundational concepts and functional programming in teaching JavaScript. This is the path that I recommend, providing you can find the appropriate resources. But I’ve done some of the work for you: I’ve found some resources like this, and it’s how I’ll structure my class and the resources I create.

There is one last choice that I advise against: You could pretend JavaScript is like your statically scoped, rigidly typed, simple classical object-oriented language that you are used to. You will complain loudly every time things don’t behave as expected. You will think JavaScript is silly and want to stop using it. You will miss out on the great things that JavaScript’s flexibility gives you. You will be able to survive to do small things (like programming assignments in class), but it will be more painful than it should be.

If it’s not obvious, I am recommending the middle path. The first path might be better if you had enough time (take a programming language theory class before learning JavaScript). But not only is this impractical (I am guessing you want to learn JavaScript NOW), I’m not sure its the best thing. You don’t need to know that much programming language theory to appreciate this stuff, and it tends to over-emphasize certain stuff by trying to be pure.

One downside to the way that functional programming is taught is that it often emphasizes recursion rather than iteration. Being able to use recursion where it is appropriate is important, however learning to use it for everything is not (unless you are using a language that forces you to do things this way). In practice, recursion is harder to learn, often harder to debug, and requires specialized compiler support to be efficient at large scales. To my knowledge, JavaScript is not properly tail-recursive (if you don’t know what that means – don’t worry, it’s one for the programming language geeks, but it is a beautiful concept), so there is little incentive to prefer recursion to iteration except where it is is more convenient for what you are trying to do.

Part of the reason I like JavaScipt so much is it allows me to use the cool parts of functional programming, without having to make everything tail-recursive.

So how do I take this middle path?

Well, you can take my class. Or, someday these notes might turn into a book. But for now…

Books

One aspect of web programming is that the web really is the best resource for it (usually). Books and traditional media don’t evolve as quickly, don’t provide the diversity of viewpoints, and often aren’t the preferred venues of the “real experts.” (If you’re an expert programmer, you might be too busy to write a book, but willing to share your expertise). There are downsides to getting information from the web (how do you know you can trust it?), but to be honest books have this issue too. Except that if its a blog and its wrong, a lot of commenters will point out the problems and the author can update it.

As a JavaScript textbook, Eloquent JavaScript fits the bill. At first, I liked it because it had a free online option (it is free to look at online, but you can buy a printed copy if you want). But I’ve grown to appreciate how it does follow the philosophy I discuss above. It kindof starts out in a weird way – seeming to be telling you the CS101 stuff all over again, but not in a way that would work as a CS101 book. But if you bear with that in chapter 1, it gets better quickly. I am also not fond of his silly examples. And Chapter 4, which is trying to get some deep concepts across by telling it as part of a silly story is weird: the ideas are there, but the silly story kindof got in the way. But if you bear with that, it actually presents the concepts nicely.

Eloquent JavaScript, by Marijin Haverbeke. (hardcopy at Amazon). I like this book because it is “free” (it is free online, but you can buy a hard copy from a traditional publisher). I also like the spirit of the book (because it focuses on teaching JavaScript as a functional programming language, not as a traditional language). That said, I haven’t compared it to a lot of other books, and I didn’t use it to learn myself, and I haven’t read the whole thing. After reading the whole thing, I like it even more, for reasons discussed here.

Tutorials

There are zillions of JavaScript tutorials out there. If you find one that you think is particularly good, let me know.

Some that I think are notable:

• A re-introduction to JavaScript (JS tutorial) – An official Mozilla thing. Supposedly an “intermediate level”. A nice concise description of the important stuff.
• There are actually a lot of great things on the Mozilla tutorials page. I haven’t read them all – but I probably should.
• JavaScript in Ten Minutes – A misnomer (even he admits it takes more than 10 minutes to read). But it’s useful – a programming language geek rants about what is good and bad about JavaScript, making sense of stuff by using the real CS terminology and concepts.

Tools

Web Browsers: All modern web browsers implement JavaScript well. This hasn’t always been the case. But nowadays, just about any web browser will be good enough. The differences between them are good for debates. Both Firefox and Chrome now have good compilers, debuggers, and profiling tools – I assume that Internet Explorer and Safari do as well (but I haven’t tried them). Make sure you can find the “web developer console” – this is slightly different in each browser, but gives you access to your programs error messages, console logging, as well as the debugger and other tools.

Debuggers: I recommend getting familiar with the debugger before you need it. Being able to step through your program and look at its data is really handy when things go wrong. Looking at the data can be enlightening even when things work (because something JavaScript will represent things internally in a different way than you might expect. Debuggers are built into current web browsers. Some IDEs (see below) offer connections to them.

Editors / IDEs: You can use any text editor you like to edit JavaScript code (and the HTML that loads it). Since you’re just loading these text files into a web browser, you don’t need anything more than a simple text editor. You can use notepad, notepad++, TextWrangler, emacs, vi, or whatever you like. However, you probably want to use something that is a little more specialized for web development.

A good code editor will give you syntax highlighting with integrated checking (see style checking below). They’ll give you autofill, hints about things like function parameters, and other handy things.  It will help you organize your code in various ways. Some even connect to the debugger and browser to give you an integrated development experience.

Personally, I use the tools from JetBrains. Their python IDE (PyCharm) has their web tools (HTML and JavaScript) built in. For Python its the best I’ve seen, especially for mixed language development (mixing python and web stuff). For web stuff, I’m already used to PyCharm and have it installed on my machines. I believe their web development tool (WebStorm) is just PyCharm with some features removed, but I’ve never checked. One cool think about JetBrains: they will give you a free license to the Pro version if you are an education user. There are web development environments based on Eclipse (see Aptana), there are tools from Adobe, and some people I know swear by Visual Studio (especially since it has good TypeScript support).

In the opposite direction: there are some surprisingly good development tools that run right inside the web browser. These have a ton of advantages – no installation, you can work anywhere (since your code is stored in the cloud), there is the potential for easy sharing, … From what I’ve seen (and I’ve only really looked as JSBin, and a quick glance at some others) they are mainly good for small programs (plunker might be better for multi-file development). But since you’ll be writing small programs when you’re learning …

For Example… I started using https://jsbin.com because it allows me to easily embed live code examples right onto web pages (look at the other tutorials). It has an editor with syntax highlighting (which I find helpful) and a code-analysis engine (see hinting below). One catch: to get all the cool coding features, you need to put your JavaScript code into the JavaScript pane, not the HTML pane.

Style checkers: I recommend regularly running your program through a style checker. It will point out potential problems. Things that will either cause bugs, or might cause bugs in the future (if you try to add to or modify your code). It will remind you of good habits you should get into so you will write code that is clean the first time.

Many JavaScript editors have style checkers built in (PyCharm does, even JSBin has some code checking features). Or you can go to http://jshint.com/ and paste your code in.

Source Control: You should keep your program in some kind of source control so you back up old versions. I recommend putting your repositories someone that isn’t your own local computer – either the CS file servers (AFS) or a source control service (BitBucket, GitHub). Or don’t believe me until you learn the importance of source control the hard way when you lose your work.

If you are working by yourself, there are easy ways to get the versioning/backups without a full-blown source control system. If you use a file box service (box.com, dropbox), they can do versioning. Some of the online IDEs (JSBin, for example) will keep multiple snapshots of your work. You can decide how safe, secure and reliable this all is.

Warning: this is from 2015. Some of it is obsolete – there are newer (and better) ways to do things as JavaScript has evolved.

One thing which is weird about JavaScript (in the web browser at least) is that your program doesn’t have a beginning. It is embedded on a web page, and attached to things. This brings up questions of when your code actually gets run. It is particularly important for drawing – since you want to draw at the right time.

This is a bit of web programming detail – it is more about how web browsers work than graphics or JavaScript. You need to worry about this so your web programs work.

Draw on Start

There’s a problem that when you write some JavaScript code on a web page, there’s an issue of when it actually runs. Consider the most trivial example.

JS Bin on jsbin.com

You would think that the script should run after the canvas gets created. And most of the time it does. But since web browsers are smart, they might not finish step 1 before step 2. So the canvas might not be set up before the script gets run. Or worse, you might not want to put the script in the middle of the body – you might want to load it at the top of the program (especially if you are loading it from another file).

Here’s something that plain does not work: just sticking the code into the top part of your html page (the <HEAD></HEAD> block – which I call the header, although that might technically be a misnomer). It’s not unreasonable to want to put it there – especially if you are loading the script from a file, you might want to have the browser start fetching that file before it needs it. However, if the code runs at the beginning of the web page, it almost certainly will run before the canvas gets created, and will fail.

As with most things web, there are lots of different ways to deal with this “when do I run my script” issue. The one that I use is to have the code execute when the window is finished loading. To do this, I set the window’s “onload” function to be the code I want to execute.

JS Bin on jsbin.com

As you can see, this isn’t too much different than the first example. The big difference is that I’ve put my drawing code in the header of the HTML file. However, rather than running it, I instead define a function with the code inside and assign this to the window’s “onload” attribute. This way, they code gets run when the window is done loading, so that I know that all the HTML objects (like the canvas) have been created.

If you’re a web pro, you probably would have reasons to prefer an even fancier method. But this usually involves learning about some other library (jQuery’s “ready” function seems to be the preferred approach). For this class, onload functions are probably good enough.

I had the code execute with the window’s onload. Some people put it on the body’s onload. I am not sure if it makes a difference. It might make a difference if you put stuff after the body (but still on the web page).

Draw on Update

Here I’m going to do something simple: I want to make a slider (on the web page) and have the X position of the square be determined by the value of the slider. Making a simple slider is easy: there is a “range” object that we can put on the web page. Then, in our script, we can find the slider (just like we found the canvas), and ask it for what it’s value is.

JS Bin on jsbin.com

One trick: we can’t draw the rectangle until after the slider has been made (since we need to ask the slider where we’re supposed to draw). Our “onload” trick from above can help with this.

There’s another trick: when the slider changes, we need to redraw the picture. Remember, we’re using an immediate mode API. When we draw the square, we are actually drawing the picture. If we want the square in a different place, we need to redraw the picture (for now, the whole picture – there are ways around that, but it’s a longer story).

JS Bin on jsbin.com

So what I’ll do is to make the thing that draws my picture into a function (I’ve called it “draw”). I’ll call it during the onload function. But I’ll also want to call the very same draw function each time the slider is moved. Notice the line where I “attach” the draw function to the slider, so it gets called when the slider gets moved.

http://www.impressivewebs.com/onchange-vs-oninput-for-range-sliders/

Some comments on JavaScript Style and Efficiency

Let’s think about this code for a minute – and see how some of JavaScript’s features are leading us into potential problems as this program grows more complicated…

First, notice that draw is a global variable. We can only define one draw function. If we load another module, and it wants to use the name draw, it will over-write this one. For the draw function, this might not be such a big deal – but we probably want to avoid having too many global variables.

Second, notice that on every update, we have to search the whole document for the canvas and the slider. If the document was big, this could be time consuming: and we want draw to be fast, since we want the screen to update as we move the mouse. An obvious thing to do would be to find the canvas and slider once, store them in a global variable. Of course, this makes a yucky global variable. There is also the problem that this has to happen within the onload function (because we can find them until we’re sure the page is ready).

There is a nice way to address both of these problems, using the basic features of JavaScript (the fact that it is a lexically scoped language that supports closures). This is a common paradigm of JavaScript programming that you will see a lot: use scope and closures to build other useful abstractions and achieve things (like modularity) we like.

The idea is that we put everything into the function that gets called onload. Note that in this example, I am also giving that function a name – but we could have created it anonymously as in the previous example. The more important thing to note is how all the things we might have declared as global, are instead placed inside this function – so they can only be seen inside this function.

JS Bin on jsbin.com

Notice how this solves both of the issues above. The draw function is now not global – nothing outside of the setup function can see it. Similarly, I can create other variables (canvas, slider) that are similarly hidden. Since they are inside the setup function (which only gets run at “onload”) they happen at the right time and place. And that I only search for them once when the page loads – not each time the slider moves.

Take time to understand this example – it gives you a sense of a real JavaScript programming idiom. It shows why programming in JavaScript might be different than some other language you’re used to.

Draw All the Time

Suppose I want to just keep redrawing. This doesn’t make sense if the picture isn’t changing, but if the picture is animating (changing on each frame) then I want to keep redrawing. As soon as I finish drawing, I want to draw again (or maybe wait a little while). The trick is that we want to give the web browser a chance to do other stuff too.

JS Bin on jsbin.com

Again, there are probably many ways to do this. The one I learned uses a feature called “requestAnimationFrame.” The idea is that this schedules a redraw at some time in the future. It’s a method of window.

Notice that I commented out the extra call to “draw” when the slider changes. Because the things are being redrawn all the time, we don’t need to force a redraw when the slider changes. In fact, if we ask for an extra draw when the slider changes, this will add another request for a redraw, and before we know it, we’ll have way to many requests, and things will go crazy.

http://creativejs.com/resources/requestanimationframe/
https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame

One problem with requestAnimationFrame is that it tries to go fast (60 frames per second). So a different possibility is to schedule the redraw a certain time in the future (some number of milliseconds) use “setTimeout”. You can look up how to do that. You can also look up debates as to why one is better than the other.

What you should have learned

This isn’t really graphics, but its stuff that is useful for writing graphics programs. Hopefully, you got a sense of when you can make drawing happen in your web-based graphics program: this will also be useful when we start using other APIs than Canvas. You saw simple ways to:

1. Make sure your pictures get drawn onto a web page
2. Add a slider to your program so you can change things about your picture
3. Make animation
4. Use common JavaScript programming idioms to organize your code.

Now you can use this to make something less boring!

Why do I need to write my own Canvas tutorial for CS559?

There are some good tutorials out there (I have a few on a list, but that’s just a start). I recommend that you use them AFTER this one. Before you read this one, you might want to read my post on what Canvas is and why we use it.

The problem with those other tutorials is that they all assume that you know a certain set of stuff from prior tutorials. You should be able to figure this out yourself, but in case you need to be walked through it…

You should start with the explanation of what I mean by Canvas

Then we can start…

To draw, you need to answer three questions:

1. Where do I draw?
2. When do I draw?
3. What do I draw?

But since you can’t do any without the other, we’ll look at them all together.

The simplest possible program

JS Bin on jsbin.com

Notice that this is an HTML file – you can load it into your web browser. I am using a spiffy thing to embed it on this web page so you can see the code and the output side by side. You can edit the code and see what the changes do. You might want to move the divider between the code and the output so the lines don’t wrap.

You should recognize some of the basic HTML stuff. This page is really minimal – it has no “<HEAD>" section (which is where I would set the title and other useful stuff). This is bad, since some of the stuff in the HEAD is important (like declaring the character set). In practice, you might not want to make your pages so minimal. I wanted to keep it simple here (so it fits on the screen). Later, I’ll show you a more realistic example.

In the body, you’ll see there are two tags.

The first is the canvas tag. This creates a blank rectangular space on the web page. The size is set by the width and height. I have given it a name (or "id") of "myCanvas" – this is important, since I will need to refer to it later.

The second thing in the body is a "script" tag – inside this script tag, I put my javascript code. Technically, I probably should have had the script tag say javascript – but the web browser will figure it out.

The script is simple. It finds the canvas (that I made above) by looking up its name. It then gets the drawing context from this canvas. The drawing context is the object that we use to actually do the drawing – it stores all the information about drawing state.

Aside… I could have done this differently. Rather than naming the canvas and searching for it, I could have searched for the first (or last) canvas on the web page – but this is bad practice, since it makes assumptions about the rest of the web page. In fact, I could have just assumed there wasn’t a canvas and added one to the end (or beginning) of the web page right in the JavaScript code. This is less desirable because it makes it hard to mix the canvas with other stuff on the page.

Aside… This code works and is simple, but in practice is way too simple. For example, there is no error checking. When writing a JavaScript program you need to worry about errors. Also sticking the program right in the html becomes unwieldy when the program is more than a few lines long.

Then, finally, I can actually do some drawing. Notice that I need to start a path before I can do anything. Then I add a rectangle to the path. Then I fill inside the path.

Besides the fact that the picture I drew is really boring (a black square), there are some over-simplifications in this example that you should understand before trying to draw more.

Where do I draw?

There are two parts to the where question.

The first part of the question is the space we’ll actually be drawing on. This is a canvas element on a web page. To be able to create this, you’ll need to know enough about web pages to make one that you can put a space on, and then actually put the canvas tag someplace.

Web pages usually give a lot more information about themselves, so that the browser doesn’t have to guess. It’s probably a good idea to do some of that.

You can put other web-page stuff around the canvas element – this is useful for making titles, or putting controls (like sliders), or even documentation.

Once you start drawing, you’ll need to understand the coordinate system of the canvas (so when you position things, you’ll know where things will go). For canvas, this is simple: by default, things are measured in pixels, the origin in the upper left corner, and the positive Y axis goes down.

When do I draw?

Or… where do I put my code?

If you notice, I placed my program code right in the web page within a script tag. This is OK for a tiny program like this, but you can imagine that quite quickly you’ll want to put stuff elsewhere to keep your code organized as it grows bigger.

There is another issue as to when this code actually gets executed. It would be nice to assume that everything works all linearly. The script tag gets processed after the canvas tag is done being processed, so the code inside the script tag only gets run once the canvas has been created and is ready to go. In practice, web browsers are more complicated than that. Especially since something can modify the canvas later on (for example, to relocate it to a different place on the page, or put a border around it). So, in a real program, you want to do something smarter about having your code run only when things are really ready.

I’ve written a separate tutorial about this. I recommend that you read it. Either right now, or after you finish this tutorial.

The real answer can be complicated, because it gets to questions of how to best organize your program.

But here’s a more realistic version of that same minimal program

HTML Test on jsbin.com

Here, I’ve turned off the output pane (you can turn it back on to see that the program draws the same back rectangle).

If you read the “When do I Draw” tutorial, this should make sense to you (since it’s one of the examples). If not, what’s happening is I am putting my code inside of a function that gets called when the window is done loading. But the important thing is that the drawing commands (begin path, …) happen at an appropriate time. This is a more realistic program for you to start with. I suggest that you take this and start tinkering with the stuff that actually does the drawing…

What do I Draw?

Now the fun part… we can draw stuff. Preferably something more fun than a black rectangle.

OK, here’s something that’s just a little bit better.

HTML Test on jsbin.com

Notice that drawing has a few parts (that I do over and over)…

1. I start a path.
2. I add shapes to the path, either as a whole shape (the rectangle) or by moving a “pen” around (the MoveTo and LineTo that draws the triangle). If the shape is closed, I make sure to close it.
3. I decide how I want that shape to appear. You can see I set the fill color, the stroke color, and the width of the stroke. I could set other things (like making the lines dashed, or patterns to fill the shapes).
4. Then I draw it (using the currently set style parameters). I can either fill it, or stroke it.

You’ll notice that I refer to colors in a funny way – as a string beginning with a # (hash mark) and a hexidecimal number following it. This is explained in another tutorial on color.

There are a bunch of different basic shapes (primitives) you can draw. Look at another tutorial to get a more complete list. There are a bunch of different style things you can do. Again, look at some other tutorial. But at this point, you can probably have enough of the basics so that you can start drawing stuff.

If you haven’t done it already, now might be a good time to go back to the “when do I draw” tutorial, so you can get some ideas on JavaScript code organization idioms.

There is a resource list for more Canvas info as part of the “Canvas: What and Why” tutorial.

Because I want to see what happens with the front page including multiple categories. Who knows what will happen!

Hopefully, the first 2 paragraphs will show up. So You will see this one.

But this one is the 3rd paragraph and should not show up.