Elisabeth Robson

Ranch Hand
+ Follow
since May 14, 2004
I'm co-author of four books in the Head First Series, and co-founder of WickedlySmart. My books are Head First JavaScript Programming, Head First Design Patterns, Head First HTML and CSS, and Head First HTML5 Programming.
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Elisabeth Robson

Congrats to Asif, Rob, Margaret and Paul!

And thank you all so much for having us here this week. We really appreciate your questions.

Yes, I agree B. Thank you for having us here! Being on javaranch is always so much fun.
Hi Saumyaraj,
Head First JavaScript Programming is very much the same as Head First Java in terms of style and presentation. However, the content is obviously very different But the same idea: we cover the language fundamentals.

We don't cover jQuery or Ajax; we cover Ajax in Head First HTML5 Programming, and jQuery is covered in Head First jQuery (not our book).

You can check out a sample chapter here to see what it's like: http://oreil.ly/1mvCjfE


Hi Paul,
Yes! I agree, it is truly amazing. And it's changed so fast.
The plethora of tools, libraries, frameworks, testing tools… it's overwhelming.


Thanks Bert.

I do think just maybe JavaScript might get off the ground. . .

Hi Paul,
Not specifically, although we do have a chapter in which we develop a larger program using the Model View Controller, and develop each piece independently.

We don't cover RequireJS or any module framework in the book.

Hi Vladimir,

For (1) I'll refer you to this thread: http://www.coderanch.com/t/631821/HTML-CSS-JavaScript/Differences-Head-JavaScript

(2) I'm not quite sure what you mean by "compatible". We teach how to use some of the language features that JavaScript: The Good Parts says are "bad", because you can't really avoid them entirely. We do try to point out how to be careful using these features. For instance, we don't come down quite as hard on the == vs. === issue; however, we do point out what to watch out for and how to use == correctly, so if you want to take advantage of type conversion, you'll know how to do it right.

I do think that JavaScript: The Good Parts is a good companion book to a learning book so you know some of the nitty gritty details about some of these features, especially the ones you simply cannot avoid.

Hope that answers your questions!

Hi Kumar,
Our book doesn't cover any of the topics you've identified, because it focuses on the fundamental language concepts.

However, all of the topics are important to learn about!

1) Performance is definitely an issue. There are a couple of things you can do. One is to request chunks of data at a time using XHR (Ajax) from the server, if it's the case that your data can easily be split up into chunks and processed on the client a bit at a time. That way, the client doesn't have to wait until all the data is downloaded to be responsive to the user.

You can also cache your data using local storage. All modern browsers support local storage now, and loading it from the local browser is going to be faster than downloading it from the network. Some have complained that local storage is not as fast as it should be, so you'll want to do some performance testing and compare it to say, using the file api, using the network, or even a database solution (although those are not as widely supported).

Once your data is loaded, if you need to process data speedily, take a look at the web workers API for splitting up the processing across multiple workers. Most people have multi-core computers now, and you can get a big boost in your UI responsiveness with big data using web workers. For instance, for Head First HTML5 Programming, we used web workers to process fractal data, and the results were pretty amazing.

2) There are lots of best practices for coding JavaScript. One pattern we use in the book (although we don't call it out specifically as a pattern) is the Model-View-Controller pattern, which is helpful for splitting up the concerns of a program. Another pattern that is used frequently in JavaScript is the module pattern, which allows you to create modules of code. We show one example of this in the book (again, without calling it out specifically as a pattern), but we don't go into it in depth at all. However, you learn everything you need to know in the book in order to understand the pattern, so you can go tackle that on your own.

3) I agree, cross-browser issues are a pain, and always will be as long as browsers continue to innovate each in their own direction. However, as far as the core language is concerned (not API support, for instance), all modern browsers are all pretty much equivalent now (as of IE10). Which is great news! That said, using libraries that provide shims or polyfills for back compatibility and cross-browser compatibility can really help. There are several mobile libraries that can help with this for mobile sites, too.

Hope that helps!


Hi Pawan,

(1) Is it for beginner or some experienced developers will also learn new stuff?
We designed the book so if you don't have any programming experience, you can pick it up and learn to program. That said, if you already know another language, you can use the book to learn JavaScript. The first couple of chapters are going to seem pretty easy, but beyond that you'll quickly start getting into language features which are different from other languages.

(2) Is this book going to explain most of the things in Object Oriented way?
Yes! We take a little while to introduce objects (Chapter 5 I think), but once we do, it's objects all the rest of the way. From chapter 8 on, we take a very object-oriented approach to the examples.

(3) I saw book has a chapter "Anonymous Functions, Scope and Closures: Serious functions". Are you covering Closures and scope in detail?
Yes! We cover lexical scope and closures, and provide several examples.

(4) Are you covering DOM extensively and API's that can hurt performance.
No. We do introduce the DOM and talk a bit about how to work with it, but that is more the topic of Head First HTML5 Programming.

(5) I would love to see how compiler or javascript interpreter will interpret code. So I am not sure if while showing examples you are also explaining how Compiler will interpret it.
We don't talk about this at all either - that is quite an advanced topic. I'd like to see a book on this myself!
Hi Ken,
With regards to beginning vs. advanced; instead of describing Head First JavaScript Programming as covering "beginning" material, I'd say it covers the language fundamentals, and is appropriate for those who are either new to programming, or for people who may have programming experience in another language, and want to learn the nuts and bolts of JavaScript. For these latter people, the first couple of chapters might feel somewhat basic (variables, if statements, etc.) but after that, we quickly get to topics that are fairly unique to JavaScript that you need to know, even if you already know a different language.

There are many ways you can go beyond the book in terms of learning more advanced topics; for instance, in Head First HTML5 Programming, we talk about several of the HTML5 APIs (e.g. geolocation, web workers, local storage, canvas) which requires knowledge of JavaScript first.

And of course, you can go on to study server-side programming (e.g. with NodeJS); more in-depth on many of the various APIs available, such as audio, video, graphics; using frameworks like Angular, Ember and Backbone; the possibilities are really quite endless for how you can expand your JavaScript knowledge once you have the fundamentals down.

With regards to JavaScript communicating with databases, I'm with Bear: you'll probably want to look at how to make requests to a server side program with XHR (previously known as Ajax), using a RESTful API. We don't cover this at all in Head First JavaScript Programming, and we cover the client-side of that equation (along with JSONP) in Head First HTML5 Programming.


Thank you!! We're very glad to be here.
I agree, it's great to have all those options. And for the PDF in particular, I do like that the PDF makes it easy to copy and paste code! And easier to carry around. At over 650 pages, Head First JavaScript Programming requires a bit of muscle to lug around in paper format
Hi Margaret,
Probably not, I don't believe that O'Reilly has changed how they generate the eBook files. Unfortunately, because of the way Head First books are laid out, in order to maintain things like the position of the graphics, annotations, and such, it's very difficult to generate the pages in a mobile-friendly way.

Have you tried viewing the PDF on your phone? I don't know if that would be any better. The PDF works really well on my iPad, I can zoom in etc. I think I'd have a hard time reading it on my phone though! My eyes just aren't that good.

Hi Louis-Philippe,
Great question.

If you look at what we did with the Battleship example in Chapter 8, you'll see some ideas of how you can organize code. The technique we use there also seems to be common in a variety of JavaScript libraries and frameworks. And that is to use objects to organize code. So, for instance, if you have several functions that are set up to handle validating form inputs, then you can create an object, FormData, and make methods within that object. So think of the object as a way of grouping like code together. Then of course when you need to use that function, you'll use FormData.functionName to do it.

Another thing you can do is nest functions. Let's say you have a function that needs to use several other "helper" functions that aren't used outside the main function. You can nest the helper functions inside the main function to "hide" them away from the other code, and also keep things organized. Two downsides to this: one is that if you end up needed to use a helper function elsewhere you'll have to change that organization strategy, and two, every time you call that main function, those nested functions have to be recreated, which is slower than if they are created once at the top level.

I do think splitting up functions by functionality into different files can be helpful. Just keep in mind that you still only have one global space! So don't forget about global variable names potentially clashing etc. That's one reason why keeping global variables at the top of your file can be helpful (so it's easy to see what they are across multiple files).

I'd say code organization is a big issue with JavaScript! Some frameworks help with that (some maybe a little overkill, putting every single function into a different file! yikes). E.g. If you learn BackboneJS (http://backbonejs.org), you'll find you group your code into modules, which can help organize.

Also, check out RequireJS (http://requirejs.org) which provides a way to create modules also. As I mentioned in another thread, ECMAScript 6 will have modules, but it's not likely these will be available in the core language in browsers for at least a couple more years, so using a library like RequireJS in the meantime can help.


Hi Narendra,
I think this is one of those questions which doesn't have a definitive answer and you're likely to get different answers from different people depending on what they think of as "lightweight".

Here's my answer: I think JavaScript can be thought of as lightweight because (at least up to ECMAScript 5) it isn't a particularly "big" language with many many constructs. It's actually a fairly simple language for the most part. Now, each new release of the language inevitably adds more "stuff" to it, which makes it less lightweight. Personally, I don't like that inevitable march towards more "stuff". I like when languages are lightweight: that makes the language easier to learn and understand.

A related way to think about whether a language is lightweight is: is the interpreter/compiler/execution environment for that language simple and fast? Which is really only possible if the language itself is simple. JavaScript engines have become a lot more complex in the past few years, but the tradeoff is that executing JavaScript code has become a LOT faster. I really have no idea how a JavaScript engine compares in complexity to, say, a Java compiler/runtime so I don't feel qualified to really comment on that end of it.

Another way to think of this is to consider the language "ecosystem": how many libraries and frameworks are built for it? While libraries and frameworks are useful, they can make a language feel less lightweight, because if using those libraries and frameworks becomes a necessary part of working with the language (your employer requires it, or your co-workers, or "everyone is using library X"), then again, it's more "stuff" to wrap your head around. In that sense JavaScript becomes less lightweight by the day as more and more libraries and frameworks are released.

In conclusion, I'd say that I think the core JavaScript language is still fairly lightweight, but the JavaScript ecosystem is becoming a lot heavier by the day.