That’s why I quite like the unobtrusive method… sometimes known as progressive enhancement…

http://onlinetools.org/articles/unobtrusivejavascript/

NOTE: Anyone reading that article should perhaps not pay that much attention to the specific examples… but the theory is spot on.

At the end of the day… if it works well in standard HTML, then keep it that way.

One thing I have found with screen readers, if the user requests to follow a standard HTML link, the new page will load and start being processed… but if its done with JavaScript, most of the time, the JavaScript will trigger, but the screen reader will sit there and do nothing… the user has to wait, as they might think that the new page is taking a while to load, but eventually they will have to investigate on what has happened.

I once did a website which hi-jacked all links, whereby it replaced the page content, instead of reloading the whole page, the result… a disaster… the back button was broken, users could not copy links to specific pages, the page loaded in a strange way (middle bit changed, which freaked out some users)… the alternative, without JS, seemed to load just as quick… so why bother?

But that was a bad example… there are many other examples which are useful… for example a hidden block of text (like the terms and conditions for a competition) which is displayed on request…

http://www.craigfrancis.co.uk/features/code/jsLinkedWidget/

But the reason why I started this site is that I saw more and more advantages in using javascript. It makes my applications faster, cleaner and more user-friendly.

But there’s also hundreds of reason not to use it…

Fair enough… I’m sure that its valuable if you are doing allot of work in JavaScript.

Personally I tend to keep the JavaScript usage to a minimum, as I find that most websites I build only need the odd little helper script.

But its handy knowing as many different methods as possible… you never know what the next project might bring.

Thanks

An example? If I have a list of contacts, every contact should be a different instance of a class. This way, they share their methods and properties and take less memory.

With your technique, it creates a global variable and these variable can be really difficult to track. But I have to admit that I used your technique myself a lot before switching to the new one.

I’d say that even if you don’t need multiple instances, you should encapsulate (when possible) your functions in class. It won’t change nothing to javascript but it will be easier to maintain.

Thanks!

While you are correct about not being able to create multiple instances… I have not been in a position where I need to have this feature. Typically it is only being used to help create a single name space for the code.

Have you got any examples where multiple instances are useful?

As to the memory requirements… I take this is related to having multiple instances of the main object (a copy)… in which case, I still don’t think this is an issue for me, as I only have one instance of each object.

First, you can’t create more than one instance of an object because you are directly assigning the class to a variable.

Second, because you are not using prototypes, it uses more memory because each instance of a class will have its own method instead of using a reference to a single method.

Take a look at to see how I do it (might not be the best way) : http://www.javascriptkata.com/2007/03/23/how-to-create-objects-in-object-oriented-javascript/

Thanks for your comment!