The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Can javascript be relied on?

Hi,

I am building my site in php and have found the amazing world of ajax. I have always been weary towards using javascript in the past as I am worried that some browsers won't support it or that users will have turned javascript off.

I now see hundreds and hundreds of sites on the internet which use javascript extensively. Am I living in the past, or should I still be weary of javascript?

The main reason I ask is because I want to use ajax for users to change their password. If javascript is not working on their browser, they will not be able to change their pass.

There are no security issues with Javascript itself as all Javascript has access to is the current web page and other pages from the same site that it either opened, was opened by, or are displayed in other frames.

Javascript itself has minimal access to the browser functionality (all of which can be overridden by the browser owner). The only files it can read and write are cookies. The only other access that it has is to communicate with the server via Ajax. Those security issues that are blamed on Javascript are usually the person having not distinguished between Javascript and ActiveX which Internet Explorer uses with Javascript to create about 600+ security holes in the browser. As IE6 produces warning popups every time you visit a web page with activex disabled to block the security holes but Javascript still enabled many IE6 users turn off Javascript as well simply to get rid of all the stupid popups.

Any security issues relating to using Ajax relate to not implementing proper server side security measures the same as you would use if you were writing it exclusively server side. You can't rely on Javascript to implement the security that your application requires.

the number of users who have javascript disabled floats between 4 and 10&#37;, depending on the month. I'm sure someone will disagree and say that it's not accurate but whatever, lets use those numbers for argument's sake.

A good percentage of those will turn on javascript if confronted with a page that they want to access that requires javascript, and tells that so in a nice non-threatening way.

That is for the general public. In a corporate environment, you may have the luxury of requiring javascript to be turned on for all machines (or off I suppose).

Therefore, if you're coding a corporate system, you can go ahead and use javascript all you want, if it's in the specs. If you're coding a public internet site, you have to figure out if you can live with (a percentage of 4-10%) not bothering with your site because it uses JS, and if not, go ahead and do all the extra work to make it work both ways.

Many web-apps require JavaScript, but there is a big difference between web-apps and normal web pages. The purpose of normal web pages is to provide information to the public, while a web-app's purpose it to allow the user to perform a task.

Many web-apps require JavaScript, but there is a big difference between web-apps and normal web pages. The purpose of normal web pages is to provide information to the public, while a web-app's purpose it to allow the user to perform a task.

Very valid point. I have seen many web apps, such as mail clients which are coded entirely in JavaScript and Ajax. However, you would not want an 'information' site which would not work at all unless your users turned on JavaScript.

This question comes up ever so often - but this one has turned into a great thread. Excellent replies by everyone!

Originally Posted by felgall

Those security issues that are blamed on Javascript are usually the person having not distinguished between Javascript and ActiveX which Internet Explorer uses with Javascript to create about 600+ security holes in the browser. As IE6 produces warning popups every time you visit a web page with activex disabled to block the security holes but Javascript still enabled many IE6 users turn off Javascript as well simply to get rid of all the stupid popups.

EXACTLY!!! Microsoft shoulders much of the blame for users thinking that Javascript is "not safe" - when the real culprit is ActiveX.

Would also like to point out, as a case study, these forums use JavaScipt and Ajax a lot, but I guess that 'we', the targeted users, are the type of people to realise that we need to turn JavaScript on to use this site, so it does not matter that these forums rely on it.

Would also like to point out, as a case study, these forums use JavaScipt and Ajax a lot, but I guess that 'we', the targeted users, are the type of people to realise that we need to turn JavaScript on to use this site, so it does not matter that these forums rely on it.

Well, this forum only uses javascript to add some niceties. It still works perfectly well without it, so I wouldn't say it relies on it.

It is okay to use Javascript on a site as long as the site is still usable for those who don't have Javascript enabled. Best solution is to build the non-Javascript version first and then add the Javascript that enhances the site functionality for those with javascript enabled.

The only types of site that I can think of that can legitimately assume that javascript is enabled are intranets (wher you control the browser configuration as well as the site) and sites where the content is actually about Javascript itself (where obviously people need Javascript enabled in order to see the demo scripts function).

the number of users who have javascript disabled floats between 4 and 10%, depending on the month. I'm sure someone will disagree and say that it's not accurate but whatever, lets use those numbers for argument's sake.

A good percentage of those will turn on javascript if confronted with a page that they want to access that requires javascript, and tells that so in a nice non-threatening way.

That is for the general public. In a corporate environment, you may have the luxury of requiring javascript to be turned on for all machines (or off I suppose).

Therefore, if you're coding a corporate system, you can go ahead and use javascript all you want, if it's in the specs. If you're coding a public internet site, you have to figure out if you can live with (a percentage of 4-10%) not bothering with your site because it uses JS, and if not, go ahead and do all the extra work to make it work both ways.

I think you aren't taking into account the webcrawlers that google, yahoo, msn, and many other search engines are using to mine content. The crawlers don't support frames, javascript, or CSS; they are looking for content. I think that if you take away the "bots", you'll find that there's a very small percentage of internet users with javascript disabled.

What about content generated by javascript? Do the bots 'see' elements created by it, in the same way Firefox's DOM inspector and its View Selection Source do?

Not as far as I know. As a rule of thumb, the bots will follow the href in a link. What I try to do is intercept normal HTML page behavior with JavaScript so if a user has it turned off, they have to wait for page reloads, etc. If they have JS enabled, the page will have the extra "niceties" like Ajax-generated content, etc.

If you make the content *only* available via JavaScript, the design should probably be refactored.

I have just noticed, for example on the sitepoint site, if you turn javascript off, links such as the search link, which normally pops up a little box using javascript, still work, but they link you to the full search page instead.

As you say, javascript should be used to enhance your site, but your site MUST still be accessible with javascript turned off.

MUST is a very strong word. Again, depends on the target audience and what kind of feature the website has. Take the organize sets in Flickr as an example. Or a chat functionality. Everything MUST not require to work with JavaScript off.

MUST is a very strong word. Again, depends on the target audience and what kind of feature the website has. Take the organize sets in Flickr as an example. Or a chat functionality. Everything MUST not require to work with JavaScript off.

Fair enough.

BTW: Is there any way in php to detect if JavaScript is enabled so you can alter your links / display a message as needed?

Or just make the JavaScript unobtrusive in the first place, and use it to either modify or flat out replace existing content.

I think the funniest thing about unobtrusive javascript is that it brings me back to '96 when I wrote my first web "site" (it was really cheesy, but what do you expect when it's your first time?).

My first site, and several sites thereafter, relied on good HTML markup that functioned well from page to page. Even with the advent of PHP and ASP/VBScript, you still needed to make sure everything worked right.

With JavaScript becoming more popular as of late as well as the introduction of a plethora of libraries and helpers, people are suddenly worried about "what if javascript is turned off? Now my site won't' work!". We need to maintain that 90's mentality of building solid websites that function great without javascript (or CSS) - with the painful page reloads and everything - then "dress them up" with javascript to give the users a rich experience.

Of course, that doesn't mean we have to revert back to tables for layout, blockquotes for indentation, etc. It just means that it's important to code each page, template, and widget to be semantically correct and clean (a.k.a. devoid of inline event handlers and tags used to make stuff pretty). It's a lot easier than it sounds, and you'll end up with a much more maintainable code base once you're finished; the only changes you'll probably have to make for site enhancements will be to your .js files instead of your HTML.