Page style:

A Blue Perspective: JavaScript is not the devil's plaything

JavaScript is not the devil's plaything
12 April 2005

JavaScript has only ever played a bit part on the Web. Back in the 90's it was good for making things go whoosh, but it wasn't used for much more than mouseovers and cursor trails. Gradually, however, it has been making itself useful.

Along with the Standards that have made a difference already, browsers have been standardising on JavaScript as well. Lo and behold, JavaScript is now a mature and well designed programming language that 98% of today's browsers implement consistently. But JavaScript still suffers from an image problem.

In many respects, JavaScript is where CSS was about two years ago. Only a handful of people have a handle on its true capabilities, and everyone else is sitting around sceptically judging it with their tainted knowledge, circa 1998. Everything coming out of Google's stable helps to raise the profile of JavaScript, but I think that the natural complexity of a programming language (compared to a simple layout language like CSS) and the usual amounts of obfuscation that appear in Google's code prevent their applications from helping to re-educate developers about JavaScript's capabilities.

Meanwhile, there's still people moaning that everything should degrade gracefully without JavaScript. My problem with this view is that those commenters are still thinking of JavaScript as if it were some half-assed programming language that was built specifically to do rollovers and make pop-ups. They think that HTML uses JavaScript rather than JavaScript using HTML.

I think we are now at a crossroads. JavaScript is now developed enough to offer cross-browser, cross-platform solutions from the same codebase, and this has made it viable to develop large scale applications using it. Given that there is a difference between webpages and applications, and that they have different goals and requirements, it is meaningless to point out that a JavaScript application fails when you disable JavaScript. I could equally point out that Firefox fails when I remove my operating system.

BBEdit isn't accessible to anyone that doesn't use a Mac – that's probably about 20 times more people who can't use BBEdit than JavaScript – and yet Bare Bones Software are doing just fine. It was their decision to code for that platform, to require the Mac operating system to run their software. So why can't we require people to have JavaScript in order to run an application? You're not targeting everyone, you're targeting your market.

It is a separate question entirely to ask whether JavaScript applications are accessible to non-visual users, but one that is still of paramount importance to its future. (Although it wasn't to Flash's.) We will always need companies like Google to push the boundaries of technology, and accessibility tools will always lag behind the bleeding edge.

Inevitably a compromise will have to be reached between what is possible and what is practical, but without the constant tension between the real and the ideal, humans would never have progressed in 10,000 years. As Web technology develops, so must the tools for accessing it.

Note: Before you parrot the "webpages should work without JavaScript" mantra in the comments, read my previous post: "This is not another XMLHttpRequest article"; and understand the difference between a webpage and an application.


1/42. 12 April 2005 @ 04:18, Simon Jessey wrote:

JavaScript is a wonderful thing, but despite what you say I still feel it is important that a website can work without it. I try to build websites on the basis that I have no idea how the content is going to be accessed.

There are plenty of weird and wacky user agents out there that don't understand JavaScript, and I'd like to make sure that they can access my content too. Nevertheless, I like to use both CSS and JavaScript to pretty things up when I can.

2/42. 12 April 2005 @ 04:28, Charles Martin wrote:

I do agree that there are several wacky user agents that just can't handle real programming.  However, the only way to make sure those go by the wayside altogether is to create the need for something better.  This can't happen if we always cater to the "weak-willed" masses who have "always used their user agent and refuse to give it up".

Change is good, but we must push the change.

3/42. 12 April 2005 @ 04:28, Ithika wrote:

I think the opinion outlined above makes two assumption:

  1. People want applications when they use the web. Which, most of the time, they don't. Especially as most web-applications are really IE applications making abusive use of ActiveX and OS-level hooks.
  2. The rest of the web doesn't abuse the user's javascript-enabled browser to change the size of the browser window, pop-up or pop-under images, add itself as the Home page, that kind of thing. Which they all do. Like email would be so much more useful without spam, wishing won't make it go away.

So while it's a nice idea there's a lot more work needs to be done first.

4/42. 12 April 2005 @ 04:34, Rob Mientjes wrote:

I know this one kills all arguments, but it remains true: it depends on audience and goal. Gmail's interface indeed consists of many kilobytes of JavaScript, but it's what we can expect, and I also don't think they're targeting the UNIX text-browser geek.

Simon is right. A normal site should still work (well) without JavaScript, but if it's more of an application, then be sure to aim for your audience.

5/42. 12 April 2005 @ 04:38, Charles Martin wrote:

Just as an emphasis to what I said, many of the PC games that come out today don't run on old 486s.  Why is that?  Games are developed usually using cutting edge hardware and software.  In fact, most software developed these days try to take advantage of what only about 25% of the market actually has in their home or workspace.  This pushes the users to buy updated equipment to meet the needs of the software. 

In fact, we have the bonus right now that, as Cameron stated, 98% of the browsers used already can handle this technology.  So we'll only be ticking off 2% of the users out there while our game developers tell 75% of the users that what they own isn't good enough... and the gamers agree and buy the stuff. 

Let's just convince the 2% to see the light and we'll be into a better age of web development.

6/42. 12 April 2005 @ 04:42, Vincent Grouls wrote:

I think at some point in the future, someone will develop accessible Javascript that is also well documented. Until that day, I will continue spending too much time scouting the internet looking for a simple replacement for 'innerHTML' in Gecko browsers and stuff like that.

As you point out, web sites and web apps are two different things and should be approached as such. I usually depart from plain (X)HTML and build in the Javascript when I am sure I have reached a good level of accessibility. Sure, some things require a Javascript solution and don't degrade gracefully but at least you know you've done your best.

Compare it with how IE treats standards. The design may not look as good but at least you've tried your best (uhuh, right... =D ).

7/42. 12 April 2005 @ 05:49, Mike Purvis wrote:

I liked what you said previously about the difference between apps and pages.

Mis-understanding is definitely Javascript's biggest problem. People (myself included) still approach a web page as a static page, even if it's behind a javascript-login and could be far more.

The main thing is: If the web-app could function without the javascript, it should. But if the entire app depends on it (gmail, gmaps), then dive in head first!

8/42. 12 April 2005 @ 07:27, Kim Siever wrote:

When it comes to making sure websites work without JavaScript, I think what is really important (and what most people argue for) is that basic functionality shouldn't rely solely on JavaScript.

For example, if I don't have JavaScript enable, I should still be able to use the top-level menu in a site's navigation even if the dropdowns don't work. I should be able to click on link even if the desired pop-up doesn't work. And so forth.

9/42. 12 April 2005 @ 09:12, Paul wrote:

A common mistake made when using a visual editor such as Dreamweaver or FrontPage is to put the link within javascript, creating an onclick like that will only work with javascript enabled. This can be bad, since some people disable javascript in their browser preferences.

Another common mistake is to open new windows with designer-specified widths and heights, the lack of scrollbars and disabling the users' abilty to resize the window. This takes all control away from the user, which is confusing for anyone using adaptive technology and frustrating for many users.

10/42. 12 April 2005 @ 09:18, Andrew K. wrote:

The web as a hypertext-based information archive NEEDS graceful degredation -- I'm talking all the way back to nn4.

The web as a software interface is an entirely different story; this is the place where JS can become crucial.

At the end of the day, an interface/usability crime is still a crime regardless of the language used to implement it. Now please excuse me while I go change all my background colours to pink and my text to green ;)

11/42. 12 April 2005 @ 10:26, Chris Fritz wrote:

In a web application I'm working on, the interface is currently completely Javascript.  With projects like Sajax, however, I one day be able to replace the interface with a Javascript interface that falls back onto server-side programming.  The latter would be enough to do all the things the program can do, and the former would do it with speed and style.  Javascript's a minor requirement for it, though, considering the CSS and Javascript for my application break in Internet Explorer 6 complete, requiring Mozilla, Safari, Konqueror, Opera, etc.

12/42. 12 April 2005 @ 13:56, Lachlan Hunt wrote:

When a web application requires JavaScript to function and does not degrade gracefully, you are not necessarily targetting your full target audience. You're only targetting the intersection of users in your target audience and users with JavaScript enabled. The people within your target audience with JavaScript disabled or unsupported are either locked out entirely or annoyed by the fact that a web site is forcing them to alter their settings.

Don't say it doesn't happen, it happens to me all the time when i have JS disabled, and web sites like that annoy me, particularly many of Google's applications which I now avoid for that and many other reasons.

13/42. 12 April 2005 @ 14:32, The Man in Blue wrote:

But if their application is JS only, wouldn't their target market be JS-capable users? Much as any software's requirements (operating system, processor speed, hard disk space) affect its market?

It is a conscious effort to eschew the "one size fits all" mentality of the information Web, and is a totally different model altogether.

What it all boils down to is profit margin. No one creates a (non-open source) application without wanting to create a benefit to themselves, usually monetary. In order to get people to use your application, it is has to do something better, something new. If your JavaScript application contains enough innovation and good features to attract X amount of people and make it profitable, who's to say that it is a failed exercise?

It is a point of differentiation, and commerce is built upon differentiating your product.

14/42. 12 April 2005 @ 15:48, Lachlan Hunt wrote:

> But if their application is JS only, wouldn't their target market be JS-capable users?

No, not necessarily. It depends on the purpose of the application, and in most cases I would say that a user's choice to use javascript or not is in no way related to their desire for the product, service or information provided.

Take, for example, Google Maps. The sole purpose of that is to provide maps, directions, locations, etc. Their target audience is people that require a map for whatever purpose, and IMO, they have not met all of their target audience at all (which I'll cover later). There is no direct correlation between a user in need of a map and a user that likes to use JavaScript.

While an implementation with JavaScript may provide a much better user interface than without, the interface is not what the user is interested in, it is only the means by which they access the product, service or information.

Now, as I said, Google Maps have not met their full target audience needs at all. They have incorrectly assumed that all their users will be using a desktop computer running IE, Firefox, Opera, etc. However, travelling users without access to a desktop computer, but with access to an internet enabled Phone/PDA that does not support JS may still require access to a map.

When such users access google maps, they're essentially told to get lost because they don't have a supported desktop browser (despite the fact, they may already be lost if they're looking for a map :-)).

15/42. 12 April 2005 @ 15:56, Lee wrote:

I have to say I agree.  I avoid using it on my websites because I fear people either not having it, or more likely, switching it off.  But that audience must be tiny, and I'm dealing with web pages.  For applications it would be much more applicable.

I would certainly like to know more about how best to use it (I hear a lot more about it these days), where it excels and some information on how to use it best.

16/42. 12 April 2005 @ 14:32, The Man in Blue wrote:

Re: Lachy (#14):

> Their target audience is people that require a map for whatever purpose

Here you are assuming what Google's intentions are. BBEdit makes a text editor. Their target market should therefore be people who want a text editor. But they have chosen to specialise.

Google's possible market is everyone who wants a map, but their target market could be anything. My point is that the JS-enabled market, with well over 75% coverage, is a valid market to target.

> While an implementation with JavaScript may provide a much better user interface than without, the interface is not what the user is interested in.

I disagree strongly with this statement. MapQuest produce a similar product to GMaps, but over the past few months the GMaps:MapQuest mention ratio has probably been running about 50:1 (it would be interesting to see the site statistics for both). This has largely been due to Google's interface and the way it makes browsing for maps easier. e.g.:

The same can be said of Apple's iPod. It is often a more expensive alternative, when every other brand plays the same MP3s, but its interface and -- even more superficially -- its looks, have carved it a significant niche in the digital player market.

This isn't to say the GMaps will remain JavaScript only. I mentioned in my previous article that it uncomfortably straddles the divide between a task-oriented service and an information service, so that makes it suceptible to the needs of a page-based model.

17/42. 12 April 2005 @ 16:37, Matt wrote:

Let's not forget about this:

Javascript 1.2+: 55112827 (89%)
Javascript <1.2: 172693 (0%)
Javascript false: 5967731 (9%)

10% of the people out there (this is excluding various indexing bots) DO NOT have Javascript turned on.

18/42. 12 April 2005 @ 16:53, The Man in Blue wrote:

Why should 10% of people stop you from making a superior product? Last time I checked, underage people couldn't drink. Doesn't stop Jack Daniels from making a few dollars.

19/42. 12 April 2005 @ 17:00, Matt wrote:

Last time I checked, there were some 14-year-olds in the local park, drunk as hell, but that's not the point ;)

You can't think like that. Worldwide, IE still holds close to 90% of the market. Do we dismiss the other 10% (Opera, FF, Mozilla, Konqueror, Safari, ...) and use proprietary IE stuff? No. In fact, we code for that exact 10%, dismissing IE, because we aim for accessibility and usability.

20/42. 13 April 2005 @ 00:07, cody lindley wrote:

My personal opinion aside, (assume the user is everyone) I have never meet a client/stake holder/business that felt the extra money/time/investment to account for such small percentages of users made any sense what so ever. I've even been laughed at bringing up a silly number like 2 percent, or even 10 percent of odd-ball broswers. If you are reaching 98% of your users with complete functionality, your a rock star to the people footing the bill!

Also, I'm no so sure I agree that functionality should degrade perfectly. Or that a contingency plan should be implemented for every piece of functionality. In the real world, in my opinion, content should degrade perfectly, not the complete functionality.

21/42. 13 April 2005 @ 00:22, Charles Martin wrote:

I agree with Cameron because the possible market and the target market ARE two different things.  For example, I used to read and found that the applications referred to in the articles were Mac only.  Now, these applications had specific capabilities not found in an equivalent Windows application.  Thus, if you feel that you must target the entire audience, why do many developers for Mac/Windows not port their software to other operating systems?  After all, it's easy enough to turn on javascript, but not so easy to purchase two computers with different operating systems to access all of the programs you really want.

22/42. 13 April 2005 @ 00:32, Charles Martin wrote:

Along a similar vein, why is the Javascript issue such a big deal when there are already other sites out there that REQUIRE Macromedia Flash in order to view their content?  Most don't provide an alternative version in just HTML.  They are limiting themselves to only users who are willing to download the plugin for their browsers.

Javascript is no different... yet no one seems to complain about Flash.

23/42. 13 April 2005 @ 00:35, cody lindley wrote:

@Charles - Well said!

24/42. 13 April 2005 @ 03:08, beto wrote:

This obsession with "graceful degradation" is a mixed bag of goods. For starters, regardless of how altruistic the idea of "graceful degrading" is by not leaving anyone behind simply because some given user can't (or won't) run Javascript, truth is that can only take you so far as interactivity offerings are concerned. Non-Javascript users were a big concern back in 1996. But what about now?

Just take a look at Gmail, Yahoo's multi-categorized search bar, and Google Maps. Everyone is loving the instant, on-the-fly performance that Ajax offers, and it won't be long before these features begin to be demanded by clients on their sites and web applications. On the client side, Javascript is what makes most of this possible. How could this be expected to work otherwise?

For what I have seen on my non-scientific analysis of experience, most casual web users couldn't care less -or understand- whether Javascript is on or off on their browsers. Most have it on by default, and those who don't, they have it so consciously (and know what to do)

However, I share the opinion that critical site components such as navigation should not rely solely on Javascript. CSS already allows you to create navigation styles and effects with HTML lists that required JS in the past, without leaving any users of lesser browsers out in the cold. But as the barrier between web site and web application blurs even further, I think it is about time to reconsider Javascript functionality and give it the attention it deserves.

25/42. 15 April 2005 @ 07:14, Adam Michela wrote:

26/42. -1 @ 0

Eh, I don't agree.

I'm a full time JavaScript developer (9-5), have been for sometime, and I have nothing but respect and love for the language.

Nevertheless, I feel like a professional application should still WORK without JavaScript.

"Why should 10% of people stop you from making a superior product?"

They shouldn't. But it's not difficult to add alot of very useful JavaScript while still developing your application to WORK for those people too (albeit not as niftily).

Why not take the extra step?

You've made efforts to design your XHTML and your CSS to be accessible, why not your JavaScript as well?

Granted, there will always be exceptions to this rule. However, for the vast majority of very cool things we see being done with JavaScript right now, it all can degrade gracefully with minimal effort.

:0, wrote:

27/42. 16 April 2005 @ 08:56, patrick h. lauke wrote:

"You're not targeting everyone, you're targeting your market."

of course it all depends on your target audience. fact is, though, that if there is any chance that this includes users with disabilities, you must take either degradation of offering alternatives into account. simply saying "blind users won't go to my site" won't hold much weight if your site falls under the remit of legislation such as the UK's Disability Discrimination Act.

28/42. 16 April 2005 @ 23:47, The Man in Blue wrote:

Although I'm no expert on accessibility legislation, and I specifically stated my accessibility concerns in the entry, I think that there is a strong case that could be argued (legally) rejecting the claim that someone couldn't use JavaScript due to a disability.

In the UK the relevant legislation states that "service providers have had to consider making reasonable adjustments to the way they deliver their services so that disabled people can use them".

The question is whether a JavaScript application of the type of which I speak (whose functionality is inherently tied to JS i.e. it would be difficult to replicate in only HTML) could be "reasonably adjusted" to enable delivery to disabled people who are unable to access it.

This isn't to say that I would recommend locking out disabled people, it is merely a note about relying upon legislative measures to enforce it.

29/42. 17 April 2005 @ 21:58, patrick h. lauke wrote:

"I think that there is a strong case that could be argued (legally) rejecting the claim that someone couldn't use JavaScript due to a disability."

for one, screenreaders are not notified - and hence do not flag up to the user - when page content is dynamically/programmatically changed. any ajax-type functionality simply happens without those users knowing. obviously, the same holds for users relying on text-only browsers
yes, you could take the "it's a user agent issue, so it's their problem" stance, but right here and now, i don't think it would stand up in a court of law if it ever came to it..

additional consideration should also be taken with regards to device independence: yes, you can use javascript, but make sure that (depending on the situation, of course) it does not rely solely on the use of a mouse / pointing device, but provides reasonable keyboard access.

of course, if the application is an inherently visual, interactive one (e.g. the google maps type scenario), you could probably argue that this is not an issue. but the danger is that javascript-only functionality will be implemented even in situations where it can't reasonably be argued that only sighted users will take advantage of it. but beyond those edge cases (where nobody would argue, say, that you're in the wrong because a blind user can't access your purely visual application - e.g. an image cropping tool or similar), i can't think of a web app scenario where you couldn't provide a reasonable fallback, possibly breaking down what would be a single-page, dynamic process into a multi-page, step by step process with a few additional roundtrips to the server.

30/42. 18 April 2005 @ 02:31, The Man in Blue wrote:

> For one, screenreaders are not notified - and hence do not flag up to the user - when page content is dynamically/programmatically changed.

Much to my surprise (as I assumed it would totally fail), when I asked a JAWS user how it handled JavaScript page changes, he said:

Jaws seems to catch some changes and not others. I don't know what triggers Jaws to refresh its virtual view of the page, but sometimes changes are not caught until I manually refresh Jaws' internal view.  My guess is that Jaws will refresh its virtual view if one of the elements in the tab order changes.  Generally, elements with onclick handers aren't tabbable and so changes to one of those elements won't necesarily trigger a jaws refresh. However, I've seen circumstances where it did cause a refresh...  If I put an onclick on a heading element, jaws always seems to catch the changes made when it is clicked.

So obviously a much more rigourous set of tests is required in order to see whether JS pages can be adapted to be accessible (in Jaws, at any rate).

Aprt from that, hopefully the Jaws developers will play catch up to modern practices and make it easier to produce accessible JS applicaitons.

31/42. 18 April 2005 @ 10:41, Jerome wrote:

I always surf the web with JavaScript (and Java) turned off to minimize threats from malicious, inconsiderate, and snoopy web sites. I know this puts me in a small minority, but it also gives me minority benefits: I don't have problems with spyware or pop-ups. Not even when using IE.

Web sites that needlessly require JavaScript annoy me to no end. Sites that require JS for good reason (e.g., Google Maps) tend to lose my traffic to those that can work without (MapQuest).

Here's why you shouldn't require JS if at all possible: to enable safe surfing by those who know how.

JS and anything else that runs client-side will have security holes that will be exploited. Look at the holes patched in FireFox 1.0.3. Almost every one has this workaround: disable JavaScript.

Don't think that the browser-writers will eventually find all the holes. *There will always be bugs and exploits.* Have you seen any let-up in the rate of critical patches from Microsoft? Do you think they would leave the browser implementation alone forever if they did patch all the holes? (They tried to leave IE6 alone, didn't they? But market forces called for change.)

Running code server-side and returning plain (X)HTML is much safer for the browser. Not bulletproof, but much safer.

You might say, "But I'm not putting exploits in *my* Javascript." That's great, but if many sites don't work without JS people will be inclined to leave it on all the time (which they do already, because it's on by default and they don't know any better). Users need to be educated not to enable client-side script by default (or, better, browsers need to leave it off by default), and web designers need to learn how to do things w/o client-side code. The spyware epidemic would not be what it is if users turned off client-side scripting.

Almost no application on the web absolutely needs JS. If you think yours does, think again--you've probably missed something. Go ahead and add JS as an enhancement if you want (Google Maps obviously is more convenient with JavaScript than a non-JS version would be), but don't require it. Let users make their own choices regarding risk versus convenience.

32/42. 26 April 2005 @ 03:43, Charles Martin wrote:

It sounds like you would rather see Javascript go away completely rather than take any chances on spyware/malware.  So why don't we then eliminate the browser altogether so that there is no chance of exploits from other means... Oh wait, let's just shut off the Internet because not every single user out there is aware of the dangers.

The only way for Javascript to improve and for exploits to be eliminated is for it to be used to its fullest potential to find them.  We can't sit back and just eliminate everything that might cause problems because someone is always finding a way to exploit them.  Otherwise, there is no growth... there is no innovation... there is no internet.

33/42. 28 April 2005 @ 03:21, Zach wrote:

I think the person who brought up the Mac/Windows software hit it on the head.

Who ever said that you, as a developer, had to target everybody?  Nobody gets in a huff when they can not install Visual Studio on linux, or some great Mac Graphics program one Windows. Why? 

Where is all the anger and frustration that I see from those on the web over browser issues?

I personally make a choice to do something IE only, out of lack of time to learn the differences in Moz partially (though I do try, and say screw it after I have spent twice as long on not getting it to work in Moz as I did getting it to work in IE to start with - that problem is me, I have no problem admitting it) - but ALSO I do things that is in no way, shape, or form gonna work in Mozilla.  I have gotten htc's to work, I have gotten many things to work in Moz that normally natively can not - but somethings I do - in some webpages, do not work in Mozilla - for instance - - and never will unless I can dream up something that doesnt exist to make the page behave exactly how I want it to.

And yes, most users have windows, and they have IE on their computer - I am not bending over backwards to make a page that does not act the way I want it to, when for the majority of those its their choice to use a different product than what will allow my product to work.  And the security issues are at worse even now between IE SP2 and Moz, and with IE7 beta coming out soon, I expect that IE will move ahead of Moz (and IE7 in Longhorn is "supposedly" much more secure due the OS structure). 

And all that said, I have no problems with Mozilla, use it from time to time when I have a need to, and prefer it much more over any Microsoft things to use to debug JS (that works to being with in it :)) - but, I know that in ten years, IE is still going to be here - if you would have said in 1996 that Netscape was going to be a thing of the past, nobody would have believed you - that in mind, I have no clue if Mozilla will have anything more than a marginal market again after IE7 comes out in full force, let alone what their status will be in ten years - so I also consider that when I am doing things that work in IE only, I know that that it will still be working in IE years from now.

34/42. 28 April 2005 @ 19:42, Mark wrote:

Opera 8 is here and i really believe that this browser will save the day

35/42. 30 April 2005 @ 07:32, Jerome wrote:

You just made a classic straw man argument.

I didn't say that JS should be eliminated to avoid risks. Read my previous comment again, particularly the last paragraph. I'm arguing in favor of giving users choice and encouraging good security practices.

Before going any further, I should point out that the whole reason I'm reading this blog is because I do a fair amount of web development and am quite keen on web standards, semantic markup, usability, aesthetically pleasing design, and so on. It just happens that I also have a background in software development and internet security.

Exploits are never going to be eliminated. That's tantamount to saying that the web browser is going to be bug free some day. Ain't gonna happen. Not with current technologies, anyway.

The problem with JS, Java, ActiveX, and any other client-side program code is that it runs client-side. Every time you visit a web site with JS, you are running somebody's program on your machine. That program is controlling your machine.

I'm sure you're sophisticated enough to know not to run programs downloaded from dodgy web sites or sent to you in email. (Unfortunately, many people aren't even *that* clueful.) You don't hand over control of your machine to strangers who might have wicked intentions. Instead, you only run programs from reputable companies, essentially trusting them not to do anything too awful.

JavaScript and Java programs run automatically, however--often without the user's knowledge. If you have them enabled, just going to a web site makes them run. They're supposed to run in a safe "sandbox", but that sandbox has (and will always have) holes. Sometimes only the "bad guys" will know about the holes. Quite often users don't patch their browsers even when the holes are found and fixed. Sticking to reputable web sites can help, but malicious JS can still get to people through domain name typos, advertising networks, cross-site scripting, and other methods.

In short, you are significantly increasing your risks by surfing with JS enabled. Ideally, users should surf with JS disabled by default, they should enable it only for reputable sites, and web designers/programmers should respect users who leave JS disabled.

Many (if not most) JS dependencies are the result of developer ignorance, not necessity. Ignorance of techniques (e.g., HTTP redirects versus JS redirects) and ignorance of basic security principles (e.g., running with least privilege).

36/42. 11 May 2005 @ 22:58, Stephane Deschamps ( wrote:

@Rob: On the other hand, even gmail now provides a non-JS version.

Maybe this shows that even with a web application some concern is given to disabled people.

The whole Ajax stunt seduces me a lot at the moment, but the one thing it doesn't work well with is a voice synthetiser (JAWS for instance), and this is what prevents me from introducing it to my clients for the moment.

37/42. 13 May 2005 @ 02:42, Charles Martin wrote:


Let me point out the following statements you made:

Almost no application on the web absolutely needs JS. If you think yours does, think again--you've probably missed something.

If the client requires it, then it's required.  No ifs, ands, or buts.  I've worked in an environment where the way it was initially coded required use of Javascript.  Validation of form input prior to submission of the data via HTTP requires Javascript.  The client was reducing bandwidth usage as much as possible and there was no other way to get around the requirement "form input must be validated before submission to our servers".

Thus, there are applications that require Javascript.  Pure and simple.  Just because the client chooses to require something on the part of the user doesn't make me the bad guy.

As for my "straw-man" argument, it still stands.  Why require a user to go to a website to order something online if they choose to not use something insecure as the internet?  Yet we do it all the time.  "Check out my website"  "Go online and order there"  "No we don't have a support number, use our online tech support forum".  There are users who won't be your customers because they choose to not take the chance on their computers being hacked due to a bad browser security model.  Yet we still develop websites.

38/42. 21 May 2005 @ 13:53, Zach wrote:

What I honestly do not understand is why on earth does something have to be exactly the same on the net for every product?

Why should Mozilla keep making a browser, if its nothing more than an exact by the book standards browser, and say Opera and IE in the future are exact by the book browsers?

Seems to me at that point - you guys are begging for a complete monopoly - not by one company - but by a pseudo standards group.

What if IE was compelte standards from day one?  What then?

Right off the top of my head - no such thing as the :hover attribute exists.

We better hope to god that IE keeps doing things different - Opera is commited to standards, Mozilla has no real need to develope new proprietory things since its not profit driven, and is commited to standards - if IE went that route - and did what so many scream they want - browser inovation would die.

And on the comment about js and such running on your computer above, running their programs on your computer - dude - take that away and nobody is getting on line. - why would you? People want interaction, they want it now - they dont want to go to ESPN and have to refresh the page to see what the score is on the ESPN "as live as you can keep  up with refreshes" Game Tracker.

I honestly despise that way of thinking.  There is nothing different from Web Programming and Desktop Programming - both can be used for whatever purpose the author intended, be it good or bad - you as a human with common sense has to to know when to trust and when not to trust - when to open up that exe, go to that website, and when not to.  That kind of thinking is sad because what it really means is that you are hijacked worse than the guy with coolwebsearch on his system - you are hijacked by what you dont have and by god will lock up your computer to the point of uselessness just to make sure you dont get something that any one of a number of tools will get rid of as fast you get it.

39/42. 25 May 2005 @ 12:41, Jerome wrote:

At the risk of beating a dead horse on an old thread, I'm going to respond one more time.


You said:
If the client requires it, then it's required.  No ifs, ands, or buts.

Maybe, but then again clients often request things that are not good for them. That's when you, as a good designer, need to guide them onto the right path if possible.

Validation of form input prior to submission of the data via HTTP requires Javascript.  The client was reducing bandwidth usage as much as possible and there was no other way to get around the requirement "form input must be validated before submission to our servers"

1. Did I ever say that pages should not use JavaScript? No. I said they should not require JavaScript. They should not depend upon it. Optional client-side validation is fine and dandy.

2. If the company required you to validate only at the client and not the server also, they are idiots. You must validate on the server side, or you have just created major security holes that will cost the company dearly. One of the problems with the pro-JavaScript mentality is that it encourages designers to think that it is sufficient for validation. They think, "Oh, we'll just require that users have JavaScript enabled." Ignoramouses. Requiring JavaScript in the browser just causes problems for legitimate users, and evil-doers can easily bypass it. I watch for people who make this mistake (which is most people) when I do job interviews, as it really separates the wannabes from the people who know their stuff.

As for my "straw-man" argument, it still stands.

A straw man fallacy is when you attack a position that your opponent did not take. Yes, your argument would stand up pretty well if I were proposing that people should not use JavaScript. Too bad I wasn't actually saying that.


You said:
And on the comment about js and such running on your computer above, running their programs on your computer - dude - take that away and nobody is getting on line. - why would you? People want interaction, they want it now...

For the love of Pete and all that is holy, I said that JS should not be REQUIRED. You should GIVE THE USER THE CHOICE, just as they have a choice of browsers and operating systems. Is that so hard to understand?

There is nothing different from Web Programming and Desktop Programming ... you as a human with common sense has to to know when to trust and when not to trust ... you are hijacked by what you dont have and by god will lock up your computer to the point of uselessness just to make sure you dont get something that any one of a number of tools will get rid of as fast you get it

These statements show me that you are dangerously ignorant of (a) web programming, (b) internet security, and (c) human nature. Unfortunately, I can also see that saying so is useless because you're so ignorant that you won't believe that you're ignorant. All I can do is beg you to briefly entertain the thought that you might be missing a few things and then to check out a few links:

40/42. 5 November 2005 @ 05:16, Tony wrote:


According to your argument, Microsoft should design XP to run on my AT with 1MB RAM and a 20MB hard drive. I should not be REQUIRED to have a pentium-class computer just to use the latest version of Office. I should have the CHOICE of running it on a machine with less capabilities.

Or, perhaps the Safari developers should be called to task for REQUIRING OSX, and not making their program run on XP, or Linux?

In business, there is a cost-benefit decision that has to be made. Is it WORTH the time & money to make a site/application degrade in order to reach a small portion of the market?

No matter what you may believe, sometimes the answer is "no".

As far as railing on Google and saying that you won't use google maps because it REQUIRES Javascript - do you really think Google cares?

I'll go ahead and require Javascript in my web apps. You keep on writing for those without Javascript. In the meantime, I'll appeal to 90% of the market, and I will be happy to yield the remaining 10% to you.

41/42. 9 January 2006 @ 07:02, dna wrote:

Hi all,

I love Javascript and I for feel that JS is underrated. The transition between JS and C is so close that JS might as well be a full blown programming language that uses a web browser as its platform rather then a piece of HW. The concepts behind JS should have revolutionised the web however having a scriptable,JIT language thats powerful enough to write true applications with has gone beyond what most people are capable of understanding in its true form. I hope that JS will evolve in the future and become the great web language that it should rightly be.


Please check out my site to see how JS can do more than just rollovers and mouse pointers.





42/42. 25 January 2006 @ 03:29, ccsaxton wrote:

If you are writing a website that is more content than application then use CSS and allow it to be viewed using whatever browser...If you are writing a web application then use javascript all in!!!

If people are that paranoid that javascript is going to take over their house and family then go and see a  psychiatrist!

I for one think that it is a waste of time to write degrading code depending on the browser...decide what the web page needs to do and then use javascript or not...I popup a message telling users to turn on javascript if it is not enabled when I require it on certain pages and I don't find that a bad thing...if they can't be bothered to use an application that requires javascript then who cares!!!

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.