View Full Version : What's a practical use for the void operator?

08-23-2004, 05:08 AM
MSDN says:
It is most useful in situations where you want an expression evaluated but do not want the results visible to the remainder of the script.

..and I say: Huh? :confused:

08-23-2004, 06:09 AM
say, for instance, you are invoking the open() method from an anchor. The void() operator cancels the anchors normal behavior--to open a new [standard] browser window--which you want to replace with a custom js window.


08-23-2004, 06:10 AM
msdn is exactly right on this. for example when i want an html link to do nothing i do this:

<a href="javascript:void()">dummy link</a>

that is a basic example of void(). you can also do this

function noReturn(){return "this is text";}
document.write( noReturn() );
document.write( void( noReturn() ) );

that should write out "this is text" only one time.

08-23-2004, 07:47 AM
Thanks, but how is it practical to go: "void function call()"? It seems like that whole line has no purpose.

I was hoping void might be useful with custom objects, or...? I have no clue. :D

08-23-2004, 08:43 AM
Yeah, and I forgot to mention that I'd seen the javascript:void() thing before... but thought to myself: the operator couldn't possibly have been put in JS only to break hrefs.

a n y w a y...

08-23-2004, 10:47 AM
To see the utility of void() try this

<a href="javascript:window.open('popup.html')">link</a>

You will have the surprise to see that after opening the popup, the opener will try also to do a HTML action. From the point of HTML view, the expresion between quotes might be an new window, a new object (IE says [object], Mozilla says even clearer [object Window]) so the browsers will, let's say, "create" a new page emulating it.

To avoid this, void() is a much useful method, so the correct syntax is:
<a href="javascript:void(window.open('popup.html'))">link</a>

08-23-2004, 10:54 AM
Can we get beyond the href example, or is that all we know?

That's ok... it's all I know too. :)

08-23-2004, 11:33 AM
the less known thing is that, in fact void is an operator which can (and it is mostly used) as a function

void statement

(same as typeof or eval which are in fact operators)

No, I don't know any other noticeable use for void() except the href blocking.

08-23-2004, 11:56 AM
I now remember having seen some VBS examples that used void in some way.
Maybe I can convert those to JS for all the wrong reasons... ;)

08-25-2004, 05:45 PM
I take that back... there is no 'void' in VBS!

Willy Duitt
08-25-2004, 05:48 PM
FWIW: void can also be used to remove the value of a variable...

If you have a variable var test = 'test'
You would use test = void to remove the value without having this empty variable return null or undefined...


08-25-2004, 06:06 PM
You can't do that; it generates an error, because void is an operator...

var foo = 1;
alert(typeof(void foo));

returns undefined, but doesn't change foo's type.

Willy Duitt
08-25-2004, 06:07 PM
I said change its value not type....

08-25-2004, 06:36 PM
So are you maintaining that an operator can be assigned to a variable?
I appreciate the suggestion, but that just doesn't happen.

08-25-2004, 06:38 PM
Let's bring a little light on what void does in JavaScript:
- First of all, void is older than the undefined keyword. From the start, using void was the only way you could yield undefined. Later, when functions became first class objects in the language (we're talking about pre-ECMA time here), they also by default returned undefined. (Before that they had returned without a value, which is not quite the same.)
- You might have problems believing it, but in fact void was introduced with a single purpose in mind: cancelling the following of links. Again, this was before the DOM0 event model was set in stone and more consistent methods for doing that was created.
- void is not a function, though some implementations may treat it like that. It's a unary operator, which you may give a unary expression as argument. If this unary expression happens to be a parentesised expression, so be it, but it's still an operator and not a function. (This is of little consequense for void since it acts like a black hole, but consider the sibling operator typeof instead, which acts different from how it would have acted were it a function.)

Of what use is the void keyword?
In the beginning, before the DOM0 event model, it could be useful for yielding undefined to cancel the following of links on webpages. Now, we don't need it for that any longer, we return false in the onclick event handler instead.
Also, if we wanted to explicitly compare a value to undefined we could use void since we had no keyword yielding undefined back then.
Today, the sole place it's sensible to use void is within bookmarklets, since we do not have the event model to replace it's functionality in a pure pseudo-URI.

Willy, have you tried that? Operators are not expressions, and they are not values. You cannot assign an operator to an identifier, it will result in a syntax error.

08-25-2004, 06:50 PM
Thanks for sharing the back-story on that.
...guess i'll stop trying to think of a clever use for something that was not designed to be used for much... :o

Willy Duitt
08-25-2004, 06:54 PM
Willy, have you tried that? Operators are not expressions, and they are not values. You cannot assign an operator to an identifier, it will result in a syntax error.

Although my reference shows assigning a value of void (foo = void)... But no that does not seem to work.. But (void foo) does...

var foo = 1;
alert(void foo);


08-25-2004, 07:47 PM
Yeah, that's a problem with references... half the time, descriptions are so vague that they're practically useless, and sometimes the info is completely wrong--in which case it is worse than nothing. How powerful is a poorly documented feature?

08-25-2004, 08:04 PM
It's not poorly documented, you only need to know what documentation counts. Netscape DevEdge and Microsoft MSDN are very complete and accurate, developer.mozilla somewhat less so. My Opera and Apple Developer Connection are less complete but I've never found them inaccurate for the versions they are supposed to document. Those are absolute references for their respective implementations. ECMA-262 3ed. is a bit technologistic, but is a good absolute reference for the core JavaScript language. W3C XML, CSS and DOM technical reports are absolute references, HTML somewhat less so.

That covers what documentation counts in the client side web development world. Anything else should be considered explanatory or informational only.

08-25-2004, 08:11 PM
I have no problem with the completeness, per se, but the absoluteness should be extended greatly to include both clearer boundaries, and the reasoning behind the implementations (in a perfect world, that is)... I mean, we have to program with that much detail, for the most part.

Languages shape the way we think alright... driving us mad in the process! :thumbsup:

... there, that's better.

08-25-2004, 09:18 PM
ooh, a new maxim:
The devil's in the details, not the documentation.
(or is that an epigram?)

... I digressed :D