JavaScript : The Definitive Guide, 4th Edition

briandonovan writes "A new edition? Given all of the changes in the web programming landscape since the 1998 publication of the previous edition, David Flanagan's JavaScript : The Definitive Guide (JS:TDG4), 4th Edition was overdue. Flanagan delivers a book that more than measures up to its predecessor - JS:TDG4 includes a substantial amount of new material and, as a whole, has been extensively updated. The crushing gain in browser market share by Microsoft's Internet Explorer offering, the maturation of the Netscape 6.x,7.x / Mozilla browser suite and its entry into the fray along with a slew of other Gecko-based browsers, promulgation of newer versions of the ECMAScript specification (accompanied by new implementations in JavaScript and JScript), and the publication of successive W3C DOM Recommendations are all reflected in this edition." JavaScript : The Definitive Guide, 4th Edition author David Flanagan pages 916 publisher O'Reilly rating 9 reviewer Brian Donovan ISBN 0596000480 summary The latest edition of JavaScript : The Definitive Guide brings the popular reference up to date with extensive coverage of W3C DOM Level 1 and 2 and a much-improved and expanded set of appendices.

The Book in a Nutshell

Although much of the core of the language, addressed in Part I, has changed relatively little since JS:TDG3, Flanagan has added coverage of new issues that have emerged in the past several years, like the discussion of ASCII, Latin-1, and 16-bit Unicode in the beginning of Chapter 2 (ECMA-262 Edition 1, the spec that defined ECMAScript, included Unicode support for il8n purposes, so ECMAScript compliance requires Unicode support), and pruned away quite a bit of material related to NS 4.x-proprietary features, like the explanation of import and export (previously found in Chapter 6), that are naturally of increasingly less interest to developers as that line of browsers recedes into history. Much of Part II, which considers client-side JavaScript and DOM in all its glory, is entirely new or has been completely re-written. Where the chapter on the Document Object model in the 3rd edition only covered the "Level 0" DOM (the objects, properties, and methods first exposed by the 4.0 browsers), JS:TDG4 tackles the Level 0 DOM and the W3C DOM Recommendations through level 1 Core and HTML and touches on some DOM Level 2 topics, including the Range and Traversal APIs. "Cascading Style Sheets and Dynamic HTML" and "Events and Event Handling" are two other chapters in the Client-Side JavaScript section that have really come into their own in this edition.

The large (more than 300 pages), but somewhat muddled "JavaScript Reference" in the 3rd edition (it had commingled the objects, properties, and methods included in the core of the JavaScript language with those of the Level 0 DOM) has been split into 4 discrete appendices ("Core JavaScript Reference", "Client-Side JavaScript Reference", "W3C DOM Reference", and "Class, Property, Method, and Event Handler Index") that, taken together, comprise more than 400 more pages of information. NS 4.x fans can take comfort from the fact that, while much NS 4.x-specific information has been culled from the body of the text, Netscape 4.x still shows up in some screen captures (along with Microsoft Internet Explorer and Netscape 6).

What was Great

Exception handling (using throw and try/catch/finally) is covered in greater detail. In Chapter 15, "Forms and Form Elements", JavaScript interactions with buttons, toggle buttons (checkbox and radio elements), text fields, hidden elements, and fieldset elements are addressed individually in new sections not present in the corresponding chapter in JS:TDG3 and the section on select and option elements goes into more detail than in the previous edition. Throughout the book, improvements have been made to figures and tables - like the addition of the "Supported by" column in Table 19-1 : "Event handlers and the HTML elements that support them", which now helpfully lists the elements for which the event handlers can be triggered after identifiers for the versions of Netscape and Internet Explorer in which the behavior is observed. Finally, the book as a whole is significantly more readable. The type used for the text of the code examples and tables was too "light" in the 3rd edition (at least in my copy), and I was glad to see that it's a bit heavier in the 4th.

What was Not so Great

I nearly came up empty-handed in my search for defects in this book, but noticed that, in tables 11-1 and 11-3, "Automatic data type conversions" and "Data type manipulation in JavaScript" respectively, information relating to the treatment of arrays and functions present in the corresponding tables in the 3rd edition has been removed. That's really my only gripe. Some might wish that Flanagan had included more compatibility information, but, realistically, the task of fully documenting the intricacies of what's supported by which browser (or, in the case of Win MSIE, which JScript dll is installed) could probably fill a separate book all of its own. Moreover, Chapter 20 ("Compatibility Techniques"), may be brief at only 11 pages, but it does a good job of tackling best practices in dealing with JavaScript and DOM cross-browser compatibility challenges.

To Buy or Not to Buy

If you're in the market for a good JavaScript (or JavaScript+DOM) book, then JavaScript : The Definitive Guide should undoubtedly be your first choice. Although my 3rd edition was so tattered from long use that I really had no choice but to upgrade, even owners of the 3rd edition who've managed to keep their copies in near-mint condition will probably still want to get their hands on the 4th edition if they haven't already done so - for the meatier and updated reference appendices if for no other reason.

Table of Contents

Preface

• Chapter 1. Introduction to JavaScript

Part I : Core JavaScript

• Chapter 2. Lexical Structure
• Chapter 3. Data Types and Values
• Chapter 4. Variables
• Chapter 5. Expressions and Operators
• Chapter 6. Statements
• Chapter 7. Functions
• Chapter 8. Objects
• Chapter 9. Arrays
• Chapter 10. Pattern Matching with Regular Expressions
• Chapter 11. Further Topics in JavaScript

Part II : Client-Side JavaScript

• Chapter 12. JavaScript in Web Browsers
• Chapter 13. Windows and Frames
• Chapter 14. The Document Object
• Chapter 15. Forms and Form Elements
• Chapter 16. Scripting Cookies
• Chapter 17. The Document Object Model
• Chapter 18. Cascading Style Sheets and Dynamic HTML
• Chapter 19. Events and Event Handling
• Chapter 20. Compatibility Techniques
• Chapter 21. JavaScript Security
• Chapter 22. Using Java with JavaScript

Part III : Core JavaScript Reference

Part IV : Client-Side JavaScript Reference

Part V : W3C DOM Reference

Part VI : Class, Property, Method, and Event Handler Index

Index

You can purchase JavaScript: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Chapter 5

[SpanishInquisition]

23 ways to annoy people with pop-up ads.

Re:Chapter 5

[cmdr_beeftaco]

functions

boolean detectParents()
usage:
if(detectParents())
displayPorn();

Re:Chapter 5

[Oculus Habent]

I got a self-minimizing, onUnLoad() self-re-opening ad. I had to end task on Iexplore b/c End Task tries to shut down the task in a friendly manner first, which triggers the onUnLoad().

Don't know what it was, or how they expected me to see it.

Great.

[papasui]

just what we all need, more websites with popup windows. Seriously though, I've been giving lots of thought to starting an online petition to get the Javascript standards group to remove those nasty popup windows or atleast have a mandotory option to disable it in each and every browser. (Sorry just turning off javascript isn't good enough for me)

Re:Great.

[noda132]

Any decent browser nowadays can block popups while keeping Javascript enabled. Go get Mozilla, Galeon, Opera, Konqueror... the list goes on and on.

In short: Don't use IE, and you won't get popups. Your browsing experience will also be faster and more intuitive.

Re:Great.

[Prof_Dagoski]

Well, like so many other tools the evil is in the intent of the wielder. I've been finding that javascript has become absolutely essential as web users have come to expect the same level of slickness they see on their desktops from their web browser. A case in point is the MyLibrary portal I implemented at the U. I expected the user comments to ask for more services and better grouping of information, y'know, the type of thing librarians might be concerned with. Instead almost all of the suggestions for changes in the next version were about the interface. Adding it all up, it was clear that the users were expecting the stuff in their web browser to behave like their main computer interface in terms of windowing, menu selection, being able to minimize things and so on. I don't know if I could have implemented their requests without Javascript

Re:Great.

[Doomdark]

I agree that popups are really irritating, but as usual I think it's "tools are not bad, users are" thing ("Napster is not bad, pirates are" etc).

The reason I say this is not just general philosophic argument, but the fact that when creating actual web apps (and I don't mean hype-oriented buzzword meaning but 'real' applications done using thin client, ie browser) ability to open a new small window is really really necessary and useful. These are useful for displaying on-line help, opening up save/load windows (custom ones that will allow user to save data from main form window to/from a file in server side, but first browsing using GUI on popup window), opening up a config window etc. If you can't see the point, try to think if traditional apps were not allowed to open new windows (or tabs for Mozilla; different implementation, same idea).

It should be possible to have features in browser to conditionally enable/disable popup ability on case-by-case basis... but no one wants to be ok'ing "Is it ok to open popup" dialogs. :-)
One feature that seems pretty useful is to just disable javascript's ability to open a popup from 'onUnload' event, ie. pages can not bombard you with popups when you leave them.

Re:Great.

[brunes69]

Do you have write access to your hard drive? ANYWHERE? to save anything? Then you can install Mozilla. It doesn't need access to any specific directory or your registry or anything, unlike other gay software. Download the zip file, unzip. Done. Install the IE theme from themes.mozdev.org so you don't get caught red-handed.

Use Addall instead...

[MajorBurrito]

Instead of paying too much to Barnes and Noble, you can get it from AddAll for quite a bit cheaper.

Install Mozilla

[brunes69]

Edit -> Preferences -> Advanced -> Scripts and Plugins -> Open Unrequested Windows. Uncheck. Done.

Problem solved.

Re:Install Mozilla

['The '.$L3mm1ng]

Use the Crazy Browser, it's IE with tabs und PopUp filter.

Re:Install Mozilla

[rochlin]

That's a glib answer, but do you really use that as your pop-up stopper?

I actually did try it and found it blocked a huge amount of content I did want and offered no flexible "bypass" - even a key or something so I could look at a particular page.

This is really an example of a feature added with good intention but useless implementation. I use Mozilla and a 3rd part (free) pop-up stopper/proxy server.

Re:Install Mozilla

[brunes69]

What verison of Mozilla was this on? The featre was changed drasticlly around 0.96 from "Block all popups" to "Block all popups that do nto happen within x millisecods (customizeable through your prefs.js) of a mouseclick or keypress". I seriously fail to see how you would be "missing a huge amount of content", and i have never had that problem. Any clicks to a window.open() event I REQUEST work fine, all others die.

Re:Install Mozilla

[brunes69]

This is the old Mozilla behavior (pre-0.96). Since then it has evolved into not opening a ne window unless the call was made within a certain amoutn of milliseconds of a mouse click. This is pretty much IMPOSSIBLE to fake out.

If you haven't used mozilla since 0.96 you don't know what you're missing, it has improved alot. I never use IE here or at work anymore. Download it then go to themes.mozdev.org and get some cool skins.

O'Reilly quality has gone down

[tmark]

I'll never buy this particular book, because the second edition of the book was the first - of an increasingly larger number - of O'Reilly books that really weren't up to the O'Reilly snuff-of-old.

I miss the old days where I would buy O'Reilly books - no matter the topic - almost without cracking open the cover because I knew I could count on an authoritative, well-written-and-edited book that almost certainly was one of the best books on its topic. Now, it seems like O'Reilly is milking their goodwill and pumping out bushels of substandard quality books. I know, because I've bought a bunch of them.

Now, there doubtless were substantial revisions and additions to bring this particular book up to the 4th edition, but I just can't bring myself to buy an updated copy of what was at the time perhaps the worst O'Reilly book that WASN'T "CGI Programming on the World Wide Web" by Shishir Gundavaram.

Fool me once, shame on you
Fool me twice, shame on me

Re:O'Reilly quality has gone down

[telbij]

That is pretty silly reasoning. When was the 2nd edition written? 1996? The JavaScript of those days is long gone my friend.

If you need a JavaScript reference, you are best served by looking for the best available book rather than making such decisions based on idealistic dogmatic opinions of publishers.

Yes, O'reilly isn't what it used to be, but what does that have to do with purchasing a book?

Strengths of Javascript.

[taeric]

I own a copy of this book and have thus far fully appreciated having it.

Unfortunately, when most people hear the word JavaScript they immediately think of how annoying window.open() is. It is a shame, really, as a lot of interesting things can be done using JavaScript. Especially when combined with the DOM and all the options that opens up.

My question, then, is simple. How many people have noticed that true knowledge in JavaScript is severely lacking in many people who do web developement? I've met lots of people who claim to know JavaScript well, but they can barely write the examples provided in most books. I think that for a web developer, knowledge in client side scripting should be moved up on the priority notches. Am I alone in this?

Re:Strengths of Javascript.

[mitchner]

You might not be alone, but I don't agree. Certainly Javascript can do some cool stuff, but you can't count on it working for all your users. Do your processing on the server and you don't have this worry. I use Javascript if I'm doing Intranet development where I don't have to worry (as much) about people disabling JS, and I know every user is on the same broswer and version, but I stay away from it for Internet development. Also, people interested in creating eye-candy use flash instead of JS. So it's in a no-mans land where creative folks don't like it much, and most developers would rather use server-side processing anyway.

Re:Strengths of Javascript.

[Pfhreakaz0id]

agreed. We get guys on my project who immediately want to go to a server side solution on everything (oh, let's do a round-trip to the server every time they pick a new selection! That won't be annoying or anything!). When I suggest we use client-side they say "oh that's too hard". Then I whip up the script and they are amazed. I'd rather write Javascript then a SQL procedure any day of the week!

Re:Strengths of Javascript.

[Mirk]

I agree 100%. We should do more on the client side.

Wait a minute ... why doesn't your site work in my browser?

What's that you say? My site doesn't work in your browser either?

How very strange.

Moderation totals: +1 funny, -1 gratuitously sarcastic.

Re:Strengths of Javascript.

[Ravagin]

I certainly do not agree with you. Web development is principly about information architecture - the HTML. That's what really, really matters. Then you can get fancy with CSS and graphics - and javscript for the really fancy or for complex applications. But like mitchener said , JS is too often used merely for flashy effects, and while those can be cool, they are in no way important to an effective website. Javascript has its place and uses - one can make some great interfaces with it if one needs to - but I don't think it's nearly as important as you say it is.

Cheers,

Re:Strengths of Javascript.

[foo fighter]

I think that for a web developer, knowledge in client side scripting should be moved up on the priority notches. Am I alone in this?

Absolutely agreed!!

From a "consumer" perspective, there are way too many sites out there that go to the server to update the page after an action. So much can be done with really very simple CSS and DOM manipulation.

I mean, it's easier code to write, it'll work with very little platform-specific tweaking, and it's a better experience for the consumer since it's faster to download the code and update the page. Why isn't it being done?

Re:Strengths of Javascript.

[Oculus Habent]

As the developer of database-driven intranet applications, I was frequently grateful for JavaScript. When three managers would finally agree on a implementation which was practically impossible to create, I would rely on JavaScript to make the impossible happen.

JavaScript is extremely versatile. It is also very powerful. However, it is also very easy to abuse. If you've ever visited a site where layers of transparent GIFs floated around following your cursor, you probably understand. I have had to troubleshoot a fair share of bad JavaScript that others wrote/copied (subducted layers of size-and-color-changing fonts making a colorful expanding flashing title was chewing 97% processor time, for instance) and have taken the Aramon stance on JavaScript.

Stone and steel are at Aramon's side, and good king Elsin forsakes magic for spear and hammer.

Re:Strengths of Javascript.

[Sludge]

Oh, hell yes.

Artists and page designers consider javascript the coder's job, because, well, it has logic branching, variables and function calls (to list off a subset of the functionality.)

Coders consider it the web designer or artist's job, as it often lays out asthetic views of the work.

Managers don't care, they want to see all their functionality implemented in flash. :-)

Seriously though, I'm one of the few staunch software developers who picked up web programming (as opposed to web designers who learned a bit of php&javascript) where I work who spent the time learning Javascript, coincidentally from the 2nd edition of this book.

The result? Almost every piece of web software I've written in my career could have had a once-over interface improvement by using something out of it. I appreciate Javascript.

One of the unsung uses of JS that I find so helpful is for the administration section of sites that I so often have to code for clients. Most of the time, the client will ask for some highly complicated features after you're already done programming something to spec. While it is fully within my right to hand them an updated schedule and cost for the changes, some of the time I can simply hack them in with JS. Sure, I can't rely on most users to have Javascript, but I can tell a few admins that they're going to need it.

Let's not forget that Javascript is not tied to the web either. The DOM is velcro'd to the language, not bolted.

I personally wish more people would use javascript with their forms, even if it is just to put an onLoad in the BODY tag, with a focus edict on the first entry in the first form.

Re:Strengths of Javascript.

[kdgarris]

No, you shouldn't count on all users having JavaScript, but if they *do* have it, you can use it to validate data and reduce the load on the server. suppose you have a form with fields that only accept numbers. You can use client-side JavaScript to check for valid values *before* you allow the form to be submitted. This way, there will be less load on the server, and the process will be quicker for the end-user, so they don't have to wait for the form to be submitted and for them to get a message that certain fields have invalid data, and have to go back and do it over again.

Of course, you should still have the same check on the server side as well, since you can't guarantee that the client has JavaScript enabled (or didn't just hack a local copy of your form themselves).

-Karl

Re:Strengths of Javascript.

[Captain Large Face]

The only problem with JavaScript is as you cite:

... when most people hear the word JavaScript they immediately think of how annoying window.open() is.

I've enjoyed using JavaScript for almost as long as I've been using HTML (4/5 years), and believe it can genuinely help to reduce server load (think of all those validation scripts), yet JavaScript is steadily becoming less applicable due to the ability to disable it in the client.

A lot of ordinary web users, in an effort to block pop-ups, have disabled JavaScript in their browsers, and all other applications which could easily make use of this technology suffer as a result. Personally, I couldn't blame them for this, as I find pop-ups as irritating as the next person.

Until ordinary web-users come to trust web sites not to thrust adverts down their throats using pop-ups, pop-unders or whatever, then this valuable technology will remain unusable on the vast proportion of (mainstream) web sites.

Of course, the odds of marketing-types not pressing developers to use any technology in an immoral way are extremely remote.

Re:Strengths of Javascript.

[Pfhreakaz0id]

Nope. I'm not. I can use whatever browser I want on my own computer (and frankly, I've got Mozzilla on it as well as IE). but on my employees dime, I do what they say. Employees on our network aren't mandated software, they don't have permission to install other software. They can't. And for good reason. It's a support nightmare.

Also, it is true I didn't say it. Which is why I said now. I've had this conversation many times on Slashdot. These guys pay the bill, they have the right. Support wise, it's a nightmare to support multiple clients and they don't want it.

Re:Strengths of Javascript.

[sporty]

Until someone breaks your site because htey have that one particular javascript setting off.

Seriously. I dont' go to some sites because it requires a seperate window to open automagically, while I have that setting in mozilla off. It's not a matter of protest -- it's a matter of preference. I don't like it, and got annoyed turning it back on for the site in general. So.. I've stopped going there.

The bigger problem, is it is hard to worry about it client side. If I turn off JS, bam, your site becomes broken. Depending on the use of JS, it can either be a security issue, to db integrety (data validation) to site navigation that becomes broken.

Re:Strengths of Javascript.

[smittyoneeach]

Echo your experience. I was hired into a project where _everything_ was happening on the web server, with extensive cookie usage.
JS has been crucial for leveling the resources between client, web- and database servers.
People seem stuck in the familiar rut, and looking at a page that has four languages (HTML, JS, VBScript, SQL) decorating it seems to scare the intellectually limp in the crowd.
The application learning curve is steeper, but it's a "feature" to know where the code will execute simply based on the default language settings that are common through the application.
This is all stated from the relative comfort of an internal database application. Heart goes out to the commercial types forced to jump through their butts with their hair on fire aiming for compatibility; we get to say "IE or ELSE".

Re:Strengths of Javascript.

[Doomdark]

I agree. Many of my co-workers who do claim they know Javascript say they never create new Javascript code, just cut'n paste. What is weird is that it would be fairly easy to actually learn the basics, and that usually programmers are not all that proud about "not knowing how to do XXX but being able to copy stuff others have done". At least not the more ambitious ones. I actully spent just one week reading a JS book and trying out things. Since then I have written couple of tree components (for browsing files on server) and a simple spreadsheet-like web app, mostly for fun. Neither is rocket science once you know the basics. Plus, knowing basics it's also much easier to write JS code that is portable and doesn't really on features (or defects) of any single browser.

Also, most people don't seem to realize that question between server/client side validation (or functionality) is not all-or-nothing. They are pretty much complementary. Client-side is really good at making web apps much more responsive and interactive. Server-side is a must for secure stuff; anything on client-side can be manipulated at will.

For example, I do think that it's much better do (parts of) simple syntax / completeness validation on client-side. Instead of having to wait for server to output "You didn't fill 'foo'" page, you could get an alert dialog telling you the same, and:

• Server-side load would be reduced, not so much because of having to do check but only because of the need to output complete replica of original page with filled-in values. For individual user load is not huge, but for big sites this does add up.
• Response time would be decimated (ie. validation is immediate, no round-trip to potentially congested server)

More complicated checks should be done on server-side (not all data may even be available at client), but for (pre-)validation JS makes things much easier.

my opinion (3rd edition)

[larry bagina]

I own the third edition of this book, and bought it when I was starting to write a web-based decision support system for a very large beverage company. I can safely say that this book, and the HTML Definitive Guide (also by O'Reilly) were critical to the success of the system.

I have seldom had a question about JavaScript for which I could not find the answer in this book. I referred to it so frequently during the development of our system that it is now the most dog-eared book in my collection. I'm going to order the fourth edition simply because this baby is ready for retirement.

If you are learning client-side JavaScript, by all means purchase this book. The first half of the book is a guided introduction to the language and does a wonderful job of explaining the syntax of the language, the underlying object model, and virtually every pertinent feature of the language. The real value, though, is in the reference, which documents every object, method, property and event of standard JavaScript.

Non-conformists who wish to exploit features unique to Internet Explorer will find some reference material here, but the book does try to focus on the "standard" features of the language, which I think is a good thing.

You just can't go wrong with this book.

Great in previous editions

[n-baxley]

I have to say that this book in both it's second and third editions has helped me through countless problems. I keep the newer edition at work and the older one at home. My 2nd edition has just about had it so I think it's time to upgrade and rotate. I may just put the 2nd edition under glass as a tribute. Thanks David!

Re:if you use JavaScript, you're a tool

[cmdr_beeftaco]

I have mastered HTML and I wish to learn javascript. Once I learn some tricks in javascript will be well on my way to becoming a highly paid software engineer. All you Engineers make this stuff sound hard but all you need to remember is begin tag, end tag, unless you are using a p tag.

<strong><i>mad skillz</i></strong>

Re:Javascript not dead

[Pfhreakaz0id]

Dead? Heck no... Even most IE-only Intranet projects (like the one I work on) use Javascript as the client-side scripting lagnuage. Why? Almost ALL example code/books on client-side scripting are in Javascript. Heck, it's even the default in MS Visual Interdev (select "insert client side script" and you get a Javascript block).

Plus, I know an increasingly large number of ASP developers who use Jscript (microsoft's Javascript, they just can't use the name) as the scripting language for the Server-Side ASP code (rather than the VBScript mose use). Why? It just makes more sense. It's annoying to "switch mental gears" when going from the client-side code blocks in Javascript and the server-side VBScript blocks. Also, many are in the boat we're in where we do some Java stuff as well. Syntax is fairly consistent between Java and JavaScript.

Great book..

[Pfhreakaz0id]

but it has been out a while. I have an old second edition that is heavily thumbed. I recently inquired and for those that don't know, O'Reily has an upgrade program where for a small fee (I think it was $10 plus shipping, but don't quote me.) you get an upgraded edition. sweet. Look on their website for info.

Re:Great book..

[n-baxley]

O'Reilly does have a book upgrade program where they give you 30% off if you send them the title page. (More Info Here). Although, Bookpool has it on sale for 39% off.

what I think

[Horny Smurf]

I have the 3rd edition. This book is considered THE Javascript book. What's makes the book worthwhile is it's fine discussion of Javascript's innerworkings. If you really want learn how Javascript's objects, functions, and data type handling work, then this is the book for you. The criticisms of this book fall into three catagories:

1. "Not for beginners". Yes, this book is not intended for people who have never studied object oriented programming. But this is slashdot! Even beginners, if they are serious enough, will eventually need some clues about how Javascript really works.
2. "It's outdated". Duh, 4th edition! Anyhow, the author's in-depth explanation of Javascript innerworkings may never become outdated, and that alone is what makes this book worthwhile.
3. "Not enough examples". This is the only criticism that I actually agree with. Not only can this book benefit from additional small examples, but the author's explanations are sometimes lacking, or even worse, missing. On a few examples, he basically says, "This is worthy of study. Go ahead and study it." Sorry, I expect more from my books, than a grumpy professor in a university lecture hall, nearing the end of class.
   

No joking, Javascript is evil.

[SpanishInquisition]

The language I mean, not what it can do. It was hacked together by Netscape to somewhat resemble C++ but with the feature set of GWBASIC, so you really get the worst of two world.

Variables can be declared or not, line termination is optional, it's supposed to be object-oriented but there's no way to decalare class or methods, some construct are really horrible:

value =selectBox[selectdBox.selectedIndex].value

Scripting language for HTML should be easy,simple and have the right features (who needs the C++ binary operators anyway >>, Any project going to implement different scripting language for mozilla?

Re:No joking, Javascript is evil.

[looie]

The language I mean, not what it can do. It was hacked together by Netscape to somewhat resemble C++ but with the feature set of GWBASIC, so you really get the worst of two world.

Variables can be declared or not, line termination is optional, it's supposed to be object-oriented but there's no way to decalare class or methods, some construct are really horrible:

value =selectBox[selectdBox.selectedIndex].value

then you also don't like perl, i take it, since all your complains apply there, as well.

while you can't declare classes as simply as you can in some other languages, you can use the javascript prototype mechanism to do the same thing; and you certainly can create constructors and methods. evidently, you need to study up on the language a bit more. the book under discussion here would be a good place to start.

JavaScript is a solid language and can be used to interesting and useful things on the web. the fact is, people abuse every language, in one way or another. no user is forced to be lazy and propagate write-only code; it's done all the time in C, C++, perl and probably any other language you would care to name.

mp

Re:No joking, Javascript is evil.

[Chris Pimlott]

some construct are really horrible:

value =selectBox[selectdBox.selectedIndex].value

That's a DOM issue, not a JavaScript issue. And, BTW, that's only necessary in IE. In Netscape, value = selectBox.value works just fine.

Re:No joking, Javascript is evil.

[m_ilya]

The language I mean, not what it can do.

Hmm, I've heard a couple of times that JavaScript actually is quite good very OO language from some quite good programmers.

It's supposed to be object-oriented but there's no way to decalare class or methods.

I could be wrong as I'm not JavaScript programmer but AFAIK you can add methods to object. Yes, you cannot create classes because it doesn't have them! It is called prototype based OOP. You create object, add more methods to it and clone it to get a bunch of objects having simular type. If it doesn't sound like C++ or Java it doesn't mean it is bad.

Alternate titles

[eyepeepackets]

1. How to Annoy Anyone on the Planet in 3 seconds (Or less!)
2. Breeding Cookies for Fun and Profit
3. Learn Browser Crashing in 21 Days
4. Fantasy Pretend Programming for Beginners
5. Make Everyone Hate the Web in Five Easy Steps

Oy, I'm getting to be so cynical in my old age.

Note to the humor impared: This is a joke. Don't take it seriously because this is a joke. Don't be offended and flame me because this is a joke. Don't get all huffy and defend java and java script to your last dying finger twitch because this is a joke.
Here it is, the definitive statement on this post: THIS IS A JOKE!

Re:Alternate titles

[Mirk]

5. Make Everyone Hate the Web in Five Easy Steps
[...]
THIS IS A JOKE!

... and yet, somehow, I'm not laughing. Not because your point isn't well made. But because it is well made.

Alternative title #6: How To Build Really Spiffy Web Sites That Will Work Perfectly For You And About Two Other People, Provided They Both Use Exactly The Same Browser, Operating System And Patches As You, in 22 easy chapters

Good thing for Mozilla

[colmore]

I like seeing non-IE browsers getting coverage in the mainstream technical press. IE has something like a 95% market share, and many people use this to justify making websites that only work in IE. If *I* were running a web business then that statistic would tell me:

"Hey, 1 out of 20 of our potential customers can't use our website!"

And I think that IT should be pitching that same line to the suits.

Anyway, until someone develops intellegent JS filtering that works, I just turn it off.

Re:Good thing for Mozilla

[altgrr]

In order to ensure that the web pages my browser receives are entirely standards-compliant, I use WebWasher and set the browser tag to "Don'tYouSnoopMyBrowserTag-Bitch!" - of course, that's neither IE nor Netscape/Mozilla. It weeds out all the evil sites that chuck code in that they think specific browsers can handle, and it means that I don't have to view sites where they say "Ah - your browser's too old".

There's nothing wrong with building features in, as long as they're supplementary to the browsing experience - anything critical to browsing must be done in HTML. IMHO window.open() should be categorically banned from all browsers - there is no need for popups to open on page load or close, and, if a page needs to be opened in a new window, you can always use <A HREF="whatever" TARGET="_new"> - of course, if the browser doesn't support the TARGET attribute, you get to view the page anyway, just in the same window.

Re:Good thing for Mozilla

[colmore]

there are more browsers out there than mozilla.

a lot of offices that standardized around Netscape 4.x a long long time ago still use it, or have moved to 6.x/7.x now.

theres Opera

there are text-only browsers for the disabled

there are older versions of IE still floating around out there

it just seems crazy to require IE 5.0+ features when NONE of them are required or are even that handy for running e-commerce.

I think HTML should be standard HTML, you should make all your pages so that anyone can access any essential info, services, and features with a simple, standards compliant browser. I understand the desire for a flashy front-end, and for that I would suggest using Macromedia since it's much better and more available than MS exclusives, and by and large has built in bypasses for people who don't use Flash (assuming the web designer is smart enough to use them)

I understand why people use Windows. Hell, I even understand why some people use Outlook. But I don't understand why anyone would write a webpage that won't work on a non-IE platform. That's just stupid.

yeah, I know you were joking. and it was pretty funny, and partly true. I just felt like expanding my thoughts.

Re:Good thing for Mozilla

[colmore]

Lots of tech people read O'Reilly, not just Open Source ("open sores" that's clever, I bet you used to say Nutscrape and AOHell) programmers.

In a book that will be used by many web developers, having an official expert opinion saying that authors need to be aware of non-IE browsers is a very good thing for alternative browsers in general, and a good thing for Mozilla specifically.

Compatibility Question

[Outland Traveller]

Does someone want to briefly outline the major javascript compatibility differences between NS4, NS6/Mozilla, and IE?

I keep hearing second hand information from web developers that Mozilla's javascript implementation "breaks" compatibility, whatever that means.

Re:Compatibility Question

[kubrick]

Speaking as a web developer here -- it usually means that they've special-cased their code for IE and NS4 and the scripts they've written break on any browser which doesn't identify itself as one of those (especially as the netscape 4 test involves something to do with layers). Decent web developers write to the spec, and then and only then put in fixes for broken browsers that they know of.

Mozilla doesn't support a few DOM access methods that IE does, because they're not in the W3 specs... they use alternative methods that IE also supports, but this leads some people to say that Mozilla's scripting support is 'broken'.

(Tangentially, I was reading on Bugzilla about some performance problems with Mozilla's JavaScript & DHTML, but that was more speed-related than functionality-related, I think.)

Re:Compatibility Question

[twocents]

This might be too brief, but:

For one thing, remember that compatibility is very often not a matter of the JavaScript, but the Document Object Model within the browser that you are trying to manipulate, which implies CSS compatibility. http://www.webreview.com/style/css1/charts/masterg rid.shtml truly reveals how CSS rules can vary.

And as far as checking differences between browsers, that is simply a matter of checking the version your browser supports against a version of JavaScript (while I have heard that there are different implementations of different versions...but that's an experience thing I think). So you could go to http://www.gemal.dk/browserspy/js.html, check your JS browser support, and then when you reference a book on JavaScript, just take note of what version they are referring to.

Danny Goodman's books used to really spend a ton of time on compatibility (http://search.barnesandnoble.com/booksearch/isbnI nquiry.asp?userid=52AY8TR23D&isbn=0764533428), at least the 3rd edition had mucho information on NS 4 vs. IE.

While this response does not give you a chart, I have found, both programming in it and teaching it, that just being aware of supported versions and maybe not always implementing the newest features (which are often just shortcuts to do things one can already program) in JavaScript should keep one out of too much trouble. But man, that CSS stuff is what kills.

Hope this helps.

Re:Compatibility Question

[aWalrus]

IE keeps on supporting things they did that weren't int the spec (since ie 4) like document.all for referencing elements. Mozilla doesn't (actually, that is a good way to sniff browsers, by detecting the referencing and functions they support). Both ie5+ and mozilla support most of the DOM well (document.getElementById() being the most standardized of the functions defined in the DOM).

I find Mozilla's javascript implementation to be better than explorer's actually. The behavior is more consistent and well defined. The event bubbling (which most developers won't use consciously) is fully up to spec, whereas ie support is still a bit flaky in some of those things.

Personally I prefer Mozilla, but it is more a matter of good png support, tabbed browsing and other features ie is still behind on. Also, I HATE the new (as of ie 6 I think) image management "features" in Internet Explorer (the annoying toolbar that shows up when you mouse over images, and automatically resizes jpegs to fit the screen) yes, it can be turned off, but it annoys the hell out of me when the browser modifies in any non standard way the look of a page without asking.
--

Re:Compatibility Question

[Chris Pimlott]

IE keeps on supporting things they did that weren't int the spec (since ie 4) like document.all for referencing elements. Mozilla doesn't (actually, that is a good way to sniff browsers, by detecting the referencing and functions they support).

I believe in taking a slightly different tact - sniff for the function you want to use when you want to use it. Why rely on the assumption that only IE supports document.all (or something similar)?

I find Mozilla's javascript implementation to be better than explorer's actually. The behavior is more consistent and well defined. The event bubbling (which most developers won't use consciously) is fully up to spec, whereas ie support is still a bit flaky in some of those things.

Hear, hear! Mozilla is wonderful for JavaScript. True, it's often more rigid than IE (which lets you get away with a lot of bad coding practices), but I find that if a script works in Mozilla, it's much more likely to work properly in other browsers than the other way around. The debugging tools are also very nice. Being able to quickly test a refex or a short snippet of code in the JavaScript console saves a lot of time. The error reporting is pretty god too (IE has the most utterly useless JavaScript error messages).

Also, I HATE the new (as of ie 6 I think) image management "features" in Internet Explorer (the annoying toolbar that shows up when you mouse over images, and automatically resizes jpegs to fit the screen) yes, it can be turned off, but it annoys the hell out of me when the browser modifies in any non standard way the look of a page without asking.

No kidding. Ugh. It's quite non-intuitive as well; it starts off drawing the image in its native dimensions while it loads, but all of the sudden when it finishes it shrinks down. Then I have to wave the mouse over the image for 5 seconds until I can finally get that little 'restore size' icon to pop up.

Can you give some examples?

[avdi]

I can't think of an O'Reilly book I own which isn't excellent. True, some of them are old classics like "UNIX Power Tools", and "Managing Projects with make". But their most recent books have been just as exemplary - the latest edition of the Camel book simply improves on the earlier editions. The "CVS Pocket Reference" is exactly what I needed for day-to-day CVS work. The latest edition of "Web Designer in a Nutshell" has a permanent spot on my desk now that I have a website.

So - what titles would you warn against?

Re:Can you give some examples?

[Kamel Jockey]

So - what titles would you warn against?

One I with which I was particularly underwhelmed was their book on PostgreSQL. Also, their guide on Apache doesn't seem to cover anything that isn't already covered in the Apache documentation. Not to mention the fact it only covers up to Apache 1.3.3!

To be fair though, I'm happy with other O'Reilly books. There is of course the Camel book, plus their book on Web Graphics using Postscript and GNU Software. Also, the book Cascading Style Sheets: the Definative Guide is also of high quality.

Re:Can you give some examples?

[bunratty]

The editing of O'Reilly books has for some reason suffered over the past few years. The most obvious symptom is that O'Reilly used to correct mistakes with nearly every new printing, about twice a year for an average O'Reilly book. However, now I cannot find a single O'Reilly title that has corrected printings for the last year. For example, compare the printings of JS: TNG3 (10 reprints in 3 years) vs. JS: TNG3 (0 reprints in 9 months). Another example is HTML: The Definitive Guide, 3rd edition (4 reprints in 2 years) vs. HTML: The Definitive Guide, 4th edition (2 reprints in 2 years). Can you find a corrected reprint that has happened within the past year?

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

Re:Can you give some examples?

[AJWM]

I think part of that problem is the rate at which such information changes in this field, compared with the time it takes for a publishing cycle. I still find O'Reilly to hold to a much higher quality standard than many of the others.

Meanwhile, as your links show, you can always check the book's web page on the O'Reilly site for errata. Just print that page out and keep it with the book (or even go through and make the corrections by hand). Beats paying for a new edition.

Re:Can you give some examples?

[irix]

The only O'Reilly book I own that I can say sucks is the old MySQL one. I own dozens of O'Reilly titles and that is the only one I ever regretted purchasing.

The only publishers I trust are O'Reilly, Addison Wesley and the in-house publishers (Oracle Press, Sun Press, Microsoft Press). Anything else I typically wait for someone to really reccomend the book before I'll buy it.

Re:Can you give some examples?

[bunratty]

I think part of that problem is the rate at which such information changes in this field, compared with the time it takes for a publishing cycle.

That doesn't explain my comments about CSS Pocket Reference. Why publish the book right before IE6 is released, and why completely leave out CSS2? It sounds more like bad planning than a rapid rate of changing information.

Meanwhile, as your links show, you can always check the book's web page on the O'Reilly site for errata. Just print that page out and keep it with the book (or even go through and make the corrections by hand). Beats paying for a new edition.

First of all, that assumes that the errata entered by customers is complete and accurate. Sometimes customers will send in what's incorrect or missing, but not give the correct information. Sometimes they think the information in the book is wrong when in fact it's correct. Second, even small books have such a long errata list, such as HTML Pocket Reference, 2nd Edition, that a new printing is the only practical way to fix the problems. That small 96 page book has dozens of errors and omissions, some major. Finally, O'Reilly does not publish changes between editions. They used to publish changes between printings, but no more!

Forget popups

[thelexx]

It's really obvious that the people posting derisive comments about Javascript have never had to develop a site that actually does anything useful. Try creating some pages that accept a credit application without using Javascript (and MS-only shit need not apply). If/when you even get basic DOB validation done, show it to us.

LEXX

Re:Forget popups

[K.]

That's what the server-side application is for. If you're going to write a client-side app, why use something as convoluted as Javascript and a browser?

And don't give me any guff about cross-platform compatibility. A), javascript doesn't have it, and B) most js-heavy systems are intranet-based and targeted at a set browser+platform combination anyway. And even ignoring A and B, Java would be the better choice.

client-server, presentation-application, it's not rocket science.

Re:Forget popups

[thelexx]

Right, so you're going to send all the form data over the wire just to find out they put in 30/11/2000 instead of 11/30/2000. WTFever.

LEXX

Re:Forget popups

[thelexx]

OK, my first reply was hasty and a bad example.

I just got done writing the exact app I mentioned (credit app taking) using Java servlets with Velocity and client-side Javascript. Exactly as you described and no it isn't rocket science. The app is used by over 3000 car dealerships nationwide. We ain't gonna support a desktop app for all those people, no freaking way. And no it isn't targetted at one single browser/platform. And it works beautifully, taking over 30000 apps a month. And it uses Javascript for preliminary client-side validation of data so as to reduce traffic for us and lag for the user. Could have _made_ it work without JS, but that would have been retarded.

Now tell us about the large-scale project have you successfully completed and how was it structured.

LEXX

Re:Forget popups

[pmz]

Right, so you're going to send all the form data over the wire just to find out they put in 30/11/2000 instead of 11/30/2000. WTFever.

Or, you could normalize the data, so you don't have to parse a string at all. Much of the unnecessary JavaScript complexity in many websites stems from poor design of the data fields. Unfortunately, poor data field choices, in turn, stem from poor database designs, so a lot of JavaScript can actually point out a fundamentally screwed-up application.

If you insist on using JavaScript, it becomes trivial to check that the month field is between 0 and 13, for example, when everything is split up properly.

Database design--as much now as twenty years ago--is still the most important thing to get right (in an application that uses a database, that is).

Re:Forget popups

[pmz]

Try creating some pages that accept a credit application without using Javascript (and MS-only shit need not apply).

Now that I think about it, I can't think of a reason to use JavaScript on something like a credit application. It's just data entry, and the credit check either needs to be done on the server or by a person, anyway. (Also, see my other reply about normalizing data to avoid JavaScript altogther).

A credit application can be done well with pure HTML and a CGI program or Servlet for processing.

Re:Javascript not dead

[timothy_m_smith]

Take a look at Microsoft's ASP.NET. Even that is highly dependent on using JavaScript on the client-side.

Learn the tricks the Pros use

[Waffle Iron]

You too can learn to replace any simple, small table of hyperlinks with an annoying pseudo-GUI menubar that takes 5 minutes of mousing to see the possible options, and doesn't even work 20% of the time.

Once you've mastered that, you can go on to advanced topics like a "browser detection script", that refuses to show users any of the website unless they happen to have the same version of IE that you are using right now!

The best type of technology is not a means to an end, it is an end in itself. Javascript is one of them.

Re:Javascript not dead

[Oculus Habent]

Even Microsoft's own web-based outsourcing support tools use JavaScript almost exclusively. They are ugly beasts, written entirely in DHTML, with JavaScript controlled XML server communication, with <span> tags using onClick() and CSS to do the underline hover, instead of links...

Surprise! Even their websites are bloatware! Of course, that's no surprise if you've ever looked at MS Word/Excel MSHTML.

You Are Not Alone

[oldstrat]

Scripting should be knowledge area number two, right after proper html coding, and before design.
Nobody should be taught or allowed to use a Wysiwyg editor until they can build and work without it.

Other folks who come to me for fixes to thier Frontpage and Dreamweaver problems drive me absolutely nuts.
Ok, you've got wizards and plug-ins. What do you do when they don't work, or when your stuff doesn't display like you need it to? You harass people like me to tweak what you should have known before you ever were allowed to be paid to do web work.

End of rant... Keep coming to me, I complain, but I do enjoy the attention.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Browser compatibility

[mooman]

Since this is a real issue for anyone that does a fair amount of web development, I thought maybe I should point out a good resource that really supplements any JS book you use..

The IRT JavaScript FAQ is a surprisingly comprehensive list of FAQ and "how do I..." type questions for JavaScript. I find myself relying very heavily on it for snippets of code.

Once you've "learned" JavaScript, a site like this is great when you don't want to reinvent the wheel or spend 20 minutes skimming a book trying to figure out why something works in Netscape but not IE...

Re:congrats, you're an idiot

[joss]

Yeah well, you're a fuckwit. And the fuckwit who modded you as informative is even more of a fuckwit. He never claimed java was similar to javascript, the context he mentioned java in was trying to avoid people taking him seriously, ie he was talking to idiots. Waste of time really, oh fuck...

Javascript is not just for browsers anymore!

[mmcshane]

I too usually surf with Javascript turned off (tip: add the Preferences toolbar to mozilla to be able to toggle js/java/cookies/etc. on and off quickly) but Javascript is gaining ground as a more general purpose language. See a recent article in Javaworld on using Netscape's free Rhino library to add javascriptability to your applications. Also, Javascript is how many XUL mini-apps are implemented.

OT Comment...

[cr0sh]

You seem to have a handle on this, so I want to ask:

I have been investigating the use of XUL/XPCOM/Javascript for the creation of a user application with a database backend (after "discovering" how XUL works in Moz). However, I have ran into a bit of a stumbling block.

The application I am wanting to develop will replace a current 2-tier application based on VB/Access. What I wanted to do was create a front-end using XUL/Javascript to access (initially, but would be migrated to PostgreSQL later) the MS Access DB via ODBC - however, I haven't been able to find a way to do that which doesn't flag security (I even tried a convoluted method of creating a java applet that referenced a java application class that used JDBC to connect, but when it tried it throws an access violation error).

I understand the reasons this is happening (sandbox model and all) - and I ran across many people seeing this same problem. The only solution I could think of was essentially going toward a CGI-style 3-tier model - having the Javascript communicate to the backend scripts (most of the examples used Java servelets, but I imagine the same could be done using CGI) via HTTP, which would then pass the info back via the same route which the Javascript would present back to the user.

Is this truely the only way? For a long term solution, realize that this is what I want to do, but the initial conversion I am doing is really for a demo (to show the PHB's what can be done), and I don't really want to go through the whole trouble of trying to set up a backend server for a demo which might not even get the project the go-ahead (plus the attendent task of getting the permission to do it anyhow).

Thank you for any response you can give...

Re:congrats, you're an idiot

[moogla]

He's right though. It used to be called Mocha.

JS != OO

[Steveftoth]

JavaScript is not object oriented at all. It's prototype based.

There is no inheritance at all, it's just copying values from a previous defination.

in JS you can declare Object, then declare Object that 'extends' the first one. All the engine is doing is copying all the values from the first Object to the second. You can't call super.method() because that doesn't exist. If you could call super.method, then there would be inheritance.

Methods are not overloadable and can take any number of parameters. Objects are wacky because the same name can point to both a function and a variable.

var o;
o.callme = function ( a ) { alert ( a ) ; };
o.callme('a');
o.callme = ' a ';
alert( a.callme);

This code is kind confusing, and as such is one reason that I don't like JS, because other people code like this.

So to sum up, JS is a neat language but its 'features' make it hard to create large applications with it.

Re:Turn off javascript

[Aqua OS X]

use mozilla :) Kill the "onLoad" event handler