JavaScript Cookbook 64
r3lody writes "I have enjoyed other cookbooks in the O'Reilly library of computer texts, so when I saw JavaScript Cookbook by Shelley Powers in the catalog, I jumped at it. The description mentioned that the book would cover HTML5 and ECMAScript 5, so I really wanted to learn the new capabilities of both. I did get to learn a lot, but I wonder if these new features are too new." Keep reading for the rest of Ray's review.
Like other cookbooks in the O'Reilly library, this one is organized as a series of specific problems, with their solutions neatly presented and grouped into the major chapters. Each solution has a discussion to flesh out the details. The website has downloadable copies of the examples in the book, which I used to test out the various recipes. ECMAScript 5 is fairly new, and HTML5 is still under development, so I made sure I had the latest stable versions of the major browsers (Firefox, Google Chrome, Internet Explorer, Opera, and Safari) to see how they would cope. The HTML5 features are very sparsely supported as of yet, so those portions of the book should be considered more of a sampling of things to come rather than a definitive set of solutions.
| JavaScript Cookbook | |
| author | Shelley Powers |
| pages | 560 |
| publisher | O'Reilly Media |
| rating | 7/10 |
| reviewer | Ray Lodato |
| ISBN | 978-0596806132 |
| summary | A well-constructed collection of JavaScript recipes, with forward-looking samples of ECMAScript 5 and HTML5 |
The first five chapters of the book are somewhat unremarkable. They start out easily enough with recipes for handling JavaScript strings. The discussion of String objects and literals obviously implies that the reader is already somewhat familiar with Object terminology and functionality. That makes this book unsuitable for beginners. The following chapter contains recipes for handling regular expressions. It starts off with an introduction to the basics, which are nothing that a somewhat savvy shell programmer should be familiar with. The remaining sections cover pretty basic problems. The only interesting ones I noted handled highlighted found phrases on a web page.
Chapter 3 covers dates, time, and timers. Handling dates is shown to be pretty straightforward, and one-shot and recurring timers are presented in a clear, easy-to-understand manner to wrap up the chapter. The next chapter, Working with Number and Math, consists mostly of basic mathematical solutions. The fifth chapter rounds up the basics with recipes for working with arrays and loops. As a Perl programmer, I found this to be familiar territory – especially the discussions of the splice and map method, and using associative arrays.
Chapters 6-10 provide the first real appetizing recipes in the JavaScript Cookbook. Shelley first discusses building reusability using function definitions, anonymous functions, recursion, scopes and memorization. It's starting with this chapter that you really begin to learn how to use JavaScript rather than just playing around with it.
Event Handling is the first major hurdle a procedural programmer needs to overcome to use JavaScript effectively. Various event triggers are discussed in the sections of chapter 7. While most of the code is easy to comprehend, I ran into problems when using the new HTML5 drag and drop was discussed. I had to ask myself could drag-and-drop be any more complicated? This example worked on all but Opera, but the solution is convoluted. Overall, if you really want to know how screwed up code must be to work in all different browsers, chapter 7 (Handling Events) will demonstrate it. Internet Explorer's differences is the reason for most of the odd workarounds in this chapter.
We would all like each browser to work just like another but, unfortunately, each one has its own quirks. Chapter 8 talks about the various ways browsers handle color support and page sizes. The chapter ends by dealing with dynamic pages and bookmarking their state.
The first time I worked with JavaScript was when I was coding some form handling. Chapter 9 covers the ways to handle forms and modify web pages. The most useful recipes (at least, for me) were the last two, which showed how to hide and display form elements on the fly, and how to modify selection lists based on other form element entries.
All programming involves error handling and usually some debugging. Chapter 10 describes the various ways to handle errors, followed by a well-written set of tips on how to use the debuggers and inspectors for the major browsers.
The following three chapters all deal with manipulating web pages. The first of these contained a lot of discussion of namespaces. Namespaces can be confusing, and I didn't really understand them much better after I was finished reading. In addition, you are presented with several boilerplate templates, with little information as to why you would use them. I also had problems with some of the downloaded samples not running correctly on my browsers. Chapter 12 contains lots of fun ways to manipulate page content, with specific instructions on how to handle IE and its different ways of doing things. Finally, chapter 13 provided some good basics of page manipulation, including creating collapsible sections, and creating tab pages.
Accessibility is the major topic of chapter 14, where you are introduced to ARIA (Accessible Rich Internet Applications). Many web pages are not built with accessibility in mind, so this chapter is very important for giving the web designer the tools for well-designed and usable pages. Some ARIA techniques are straightforward, but others (such as creating collapsible form sections) are much more complex to get right. This chapter does a marvelous job, even though it is somewhat hard to read.
The next chapter covers creating media-rich and interactive applications. This chapter was pretty deep, and the examples were not necessarily bad, but the techniques required need the coder to really think clearly about how to accomplish their goal.
Chapters 16 and 17 cover JavaScript Objects and Libraries. In the Objects chapter, there is quite a bit of discussion around ECMAScript 5, which is not yet well supported in the browsers normally available. As one example, Shelley does say regarding the preventExtensions feature "by the time this book hits the streets, I expect (hope) at least a couple of browsers will have implemented this feature". The Libraries chapter was more problematic in that I was not able to follow along and get the supplied samples working correctly. In addition, the coverage of jQuery was only a high-level overview, leaving the reader wanting more. In her defense, Shelley acknowledges the breadth of the jQuery topic and refers you to the jQuery Cookbook for more information. Overall, I found chapter 17 unsatisfying and abrupt in its coverage.
Communication via Ajax is the main topic for the recipes of chapter 18. Without a proper web server at my disposal, I could not properly evaluate the workability of the solutions. I was also somewhat amused that one of the solutions was described with the caveat that it's not a recommended procedure. I would ask why it was included in that case.
The Working with Structured Data chapter starts by covering JSON (JavaScript Object Notation), but then adds in recipes for handling hCalendar Microformat Annotations and RDFa. The transition was a little jarring, and not overly useful, in my opinion.
The penultimate chapter covered the issues around persistent information. While using URLs and cookies to maintain some state are discussed, much of this chapter revolves around new capabilities made available in the new HTML5 specifications. Unfortunately, most browsers either do not support, or only partially support these features, so the information is only useful as a "taste of things to come".
The final chapter covers the use of JavaScript in non-browser environments. Widgets and gadgets are simple JavaScript applications that are easily coded and disseminated. There are discussions of creating applications for the iPhone, Android phones, and Blackberry phones.
As I step back and reflect on this book, I think that many topics are solutions that cannot be implemented because the typically available browsers don't support the new features yet. If a web page designer wants their site to be available to users now, they need to focus on the features that are well entrenched across the internet. Having so many solutions based on features and capabilities that are still being defined is only useful as academic exercises. I would have preferred that the JavaScript Cookbook be more useful for the state of the web right now. That is why I'm rating it only 7 out of 10.
You can purchase JavaScript Cookbook from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
next to last chapter (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Expecting the wrong thing (Score:5, Insightful)
A cookbook isn't designed to teach you anything. You don't learn how to boil water or heat up a pan when you buy a cookbook. It isn't a textbook or beginner's manual.
A cookbook provides recipes. It may provide some background and hints on how to adapt recipes to fit your needs, but it is not there to discuss why something works, only the steps to make it work.
So if you were disappointed that the first five chapters were about mundane things like string manipulation, then you've sorely missed the point. These are problems that exist and the book presents the best solutions to solve them. If you think string manipulation is unnecessary to expound upon, then skip those chapters. There's no rule that you have to read a cookbook all the way through.
A cookbook can only be judged on two things. Thoroughsity and correctness. If a cookbook is sufficiently thorough in its coverage of the topic and the recipes it provides are better than adequate, it has done its job. Judging it on standards best reserved for textbooks is ridiculous since the domain is completely different.
Re: (Score:3, Funny)
The Joy of Cooking cookbook would like a word with you...
Re: (Score:2)
A cookbook can only be judged on two things. Thoroughsity and correctness. If a cookbook is sufficiently thorough in its coverage of the topic and the recipes it provides are better than adequate, it has done its job. Judging it on standards best reserved for textbooks is ridiculous since the domain is completely different.
A dictionary may be judged on two things. Thoroughsity and correctness. If a dictionary is sufficiently thorough in its coverage of the topic and the definitions it provides are better than adequate, it has done its job. Judging it on standards of the words used in this sentence is ridiculous since the domain is completely different.
Re: (Score:2)
How can you judge something by a non-existent criterion?
You should be kissing the author's feet (Score:4, Insightful)
As I step back and reflect on this book, I think that many topics are solutions that cannot be implemented because the typically available browsers don't support the new features yet.
Most technical books are partially obsolete before they see print, or rapidly become obsolete. You're complaining because the book might have a longer shelf-life, thus giving a better return-on-investment and greater longevity and usefullness? Take a step back and think. Really.
Re:You should be kissing the author's feet (Score:4, Interesting)
Except that sometimes the new features take another turn and then the book becomes useless.
Look at HTML5 file uploads via XHR2... Firefox went one way, Chrome/Safari went another way. From what I understand Firefox won't be the new standard, but that method could be what is described in the book. I won't help you once Opera supports the Chrome/Safari way and once Firefox switches to that new method.
For YACC - Yet another crap cookbook? (Score:2)
If it takes you half the book just to get there, this isn't a cook-book unless it's a "For Dummies."
The C++ Cookbook was equally disappointing. I'm sorry I bought it.
In fact, the ONLY good cookbook was the Perl one.
This book is a dumb idea, when
Re: (Score:2)
I was angry that my cookbook took 7 chapters to get to chicken florentine. What good is that!?
Re: (Score:2)
Why pure JS vs a Library? (Score:4, Insightful)
What I wanted to learn from this review is, why should I do anything in pure JavaScript instead of using a JS library like jQuery? What are some recipes that are simpler in this cookbook than finding a jQuery example on StackOverflow?
I suppose built-in data structures, looping, and math is independent of a library, but why would you ever do form manipulation, DOM manipulation, or ajax without using jQuery (or your favorite js lib)?
Re: (Score:2)
Maybe you don't have a favorite library. Maybe you have an idea for a new library, but because you've only ever used other people's libraries, you're not quite up to speed on how to do things the "pure" way. The people who write the libraries had to start somewhere, and its often times at the bottom.
Re: (Score:2)
I wrote a Javascript library to be used internally with our almost-but-not-entirely-unlike CMS - I could have used jQuery (which I use a lot, and really like), but there were two reasons why I didn't. First, Javascript is sadly a very misunderstood language, also by most of our technical staff - while jQuery is very powerful, the syntax is a bit terse (not a bad thing in itself, but might take some time getting used to), and it's very extensive even with no plugins. It was simpler for the others to adapt to
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1, Informative)
Because javascript libraries have become monstrous beasts loaded down with lots of bloat, and unlike dynamic libraries on the local system there is a performance penalty for loading the parts of the library that you don't need. If you only need 5% of what a library does, it's better to rewrite that 5% than to have to constantly ship around and load that other 95%.
Re: (Score:2)
Some libraries are monstrous and require loading the full (even if compressed) feature set.
However, MooTools is highly modularized. It lets you pick and choose [mootools.net] which parts of the total library you need. Many MooTools Add-ons [uvumitools.com] will explicitly list the sections of the library needed.
If you feel it is better to re-write parts of a library, then either choose another or contribute your superior code back to the community.
Re: (Score:2)
You want to work in the "metal" for the simple reason that you learn more about how and why things work. Once you have a reasonable understanding of how stuff works, you can look at libraries with the appropriate background to understand which will satisfy the problem you're trying to solve. You can then properly use the library and won't piss and moan when the library doesn't do things the way you expect them to because of an incorrect expectation.
[John]
Re: (Score:2)
Say you wanted to author a js library... you might find pure js handy.
Now whether there's any good reason to write yet another js library, is another thing.
Re: (Score:2)
Boy, where's Pizza analogy guy when you need him?
(Homemade Pizza vs. frozen deliscio crap)
From TFB: (Score:2)
Solution:
For who is written this solution? Loops are as basic as you can go in programming.
Re: (Score:2)
Re: (Score:3, Insightful)
A more optimal solution is to create an 80-character string, and append a substring of that to the original string.
Whoever wrote this book has no clue as to how javascript works.
Re: (Score:2)
I remember learning javascript and html from a book about 10 years ago...the html book told me to use tables for layout, which I soon thereafter found out was stupid, and the javascript book was full of stuff that is "bad practice" - for example lines where NOT ended with a semicolon.
BTW, does previewing of
Re: (Score:2)
With Google (Score:2)
...why is a cookbook needed? I do various types of programming (currently with PHP and JavaScript manipulating a MySQL backend) and when I'm stuck on something I want to do, I just bring up Google and search for an answer. So far I have yet to be disappointed.
[John]
JavaScript is ok, DOM is a train wreck (Score:1)
Re: (Score:3, Insightful)
Why? Let them upgrade. Or let them pay 3x the price for IE6 support (because it's a minimum of 2x, and that's if you can still find a machine that has IE6 to test on that you can boot).
"oh, but business ..." Don't give me that business. Either they pay the price, or they don't get. IE6 support is a messy business, and doesn't give enough returns for the work.
Re: (Score:1)
Oh I knew that statement was going to be controversial. Yes, IE is a huge source of pain, but for goodness sakes, butch up! Don't be so whiny and/or smug: usually we do not get a choice about what we must support, and often it is only IE that we must support. Are you doing something custom, and you wanna make a political statement and not support IE? Knock yourself out.
I am myself a huge critic of Microsoft, and I relish in the fact that the market demanded they support the Canvas tag in IE9, for insta
Re: (Score:3, Insightful)
Businesses had plenty of warning about lock-in. Let them feel the pain. It's the only way they'll correct their behaviour.
IE6 has a very small market - business and government that are stuck not being able to update becaus
Re: (Score:1)
A few seconds of googling shows you are uninformed:
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2 [hitslink.com]
IE6 is browser #3 in total market share with 16% share. IE8 is first with 28% followed by Firefox 3.6 with 16.8%.
You can't make the same argument about Netscape Navigator because its numbers are 1%.
I'll change my tune when IE6 finally drops off in usage, but that's only when XP finally falls out of widespread use, which will be in, what ... 3-5 more years?
Re: (Score:2)
Unless you're the one who locked them in in the first place, you're not selling to them anyway, so who cares?
Re: (Score:1)
OH! Sounds like you have sixteen percent of the entire online world figured out. I sure am glad you don't run things.
I went to XML Sucks, and surprise surprise: I disagree with practically everything you have written. I disagree generally with your negative attitude.
Re: (Score:2)
And yes, that 16% figure being mostly corporate and government sites that cant/won't upgrade from IE6 is pretty much the entire IE6 install base.
Re: (Score:1)
Yes you are a negative guy! "xml sucks"? Canadian email address? Pat answers? Negativo!! A heck of a lot of poor folks get internet connectivity from public libraries running IE6, you would deny them our collective experience! Neg-a-tive.
Re: (Score:2)
It's not like a library with public computers needs to have ONLY IE6 on it. Next you'll be saying that they should have ONLY one book one each topic!
Re: (Score:1)
That's not how the world works, and that's definitely not how public organizations work. You talk as if public institutions are hyper-competent and on the ball or something.
Sometimes the just and right thing to do is also the uncomfortable thing. You don't get to just spy an inequity and say, "it shouldn't be that way!" and then break your arm patting yourself on the back because your work is done here.
If you can actually EFFECT positive change in public libraries, then I would salute you, because foistin
Re: (Score:2)
Re: (Score:1)
That's true.
Re: (Score:2)
I don't know about you, but I've still got a couple hundred blank dvds hanging around (dvds are so last decade :-) - if I became aware of a problem in my area (library or school), I'd be happy to make a bunch of bootable browser-centric dvds.
And libraries *are* supposed to be where people learn things.
And working off of read-only media reduces maintenance, saves money, etc. For personal data storage, pretty much anyone can afford a $5 for a one gig thumb drive, or $7 for 4 gigs, or t
Re: (Score:1)
In my opinion, there is not much we can do, short of running for office ourselves and making it a platform item that we are . This exchange has prompted me to send an email to my local library administrators, and I will probably make a follow-up phone call or two just to register my feelings. Honestly, I don't believe there will be any change in the system here until there absolutely must be change.
You tell me why I should expect anything different when we pay disinterested people to do
Eclipse Javascript Engine? (Score:2)
Is there a good Eclipse IDE plugin that embeds a JavaScript engine in a console? I don't want to develop JavaScript projects with Eclipse (though that's a useful extra); what I want is to use JavaScript as a scripting language to call the Eclipse API, and to do something like what jrunscript does: use JavaScript to call the JDK API and anything else I specify in the classpath. If that's useful, then managing JavaScript projects in the Eclipse IDE would be handy as I'd be creating lots of JavaScripts.
Huh? (Score:2)
Why not just buy a coffee machine?
jQuery is your friend. (Score:1)
I used to hate writing JavaScript until I found jQuery. What used to take me writing a lengthy mess plus patching it with cross-browser hacks has now become elegant one-liners thanks to the wonderful jQuery libraries. I recommend everybody that writes JavaScript take a look at it.
Re: (Score:3, Insightful)
Absolutely. If you need a cookbook of recipes to copy/paste to solve some JavaScript problems, research jQuery instead.
inaccessible accessibility (Score:1)
How ironic that "Accessibility is the major topic of chapter 14" and "it is somewhat hard to read".