Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

The Case Against Javascript

by Aristotle (Chancellor)
on Nov 18, 2002 at 17:18 UTC ( #213813=note: print w/replies, xml ) Need Help??


in reply to The Case for Javascript

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.

Replies are listed 'Best First'.
The Case Against The Case Against Javascript
by jryan (Vicar) on Nov 18, 2002 at 21:14 UTC
    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.

    No offense, but why should a commercial developer developing for a commercial firm feel the need to design to as low of a case as yours? The extra traffic that might be kept by a flashier design will more than make up for the traffic that is lost by a visitor that is using a browser that is too-primitive to view the site.

    By the way, at home I connect via a 56k modem, and I use mozilla 1.1 as my browser. ISDN must be luxury ;)

    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?

    I don't know about you, but my browser specifically allows me to turn off popups.

    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.

    Incorrect. Netscape lost the browser war serveral years ago; Internet Explorer 5.0+ is now used by over 92% (and rising) of the internet populatation. Please see http://www.thecounter.com/stats/2002/October/browser.php for more info.

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

    Why? The DHTML menus that I've seen involve lists of links in divs, that are then hidden, showed, and moved by JavaScript. Theres no reason that a search engine wouldn't be able to follow that.

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

    No; If you read the article, you'll find that is mostly about not retro-designing for dead, non-CSS supporting browsers (NN4), when the future of web browsers promises to be rich with CSS support. A List Apart has always advocating support for wireless browsers; in fact, that article even mentions that.

    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.

    You're comparing apples to oranges. Javascript is a scripting language, CSS is a descriptive language. Don't forget that DHTML includes CSS as well; it would be impossible to implement DHTML menus without the 'visibility' and 'position' CSS attributes. In fact, going the other direction:

    <script language="JavaScript1.5" type="text/javascript"> document.writeln(" Your favorite CSS-compliant code goes here"); </script>
    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.

    Thats why DHTML menus came to be in the first place. Even a couple of years ago, it was impossible to implement a pure CSS menu like the ones you describe. I'm not saying that there is any excuse nowadays for using a DHTML menu, but there is a reason they exist.

      The extra traffic that might be kept by a flashier design will more than make up for the traffic that is lost by a visitor that is using a browser that is too-primitive to view the site.
      You're missing the point. If you treat Javascript as nothing more than form-handling gravvy for those whose browsers support it, and rely on CSS for formatting, and do it right (that is, no tables for layout, H? headers, P and DIV sections formatted using classes, and so on), then, funnily enough (or is it?), low-capability browsers like Lynx suddenly are able to produce a very usable browsing experience. You miss the eyecandy, but you get the content. And that should be a given. I have seen almost no use of Javascript so far that wasn't avoidable.
      Internet Explorer 5.0+ is now used by over 92% (and rising) of the internet populatation.
      Incidentally, IE's CSS support is the most idiosyncratic of all current browsers. I hope they don't keep that sort of market share. Oh, and what about the other 8%? That means 2 in 25 customers - a small, but not insignificant percentile. Can you afford to disgruntle them?
      If you read the article, you'll find that is mostly about not retro-designing for dead, non-CSS supporting browsers (NN4), when the future of web browsers promises to be rich with CSS support.

      I have read the article quite a while ago - but BUU was referring to DHTML, not CSS.

      As far as heavy reliance on CSS and the departure from HTML3.2 design is concerned, you're preaching to the choir - as the last paragraph of my previous node might have indicated. I hate the fact we still have to pay attention to fastidious browsers when using CSS even so many years after the standard was publish. It's a huge shame - the web would look better and be more useable at the same time and also work well for the low-capability browsers as well if CSS was widely and properly supported. We could have our cake and it eat it too. Sigh.

      You're comparing apples to oranges.
      I'm not comparing anything. I was saying that DHTML locks out a small, but very important (and growing) part of your audience, which needn't happen when you can do the same thing with a different technique, and better in many ways to boot.

      Makeshifts last the longest.

        You're missing the point. If you treat Javascript as nothing more than form-handling gravvy for those whose browsers support it, and rely on CSS for formatting, and do it right (that is, no tables for layout, H? headers, P and DIV sections formatted using classes, and so on), then, funnily enough (or is it?), low-capability browsers like Lynx suddenly are able to produce a very usable browsing experience. You miss the eyecandy, but you get the content. And that should be a given. I have seen almost no use of Javascript so far that wasn't avoidable.

        No, I think you are missing the point. I'm simply being the devil's advocate; you seem to be saying to "do it (the right way)/(my), or you're idiotic!"; while I am trying to say that there might be other motivations than conformity with standards when designing a website.

        Incidentally, IE's CSS support is the most idiosyncratic of all current browsers. I hope they don't keep that sort of market share. Oh, and what about the other 8%? That means 2 in 25 customers - a small, but not insignificant percentile. Can you afford to disgruntle them?

        Please give credit where it is due. IE has been one of the leaders in supporing the CSS standards. IE5.0/Mac was even lauded in the web design community for its excellent support for standards. Besides, other browsers besides IE have support for CSS; Netscape 6+, Opera 4+, Konquerer, and Mozilla also have excellent CSS support. The actual baseline should actually be about 97% of browsers supporting a descent amount of standards. Ironically, most of the design at CSS edge is only viewable by these browsers.

        As to your last remark on this topic (about disgruntling customers), the way I see it is like this: You can look at a website like a store. Now, your store can cater to all customers (browsers), which means you can serve 100% of the people out there, or you can limit service to a somewhat higher class crowd (newer browsers). For instance, a restaurant might require a shirt and shoes (CSS/JavaScript compliance) for service. This might mean you lose the business of the swimmers coming back from the beach (users of older browsers), but at the same time it makes for a more comfortable experience for the rest of your customers.

        Which is the way to do the most amount of business? Thats hard to decide. On one hand, you lose some business from the customers you deny, and on the other hand, some customers' confidence might be shattered due to poor appearance and aesthetics.

        I'm not comparing anything. I was saying that DHTML locks out a small, but very important (and growing) part of your audience, which needn't happen when you can do the same thing with a different technique, and better in many ways to boot.

        And growing? Since when do browsers lose support? Are referring to handhelds? I think that the number of new computer users in general is growing at a much faster rate than the users of wireless internet.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://213813]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (8)
As of 2017-12-15 13:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (432 votes). Check out past polls.

    Notices?