The number one issue that most people cite when talking about Javascript as a Security Risk, is a so called cross site scripting attack

No, the number one security risk is activating JavaScript in Internet Explorer and having a malicious or just plain infected site exploit you. Cross site scripting only holds the second spot.

It is the Website's responsibility to validate all the data it sends to you

That holds true for data submitted to a site by third parties, but not for the site itself. If the webmaster himself has nefarious intentions, this assertion is useless.

Blame javascript for the fact that someone, somewhere can use it maliciously, is like blaming email because people write outlook viruses

Do you surf with ActiveX enabled?

Get a fricking decent browser already.

I have. Links lets me surf without all the flashy colours and blinking GIFs, and it's actually very good at producing a close resemblance of the actual layout using a TTY. And a graphical browser is hardly viable if you're connecting via SSH over an ISDN line's 7.6kb/s anyway. Yes, some of us do.

And what about the folks who disable Javascript because they don't want to be annoyed with popups, Geo***tties or Tripod overlay ads and the like?

To Hell With Bad Browsers

Does that mean "to hell with the people who use PDAs, smartphones or other similar appliances" too?

client side form validation

That was the reason Javascript was invented in the first place. I admit that dingus' node's somewhat ambiguous wording misled me. So long as you don't omit checking the data again on the server, using JS for this purpose is fine. In fact, it's the one and only purpose Javascript can and should serve.

DHTML menus, allowing you display a great deal of information in a small area

Unfortunately, your DHTML menus won't work for 50% of your audience unless you put in a gargantuan effort to develop for multitudes of browser brands and versions.

Even if it works satisfactorily, the dynamically client-generated information is then out of any search engine's spider's reach.

Along the same vein, folks with PDAs/smartphones, voice synths, braille readers and so on are out of game. With purely CSS-based menus such as those shown on css/edge, there's a fighting chance that the menu information can be made available even using uncommon media that aren't a mouse/computer screen combo - I want to see you try that with Javascript.

Now, if you want me to rant about inconceivably abysmal CSS compliance in just about every current browser, six years after the standard was finalized and published (and several more after it was first talked about), that I can do.. I'm glad Mozilla is getting usefully close - though even it has its issues.

Makeshifts last the longest.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.