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

Turn off javascript

[Anonymous Coward]

Damn popups.

Re:Turn off javascript

[Anonymous Coward]

Damn browsers with no "refuse popups" option.

Re:Turn off javascript

[Aqua OS X]

use mozilla :) Kill the "onLoad" event handler

Chapter 5

[SpanishInquisition]

23 ways to annoy people with pop-up ads.

Re:Chapter 5

[Anonymous Coward]

In the new edition they're pop-under.

Re:Chapter 5

[the way, what're you]

Chapter 5, Section 2: Advanced Timing Techniques (Or, How to Pop Up Windows At the Worst Possible Moment)

Re:Chapter 5

[chickerino]

couldn't see that one coming! anyway the new popup is the 'I'm going to take up you whole screen with a horrible great big flash ad which you can't close for 10 seconds, and will probably press the back button to get rid of me' type ad

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.

Re:Chapter 5

[Anonymous Coward]

That would be a window that sits there and spawns new popup ads every couple of minutes on a timer. You're not supposed to see it (because if you can see it you're better equipped to kill it), you're supposed to see the ads it spawns.

Time to go home...

[HiQ]

the maturation of the Netscape 6.x,7.x / Mozilla browser suite
It's friday afternoon, it's 16:30 over here, I'm at work, it has been a busy day, and I was convinced it read 'the masturbation..'. I think I'll call it a day and go home now.

Re:Time to go home...

[Anonymous Coward]

ltrol

Re:Time to go home...

[Smedrick]

Haha...I did the same thing. Unfortunately for me, it's not even noon here.

This is going to be a loooong day...

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.

[papasui]

I love how you all suggest not to use IE. Well when you work in a big company and everything that gets installed on your computer needs authorization through a department thats literally 5 states away and takes over 3 months to get approved installing a different browser insn't a choice, get used to the fact that 95% of the US uses Microsoft. I suggested a standards change so that every browser no matter what you use will have this feature.

Re:Great.

['The '.$L3mm1ng]

As I said before, use the Crazy browser and you have IE with tabs and a popup filter. IE is faster than Mozilla in certain areas, while Mozilla is faster in different areas. Don't be so biased.

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.

[Anonymous Coward]

That's right. Mozilla is faster than IE when it comes to crashing or chewing up memory. When it comes to browsing and rendering, IE wins hands down.

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.

Timing

[sys49152]

New Edition? Overdue? I know that /. reviews are not necessarily timely, but I've had the 4th edition of the JavaScript book sitting at elbow for at least six months.

Re:Timing

[Cnik70]

same here.... it already has loads of cobwebs on it.

Use Addall instead...

[MajorBurrito]

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

Re:Use Addall instead...

[Anonymous Coward]

Humm, at first glance it seems that site is
very javaScript heavy but I tried it out JS
off and it worked OK.

Re:Use Addall instead...

[Anonymous Coward]

sure, but BN has same day bike messenger delivery in NY at least (don't know about other places)

Re:Use Addall instead...

[Anonymous Coward]

http://www.walmart.com/catalog/product.gsp?cat=186 74&dept=3920&product_id=1612207&path=0%3A3920%3A18 674%3A18691%3A20239

or walmart. I buy ALL my books from them now. They really *do* have the best prices

Install Mozilla

[brunes69]

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

Problem solved.

Re:Install Mozilla

[papasui]

I have it and it works great, but IE doesn't have this feature and I have to use IE at work.

Re:Install Mozilla

['The '.$L3mm1ng]

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

Re:Install Mozilla

[Mirk]

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

Or better still: Edit -> Preferences -> Advanced -> Scripts and Plugins -> Enable JavaScript. Uncheck. Done

Re:Install Mozilla

[Anonymous Coward]

You can install the IE explorer theme for mozilla, view->apply theme-> get new themes. The boss would have to be looking pretty hard over your shoulder to tell the difference!

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

[sys49152]

For all of you who think that Mozilla stops pop-ups go to epicurious.com and watch. Then go to bugzilla and check out bug # 126224.

Apparently the pop-up handling routines are relatively simplistic and stop window.open calls while a page is loading or unloading. But our friends at doubleclick and the NY Times simply moved their pop-up calls onto the *image* on-load event. And when that one's squashed they'll put it on the submit event, and then the mouseover event, and so on. The good folk over at Mozilla are noodling out the solution right now. I'm rooting for 'em.

Re:Install Mozilla

[basso]

For all of you who think that Mozilla stops pop-ups go to epicurious.com and watch.
Hmm. I just went there in Galeon (1.2.0). No popups in sight. I don't get popups at the NYT either. And yes, JS is enabled.

Re:Install Mozilla

[OYAHHH]

I'm using Mozilla and I'm not seeing any pop-ups on epicurious.com.

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.

Re:Install Mozilla

[Nf1nk]

I hate to say it but other than the crappy unrequested browser windows (which I fixed by using mozilla) Java script isn't too bad, It does simple math problems fairly well (most of the time) it does nice image swapping for navigation, it does navigation pretty well (pull down menus for navigation are nice.)

At any rate I would rather a site made use of javascripts than flash

Javascript not dead

[larry bagina]

I'm sure the Microsoft FUDders will pop in and claim the VBScript killed JavaScript. Not true! JavaScript is standardized and cross-platform, VBScript isn't.

Heck, Macromedia uses JavaScript as the programming language for FireWorks and DreamWeaver customization. I think the next gimp release will allow you to use Javascript for scripting (like you can do with Perl and Scheme). Too bad source forge searching is down right now, or I'd find the link for that project....

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.

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.

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.

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

[PissingInTheWind]

I haven't noticed what you are talking about, but maybe you are referring to more "newbie friendly" titles on some chosen subjects.

If you get to hardcore references (like the reviewed book here, the camel book, or a lot of others) then you are wrong. They still have the same good old O'Reilly quality.

If you are talking about "Learning VBScript" or "ASP in a Nutshell" or stuff like that, then you are right, it won't be a very interesting book. But hell, who can write a good, fun and informative book on subjects such as VBScript or XML?

Re:O'Reilly quality has gone down

[cifey]

When I was doing web programming the 2nd edition was the most popular reference book we had. The section on dragging and dropping was excellent, the reference material was very useful. Thought it was a great book.

Re:O'Reilly quality has gone down

[paulplee]

I know it is very tempting to just trust a brand, but shouldn't consumers be doing their homework before taking the hit?

If we all just buy without "cracking open the cover", we'd all be using Microsft everything.

And now you won't buy any O'Reilly book without cracking open the cover either. I am sure it's their loss to lose customers like yourself, but you might also be missing out if you just blindly trust/don't trust a brand.

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.

[Pfhreakaz0id]

your argument doesn't apply. Intranet project. Browser is IE 6. Period. End of conversation.

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.

[Anonymous Coward]

It isn't being done because all of the minute differences in javascript implementations in the various browser flavours & versions on different platforms make writing truly universal code a nightmare. The only solution I've found is to stick to the most basic features that are guaranteed to work for nearly all clients. Every time I try to use more advanced features, I end up pulling my hair out for hours/days trying to make it work for all versions, and then someone *still* comes back saying it doesn't work on IE 4.5 on the Mac (or fill in your least favorite browser here).
I suppose the other thing I could do would be to detect the client when they access the page and do a code branch specifically for that browser, but that's a nightmare as well.

If I do everything on the server side, I can guarantee that it will work for everyone, since I only need to code for my app. server. Yeah, that means that I have to go back to the server sometimes when I could use JS, but it's a tradeoff I'm willing to make. Consider error checking/form validation. I could write a client side validation script for every form I produce, but doing so isn't going to get me out of doing the same thing on the server side, since users can disable javascript.

Don't get me wrong, some great things can be done with javascript, I just find the overall effort required not worth it. I'd rather spend my time writing code than endlessly running around the testing lab trying to fix the differences between Netscape 4.6 and 4.7x.

As a user the lack of standardization is a total pain in the ass as well. Last night is a perfect example - my SO couldn't view a well-known travel site through Netscape on our (admittedly aging) Mac because whoever coded the damn page had left so many script errors/incompatibilities in the page that she was effectively barred from accessing the site.

Just my humble rant.

Re:Strengths of Javascript.

[Mirk]

your argument doesn't apply. Intranet project. Browser is IE 6. Period. End of conversation.

``End of conversation''? You are joking, right? :-)

Really, in the sort of homogeneous environment you describe - in which a central authority mandates that everyone has to use the same software - then you're quite right. Everything is easier when your allowed to throw portability out the window. But is that really the kind of world you want to live in? Do you want your employer to tell you that you have to use their favourite browser, which doesn't block adverts/prevent popups/support tabs/[insert your favourite feature here]?

If you're happy with that, then yes, we can all go ahead and build applications that run on the client. But if we want the freedom to use the client software that works best for us, that approach ain't gonna work.

(And, for what it's worth, you didn't say anything about a homogeneous environment in the comment I was replying to.)

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.

[Foggy Tristan]

Nope...

My favorite was a colleague who wrote Javascript to write out the Javascript (e.g., document.write("var somevariable = 6"))

Re:Strengths of Javascript.

[Anonymous Coward]

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?

Because IRL it's harder code to write, it doesn't work even after extensive platform-specific tweaking and it's not really a much different user experience, given that it tends to result in heavier pages taking longer to download and update.

Re:Strengths of Javascript.

[jesser]

One example of how javascript can improve a web site: a webmail site could do a client-side sort in javascript-supporting browsers and a server-side sort in other browsers. I know that sorting a table works in at least IE/Win and Mozilla, because I wrote a bookmarklet that does it, yet none of the webmail sites I use do a client-side sort :(

Another example: an inline or onload script can focus a form element if the the user more likely to enter something into the form than scroll the page. Most major search engines do this. Alltheweb doesn't in alchemist mode and Netscape search never does.

What other examples do you know?

Re:Strengths of Javascript.

[taeric]

That is a valid point, but I am afraid I don't agree with you on this one. Web *Design* is all about HTML. Indeed, I would prefer it if most sites are all designed as skeletal html files before the developers start trying to work them out.

However, that is only one of the parts of web design. JavaScript can be used to make all sorts of tasks more manageable. Especially if you are working in a controlled environment and can use some of the more advanced features of the DOM. At this point, JavaScript can help integrate all sorts of solutions into a web based product. Like another poster said, JavaScript can help make possible some rather usefull solutions.

Note, though, that I fell into the same trap of using the wrong words. I said internet developement. There, you are right, using JS is risky. However, in an in-house solution, I prefer the developer to have knowledge of what can be done with JavaScript without having to resort to server side trips.

Re:Strengths of Javascript.

[Inda]

I'd rather write Javascript then a SQL procedure any day of the week!

I know what you're saying... :)

I've used JS recently for accessing the FSO and producing dynamic VML graphs. It is always my first choice before server-side scripts. Intranet publishing removes any hassles I have with browser compatablity meaning I can spend longer on the functionality. It's so much better than VBS - I love it.

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.

[Ravagin]

> I prefer the developer to have knowledge of what can be done with JavaScript without having to resort to server side trips.

Aye, I concur.

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.

[Anonymous Coward]

but on my employees dime, I do what they say.

Cool...where did you find people gullible enough to pay you for the privilege of working for you?

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.

Re:Strengths of Javascript.

[Fishstick]

I've always been very annoyed with web forms that don't use Javascript to do some basic validation before the form is submitted.

Like, when I fill out a form, sumbit it, wait for a response and, oops, the phone # must be in xxx-xxx-xxxx format. It went all the way back to the server before this was caught, and a new page had to be sent all the way back with this "error" for me to correct.

I've done a small amount of client-side form validation in Javascript for an intranet site we set up, it's not that hard. It's a win-win: you decrease the load on the server in doing the initial validation and you improve the user's experience by eliminating the extra round trip.

Re:Strengths of Javascript.

[Anonymous Coward]

the only time I've seen crap code like that is in advertisement code. bleh!

Re:Strengths of Javascript.

[Anonymous Coward]

I pretty much missed all the pop-up and pop-under ads, but that was as I had disabled javascript even before that.

Why did I do such a thing?

I hated how abusers of javascript would hijack the address bar to march text around. (And then some bozo went and coded <marquee> in a browser without a means to disable it. Argh!) I now use a browser that can defeat unwanted pop-ups & pop-unders, but I still keep javascript off most of the time.

While many useful things can be done with javascript, far too many annoying things actually ARE done with it. I only turn it on if there is promise that it'll be useful *to me*... this doesn't mean it gets turned on for sites that do nothing without it. They just get skipped over.

Re:Strengths of Javascript.

[madprof]

Nope. Client-side processing is so annoying to get right for *all* users that you may as well not use it for anything important.
Cool features are "okay" but when they break because you just happened to use a PDA or something you get annoyed, and whoever owns teh web site you're looking at it about to lose an pair of eyeballs.

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!

Typecast

[intermodal]

Javascript has been typecast. There are a lot of useful things you can do with it if you want to, but it definitely gets a bad rap for all the popup functions and such. This isn't to say it's a particularly good language, just that it does have its uses.

Re:Typecast

[Anonymous Coward]

No, there is nothing useful that you can do with javascript, at least not for me.

In order to avoid all the stupid javascript tricks out there, I browse with javascript turned off.

I will leave your site at the point it stops working with javascript turned off.

That's too bad if expecting me to buy something from your site. I will take my browser (and my business) elsewhere.

JavaScript...

[m.batsis]

...is a full blown programming language and as with anything that works, it can be used in good and bad ways; so please spare me with the popup bla. JavaScript is the most compatible way of applying client side programming logic for internet applications today (it's been some time since we where talking about mere web pages) and is the best in what it does. This book is indeed the best in it's category (and I've been over a number of books on the subject, as well as several on-line tutorials); I bought it the day it came out. It can be used as a refference as well as a way to learn the language. Another piece of good work by Flanagan.

Re:JavaScript...

[knorthern knight]

> ...is a full blown programming language ...and that means that *YOU* want *ME* to download and execute *YOUR FOREIGN CODE* on my machine. No fucking way. You may not be 50 like me, and remember the days of BBS's, when the prime directive was *FER-CRYIN-OUTLOUD-DON'T-DOWNLOAD-AND-EXECUTE-EVER Y-PROGRAM-YOU-SEE*.

It was a good principle in the days of BBS's, and it's still a good idea today. A lot of people were infected with NIMDA because their Internet Exploder had scripting turned on. I run linux and Mozilla; however, I don't bury my head in the sand with an "it can't happen here" attitude.

I got sick and tired of the security-advisory-loop
1) javascript is your friend. All of you people with javascript turned off are a bunch of paranoid pinko-commie-fags.

2) security alert. The sky is falling, security hole discovered in Javascript, turn off scripting immediately

3) security patch/update released; apply and GOTO 1)

Javascript started with so little functionality in the Livescript/Mocha days that everyone figured it didn't need a sandbox. Now feature-creep has set in and it's obvious that Javascript gives too much power over your machine to the website. Outside of trusted code in the intranet at work, forget it.

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>

I love popups

[RestonVA]

I actually do.

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..

[awrc]

Yes, Bookpool shows the 4th edition as being released in December 2001, so it's been out for about eight months.

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.

[Anonymous Coward]

you could use VBscript instead

Re:No joking, Javascript is evil.

[Anonymous Coward]

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

Of course not - it's a prototype-based OO language, not a class-based one.

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.

[axxackall]

It was a strategic mistake to use such a horrible language to add some "dynamic" functionality to HTML.

I think if they would really want to add "dynamic" functionality then they should use someting from LISP family or, generally, any functional programming language.

Even years ago Emacs was one of the best document processing applications written itself mostly on the language that extends it - on Lisp. Emacs example proves that a harmony FP language brings to the application doesn't break performance. Why did they ignore Emacs experience?

Re:No joking, Javascript is evil.

[Anonymous Coward]

because only retards use emacs.

VI UBER ALLES!

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.

Re:No joking, Javascript is evil.

[Anonymous Coward]

See the Javascript 2.0 specs if you want classes.

Preliminary work has been done about "Rhino2" - a JS2 interpretter.

Re:No joking, Javascript is evil.

[Media Tracker]

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

It's supposed to be Object-Based, not Object-Oriented.

Furthermore, there are ways of declaring classes, although the keyword class is never used. It's not a particularily powerful language, agreed. But in an environment such as the web, flexibility is a must and JavaScript provides it very well.

I think it's well suited for what it's used for.

Re:No joking, Javascript is evil.

[Fabb]

I suggest you learn the language a bit more.

There are ways to declare classes and methods, you can even achieve inheritance. Sure it's not as pretty as true OO languages, but it works, and works well.

You can easily shot yourself in the foot, but if you are careful you can write very expressive code.

We're using JavaScript a lot for server-side processing. And we find that the ability to define new properties on the fly help us write very readable code. For example you can easily map an XML document to the corresponding JavaScript structures, interface to a RDBMS and map the columns to variables automatically named after the column names, etc.

Re:No joking, Javascript is evil.

[Anonymous Coward]

mod parent up...

javascript implements OO through it's special prototype based way of inheritance.

sure, it doesn't to fancy sounding stuff like polymorphing...

but yes. you can create objects. "classes", extend these, through the use of prototyping. add methods to these objects. a simple javascript function is an object in itself... and can be assigned to another object, as a method.

how do you think entire DHTML API's are written, with the use of ugly ugly chucks of "if then, elseif" and so on? no. through the use of advanced OO programming. yes. programming.

you can program in javascript.... really!

Re:No joking, Javascript is evil.

[Zaiff Urgulbunger]

Funtional programming is a total git! I've been subjected to it in XSLT and its not a great experience.

I'm guessing the reason why you suggest it would be good for adding dynamic functionality is the same as why it was chosen for XSLT; so that parts of the page can be rendered without having to re-execute/re-render everything. I can understand that, but I can better see the benefits of using a light *scripting* language - i.e. typeless and easy to code.

So my question is, how would using an FP language benefit a browser?

Re:No joking, Javascript is evil.

[axxackall]

XSLT is not a general FPL and therefore it is not a good start to begin with FP. Try Lisp or Scheme to learn FPL. You may also try to learn FP in Python, but FP is some limited there.

Why FP for page rendering? Because you can "attach" functionality to data "on the fly", modify it, re-attach - something that OOP will never give you (unless it's OOP in FPL). Embedding scripts to pages (JavaScript in HTML) is a good step to it, but this step is not complete.

With lambda expressions documents would be much more than "just a set of paragraphs" (HTML) or "just a tagged structure" (XML).

The industry was frustrated with HTML and created XML, which is more general than HTML, but still primitive. That's why the industry has created RDF - even more general format, but even RDF is still not functional (despite DAML-OIL attempts to fix it).

There is some projects to bring FP into documents - XLambda, XESPR, but I am not sure if there any progress out there.

Re:No joking, Javascript is evil.

[Xaltlee]

Actually, Javascript now supports class declaration, package declaration, variable and function modifiers (public, private, etc), try/catch/finally, and so forth. This probably has to do with it being turned into a compiled language for .NET. It can and has been used to create compiled programs, web services, all Windows stuff, and some very truly unique things thanks to its integration with Windows Scripting Host and with IE. One of the most impressive JS coders I know is Essam Ahmed - look him up here. Like anything else, Javascript is a tool and can be used for good or evil. The rightness or wrongness of its functions is dependant on the wielder. Simply because it's different from what you know does not make it 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

COmpare this to Javascript Bible

[pcause]

I am a user of the Javascript Bible. I found that it has some of the best examples, and does a particularly good job with NS4 strangeness. How does this book compare

me too

[af_robot]

but considering development time of Netscape 6.x words *masturbation* and *maturation* have almost the same meaning.

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

[Anonymous Coward]

"non-IE browsers getting coverage in the mainstream technical press"? You are a dork. O'reilly started by selling printed manual pages for open sores applications. Hell, they even have a book on SLASH.

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

[Anonymous Coward]

I think that should be ..

"Hey, 1 out of 20 of our potential customers are actually Linux dorks running Mozilla who wouldn't pay for it anyway!"

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.

BROWSERS Comparison

[Anonymous Coward]

Does anyone know a good site that has either a chart or a listing the various functions that browsers supports from IE to Netscape?

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

[Anonymous Coward]

You don't know what you're talking about.

Justification :

If I turn off Javascript, I can put in any date of birth I like. In fact, I can post the form data with a script, if I really care to.

Therefore, you still have to do the form authentication on the server side of the link, regardless.

Javascript is a nice-to-have, if you've got the time to write your authentication twice. It makes things so much easier for the user, but it can only ever be an addition to sane server-side checks. If you rely on the browser to do validation, you've broken the cardinal rule - /never trust the client/.

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

[the_verb]

Obviously you've never developed a web system that had to deal with any load.

Form validation and image swapping are the two best uses of JS, in my opinion. But they're pretty important.

--the verb

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

[Anonymous Coward]

Three letters. J S P.

Re:Forget popups

[Anonymous Coward]

Validation must always be done on the server anyway, otherwise the user could spoof input values. So the argument that client-side validation will somehow reduce server load is false.

Using JavaScript for validation increases development time because validation must be done on both client and server.

Maintenance cost is increased since the validation code for client and server must be synchronized.

Using JavaScript allows the introduction of security bugs, such as cross-site scripting.

In summary, JavaScript is icing on the cake. It is a high-cost item suitable at best for intranets, and is unusable when your goal is to develop a secure system.

Re:Forget popups

[Anonymous Coward]

You're on the money, Lexx.
This isn't about somebody's weblog and photo album.
Every click, 1k graphic and nested table counts on a high traffic site. I've used javascript to do some pretty complex calculations on a high volume market application that would have been brought to its knees if it had to hit the server everytime Joe trader wants to see a new scenario.

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:Forget popups

[Xaltlee]

How 'bout this?

//Other global variables
var strError='';

function checkDOB() {
var intMonth=Request.Form("DOB_Month");
var intDay=Request.Form("DOB_Day");
var intYear=Request.Form("DOB_Year");
/*Thanks to JS's non-required typing,
the code above doesn't error out if the items
involved weren't entered as an integer.*/
if (isNaN(intMonth)||isNaN(intDay)||isNaN(intYear)) {
strError="You entered your birthdate incorrectly. Please try again.";
/*Note - if you use select boxes for the DOB
fields, you won't have to worry about this
TOO much - but be sure to secure your application
so that it only accepts connections from itself
or other pages on your site. Even then, it's a
good idea to perform the above check.*/
return false;
}
var datCurrentYear=new Date().GetFullYear();
if (datCurrentYear-intYear<21) {
strError="You are too young to apply for this loan.";
return false;
}
else if (datCurrentYear-intYear>125) {
strError="You seem to have entered the date of your birth incorrectly. Please correct this.";
return false;
}
//Go on and do other stuff.
}

function Page_Load() {
checkDOB();
//Do other stuff.
}

And best of all, this code can be reused with only minor changes (make Request.Form() into document.FormName.FieldName.Value, change the display of strError) on the client side, since it's Jscript ASP. Javascript is good for more than the client side.

I realize the post above was commending Javascript. I'd like to point out, though, that JS has its strong and weak points. It IS best when used with server-side code, and I believe this will help make that point.

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:Learn the tricks the Pros use

[elmegil]

ah bite me.

I have created a web-based lab equipment reservation tool that would have been impossible without javascript. Just because most people abuse the tool doesn't mean the tool isn't any good.

Re:Learn the tricks the Pros use

[Anonymous Coward]

impossible without javascript? what?!?! not to sound condescending, but a web-based lab equipment reservation tool doesn't sound like rocket science. there are many ways to do that without javascript.

Re:Learn the tricks the Pros use

[elmegil]

There may be ways to do it without javascript, but the interfaces all suck.

Javascript lets me, for one example, do a search for an employee's ID number (to add someone to the database so they have access) from one window and use the result to populate the form that actually adds the ID to the database.

Impossible means impossible to do elegantly with a reasonably functional interface. I could do everything with serial forms in one window, but that would suck and be confusing to most users.

congrats, you're an idiot

[Anonymous Coward]

Javascript has nothing to do with Java. Netscape chose the name to make it popular.

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...

Re:congrats, you're an idiot

[moogla]

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

Re:Time to go masturbate

[Anonymous Coward]

All JavaScript programming is just a "masturbation":

Programming with bad VM is alike a sex with an ugly woman.

Programming with VM without good libraries is alike a sex with a doll.

Programming on language without good paradigms is alike a sex with animals.

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

[Anonymous Coward]

> all you need to remember is begin tag, end tag, unless you are using a p tag.

You're wrong. It's perfectly valid to use an end p tag.

http://www.w3.org/TR/html4/struct/text.html#h-9.3. 1

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

[Anonymous Coward]

What about:
<br> and,
<hr>

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.

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

[Rytsarsky]

XHTML mandates that all tags be closed. So, <p>'s MUST be accompanied by a </p>. <img> tags will become <img />. There are other small differences from html 4.01, you can find them all at http://www.w3.org/TR/xhtml1/. For the sake of forward compatibility, use xhtml when writing pages. For the sake of being nice to all your viewers, validate your pages at validator.w3.org.
I have read all of the html specs and recomendations thoroughly (as well as css, xml, and others), and do not claim to have mastered html... ;)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Finally someone

[Anonymous Coward]

How well written. You really said it. I couldn't agree more about the misconception of javascript. Most people think of either popups or the slow compiling grey box. I've been using Javascript with DOM for a while. I love how it enables true usable applications.

any opinions on VB Script. Some people seem to live by it. Can't figure it out for the life of me.

JavaScript != annoying HTML

[jeti]

Mhmm. Joke or not - I recently taught myself JavaScript and I was positively surprised. Since I'm working on a Mozilla project, I was spared the usual hell of incompatibilities. Here's some points I didn't know about JS:

1. JS can fully manipulate any XML document.
2. Mozilla is largely implemented in JS (natively implemented libraries + JS + XML).
3. JS is kinda clean and simple. Everything is based on associative arrays.

most books about JavaScript are about old versions

[Anonymous Coward]

Take C++ or Delphi (ObjectPascal) programming, for example. By searching the web, you can find A LOT of useful articles, tutorials and references, and they are current.

If you search the web for JavaScript, 99% of the things you will find are:

- Lots of ready made JS scripts and effects for your site. Most of the time they work, but the code in them is usually so poorly written that understanding and modifying them is very hard.

- Tutorials and articles that are way outdated and refer to ancient versions of browsers, without using new features.

I found that most of the books are severely outdated, too.

What we need is a good, comprehensive book which teaches JavaScript STANDARDS and how they apply to the browsers currently in use.

I don't need 100 ready made scripts.

Instead, I need a complete list of what objects are available, what events, methods and procedures are available, a DETAILED description of each object, method, procedure, and most importantly, for each item above, I need to know what browser supports it!

Also, a detalied description of common techniques (like using an absolute positioned DIV) is badly needed.

A book about JavaScript should also be about DHTML. The book should teach JavaScript and DHTML together.

I don't know how good the O'Reilly book is, because I haven't read it, but I recommend JavaScript Bible, Golden Edition, by Danny Goodman. It's pretty good.

Re:Alternate titles - don't get it!

[Anonymous Coward]

You could have saved yourself some effort by not stating that this is a joke.

As you can see from the people that replied to your post (above), some people just don't get it even if you tell it to them.

BTW, I am not complaining about your post but about the ones that, in spite the fact that you told them it was a joke, replied to complain about the joke not being funny/accurate/complete etc...

JOKE: Why did the chicken cross the road?
A: To get to the other side...

Replies:

• Your are wrong! there is no scientific proof of this!!!!
• You are a moron!! you know nothing about chickens or roads
• The joke would be funnier if it would have been a kangaroo instead of a chicken (who likes chickens anyway?)

I guess some people don't have a sense of humour or live in a very tense environment they don't have time for silly jokes (only the good ones!!)

cheers

window.open() does need rules..

[Anonymous Coward]

It's not necessarily evil all the time. There are a variety of sites I visit where smaller popup windows are used to view comments or deal with additional information. Recently, on our intranet, we used a popup to allow users to select a date from a calendar, as sticking the calendar on the main page would just be clutter.

TARGET="_new" is useful, but it won't allow you to specify the size or format of the browser window.

Install Opera

[Anonymous Coward]

F12- Check refuse popup windows

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

[Anonymous Coward]

Is there anything worse than a Christian HTML KnowItAll?

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...

You know what's _really_ cool?

[cDarwin]

I have started using javascript to compose XML from form data on the client side. I then pass a single parameter containing this XML back to the server in the query string. Presto! I am now able to use standard XML parsing/processing libraries to deal with all of that messy form data. This technique really shines when dealing with nested one to many relationships in forms.

Have fun!

Slashcode.com has disabled AC posting!

[Anonymous Coward]

In a move I find more childish than the trolls it aims to stop, AC posting has been turned off. This is more of an outrage than the lameness filter that filters nothing.

Try to AC post

tp

[Anonymous Coward]

test_p0st

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.

Months overdue

[Anonymous Coward]

I usually don't come down on this site, but come on guys - this book has been out for months. OR are the sales a little low and O-Reilly paid for the review?????????????????

In that case...

[Anonymous Coward]

...try AdSubtract.

Sits in your system tray; works with any browser; kills popups and all other advertisements. You'll be surprised at how much more friendly your browsing experience is.

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:OT Comment...

[elmegil]

Unfortunately, I'm not using XUL/XPCOM and really have no idea what they are :-). My app uses PHP mixed HTML primarily for the "front end", with some glue bits like the one I mentioned in Javascript, and a MySQL backend. So technically, it's the cgi-style 3-tier model you're talking about, since PHP is executing in my (apache) web server.

Just for the record, writing this app has been my own way to educate myself in the tools to do web apps, not my primary job function. Version one was really ugly CGI/flat files, Version two which I've referred to here is PHP/Javascript/MySQL, Version three which is only vaguely planned at this point will be full blown java with JDBC etc. Since I'm using these projects to teach myself the relevant technologies, I can't say that I know all the ins & outs; only that I have strong opinions about clean user interface design.

I don't know that my way is the only way to implement things, nor that the 3-tier model is required. I just know that this is what works for me, and that javascript for communication from one window to another and inter-window control are key to keeping things simple for the user with my particular implementation.

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:JS != OO

[Fabb]

True, JavaScript is not really recommended for large application (besides features, performance would be a problem).

But readability is not a language feature. I know some people able to write extremely obscure (and thus stupid) code in C++.

The original poster claimed that classes or methods could not be declared, that is why I felt compelled to answer.

At our site we like JavaScript, it is a nice addition to our toolset. But are disciplined when it comes to coding style and conventions.

BTW, it is possible to call superclass methods in Javascript:

function BaseObject()
{
this.init();
}

BaseObject.prototype.init = function ()
{
this.value = 10;
}

BaseObject.prototype.method1 = function(val)
{
this.value = this.value + val;
}

DerivedObject.prototype = new BaseObject();
DerivedObject.prototype.constructor = DerivedObject;
DerivedObject.superclass = BaseObject.prototype;

function DerivedObject()
{
this.init();
}

DerivedObject.prototype.init = function()
{
DerivedObject.superclass.init.call();

}

DerivedObject.prototype.method1 = function(val)
{
this.value = this.value * val;
DerivedObject.superclass.method1.call(this, val);
}
var derived = new DerivedObject();

derived.method1(5);

alert(derived.value);

(sorry for the indentation, can't figure out how to post properly indented code)

Granted, this is not as obvious or pretty as in other languages as C++, Java, ObjectPascal or C#. But this is possible.

Which version?

[Steveftoth]

Which JavaScript language version is that from? I'm assuming that it's 2.0, not 1.2. Which browsers support it?

Re:Which version?

[Fabb]

I don't use this kind of construct for client-side JavaScript 2.0 (only server), but this is supported (at least, haven't tested in other ones) in Mozilla 1.0 and IE 6.

Who cares?

[kayakgreg]

Javascript sucks and it should be avoided like the plague. I hate visiting websites with stupid cutsey popups and mouseovers.

Seems a lot of websites try to de-emphasize their hideous design flaws and lack of content with Javascript that reminds me of cheap parlor tricks.

The worst thing is that it's buggy and half the sites that use it don't know how to use it correctly, so I get a Javascript error in my browser and the rest of their crappy site doesn't even work.

Re:Who cares?

[xutopia]

Javascript is the only way to create a full fledged web application. JS does a lot of things and you couldn't name half. You just happen to know the porno popup the most and base all your opinion on it.

Slashdotted!!! +5, Informative

[Anonymous Coward]

JavaScript : The Definitive Guide, 4th Edition
Posted by timothy on Friday July 26, @10:30AM
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.