Slashdot Mirror
JavaScript and DHTML Cookbook
I'll begin my review by making a bold statement -- if you've read and like O'Reilly's Definitive Guides on JavaScript and DHTML, you'll adore this book. I use the word adore very deliberately here, because in my opinion JavaScript & DHTML Cookbook is much easier to love than the gigantic and sometimes monotonous Definitive Guide series. Why, you ask? Let's see -- the book is compact (some 500 pages), concise, and filled with the essence of JavaScript and DHTML as far as what you can create using the language/ technology.
JavaScript & DHTML Cookbook is broken up into 15 chapters, each containing a series of recipes. The chapters are:
- Strings
- Numbers and Dates
- Arrays and Objects
- Variables, Functions, and Flow Control
- Browser Feature Detection
- Managing Browser Windows
- Managing Multiple Frames
- Dynamic Forms
- Managing Events
- Page Navigation Techniques
- Managing Style Sheets
- Visual Effects for Stationary Content
- Positioning HTML Elements
- Creating Dynamic Content
- Dynamic Content Applications
These chapters are used mainly to facilitate the look up of a particular recipe, as each recipe exists and is explained independent of one another. This is consistent with the style of most Cookbooks, and it seems to work well here as well.
If you're a complete novice, you may be wondering at this point the distinction between JavaScript and DHTML. The book doesn't make a conscious effort to differentiate between the two when discussing recipes, and for a good reason. DHTML is basically JavaScript, though the latter draws in your page's HTML and often CSS as well to create something more encompassing.
Ok, on to what's important now -- the recipes themselves. I was expecting a series of flashy, long and tacky JavaScripts you can find in the source of every other site on the web these days, padded with some nonsense accolade like "the web cannot survive without them." Such scripts are mostly counterproductive, and do little to educate a JavaScript learner, let alone a master like myself (hur hur). To my delight, things were the complete opposite. The recipes in JavaScript & DHTML Cookbook are extremely practical, well thought out, and even educational. Discussions like Calculating the Number of Days Between Two Dates, Simulating a Hash Table for Fast Array Lookup, and Transforming XML Data into HTML Tables not only are very useful to the cut-and-paster, they teach even seasoned JavaScripters a thing or two about the language.
The only minor compliant I have with this book is the length of some of the script examples -- they span a little too long to follow effortlessly. The longest script I can recall in the book runs about 5 pages in length. Fortunately, such recipes are few and far in between, and 95 percent of the recipes are extremely short in length and packed with useful information and techniques. For the long scripts, it's easy to see that they exist out of necessity to create and show a fully functional script rather than just to pad pages.
In summary, I walk away from reading JavaScript & DHTML Cookbook with many new tricks up my sleeve, something I had not expected at all. Some good resources online that compliment the reading would be DevEdge's JavaScript Reference and JavaScriptKit's JavaScript tutorials."
You can purchase JavaScript and DHTML Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Seriously, who needs a javascript and dhtml book with all of the references on the net? Just give me a nice object reference for DHTML (*cough*, MSDN isn't bad.. i hate to admit it) and DevGuru's JavaScript reference.
My sig can beat up your sig.
You're right on that front. Quite a few people use Microsoft FrontPage for building their webpages.
DHTML support is not that great and even then its a bit cumbersome to use than say Dreamweaver.
Frontpage is good for those building simple websites without much user configuration. DHTML usually does not figure in it.
Bush is on fire and its not good for my lungs.
javascript is polymorphic
you can code round different browsers by implementing a common API for your applications and let your library do the platform specific work
I've done plenty of intranet javascipt applications, one of which is an HTML email composer.
It uses DHTML to drag and resize the html elements around. It works like Quark, you draw a square and type in the text.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
"often with CSS"? That doesn't even make sense.
;)
DHTML was coined, as the combination of HTML providing structure, CSS providing presentation, and JavaScript providing logic.
If you just use HTML and JavaScript, you're just doing a plain HTML page with logic (like form checkers).
I would also note, that JavaScript object are already hash tables, so "simulating hash arrays" isn't really needed (or I fail to see where it becomes relevant?)
object["myprop"] == object.myprop
There's only one book JavaScript programmers need, the rhino book. It's all in that. Everything else is just experience, and cannot be conveyed by a bunch of scripts. Or if it can convey something, it's most likely because said reader didn't catch it in the Rhino book
Personally, I tend to dislike JavaScript. It has its uses, but JS programs quickly turn into huge messes that Anderson himself couldn't debug. Of course, most of these problems stem from the lack of engineering that goes into most Javascript code. If you define clear APIs (like any good engineer should) Javascript ends up being not half bad.
//do something;
BTW, can anyone spot the problem with this code:
function myfunc1()
{
for(i=0; i<10; i++) myfunc2(i);
}
function myfunc2(value)
{
for(i=0; i<15; i++)
}
Here's a hint for you. "i" in myfunc1() is not what you expect it to be.
Javascript + Nintendo DSi = DSiCade
I do not think there is work for someone to do DHTML programming. Everything I have seen is going to servlets. Nobody is putting up static pages (No matter what anyone says, JavaScript does not make a page dynamic). Why pay someone 20 dollars an hour in today's market when there are hardcore programmers unemployed, who can write Java servlets and JSP?
Rosco: "If brains were gunpowder, Enos couldn't blow his nose."
I bought this book, thinking that if it is anywhere near as useful as the Perl Cookbook, then I would be getting my US $39.95 worth. I was very disappointed with the book and would not recommend it to JavaScript/DHTML experts.
The problem with this book is that is almost completely tailored to the person who hasn't much experience with these technologies. For example, the section on the String object gives newbie tips like:
(Whoo-hoo! Thank you Danny Goodman, where can I mail my check to?)
In this very same section on String concatenation it completely fails to discuss the geometric performance loss experienced as strings become larger and larger. Why wouldn't you discuss this? What I would expect to see is a discussion of how you can implement your own version of a StringBuffer, similar to Java, by using Array operators.
There is almost no discussion of client-side XML, absolutely nothing on XSL. If you do much dynamic in-place refresh of data or styles, this book will not help you much.
The book might be fine for novices and maybe even intermediate developers, but for experts it falls very flat. I skim the book once a week or so hoping to glean something new, and I'm always disappointed. Caveat Emptor.
If you are a serious developer you should probably just have your employer buy you a subscription to the O'Reilly Safari online bookshelf, and then you can see for yourself whether or not this book is any help to you.
(BTW, for those have said that you cannot get work as a DHTML programmer, you are so wrong. I make a comfortable six-figure salary doing this work for governments and large corporations. If you are good enough at what you do you can always find someone willing to pay you for it, and DHTML is no exception.)
I've found that there is a growing demand for web designers who can use DHTML as an alternative to Flash, especially considering most of today's web-browsers have become considerable more compatible in the last few years.
You should also note the increasing growing market of selling JavaScript components like Dynamic Menus, Calendar Pickers, Tables, and other goodies.
Obviously DHTML is only half the solution for most problems, so we find that most DHTML programmers usually use DHTML in conjunction with ASP, PHP, JSP or some other server-side technology.
Not to mention the learning curve from something like JavaScript to PHP is fairly short. So the incentive to isolate oneself in a DHTML-only world is probably slim.
"Communism is like having one [local] phone company " - Lenny Bruce